When Gramps starts embedding UUIDs in GEDCOM7

Development
1

I recall seeing discussions about supporting Ancestry, FamilySearch and WikiTree UUIDs when importing GEDCOM7 files in the future.

But how should Gramps record identifiers be exported to maximize persistence of value in matching?

The ID doesn’t even survive an import. If the person you gave a .gpkg file has different leading zero preferences, Gramps will make a cursory effort to preserve the significant digits. But even then it re‐write the IDs with the preference pattern. And if that is in use, it just uses the next avaiable auot-assigned number.

So, should the UUID be a multi-value ID? Have the originating database ID, the handle AND the Gramps ID?

2

See the IDENTIFIER_STRUCTURE in the Gedcom specification for details.

3
4

Page 47
IDENTIFIER_STRUCTURE :=

[
n REFN <Special>          {1:1} g7:REFN
   +1 TYPE <Text>         {0:1} g7:TYPE
|
n UID <Special>           {1:1} g7:UID
|
n EXID <Special>          {1:1} g7:EXID
   +1 TYPE <Special>      {0:1} g7:EXID-TYPE
]

Each of these provides an identifier for a structure or its subject, and each is different in purpose:

  • REFN (p.82) is a user-generated identifier for a structure.
  • UID (p.91) is a globally-unique identifier for a structure.
  • EXID is an identifier maintained by an external authority that applies to the subject of the structure

I don’t think that this addresses the question.

There are guideliness for the IDENTIFIER_STRUCTURE in GEDCOM. But it does not suggest how Gramps would make this more effective for its own needs.

Since GrampsIDs are not “world tree” UUIDs, we would need some extra disambiguating to help determine if they are the same records during import and export. Some discussion would helpful since Gramps does not respect the Gramps ID (or even the internal Handles) during the Import process. So we need to work toward better handshaking.

This line of thought was inspired by @Urchello 's question about uploading GEDCOMs to WikiTree and FamilySearch. (I omit Ancestry because I have zero experience with that service.) WikiTree has a GEDmatch utilitiy. So I was going to ask their help how GEDmatch tags known matches… thinking we might conform to their system and ease that work. But then I double-checked our systems and realized we lacked any way to persistently identify merge (or cross-reference) candidates.

If such a capability is to ever evolve, then any UUID would need to include enough information to disambiguate Gramps records. Perhaps it should the export for Gramps GEDCOM7 will need a 3 part UUID? One that includes the GrampsID, the record handle and the database handle

1 Like
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.