Should we also be exploring a variant of the GEDCOM7 tag “EXID” that relaces AFN, RFN, RIN in 5.5.1? The spec call for it to hold the URI of the authority for the identifier in the EXID.type payload
Of course, these EXID.types are intended for the standard public online genealogy databases: FamilySearch, WikiTree, FindAGrave and so forth. But it seems like the approach could be adapted to a LOCAL file or JSON Note embedded in the Tree database for private UUIDs.
Given the prevalence of linkrot over a 20 year period, I have very serious misgivings about the sustainability of the proposed URL approach. There is a lot of risk in creating an external dependency.
But couldn’t the URI for that EXID.type payload also be stoed as a GRAMPS:// with an internal handle to a Note of JSON type? Which could include a fallback to an external URL? In addition, there could be an interface to write the content of the JSON Note that described the particular UUID system.
One of the spots where the spec seems to fall short is in providing a direct access URL for the online database. The JSON for the FindAGrave includes a URL for their cemetery search webform: https://www.findagrave.com/cemetery . But it could have a placeholder pattern that leverages the EXID value: https://www.findagrave.com/cemetery/[EXID.value] so that FindAGrave Cemetery EXID.value 181852 would substitute the value into the URL to find https://www.findagrave.com/cemetery/181852