merging duplicates
LegacyUser
✭✭✭✭
Leland Moon said: I just had to look at 30 possible duplicates that were not correct. The husbands name was the same but thee was a different wife on almost every occasion. That was a waste of my time when I could have been entering names into FamilyTree. Shirley you can write a better algorithm for merging!!!
Tagged:
0
Comments
-
Brian Jensen said: Hi Leland,
Thanks for your post. Can you share with us specific examples (Person Ids) of these bad possible duplicates?
Thanks,0 -
Paul said: With respect, Brian, I and others have given plenty of examples, so is there any point in providing more? Like Leland, I still get the same crazy possible duplicates - wrong surname, wrong area, even wrong first name. There are serious problems with the algorithm, which are not only wasting users' time in dismissing these offerings, but in having to undo merges that inexperienced users believe must be completed.
Does no one see the seriousness of individuals being "deleted" (FamilySearch terminology) from the system because of the far-too-loose current algorithm? If users don't have a very long watch list, they probably have no idea their ancestors are being wiped from existence!
Hopefully - once the engineers have ironed out its current problems - the revised merging process should help to limit the damage, if not cut down on the large number of mismatches being offered.0 -
J. Matthew Saunders said: I do agree that "deleting" individuals doesn't seem to be taken as seriously as it should be...0
-
Tom Huber said: Uh, unless something has changed, merge-deleted persons can be traced to the surviving record (of a merge). I typically use Ancestral Quest and it will update my local database to the current PID if the original was merge-deleted.
Physically, when a person opens a merge-deleted person, they will see a link to the surviving record in the Person Deleted window. However, that record may have also been merge deleted, so a user may have to go through a number of them.
The bigger issue is not tracing the person to the existing surviving record, but see enough of the merge deleted record to tell if it should have been merged or not. The change log is often very difficult to decipher in those cases, so it can take some work to figure out what the merge-deleted record contained (without restoring the record). There is a discussion about this issue at https://getsatisfaction.com/familysea....0 -
J. Matthew Saunders said: I read the other discussion as well, and am familiar with the process. I guess what I have read so far is that there is a lot revolving around the merger process and how to make it better and also the fact that some may just merge without making sure it should be merged...a very big subject....0
-
Tom Huber said: Yup.
I always try to specify "merge-deleted" since the record is not actually deleted. Part of it can still be viewed (but not enough, in my opinion).
The reason I specify merge-deleted versus deleted is that for a period of time, users could (and did) delete a record/profile, effectively hiding it from view.
If a user knew the PID, then the record could be partially viewed, just like the merge-deleted record, and restored, just as we can restore a merge-deleted record. But without the PID there was no way to know if someone had deleted the record or if it ever existed.
Once FamilySearch realized this was a problem, they changed the process so that only the user who created the record could delete it and only if no one else had worked on the record. Once another person worked on that profile, the only way to get rid of it was to use the merge-delete process.
Unlike the non-merge-deleted records, where the PID of those records cannot be found by a search/find routine (even though I and others asked for the means), the merge-deleted records leave a trail to the surviving record. And the surviving record should contain the original PID in the change log.0 -
J. Matthew Saunders said: Good to know, and good to learn more. It took me a long time before I would merge anyone even if it could be recovered.....If you do it right, you make sure all of the i's are dotted and the t's are crossed, and then fewer errors occur....I look forward to more insights as I read and listen.....0
-
Paul said: Tom
The problem I am specifically referring to is one whereby I create an individual (I have probably worked on / created thousands over the past year) but do not (or have not got the capacity to) put them on my watch list.
Having no direct interest in many of these IDs (not ancestors, but possibly very distant relatives) I have returned to these "by accident" and found they have been merged with totally different individuals. For example, one user had merged several individuals named James Young who had wives / children with different names and lived throughout England. Other users have merged my WRIGHTSON relatives with persons named WRIGHT.
This is okay (well, not really) if I have the individuals on watch, but how many of these incorrect merges am I missing? I am sure most of the problems arise because the FamilySearch algorithm offer them as possible duplicates - in spite of the fact they have little in common with the individuals I have added. I know this from the examples I come across elsewhere, and that I have to declare these suggested duplicates as "Not a match" when they again return to the person page(s) as "possible duplicates" after I have undone the merge!
So I must emphasise, the real problem is not the waste of time in correcting these highly unlikely matches that inexperienced / careless users have chosen to merge (on "FamilySearch's" suggestion), but the ones I am NOT picking-up and whose whole profiles are thereby disappearing for the foreseeable future: tangled-up with another ID as a "composite" person.0 -
Jeff Wiseman said: Yes. Why aren't the PIDs included in the change log? There are links there to the person that was merge-deleted, put you have to navigate all the way to the deleted record to see what the PID was.0
This discussion has been closed.