# When Gramps starts embedding UUIDs in GEDCOM7

**URL:** <https://gramps.discourse.group/t/when-gramps-starts-embedding-uuids-in-gedcom7/6277>\
**Category:** Development\
**Tags:** uuid, gedcom7\
**Created:** [October 19, 2024, 9:48pm UTC](https://gramps.discourse.group/t/when-gramps-starts-embedding-uuids-in-gedcom7/6277 "2024-10-19T21:48:44Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\
**Post date:** [October 19, 2024, 9:48pm UTC](https://gramps.discourse.group/t/when-gramps-starts-embedding-uuids-in-gedcom7/6277/1 "2024-10-19T21:48:44Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Nick-Hall](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/nick-hall/32/95_2.png) [@Nick-Hall](https://gramps.discourse.group/u/Nick-Hall)\
**Post date:** [October 19, 2024, 11:01pm UTC](https://gramps.discourse.group/t/when-gramps-starts-embedding-uuids-in-gedcom7/6277/2 "2024-10-19T23:01:27Z")

</div>

See the IDENTIFIER\_STRUCTURE in the Gedcom specification for details.

---

<div class="post-metadata">

**Author:** ![anon44746896](https://avatars.discourse-cdn.com/v4/letter/a/e99b99/32.png) [@anon44746896](https://gramps.discourse.group/u/anon44746896)\
**Post date:** [October 19, 2024, 11:21pm UTC](https://gramps.discourse.group/t/when-gramps-starts-embedding-uuids-in-gedcom7/6277/3 "2024-10-19T23:21:24Z")

</div>

> [@Was the Gedcom7 IDENTIFIER\_STRUCTURE extended into Gramps 5.2?](https://gramps.discourse.group/t/was-the-gedcom7-identifier-structure-extended-into-gramps-5-2/4355):
>
> Did this extension of the Data Model make it into 5.2? [A user noted “thousands of error Notes” on his GEDCOM import.](https://gramps.discourse.group/t/mixed-up-notes-after-gedcom-import/4353) There can be no doubt that many of these were related to the UUID for his particular dialect of GEDCOM. 2 tweaks to the GEDCOM import might eliminate thousands of Error notes and the objection to the Notes. have a list of custom ID tags in various dialects (preferably with some defaults but also with a TSV or CSV file in the User Directory that a user could edit) where those c…

---

<div class="post-metadata">

**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\
**Post date:** [October 21, 2024, 5:06pm UTC](https://gramps.discourse.group/t/when-gramps-starts-embedding-uuids-in-gedcom7/6277/4 "2024-10-21T17:06:06Z")

</div>

> [@Nick-Hall](#):
>
> See the [IDENTIFIER\_STRUCTURE](https://gedcom.io/specifications/FamilySearchGEDCOMv7.pdf#IDENTIFIER_STRUCTURE) in the Gedcom specification for details.

> Page 47  
> IDENTIFIER\_STRUCTURE :=

```python
[
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

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/gramps/original/1X/2ac1e712b7adf612e31ca08a55419f4cf37c0158.png) [@system](https://gramps.discourse.group/u/system)\
**Post date:** [November 20, 2024, 5:06pm UTC](https://gramps.discourse.group/t/when-gramps-starts-embedding-uuids-in-gedcom7/6277/5 "2024-11-20T17:06:36Z")

</div>

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