OBJE, object information and folder properties (media library)

[mrAceT]

I am working on a genealogy application in combination with a media library.

To make the whole system and the data 'durable' I naturally am relying on GEDCOM for the genealogy part.

The part for the media is a bit more tricky. EXIF / IPTC information is being red into the database,. The original plan was to sync / store the data back into EXIF / IPTC. But for exchanging / backing up data I am now taking a serious look at GEDCOM7.

OBJE
As to the image data I can link the OBJE-SOUR-AUTH to the creator of the image, but I fear I need to "abuse" that file to add the owner.. I would have loved a OBJE-SOUR-OWN property. It would also be great if an OBJE could also contain the COPR property.
The author, owner and copyright of media objects is something that is quite important and deserves a spot in the GEDCOM7 structure, does it not?

Additionally I was surprised that OBJE and/or OBJE-FILE did not have a DATE, nor a ADDR property, or am I misreading something?

AD: looking at TITL, there it is noted as being part of super structure OBJE but not vice versa? (no link back as a substructure?)

Also, it would be nice if one could not only add LATI/LONG information, but also 'heading' (HDG?) 'pitch' (PTH?),'roll' (ROLL?) and 'horizontal angle of view' (HAOV?). And a "importance score" ranging from 1 to 8 would be nice too (based upon the IPTC value 'priority' 2#010)

I will need to add them myself I think? (nicely preceded with a '_')

FOLDERS (path)
But there is a point I am having trouble with as to where to put the data linked to folders.. This (now) mostly contains a date range and general (and/or default) information of the photo's / media in that folder. I thought about "abusing" the SNOTE property for that, but that doesn't feel right.

I could link an OBJE to a "folder file" but the FORM attribute does not allow the type "folder" (does it?) .
Maybe ending the FILE with a 'slash' and use "multipart/related" as TYPE is the best way to go?

Your thoughts will be much appreciated.

[dthaler]

Discussion in GEDCOM Steering Committee 8 FEB 2024:

• We agree that EXID metadata like time and place would be helpful to store in GEDCOM.
• One imperfect place the date and place could be stored now is in a source record that points to the multimedia record. The source record holds the date and place in SOUR.DATA.EVEN.DATE and SOUR.DATA.EVEN.PLAC.
• Using an extension would also be appropriate, and this could be considered for future GEDCOM standardization.
• IPTC already have URIs defined that could be used when defining the extension's types.

regarding "looking at TITL, there it is noted as being part of super structure OBJE but not vice versa? (no link back as a substructure?)"

• It is linked back from the OBJE substructure: https://github.com/FamilySearch/GEDCOM/blob/9cb7a678d4db98f53480c5afa8946bf2b45ae166/extracted-files/tags/OBJE (this is different from the OBJE record that you linked to, and has a different URI that is not linked in the TITL file)

FOLDERS (path)
But there is a point I am having trouble with as to where to put the data linked to folders.. This (now) mostly contains a date range and general (and/or default) information of the photo's / media in that folder. I thought about "abusing" the SNOTE property for that, but that doesn't feel right.

I could link an OBJE to a "folder file" but the FORM attribute does not allow the type "folder" (does it?) .
Maybe ending the FILE with a 'slash' and use "multipart/related" as TYPE is the best way to go?

Your thoughts will be much appreciated.

• You are correct that a MULTIMEDIA_OBJECT cannot be a folder or other organizational structure (album, directory, filesystem, flash drive, whatever), but it could be a file containing other files, such as a zip file.
• There's no perfect place to store common metadata today in the standard. One could create an extension record for this information. An SNOTE as you suggest is not an unreasonable workaround.