Oh sorry @Nick-Hall, I misread your comment, you are right 
But do you agree that using an attribute with an agreed upon attribute type is the best solution for the moment (6.0)? What about the default AttributeType.ID? Is that meant for something else? Perhaps to avoid collision with other existing uses, and to be able to use it also with SrcAttributeType, we can just use a custom type "UID"?
The WebSearch addon by @Urchello is using an expansive set of custom types for UIDs… one for each.
The vast number of online databases creates an unmanageable and unsorted list of custom types. However, the values for the EXID are very cleanly displayed.
(It might be more correctly termed an EXID. I do not grasp the distinction between UID and EXID yet.)
The data is getting very messy. Perhaps a better solution should be discussed?
1 Like
Also, the PlaceCleanup addon Gramplet (and its predecessor GeoName addon gramplet) takes the approach of using a prefixed GeoName Gazetteer EXID to overwriting the GrampsID. This approach becomes a bit fragile with the Merge. And is probably problematic for the GrampsWeb Sync too.
If EXIDs are added to the Place data model, should the GeoNames and GetGOV addons switchover? And how would the outdated data be migrated?
My question was about UIDs, not EXIDs, which is indeed a whole different story (but good to know the WebSearch addon has already defined some conventions for them).
2 Likes
Using UID for all records (INDI, FAM, SOUR,…) already now helps to identify those records in different databases (after data exchange and merge operations). There is a good idea in the GEDCOM standardization forum to maybe replace the GEDCOM record ID (XREF) by UID in the future.
EXID is a different topic.
_GOV tags are used to reference the GOV gazeteer. You can replace that custom GEDCOM tag by the standard GEDCOM 7 tag EXID.
1 Like
In my opninion that doesn’t make sense, I see XREFs more like Gramps IDs, short and memorable identifiers of an object in a database that may change.
I’ll go with a custom attribute type "UID" for UIDs for now.
Would it make sense to include a leading underscore to differentiate these from more traditional uses of attributes?
Perhaps if the Custom Type list for Attributes was sorted in the menu and underscores sorted to top. Right now, the menu seems to be in order of creation.
Without sorting (or user controlled re‐ordering) or filtering, does a leading underscore matter?
I feel “UID” is a perfectly legitimate name for a custom attribute. The underscored version was used informally in older versions of GEDCOM, but in version 7 it is used without underscore, so I wouldn’t use one either.
I agree. There is no problem using “UID” as a custom attribute name.
The idea of a prefix was so that we could identify certain attributes. This would allow us to filter them as @emyoulation suggested. The prefix doesn’t have to be an underscore. Think of it as something like the “.” in a Linux file system for example.
We could even consider using new pre-defined items. I’m really just throwing out some ideas for discussion.
1 Like