Conflated profile splitter
I guess I need some education about the proper way to restore badly merged/multiple conflated profiles - let alone document the process. It seems most don't/won't take the time to try to do such detailed tree cleaning - to set right such badly merged persons - and I am finding it a difficult process. Here is a Help Center document that is supposed to help:
It would be nice to be able to assign a set of Sources and Events to a particular profile when bad merges have occurred - rather than have to pull the profiles apart one Source or Event at a time. RESTORE buttons can get you closer I guess - but when there are multiple persons and therefore Sources and Events needing split - it might make it so much easier to assign them to a 'provisional' profile at the same time.
Who knows what this tedious process does to the Record Hinter process - but I assume it gets as confused with such splitting as it does with bad merge/record hints that may have caused such a situation in the first place. Minimally it might be nice to indicate such work is occurring (so others don't have to be confused), suspend the Record Hinter until the process is complete, and a method to indicate when the process is complete.
Since there are current Ideas/Requests for easier Merging - I only thought it proper to give bad merging/splitting equal time.
Hmm: presumably, somewhere or other the system keeps track of which profile a source or conclusion was originally associated with. Unfortunately, once a merge has been completed, that information is no longer visible to users: the merge-deleted profile has no sources, Other Info, or relationships. This creates a chicken-and-egg problem when trying to un-conflate profiles: you basically have to go through with the restore (or unmerge, if you're very lucky) and then try to sort through the resulting mess to figure out who was who. Some sort of tool that would identify the original connections would be quite handy for this. I envision a screen (or set of screens) much like the Merge process, only in reverse. There would need to be a third column in the middle, for conclusions entered or edited post-merge, which the user would need to sort through and assign to one side or the other, but unedited old conclusions and connections could automatically be assigned to the profile they originally went with. (I suppose a means of overriding that would be useful, for example for re-assigning the incorrectly-attached source that caused the conflation in the first place, but it might end up too confusing that way.)
But anyway, good idea. Perhaps if such a tool had been available, I would not have abandoned my ancestor's original profile to its new identity when another user decided that a couple with the same names (but in a different crown land and with a different religion) must be the same people.2
Update (which may be helpful): In this tedious process of correcting conflated profiles - though I cannot select a set or multiple Sources to move to the other PID - I am finding that Review Attachments is quite helpful to Detach and then Attach them to the other (already known PID). Now if I could just select multiple Sources or a set of them rather than one at a time - that would be so much easier - but I guess attaching Reason Statements for the moving is sort of important - so ... still plugging away at the tedious process...0
Gordon Collett ✭✭✭✭✭
I can't think of any way to speed up untangling a confused profile, at least not the way I like to do it.
First let me say that from what I can see, there is no need to worry at all what the Record Hint system thinks of things. Watching it through the years, it is evident that the Record Hints has absolutely no interest in the Change Log but only looks at the current information on the record. This is based on seeing hints actively coming and going while correcting or adding new information to a profile.
My wife and I just finished up undoing a complete mess triggered by a GEDCOM with really bad information and one incorrect merge in 2016 that snowballed until three different Jens Olsson, one from Horneland in Stord, Hordalane, Norway, one from Hammerstad in Toten, Oppland, Norway, and one from Åse, Hafslo, Sogn og Fjordane, Norway, three areas far from each other, were thoroughly confused. Complicated further by the fact that one of then had had a duplicate created that was also confused by the GEDCOM and the wrong Jens' wife attached to him along with having both his own and the other Jens' children attached to him and that incorrect wife.
To start the process, I put a note in the Change Log for my starting point (please ignore the uncorrectable typo!):
Then I went to the very beginning of the the Change Log for this Jens to establish from his original vital information, original parents, and original children what his intended identity was (see: https://www.youtube.com/watch?v=RZeqgY47zdA ). Following up through the Change Log, we found where the first mistake, a merge, had occurred. Everything that was done to the record from that point on would need to be undone to fully correct the record.
To stay organized and not lose any of the individuals buried in the record, I created a new, clean profile for the person being separated out giving him the name NEW Jens Olsson Hammerstad and doing enough research in the original parish records and indexed records to determine his correct birth, death, and marriage information. His Change Log now starts like this:
Also to stay organized I renamed the person being cleaned up USE Jens Olsson Horneland USE. Then we printed out the Change Log down to that first error. This was eleven pages long.
Finally we were ready to actually start.
Taking our printed Change Log and starting with the most recent change, we worked down line by line asking on each line:
- Should this change have been made at all?
- Does this information belong to Hammerstad or Horneland?
Then either discarding, moving, or keeping that one change.
Source attachments we ignored on this first go through.
When we came to a merge, we would go to the very first entry on the merged in individual's Change Log to determine that person's intended identity. If he was Horneland, we left it. If he was Hammerstad we restored that person. If the restored person was clean we would merge him into Hammerstad. If that record also had errors we would pause the main track and go completely through the restored person's change log fixing information, removing information, and unmerging there as needed and only then merging the results into the appropriate Horneland or Hammerstad.
When we came to a child being added, we would go to the change log for that child, go to the first entries, determine the child's intended identity and parents. Usually this would entail restoring the child's original parents, then cleaning up the child's record and both parents records, then correctly merging the original parents with either Hammerstad and his wife Mari or Horneland and his wife Mari. We were continually in the original parish registers to confirm information.
This process took several days but at the end of it all the information was correctly on each individual, wives were with correct husbands, and children were with correct parents.
In the middle of this work we discovered that Jens Olsson of Balke, Toten, Oppland, Norway, had been thrown into the mix and I took a detour to separate out and repair his family while my wife continued to work on Jens Olsson Horneland.
During this work possible duplicates would come and go. Hints would come and go. We ignored all of them.
Next phase was cleaning up the profiles. Since restoring does not removed information on the surviving profiles, we now went through each person's vitals, other information, and family members sections doing final corrections by improving dates and places, removing alternate names and residences that no longer belonged, making sure all children were attached only to their correct parents, and attaching original parish record sources for births and marriage records.
The final step was to go through each person's source page and making sure that all sources were correct for that person and that all source attachments were in place correctly.
A final Note, and this project was completed:
This whole process added nine printed pages to Jens' Change Log.
I realize that a lot of people will have no interest in this full procedure which is a shame because it really is, I feel, the best way to completely clear a profile of all remnants of incorrect information. By completely cleaning up three unrelated families and make a couple of minor corrections on a fourth, there should not be any way these families can get mixed up again unless (shudder) someone is using ID numbers to sync from an outside program. Could any automation help? Not that I'm creative enough to come up with.3
Bravo! Yes, it sounds like a similar process though I am trying to keep all profiles straight by myself. So a couple of the Ideas I have banging around my head relate - not to say I'm that creative ... but I think they might help the process ... maybe... Hopefully I get around to suggesting them some day. As far as a GEDCOM - as long as it is 'syncing' good information - I'm all for it.
Thanks for detailing your process - I think it should help some. The reason I think assigning a set of Sources, Events, Facts or Memories at the same time would be easier is that - IF one knows to which profile they belong - it would just make the whole process a bit simpler. Notes/Reason Statements could be entered afterward. But I guess we each develop our own preferences for the process - I just wish it were easier than the merging that causes the problem to begin with.0
This is so helpful! Actually seeing the process step by step in a real example is perfect. I will be sharing this information with our ward Zoom Genealogy Class tomorrow!0