* GEDCOM Universally Unique Identifier (UUID)

[NickWalker]

However, merging two different individuals (even if they represent the same historical person) into one is potentially more complicated. However, merging doesn't require that both UUIDs are retained as far as I can tell, so perhaps GEDCOM 7 compliant apps will give the choice of discarding the superfluous UUID in order to retain identity, or keep both and so create a third person that is not identical to either of the two originals.

The point of keeping all the UIDs is to keep the change history. So if someone you've shared the file with in the past, merges your data again at a later date their software would be able to identify the matching individuals. So generating a new UID following a merger would then lose that advantage. I can see this being useful if you're regularly sharing data with a small number of researchers as the software will very quickly be able to identify the individuals and spot changes to be merged, but less useful once the numbers get larger and less trustworthy.

[Mark1834]

Fair enough on traceability, but I wouldn’t generate a new UUID. However, the concept of multiple different unique Identifiers for the same record is a challenge for the terminology if nothing else!

It’s all academic anyway, as I doubt any of this will be implemented anytime soon, but there are some interesting possibilities for the future.

[NickWalker]

It’s all academic anyway, as I doubt any of this will be implemented anytime soon, but there are some interesting possibilities for the future.

Yes agreed, thanks for raising this because it was an interesting concept to think about.

[KFN]

Since the specification never addresses the merge of two individual records within the same data-space (or if they were both created new in the singular program or created in separate programs) I would not assume that any two programs (or possibly two releases of the same program) will manage the UID tag the same way.

It is safe to say that the addition of the sanctioned UID tag (vs. the custom _UID tag) was one or more developer of software’s attempt to elevate there use of this tag to a “standard based” role.

As someone indicated previously the UID tag is the REFN tag on steroids, which is in my mind a little over the top since one could have just used the REFN tag:
1 REFN 8ad81435-595d-4711-9c82-8326892c611d
2 TYPE UID

Just like I currently do to mark the adding of any new object (Individual, Family, Source, Media) into the database with an accession number.
1 REFN 2019-0112-00003
2 TYPE Accession

[Tom Holden]

I've mucked around with the UniqueID field in RootsMagic databases over several years without knowing exactly how it is generated by the application. I generate it when adding individuals via SQLite using hex(randomblob(18)) and RM has never protested. If it is supposed to be a number and a checksum, then RM is not checking the checksum.

The RM UniqueID is not received by an Ancestry Member Tree via GEDCOM or TreeShare nor by FamilySearch Family Tree. The RootsMagic database relates the RIN of the individual to the unique IDs supplied by those services. The RM UniqueID comes into play only when using an automatic merge called ShareMerge or when comparing two RM databases. In both cases, it skips the 'smart' comparison that weighs the match between any pair of people and declares the two to be the same person. Only one UniqueID and RIN persist after a merge.

I had dabbled with a custom RMID fact in RM7 pre-TreeShare to which I copied the hidden RM UniqueID value when trying to arrive at a method of synchronising among RM7, an Ancestry Member Tree and Family TreeMaker 2012/2014. That made the RM UniqueID value visible in all three systems and transportable via GEDCOM. I got tangled up in the FTM to RM GEDCOM transfer (sources) and along came RM7.5 TreeShare which obviated the need for the FTM TreeSync.

[Mark1834]

Welcome to the FHUG, Tom. As you have probably discovered, the RM comparison tool can be a bit flakey for records with different UID values, so creating an artificial one is a good idea. Odd though that RM doesn’t bother to validate the checksum when loading - I thought that was the reason for including it, to ensure the data were consistent and accurately recorded!

GEDCOM 7 advises against using a checksum unless it is absolutely necessary, but it will be a while before all the major apps converge on a common method (if they ever do...).

[LornaCraig]

In case those who are interested haven't spotted it, the latest minor upgrade (7.0.8.2) has introduced the facility to create UIDs within FH. Calico Pie's list of changes in this version includes the following:

A new task has been added to the “Work with Identifiers” tool which allows Unique Id values (tag = _UID) to be generated for any Individual records which do not already have one. Unique Ids can be viewed on the ‘All’ tab of the Property Box. Every Individual record can have an unlimited number of them. Unique Ids are also included in the RootsMagic direct import from versions 7 & 8.

[Mark1834]

Indeed, but FH is rather inconsistent in how it handles them. They are included in the direct RM import, but not in the Legacy one, even though they are included where importing via GEDCOM . They are also generated in the GEDCOM 7 format (hyphenated, no checksum), which most other apps don’t recognise and either add their own checksum or discard them completely. CP are aware of all this, but it’s not been corrected for the released version.

The newly published Format UniqueID plugin fixes the generation issue, and enables users to convert all their UniqueIDs to their preferred format, depending on what they want to do with them.

[David Potter]

Just began to digest this post. Can anyone tell me where the UID is stored against an individual in Roots Magic 7 and or 8 please? I see settings in RM8 for REFN, RIN and FSID as to how to display the ID Number but can't find any mention of UID.

Thank you.

[Mark1834]

It's not shown in the user interface. It is only visible in an exported GEDCOM file or by viewing the database tables directly with an SQLite viewer. Presumably, the rationale is that it's not something that a user normally needs to worry about.

[David Potter]

Thank you Mark. I see, that's a pity. I was hoping to see the new FH 7 feature to generate UID's per Individual exported using Mike Tates's Export Gedcom Plug-In into RM (7 or 8) and then check the result in RM. And then ponder how this could be useful keeping thing in a manual sync.

I have some SQL knowledge, do you know which specific RM table this UID is stored in? I'm using RM8 just now.

[Mark1834]

David, I suspect we are thinking on very similar lines. Now that FH7 supports both the UniqueID tag and direct access to RM data, there is a good opportunity to improve the rather clunky FH-RM-Ancestry sync.

I have added support for UniqueID to the plugin that supports that process, and have a new work-in-progress plugin that compares data in FH and RM directly. At the moment it is read-only, but I am starting to contemplate how far it can go in updating RM directly. I was going to start a new thread shortly to get user comments on the approach before anything is finalised.

If you want to play in the meantime, your friend will be the SQLite Tools for RootsMagic site. It does not appear to be supported by the RM organisation, but is essentially a bunch of technically-minded users who have worked out how the database is structured. I use the excellent and free SQLite Expert Personal to view the tables directly so I can structure my queries appropriately. The UniqueID field is the primary key of the PersonTable table.

[David Potter]

Thanks again Mark. That sounds very promising I'll keep an eye out for new posts on this subject.
Meanwhile I will have a play around with those links to groups and tools you provided.

Cheers and Thanks once again.

[Mark1834]

BTW - the standard FH GEDCOM export now includes the UniqueID, so you don't have to wait for plugins to be updated to start playing with it. The only potential wrinkle is that older apps don't understand the GEDCOM 7 format that FH uses. RM8 is ok, but not RM7. The Format UniqueId plugin provides a stand-alone interconversion of formats, but it can easily be built into other dedicated plugins.

[David Potter]

Thanks for the Tip Mark. I'll give that FH Feature a go along with the other goodies you mentioned earlier.