Why is a profile offered as a possible match immediately after being effectively dismissed as such?

Paul W

I know this is not a new issue, but I haven't had this occur in quite a while so thought I'd show this as an example, while I had one to hand.

Another user incorrectly merged two John Greengrass individuals of different generations. As shown, one died around 1644 (date of will) and the other in 1753. I restored the "deleted" individual (along with his wife "Ann"), but immediately am offered both the restored individuals as possible duplicates of the individuals they had been incorrectly merged with!

Had I quickly left these pages, the suggestions would have remained and it is quite likely an inexperienced user (or even the one who had carried out these incorrect merges) would have repeated the same actions.

Is there no way to prevent these suggestions (e.g. "Possible Duplicate" for individuals who died fifty years apart, who have just been unmerged for this very reason) from appearing on the Details page?

Gordon Collett

Here I starting merging two siblings using Merge By ID and marked them Not-A-Match at first opportunity. That gave a notification both under the Change Log and the Dismissed Help tab:

The appearance is the same when starting from a Possible Duplicate:

I'm pretty sure that you only get the "These 2 people have previously been declared Not a Match" message if you are merging by ID and the two profiles are currently marked as not a match, that is, you would see the people you are trying to merge on the Dismissed Helps tab of both people. For example, if I tried to merge Sarah Gaskins and Sarah by ID now without first clicking on the "May Be A Match" link that is cut off in the last image, the message would appear.

Gordon Collett

One last check.

I deleted Ann and made sure the possible duplicate flag disappeared:

Then used Merge By ID:

No "these were so many years apart" caution came up so this part of merging does limit itself to comparing individual lines, that is, just birth to birth and christening to christening, not birth to christening, etc.

Adrian Bruce1

Some thoughts - not, perhaps, very certain. What I always do in a case like this is:

1) Check if PID1 is (again, I guess) being offered as a dupe of PID2 - if so, I (counter-intuitively?) start the merge process and then, at the appropriate point, declare that they are "Not A Match".

or...

2) Manually start the Merge By ID process (again, counter-intuitively) and at the appropriate point, declare that they are "Not A Match".

What concerns me is that on the two options above, I have marked both as "counter-intuitive". Yuk. How many people will either

• Leave the system-suggested dupe (as per option 1) for someone else to merge (as per @Paul W 's suggestion) or
• In the case of option 2, do nothing, with the possible result that a minor tweak to the algorithm or one profile's data later recreates a dupe suggestion again.

In the case of option 1 - the immediate suggestion of a dupe - I have to say that it's not something I've often seen recently - perhaps due to tightening of the merge-suggestion algorithm? Paul's suggestion would, I think, effectively be the same as an automatic "Not A Match". Unfortunately, I have to say that I'm not convinced that this is necessarily a "good thing".

Could there be some circumstances in which I might want to undelete a profile, do some investigative work on it, and then remerge it back into oblivion? Perhaps if there were a chain of merges and it turns out that the one that I really need to "unmerge" was a couple of layers back? It's not something I've ever come remotely close to doing so I'm unclear over whether this is likely.

Gordon Collett

Looking at both records and their change logs, I see that you got the possible duplicate flag to disappear without ever marking them as not a match by repairing all the relationships that got messed up by the merge.

I see an advantage with having that flag appear right after restoring or unmerging in that it acts as a notice that something in the records is causing it to appear and to make sure that all incorrect information, incorrect sources, and incorrect relationships are removed if that is the reason.

Just a couple of days ago I had to undo all merges on a profile to break it back down to the original six to sort out what had happened. There were all sorts of incorrect possible duplicates suggested on them until I got the incorrect residences and incorrect birth information off which had been added to the final person through the merges off the profiles where they did not belong. When I merged four profiles into one and the other two into one then made sure all the sources were attached to the correct final two profiles and all spouses and children were where they belonged, all the possible duplicates disappeared.

Maybe there should be a reminder pop up after unmerging or restoring to be sure and go back and fully clean up both profiles. Something along the lines of "You have successfully unmerged AAAA-BBB and CCCC-CCC. They are certain to show as possible duplicates because of information or family relationships not repaired by the unmerge/restore process. Please carefully evaluate and clean up both profiles. If after this they still show as possible duplicates, be sure to mark them as Not A Match."

Paul W

Thank you for your comments, gentlemen.

I will try to attempt further work on these profiles later, as per suggestions. However, I am fairly sure I had first put right all the incorrect relationships that had been created following the merge. In connection with this, I am interested to find that my action of marking the two IDs as "Not a Match" (from the Research Help link on G7GW-SHB) does not appear in the change log. I had thought that all actions were recorded there, but obviously this it not so. Therefore, there is no proof as to at which point I marked as "Not a Match", although (as I have suggested) I was sure all the "reverts" were carried out first.

(See https://www.familysearch.org/tree/person/changelog/G7GW-SHB - no record here of my action in declaring Not a Match with L83P-HH2. I assume such actions are never recorded.)

Gordon Collett

This is very strange. They are not marked as "Not-A-Match." Otherwise that would show here under dismissed helps and it does not:

Áine Ní Donnghaile

I was certain I had seen "not a match" notations in my Following list recently, but I had to scroll back to July to locate one: https://www.familysearch.org/tree/person/changelog/97JS-MYL

Paul W

Not sure how far I will continue with the (re)merge at this point, but note the warning at the top of the page. I thought I had seen a message like: "These 2 people have previously been declared Not a Match". But maybe a message relating to a previous merge would take precedence in cases like this.

Being sure the previously entered 1753 Burial date was not compared to the 1644 Death date, I confirmed that a flag only occurs relating to this after a 1753 Death date is inputted. That is, a Burial input is not compared to one for a Death - as there was no flag until after I added a Death to L83P-HH2 just now.

Paul W

@Gordon Collett

Now you have made me doubt my actions! But I was sure (earlier today) that I had made a "Not a Match" declaration and that is what made the "Possible Duplicate" Record Help item disappear. Am I perhaps imagining this and it disappeared "by itself" once I'd reinstated all the relationships to how they were before the merge?

(My first screenshot shows at least I did not imagine the Possible Duplicate suggestion!)

Update - I just entered Not A Match on the page illustrated immediately above and now do have this (later) action recorded in the change log! However, this is not really comparing "like with like" actions, as the former example related to a Record Help item and the latter to a "Merge By ID" I instigated without there being the Research Help item on the Details page.

Adrian Bruce1

@Paul W said

However, this is not really comparing "like with like" actions, as the former example related to a Record Help item and the latter to a "Merge By ID" I instigated without there being the Research Help item on the Details page.

I think I agree. I would have guessed that setting "Not A Match" in response to a manually initiated "Merge By Id" need not be reported in the same way as a "Not A Match" in response to a Record-level Help item. The latter seems likely to appear under "Dismissed Help" (as @Gordon Collett highlights). The former, I guess, would not count as a Dismissed Help. It just feels that way to me based on my experience as a programmer and my experience of FS.

Paul W

Thanks again for further responses. Had to take time away from here, so haven't been able to respond sooner.

Perhaps I have dragged the discussion away from my original post: about getting a Research Help "Possible Duplicate" suggestion following a restore of an ID because it was found not to be a duplicate.

Sticking to that for a moment, I wonder if the algorithm "starts from scratch" in these circumstances and just whether the item would not have "reappeared" had the Death fields on both IDs been completed earlier?

Now - generalising again on the wider subject of the algorithm that offers these "helps" - I will have to keep a look out for whether a burial is ever matched with a death. On the Details page (at the top), on the Pedigree view pages, and in ones "Following" section, Burial data is substituted if the Death field is empty, in the same way that Christening data is substituted where the Birth field has been left blank. (This was not the case in the early days of Family Tree.)

There appears there might be an inconsistency here in that the "Possible Duplicate" algorithm does not match these respective items in this manner. Hence, we continue to get these suggestions against individuals who lived in different centuries unless we do enter data in the Birth and/or Death fields.

A shame if this is the case as, whilst I do not want to be presented with ludicrous Possible Duplicate suggestions, neither do I want to add data to the Vitals for which there is no evidence. (For example, I leave the Birth field empty if the date is not found in a Christening source - or elsewhere - as some of my relatives were christened some years after their births and I prefer not to add guesstimates to their profiles.)

In short, I will need to keep an eye open in future as to whether these suggestions reappear (after a restore / unmerge) just under specific circumstances, or if this is "automatic". Gordon's suggestion of other relationships not having been sorted out first (e.g. removing / reattaching all the spouse and child relationships, too) also appears to be a valid one.

Sorry if I have sent anyone to sleep here, but the interesting thing to come out of this, for me, is the apparent inconsistency regarding the substitution* of a missing Birth vital with a Christening one (and Death with a Burial) in some areas of Family Tree, but not in others (primarily, the Possible Match algorithm).

(* I believe Gordon uses the term "proxy events" where this applies.)

Christening and Burial events are substituted for the missing Birth and Death, at top of Details page (and elsewhere), but this apparently does not happen when it comes to the Possible Duplicate algorithms:

Paul W

Sorry, also, if I have not directly acknowledged some of the comments / responses made here - I have taken everything in, though!

Julia Szent-Györgyi

It'd take some testing in Beta (that I don't currently have time for) to figure out whether the proxy events are ignored by the matching algorithm, or just by the alerts. I know that the alerts are highly (and infuriatingly) literal-minded: they told me just the other day that Eric and Erich might be twins. I can't believe that the Possible Duplicates algorithm could function with that degree of, um, stupidity, but maybe I'm wrong: maybe the unflagged duplicates that I've been attributing to unentered dates or relationships really are due to spelling differences?

Gordon Collett

A nagging question all night. A calm, quiet morning when I should be working to actually get something worthwhile done in Family Tree but the need to know is rather compulsive. It all adds up to the following for which I will apologize in advance.

Working in Beta, I created two gentlemen of the same name with no other information. They are not flagged as possible duplicates after plenty of time and plenty of page refreshes for the system to flag if it was going to:

Adding the same birth date to both triggers the flag:

I removed the birth date from the one on the left and refreshed a few times to make sure the flag vanished, which it did, then added a christening date on the left identical to the birth date on the right and the flag came back:

I then increased the christening date by ten years and the flag vanished:

I then deleted both the birth date and christening date and put the same death date on both profiles. As expected the flag reappeared:

I then deleted the death date on the left, refreshed until the flag vanished, put in the same information for burial date, and watched the flag come back:

I then increased the burial date by ten years and the flag vanished:

I then left the ten year difference between death and burial but added the same spouse, with same ID, to both men:

The possible duplicate flag came back.

Conclusions:

1. Same name has low priority.
2. Birth and christening information are treated as the same information.
3. Death and burial information are treated as the same information.
4. Relationships are given very high priority and will override conflicting birth/christening and/or death/burial information.

Paul W

Thank you so much for spending your valuable time on this, Gordon. (I feel quite guilty now about raising this / these issues.)

I must say I am particularly surprised about the comparison that there does appear to be made between Death and Burial events. I remember joking in the past (in good old GetSat days) about FamilySearch's seeming to think so many people must have been buried alive - because it was ignoring the fact (back then) that a death must have preceded a burial.

Even in the example I illustrated above, it was not until I entered a 1753 death (for the John Greengrass on the left) that there appeared to be a comparison made with the 1644 death to the right: the "These 2 people died more than 3 years apart" flag not having appeared when only the 1753 burial date had been inputted.

So, there still appears to be some inconsistency between the algorithm that triggers the flags in the example illustrated (e.g. when undertaking the MERGE BY ID process) and the one that presents a Possible Duplicate under Research Help.

Again, thanks again, and so sorry to have taken up time that you could have spent so much more usefully in your personal research!

Adrian Bruce1

@Gordon Collett said:

"... the need to know is rather compulsive ..."

I understand that feeling! In this case, I wasn't sure whether the requisite background routines ran in Beta so didn't fancy possibly wasting my time wondering what - if anything - I'd proved. Or not. And I'd no doubt have missed the bit about "... refreshed a few times to make sure the flag vanished ..."

So thanks Gordon.

Gordon Collett

My time's not that valuable! It was a fun comparison to run and I never mind learning anything! One last item that I must have forgotten to click post on. I went ahead and deleted the spouse, left the ten year death difference, made sure there was no possible duplicate flag:

Then tested merging by ID:

There was no "these events are so many years apart" warnings. So this part of the merge only compares single lines, that is, only birth to birth or christening to christening and does not compare birth to christening, etc.

Gordon Collett

(Sorry for the duplicate post, I forgot about the feature here that pulls a post out of order and moved it to the top of the list if it is marked as an answer.)