Family Historian User Group

Posted: **21 Oct 2023 08:05**

Issue: FH does not automatically create UniqueID values for newly added individuals. For users who use this field for its intended purpose of uniquely identifying records as they are transferred between applications, an additional step of Tools > Record Identifiers > Create UniqueID where missing is required.

Proposal: A user-selectable option (probably under Tools > Preferences > General > Advanced, and off by default for consistency with previous practice) be provided to enable automatic generation of UniqueID for both new projects and new individuals added to existing projects.

A related but independent option would be to provide an fhCalculateUniqueId(ptrI) function for plugin authors to create values directly.

It's a minority requirement, so will never come top of a vote poll, but getting it on the list will raise the visibility with CP. It appears to be simple addition with no obvious downside.

Posted: **21 Oct 2023 10:06**

I'd vote for it.

Posted: **30 Oct 2023 16:14**

Mark1834 wrote: ↑21 Oct 2023 08:05 Issue: FH does not automatically create UniqueID values for newly added individuals. For users who use this field for its intended purpose of uniquely identifying records as they are transferred between applications, an additional step of Tools > Record Identifiers > Create UniqueID where missing is required.

Thank you for posting this Mark, I was unaware.

Would you not go a step further and suggest FH assigns a UID to any newly entered individual?

I can appreciate gaps will still appear where import from other software is involved and that would need a Tool such as you describe or better still an import routine to fill those gaps.

For the benefit of those who don't understand the issue my previous software, Rootsmagic, assigned such a UID to everyone in the database. Regardless of changes to an individual outside the program, maybe by a family collaborator, these two variant individuals were combined rather than duplicated due to differences using a feature called ShareMerge which used this Unique Identification of individuals

I was reassured to see all those Rootsmagic UID's are still within my FH project but a little surprised FH does not automatically assign a UID to new entries.

As one who does transfer between applications your suggestion gets my vote also.

Posted: **30 Oct 2023 22:45**

Vyger wrote: ↑30 Oct 2023 16:14 Would you not go a step further and suggest FH assigns a UID to any newly entered individual?

Yes, that's essentially what I was proposing, but have it as an optional feature to cater for users who don't want to use UniqueID.

FH was relatively late to the UniqueID party (and it's not difficult to find older postings here from long-term FH users sceptical about the concept), but now that it has moved from becoming an informal standard to properly supported in GEDCOM 7, hopefully FH will take the next step and support it fully for users who wish to exploit it.

Posted: **31 Oct 2023 11:20**

How would you expect merges to be handled?

Obviously, two individuals with the same UID are the same individual... unless the user knows better, in which case one of those individuals should automatically have a new UID assigned (if the relevant preference is enabled).

Two individuals with different UIDs may be the same individual, in which case upon merge one of those UIDs should be discarded -- I assume the user would get to choose which.

What happens if the user decides to discard both UIDs for a merged individual? Should this be disabled? Does the preference then force a new UID to be created?

Posted: **31 Oct 2023 11:39**

That’s more a point on UniqueID in general rather than directly relevant to the proposed wish list item, isn’t it?

It is stretching the English language somewhat, but GEDCOM 7 permits an individual to have multiple UniqueIDs. That is how CP have implemented it in FH as well, so I suspect that merging would combine values (I’m not at the desk to try it).

The RM implementation that Jackson described is slightly different, as it allows just one value, with the option to merge records unconditionally on UniqueID, irrespective of other differences. That’s a powerful feature for merging external updates, but outside the scope of the wish list proposal.

Posted: **31 Oct 2023 11:44**

Mark1834 wrote: ↑31 Oct 2023 11:39 That’s more a point on UniqueID in general rather than directly relevant to the proposed wish list item, isn’t it?

No.

If you want "automatic generation of UniqueID for both new projects and new individuals added to existing projects" then you have to address how to handle individuals added by a merge.

Posted: **31 Oct 2023 12:03**

Isn't that an implementation detail that is up to CP to resolve?
However, it seems from what Mark says that they have already catered for it by allowing multiple UniqueID.

Posted: **31 Oct 2023 12:08**

It's an implementation detail if we don't care about what happens on merge, yes.

If we do care, the proposal could be reworded to explicitly bring merge into scope.

[Disclaimer: I don't care either way -- it's not something I have an interest in.]

Posted: **31 Oct 2023 12:13**

1. When do you suggest that the UIDs are generated if the option is turned on for an existing project, immediately on saving the option or next time the project is opened?

2. Would this be a global setting or a project specific setting? If it was global and a user imported a GEDCOM without UIDs you'd get new UIDs on all individuals. If that was then merged with the users main project, any individuals in both would end up with two UIDs unless the user specifically discarded the one coming in. My gut feeling is that a project specific setting would be preferable.

Posted: **31 Oct 2023 12:18**

ColeValleyGirl wrote: ↑31 Oct 2023 12:08 It's an implementation detail if we don't care about what happens on merge, yes.

I'm not sure I can see how this is any different what happens during a merge with any other fact, choose which one to keep or keep both. The existing merge process gives the user the full control to decide how it is handled.

Posted: **31 Oct 2023 12:36**

jelv wrote: ↑31 Oct 2023 12:18 I'm not sure I can see how this is any different what happens during a merge with any other fact, choose which one to keep or keep both. The existing merge process gives the user the full control to decide how it is handled.

Is the objective of the preference to ensure that every individual in a project has a UID? (Except of course, it can't be, because a user can delete them manually).

Because if so, shouldn't the merge process adhere to the preference? Individuals without UIDs would acquire them (and that would I *think* be the first instance of a piece of data created by the merge process, other than the inescapable record ID.). And if the UIDs were added at the end of the merge to all individuals who didn't have one, would that be honoring a user's decision to discard them for certain individuals?

Posted: **31 Oct 2023 12:50**

It’s automatic generation for new individuals (not existing ones), so I would implement it as active from when set, as for other preference settings. It supplements the current option to set where missing, not replaces it.

A project setting is probably most flexible, but I think a global one would work as well.

The most important aspect though is that it is off by default so does not affect default behaviour. Users who want to use it have to opt-in by selecting the option (as they do now for the manual process).

Posted: **31 Oct 2023 12:57**

ColeValleyGirl wrote: ↑31 Oct 2023 12:36 Because if so, shouldn't the merge process adhere to the preference? Individuals without UIDs would acquire them (and that would I *think* be the first instance of a piece of data created by the merge process, other than the inescapable record ID.). And if the UIDs were added at the end of the merge to all individuals who didn't have one, would that be honoring a user's decision to discard them for certain individuals?

You’re grossly over-analysing this (IMHO, of course

). It’s a simple option that supplements an existing manual process of creating UniqueID where missing by creating them automatically as individuals are added to the project.

Why should anything else about current processing of the field change?

Posted: **31 Oct 2023 13:22**

Mark1834 wrote: ↑31 Oct 2023 12:57 It’s a simple option that supplements an existing manual process of creating UniqueID where missing by creating them automatically as individuals are added to the project.

So, it applies when adding a new individual manually and when adding them via a merge. New individuals without an UID will receive them whichever way they're added. The UIDs of merged individuals will be handled as they are now (with the exception that if all existing UIDs are discarded, a new UID is assigned).

Posted: **31 Oct 2023 13:35**

ColeValleyGirl wrote: ↑31 Oct 2023 12:36 Is the objective of the preference to ensure that every individual in a project has a UID? (Except of course, it can't be, because a user can delete them manually).

Firstly I don't believe a user should be able to delete or alter a system generated and managed UID, most Rootsmagic users don't even know a UID for each person exists, if they did some would probably try to reassign their own

but the benefits of a UID are many.

The implimentation will ultimately be CP design, however how Unique is several UID's?

I have been doing a lot of work on My Heritage import data and I note they preserve my Rootsmagic generated person UID's and also note they assign a UID for each newly added person via accepting matches.

I also note they appear to assign the same UID to each Fact/Attrib

I have fought duplication resulting from data shares for many years a single UID for each individual is a great benefit (when programmed) towards reconciling and merging known same individuals with slightly differing data, duplicate facts can then be reconciled and managed through the Plugin.

I want to see how Rootsmagic responds to a UID being deleted from the database but for now some extracted My Heritage Gedcom example for a newly accepted match and therefore an addition to my data. In other words the UID is assigned by them and was not a result of Rootsmagic.

Code: Select all

0 @I501685@ INDI
1 RIN MH:I501685
1 _UID 6540fa384e43c1eeaa6520cf30e1ff0d
1 ..........
1 NAME Nelson C /Drake/
1 .......
1 BIRT
2 _UID 6540fa3e38b6f1eeaa6520cf30e1ff0d
2 ........
1 DEAT
2 _UID 6540fa3e4e43c1eeaa6520cf30e1ff0d
2 ........
1 BURI
2 _UID 6540fa3e851f11eeaa6520cf30e1ff0d
2 .......
1 RESI
2 _UID 6540fa3ec8d7b1eeaa6520cf30e1ff0d

Posted: **31 Oct 2023 13:42**

ColeValleyGirl wrote: ↑31 Oct 2023 12:36 Is the objective of the preference to ensure that every individual in a project has a UID? (Except of course, it can't be, because a user can delete them manually).

That goes back to the question of how we think it should work when enabled on existing projects. I'd prefer it to be on the basis that it means all individuals in the project should have a UID (or multiple UIDs as allowed by the latest GEDCOM standard). Should missing UIDs be generated when a project is opened (or a warning and offer to generate them)? This would bring it line with other software.

Posted: **31 Oct 2023 13:47**

Vyger wrote: ↑31 Oct 2023 13:35
Firstly I don't believe a user should be able to delete or alter a system generated and managed UID

This isn't compatible with it being a preference. If somebody for whatever reason doesn't want UIDs (although admittedly I can't see that they do any harm) they will want to discard them from merged data.

Posted: **31 Oct 2023 13:57**

Vyger wrote: ↑31 Oct 2023 13:35 Firstly I don't believe a user should be able to delete or alter a system generated and managed UID

A bit obscure, but I can see circumstances where you might need to. something along the lines of if there were two individuals with very similar details in say a census, someone might have picked the wrong one so there's a UID in the FH project that matches the UID of the wrong person in some other GEDCOM. In that case you might want to delete the UID and have a new one generated to make them different individuals when merging in FH or some other software.

Posted: **31 Oct 2023 15:10**

jelv wrote: ↑31 Oct 2023 13:57 A bit obscure....
....In that case you might want to delete the UID and have a new one generated to make them different individuals when merging in FH or some other software.

This is where CP would need decide on the definition, the future use, hopefully in managing duplication, and the implimentation.

You have posed me a question I presently don't know the answer to but will test and discover.

Rootsmagic UID's were never visible in program which was good, the number of people I have read wanting to renumber their RIN's would just get a new box of crayons to play with.

A lot of users steared clear of using ShareMerge in Rootsmagic but I found it a robust and reliable process and I should revisit it again. In the case of a manual merge I would always flip the person with the lowest RIN to the primary position but unless you keep some manual reference system why should that matter?

The question you have posed me is yes, sometimes I got the merge wrong and Rootsmagic had no undo feature so the only option was to revert to a backup. My chosen solution was to;

Create a new empty database

Drag the wrongfully merged person to that file

Clean up the Fact data of each individual in each file (strip them of the wrongfully merged data)

Then drag the cleaned up person back to my main file linked or unlinked.

The question you have posed me is what happened to the UID of the person split out and recombined? and I don't know the answer at present but I will find out.

Posted: **31 Oct 2023 17:24**

I'm a touch concerned that we are discussing settings for when Auto-Generation of UniqueId should / could be switched on, without any definition of what this UnqueId is, or how it behaves (or might behave) - so far as I can see and please correct me if I'm wrong (and yes, I have read that part of the GEDCOM 7 spec'n).

I just set a UniqueId for an individual in a test project and then cloned said individual. The clone included cloning the exact value of the UniqueId. Now, of course, that's a PlugIn rather than native FH logic but the same thing happens when copying and pasting the items from one individual to an empty one.

Presumably, therefore, CP haven't programmed anything for this item yet other than creating an empty item for it. If so, how can we talk in an informed manner about it?

Posted: **31 Oct 2023 18:06**

I'm also a bit confused about what is intended by the creation of an 'additional' UniqueID and the already existing Individual RecordId which is unique within each 'Project' or GEDCOM File. To me that already appears identical to any other genealogy product where the 'UniqueID', in reality, is the the database Individual RecordId number which is allocated on creating a new Individual record and is also the consistent design across other-use database products.

I think more information is needed on the specific purpose/benefit to users of an extra individual identity identifier beyond those already available and how it might differ from the existing RecordId.

Mervyn

Posted: **31 Oct 2023 18:31**

The basic concept of UniqueID is very simple. It’s a unique identifier (essentially a 128-bit pseudo-random number) that stays with a record as it is copied between genealogy applications.

I should know better by now to describe this as a simple addition. We just can’t stop ourselves analysing it to death…

Posted: **31 Oct 2023 20:29**

Mark1834 wrote: ↑31 Oct 2023 18:31 ... I should know better by now to describe this as a simple addition. We just can’t stop ourselves analysing it to death…

But seriously, doesn't that say something about what on earth the UniqueID implies for FH's own processing? As in - we don't actually know? So at the very least, this proposal needs to be caveated by saying - we don't know if this is compatible with what CP are thinking of? For instance, it could be that the answer to

Issue: FH does not automatically create UniqueID values for newly added individuals.

... could be "That's because we haven't written the code yet".

Posted: **31 Oct 2023 20:53**

True - but that’s probably the case with many Wish List items - does it fit in with CP’s strategy for where they want to take FH…?

Family Historian User Group

[Wish List Item 626] Automatic generation of UniqueID

[Wish List Item 626] Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID

Re: Automatic generation of UniqueID