Please check Parents when proposing merges

Question

First-Thanks so much for all of the work everyone is doing on the DB_Errors project...your work is essential.

This message is for those who are working the DB_errors project and anyone else proposing merges.   Please make sure you understand how to work merges.  

1) Please read the profiles for Warnings/Cautions about previous attempts to merge similar people.  (not all duplicates identified by the data are real duplicates)

2) Please make sure the parents match, if there are duplicate parents/grandparents, etc. please propose those merges also.  ( no merges should be done if the parents are different, the parents either need to be merged first or the correct parents need to be identified)

The Arborist project is going to start working the error codes that indicate duplicates because it does take some work on some of the profiles to understand whether they are duplicates or not.  Specific cases have to do with two men with the same name born in different regions that just happen to both have a wife name Mary "unknown".

Comments

http://www.wikitree.com/index.php?title=Special:MergePerson&user1_name=Howell-4760&user2_name=Howell-4772&action=compare

Here's one where both profiles have the same sources.  Same 1850 census, same Find A Grave, same DOB, same DOD, same husband..but different parents.  Simple solution would be to disconnect the parents that aren't sourced and leave the parents that are.  But what if there is a Wikitreer that is seemingly doubting their own work and wants to have both options (which can't be I know).  File an MIR, contact a mentor?

---

http://www.wikitree.com/index.php?title=Special:MergePerson&user1_name=Weeden-1725&user2_name=Weeden-1723&action=compare

another one where a choice of parents needs to be made but must be the same

---

That one with the Howells is a good example.  Although not the point, its easy to solve.  James is the brother, William and Jane are the parents.  But yes people often would hold off on a merge like that and then not fix the data.

---

On the Weden example, the marriage data is clearly unique, meaning it represents only one real person.  There could have been 2 Pelegs born 6 years apart in different towns to different parents.  But only one of those could have have that marriage data.  So, at least part of the profiles is clearly duplicated.  The question is what can we do about things like this?  No one wants to take charge and force the duplicated data to be removed, or really require anyone to take any action at all.  Often, nothing gets fixed.

---

And right on cue the Howells are rejected

Of course they'll now get 205/305 as well.

---

What is 205/305?

---

205.305: Father/Mother too young or not born

Answer 1

I don't normally do merges as part of db_errors, just the lines I'm related to, just to put it into context.  If I have or will propose merge based on db-errors, I most likely will leave it for PM/TL to complete.

Anyway, one problem I see is that members here have wrong parents attached and that is used as an excuse to reject or unmerge match, rather than correct the parents.  It's also very common for profiles to have other data that represents multiple real people (and the PMs will not correct) to the extent there's often no way to discern who the profile is meant to represent.

I have a few profiles I don't want to see merged because the other PMs won't make any changes.  I've added notes to at least some of these warning against merging, but I'm not sure that others who come along will honor that.

Comments

I've been thinking about this some more and...

The way WikiTree lists children makes errors harder to spot and to understand.  The children of multiple spouses are all grouped together and birth dates aren't visible (except tooltip on hover).  A more conventional, Family Group Sheet style list would help aid spotting errors.  I personally prefer the way my genealogy program attaches children to both parents, but even with WikiTree's approach of attaching the children separately, a change in the display format would still help.  The dates for the parents of the current profile should also be visible not just in tooltip.

---

Family Groupsheets view /treewidget/<WikiTree ID>/300

/treewidget/Haden-90/300
/treewidget/Viberg-1/300

lists all children that is part of a family ==> Lindner-118 with father unknown is not part of the mothers family Groupsheets view
/treewidget/Lindner-119/300

EDIT: Suggestion above page is maybe a better view to see a family

---

That's not what I meant.  I meant the data display at the top of each profile.  And even that view is still not a traditional FGS.  But nothing will change so it isn't worth pursuing.

---

If you go to the bottom of every profile there is a link that says " more merging tools for XXX"   it is usually right above the Rejected Merges list.

Hit that link....and you see what I think you are looking for...or at least something that helps.

Answer 2

As I answer this, I recognise that this is an old thread - but a thread that still incredibly relevant.

My process when identifying potential duplicates is
1) Check the profiles (Sample 1 and 2), looking for identical or closely similar dates and locations of both birth and death, and which sources are used on both samples. As well as checking the profile id
2) From there I check the preceding ancestors (maternal and paternal) for both samples (if relevant) for the same information as listed in 1)
3)Repeat process for an listed spouse
4)Repeat process for an listed children.

By now I can usually have a dozen or two extra tabs open because of the initial sample comparison. Then (if I'm confident that my assumption is correct, then for each pair of profiles I've identified, a merge is filed along with the relevant points and any assumptions I've made, as well as any suggestions to check before merging)

Oh and a lot of the merges I file are because I'm minding my own business working on a particular part of a family and a search for a particular name also featuring names of what turns out to be duplication