Sharing with permission from the author, The Legal Genealogist
Judy G. Russell, known as The Legal Genealogist, has a good blog post today about editing and correcting the FSFT. I asked her for permission to share her post here in the Community. https://www.legalgenealogist.com/2023/04/05/fixing-a-mess/
Judy has a sense of humor I appreciate. I hope you will too.
Answers
-
Wonderful article and an excellent example of how to work in Family Tree on such problems. Regarding her wondering how long her repairs last, I would predict a nice long time due to the efforts she made to correct both records, properly attach all sources, take care of all duplicates for both men, and add a note which she marked as an alert note.
0 -
I only had to untangle confused identities with an ancestor one time, and the 2 individuals lived 100 years apart. I found it stressful, as the Legal Genealogist indicated, even though the person that made the incorrect change was very cooperative to my undoing the work. While I cleaned up all the vital info manually on the details page (yeah, didn't notice the revert function back then), with the sources I just placed comments on the incorrect ones. I noted someone else eventually removed all the incorrect sources, so now my ancestor no longer has a paper trail indicating 200 years of robust life.
I would be happy if the merge process could be made more difficult and force you to recognize differences in vital information. I have often wondered if that merge could have been done accidentally. The 2 persons didn't even have the same name and she never said "boo" when I messaged her to ask her permission to fix it. If accidental merges can happen, then the system is way too lenient by enabling incorrect merges which are deliberately done by inexperienced "do-gooders".
1 -
I'm all for making merges easier to disentangle, but I'm vehemently opposed to any effort toward making them any more difficult and tedious to do than they already are. This is because I spend a fair chunk of my time assembling people out of the legacy data still littering the Tree all over the place, and that involves -- as the Legal Genealogist writes -- a whole lot of One. At. A. Time. In particular, any WikiTree-like move toward needing permission from some mythical entity (mentioned in the comments on Judy's article) is an absolute non-starter, unless all of the unedited legacy data is programmatically removed from the Tree.
3 -
Contrary to Julia (I'm sorry - we still disagree) - I am all for making obviously incorrect merges more difficult to happen (if vital information does not match). There needs to be a way to finalize 'essentially complete' profiles such that such potential bad merges are made more difficult or even prevented from taking place.
Why allow good profiles to morph into bad - especially if Sources and reasoned conclusion statements are not required? I believe that a merge which essentially changes the conclusions and vital/intended identity of an essentially complete person profile should be required to disprove the prior conclusions/Sources - as a complete set - especially if they have been in place on the profile for an extended time period - and especially if they are for generations near Living descendants - all or most of whom - especially the nearest desecndants - agree on the established profile. If someone is going to merge a profile that does not match - why should they not also go through the process of disproving the prior profile?
Merges of more distant tree profiles are often subject to debate and thus could continue using the open-edit structure. I believe restricting the more recent generations is going to be necessary at some time so that tree data has the likelihood of being more accurate and thus relations to Living do also.
0 -
There needs to be a way to finalize 'essentially complete' profiles such that such potential bad merges are made more difficult or even prevented from taking place.
My problem @genthusiast is still that I believe that it is impossible to define "essentially complete". In fact, when someone merges two profiles, I'll bet that they believe that they are making an incomplete profile into a (more) complete profile.
And if we allow a researcher to designate a profile as "essentially complete" (rather than the computer doing it) then the risk is that we end up with someone like my granddad's cousin being marked as "essentially complete" because someone has completed (they think) their research into how he moved from Nantwich, Cheshire, England to Montana, USA even though he's still in England throughout that time period. I did disentangle my Nantwich guy from the Montana guy (who actually did come from Cheshire, but the other side of the county). But if I'd had to wait for permission from his descendants who'd worked on him in FS FamilyTree, I'd still be waiting.
1 -
"unless all of the unedited legacy data is programmatically removed from the Tree"
Leaving behind....? (Nudge, wink, and all sorts of Smilies... 😉 )
0 -
... it is impossible to define "essentially complete".
If your Nantwich great uncle was marked 'essentially complete' prior to that merge - would you have had a problem with that merge not taking place?
What I am suggesting as 'essentially complete' includes collaborative consensus/agreement concerning the Vitals of a person - such that if someone wants to merge into them - they really need to disprove the entire profile that has collaborative agreement.
Again such consensus is more likely for near Tree relations. Could your family not have potentially agreed to your great uncle's profile prior to that merge?
'Essentially complete' in my mind involves documenting (including timeframes) residences, relationships, memories (attached photos, documents, audio, stories) and a reasonable amount of supporting sources. 'Essentially complete' does not exclude attachment of other sources that match the profile - however, if prior attachments already document places, dates and relationships that are mentioned - supporting sources are just reinforcing and don't change the 'essential completness'.
Note: Leaving behind legacy data - even if incorrect is usually not a good idea. But I do agree that if found incorrect there should be a method for removal or identification as erroneous - such that erroneous initial intended identities do not conflate those correct merged ones.
0 -
Could your family not have potentially agreed to your great uncle's profile prior to that merge?
But that's one source of the problem - I am the first relative of the Nantwich great-uncle to have used FamilySearch. There were two guys in the USA who had convinced themselves, long before I came on the scene, that William of Montana was the same person as William of Nantwich. They were the only people with any interest in either William. (Ironically, one of them did a huge amount of good work on the ancestry of William of Nantwich, my great uncle, even though he turned out to be nothing to do with William of Montana.)
So the set-up for that case would be that these two in the USA could have declared themselves satisfied with William of Montana being the same person as William of Nantwich, and marked him as essentially complete. It would have been utterly unfair on them to have said - oh wait in case someone else comes along. And they are the more direct relatives to William of Montana, being grandchildren or something like, whereas I'm only a great nephew to William of Nantwich.
I also have to say that a huge amount of the data demonstrating that William of Nantwich never left the town has appeared only in the last few years - our 1911 census, 1939 Registration and the Cheshire parish marriages. Without that data, the incompleteness couldn't be seen.
Completeness is not a bad idea - it's detecting completeness when different datasources aren't yet available, and when different families haven't looked at things, that's the issue.
2 -
Completeness is not a bad idea - it's detecting completeness when different datasources aren't yet available, and when different families haven't looked at things, that's the issue.
Thanks for somewhat agreeing. So yes, your scenario does need to be taken into account - but I never said bad data should ever trump good. I'm pretty sure since you likely are closer related to your great uncle - than probably the Montana imposters 😉 - they recognized your claim/sourcing once you collaborated.
For those that already have 'essentially complete' profiles of near family before potential bad merges - it would be advantageous to be able to indicate the need for bad mergers to be required to disprove all the current good data/sourcing - as an entire set (make the oness be on the person trying to merge).
For example, I assume it was fairly easy for you to disprove that your great uncle ever lived in Montana? You weren't merging - you were deconflating two badly merged/researched profiles. Even if they had declared themselves satisfied with the profiles - after your refutation - they could remove their satisfaction and allow you and your family to declare yours on the separated profiles - as they then could also. So the collaborative effect was that even more people now agree that there are two separate Williams - shouldn't that collaboration event have residual effect on both profiles?
0 -
I'm really of two minds when it comes to hindering bad merges.
I think more warnings such the current "These people were born more than three years apart" would be good such as "These people lived more than ten miles apart" would be good to draw people's attention to conflicting information.
But I don't think there should be hard stops on merges. I'm concerned that if someone was told "You cannot merge these people because their birth dates are more than three years apart" that someone intent on merging them would just change or delete the birth date then merge anyway.
It's pretty easy to see really bad merges in the Change Log but if someone edits one of the people to match the other then merges, that is much harder to pick up on.
But should there be some blocks? Like not being able to merge if the death date of one person is before the birth date of the other?
2 -
I don't think there should be hard stops on merges.
I do think there should be some merging hard stops - especially if there were more finalizing conclusion types which displayed collaborative consensus (especially for near related generations). I think inclusion of such conclusions into a profile could be dependent upon sufficient attached sources/research or even combined with collaborative affidavit of near relations profiles by Living descendants. In other words, for example, I believe I really do know my grandparents better than most other Living people - excluding siblings, parents, aunts/uncles, first cousins, great aunts/uncles - and their corresponding in-laws who may be living (they may know/recall bits of information I don't - as far as Vital/profile changing information I think we would all come to collaborative agreement).
Examples:
No More Spouses (to indicate this person only had relations with the current listed Spouse(s) in Tree)
No More Children (to indicate the couple relationship(s) had no more issue/children)
No More Residences (to indicate that the current residences are sufficient to document residences - towns/cities, State, Nation - whichever level one is sure about)
Final lifetime dates (any other record hints or merges not matching the lifetime should obviously be rejected)
There are probably some other blatantly obvious ones - but this is what I come up with off the top of my head.
0 -
The problem with adding more types of merge warnings is that the existing warnings train users to ignore them, because they're so often ridiculously wrong. (Such as "they may be twins" when twins is the one thing they absolutely and positively cannot be, since they have [slightly different spellings of] the same name.)
What it boils down to is that teaching a computer all of human knowledge -- such as the fact that Julius and Gyula could very well be the same person, but Julis very definitely isn't -- just isn't feasible, so no algorithm is ever going to be as good as a human being at determining whether two profiles are for the same person or not. However, human beings are highly fallible: once they've convinced themselves of something, they're very good at ignoring or explaining away anything that contradicts that conclusion. Adding obstacles to that road is likely to just entrench the error further, out of sheer spite.
I think what would really help prevent incorrect merges is better comparison tools. Instead of the unaligned, cherry-picked bits and pieces that the current first two merge screens present, put the entire profiles side-by-side, with full vitals showing for all family members, and include the source lists, collaboration notes, and even the biographies in the comparison. Perhaps it would help to highlight the discrepancies, but turning them into yet more obstacles would likely backfire: as Gordon said, bad merges are much harder to figure out if someone went through and edited one of the profiles, and that's likely what people would resort to, if the merge process got too obstructive otherwise.
4 -
... Adding obstacles to that road is likely to just entrench the error further ...
@Julia Szent-Györgyi Or the verity ... don't forget that option. Entrenching truth is what we are after? Yes, if hard stops are going to stop merges then they should also prevent edits also ... of at least the current collaborative consensus about Vital information (I really would like to see 'essentially complete' profiles Vitals marked read-only ... again please remember, mostly for near related generations - leave further generations open-edit).
I don't claim to know if such changes might cause more problems than they're worth. But I do think it could/should be tested - beta trees or something of the sort. The Computer-Generated Trees should be a good place to test theories about teaching computers to implement merge warnings. It would be interesting to compare or incorporate those into Family Tree (likely a mirror of Tree section) and see how that affected edits of corresponding profiles. I have no idea whether that level of sophistication in Tree profiles would be able to be implemented...just another Idea. The KISS rule does rule out sophisticated solutions - so perhaps I am barking up a tree...
What I mention in my immediate post above is not a suggestion to implement more merge warnings ... those would be hard stops (not allow the merge to take place if such would alter those firm conclusions/Vitals) - or minimally require the disproving Source(s) to be produced and compared side-by-side (your more robust side-by-side comparison Idea seems a good compromise ✔️. Perhaps the tagged Sources could be listed under each Vital conclusion).
Before someone concludes I am hijacking this thread - please understand this thread does include the aspect of how long edits/corrections in FSFT will remain (that is exactly what all these posts are about).
0 -
Naturally I would like to see better safeguards to prevent incorrect merges, or individuals being added to families to which they have no connection. Disentangling the mess takes up so much of my time that could be spent more "productively" that, yes, I'd be delighted with the introduction of features that could cut down on the damaging work I am encountering every week.
However, I don't see your suggestions as being workable. As Adrian has illustrated, how can a "consensus" be reached if you are the only person working in Family Tree with close knowledge of an individual or branch?
My other problem is with "who-knows-best" about an individual and their family. I have found it is often a user totally unrelated to a family who can best judge the facts, as close family members are often very reluctant to agree they have been wrong on, say, the identity of their great-great-grandparents, when they have accepted these people as their ancestors for a long, long time, then evidence is suddenly produced to show their conclusions can be completely disproven. Because you are not directly part of a family branch should not prevent you from changing details based on firm evidence, rather than hearsay, but close relatives will not see things that way! (Hence the problem with your consensus argument - one person can be right and ten be wrong!)
As I have shown in previous posts, providing examples, there is often disagreement among siblings concerning where, say, their father / grandfather was born. I have also have had to "back off" in a situation when an unrelated contact totally accepted my findings, then changed everything back because it had caused upset to her cousin! So your suggestions could easily lead to cases of never-mind-the-facts, the details have to remain - due to the wishes of the immediate family.
Also, if you do have certain revised protocols, I just don't see how you could implement these just for more recent generations (as you seem to be implying) and not apply them to individuals / families who lived at earlier periods of time.
Unfortunately, your "essentially complete" expression is not one I see as applying to genealogy / family history, where additional evidence can occur at any time to disprove the hitherto, accepted "facts" and thus make it necessary to make changes to a profile. But: only with the agreement / consensus of close relatives? I don't think obstinency, or even genuinely misguided beliefs about an individual's identity, should take precedence over proven facts, which "close" family members might still refuse to accept, whatever the evidence. So, I stick to my current belief that anyone (regardless of relationship) should continue to be allowed to make changes (hopefully, always based on firm evidence) to any profile in Family Tree.
3 -
... Unfortunately, your "essentially complete" expression is not one I see as applying to genealogy / family history ...
Wow. Way to dismiss an argument. That's fine if you cannot see the benefit from my suggestions. Yes your counters do indicate areas where the suggested model may not work/benefit - but that does not deny cases/families where it likely would work and benefit - to establishing a more final, consensus driven profile. Yes I am still trying to establish and promote 'essentially complete' profiles ... Which I do need to refine into definition/examples which are easily interpreted (I have given many many descriptions but perhaps some still cannot see the meaning).
Obstinacy and proven facts should be resolved through collaborative consensus - in my current opinion - taking into account the input of nearest related descendants and any relations wanting to contribute to a Family Group. What I would wish to exclude is a distant, remote or unprovable relation from changing that established consensus of those near relations entered profiles (again with the idea that this model will likely be more easily established on profiles with near-related Living descendants). I am not worried about how the model may extend to further back ancestral lines - if a Family Group wants to establish that consensus - go ahead - they should have every right to do so - extend consensus driven profiles as far back as your Family Group can (yes individuals can make their voices heard).
As a simple example - for brevity of argument and to illustrate established consensus versus later source document 'facts' being discovered: take person A who lived their entire life at residence x. Does a fact showing they travelled to place y mean it affects residence x in the remotest fashion? I would answer no - residence x is sufficient to establish an 'essentially complete' profile for places connected with person A. Suppose Person A had a child (or throw in more family - aunt's, uncles, cousins that knew person A and contributed to Family Group consensus) that entered this 'essentially complete' profile of person A into Family Tree.
Now suppose another Family Tree user finds that record of person A travelling and because of distant/non-provable relation - and that they cannot currently in FS easily see that person A's profile is already 'essentially complete' - they change person A's residence to y - and because of that one change FS Record Hint engine kicks in with all sorts of sources for person A' (similar name is a common cause) and that starts morphing person A's (A not A') profile into a conflated combination of two people.
Anyway I could go on and on ... But it should be clear what I am trying to prevent with 'essentially complete' profiles... If person A's friends or non-relations want to contribute consensus to that profile - great - but does it change the 'essentially complete' consensus already established?
I furthermore wish to emphatically state: The child of person A's truthful assertions on person A's profile (and sure add in the corroborating consensus of a Family Group) alone - because of proximity/relation without records - is sufficient to establish person A's 'essentially complete' profile. That FamilySearch's Family Tree does not currently have the finalizing assertion elements - 'no more residences' for example - such that those assertions may prevent FS Record Hints engine (or any other FS user for that matter) from suggesting potential merge candidate person A' - is something to consider. Yes Family Group/consensus driven profile assertions - unless mistaken - should have a narrowing/finalizing effect - making profiles 'essentially complete'.
This brief simple example argument by deductive extention applies to any Family Tree profile for which Residence 'fact(s)' is a closed, known, and/or consensus agreed set (which is the case for many many profiles).
Am I disappointed that some user has the ability to morph a profile simply by their 'unknowing' assertion of person A's residence y? Yes. Can profile A and A' be separated and corrected? Yes. But my point is profiles A and A' should not have been conflated in the first place.
An 'essentially complete' profile therefore is very relevant to genealogy/family history. I'm surprised you would even dismiss it as irrelevant. Hopefully my simple example changes your mind.
0 -
Possible correction to my post above needed:
This brief simple example argument by [deductive/inductive] extension [from looking at definitions I can't decide which or whether both are applicable in this sentence - all I know for sure is that it is a reasonable conclusion that this ...] applies to any Family Tree profile for which Residence 'fact(s)' is a closed, known, and/or consensus agreed set (which is the case for many many profiles).
Im just making the case by extension from this simple argument that 'essentially complete' profiles are VERY relevant to genealogy/family history.
0 -
Oops another possible correction - lest anyone be confused: Residences are classified in Tree as Events not facts.
So for my example:
0
