Help get this topic noticed by sharing it on Twitter, Facebook, or email.

Special case for merging older PIDs into newer PIDs. Opinions anyone?

Normally I do (as has been suggested) by merging the newest/least detailed and sourced person into the oldest/most detailed and sourced one. Recently though, when splitting out the pieces of 2 families that had been built as one, I had reason to do the opposite. I would be interested in opinions as whether or not my reasoning was effective.

In “Family A” The oldest, more detailed profiles for about 7 children were included along with another 5 children. Parents were Samuel McWilliams and Mary. Samuel was born 1794 in Pennsylvania and Mary was born 1796. All ordinances including SP for entire family were complete.

For various reasons (mainly dates) it was obvious that all 12 of the children were not siblings, and therefore the SP ordinances for at least 7 of them had been performed to the wrong parents.

In Family “B”, there were 7 children that were duplicates of those in Family “A”. Parents were Samuel McWilliams and Margaret. Samuel was born 1786 in Pennsylvania and Margaret was born in 1799. All of Family “B” were clearly hooked together with a single source being the 1850 census.

Both sets of parent marriages and all 12 children births were in the same county in Ohio.

So I had a choice.

Choice 1:

1) Detach each of the 7 children (with their extra details and sources) from the Family A parents.

2) Attach them to the Family B parents.

3) Merge the existing less detailed children in Family B with their newly added duplicates

Or, Choice 2:

1) Merge each of the 7 children (with their extra details and sources) from Family A *INTO* the less detailed (and newer) duplicates in Family B. During the merge bring over ALL details from the Family A child EXCEPT THE PARENTS.

As you can see, Choice 2 performs all 3 of the steps in Choice 1 as a single step but requires the older more detailed duplicates (Family A) to be merged INTO the newer less detailed duplicates (Family B).

So what do you think? I used Choice 2 because for 7 children there were only 7 steps instead of 21 and therefor less chance of making mistakes. I understand that for someone to follow what the change history is for one of those children will be more difficult now, but since they are now correct and properly sourced, I don’t really care :-)

Would there have been some other advantages in this particular case to have used Choice 1? Opinions?
1 person likes
this idea
+1
Reply
  • 1
    Jeff,
    My thought process is to use whatever merging order makes sense to you. I do not agree that the older PID always needs to be on the left. As others have described in the companion thread, this approach frequently makes the most sense. But sometimes a opposite order seems more appropriate. For example, I have found a family with one child which is a very old entry as it was the direct ancestor of someone. Later someone added a census record for the family and it contained multiple children. I would put the later record on the left and merge the record with the single child into the larger family.

    The most important thing in my opinion is to be logical in what you are doing and to document with good reasons. In you above example, I have no disagreement with what you did because you were logical and I assume you provide good reasons. I would have not removed the incorrect parents during the merges but after all merging was completed, I would disconnect the parent because I could then give a good reason for removing them. I know others do not believe that is necessary but I am a little pedantic about making sure all steps that I have taken are documented.

    Thus If I had my choice all relationships would automatically be moved from left to right except for those already existing and there the user would have the choice. This becomes important because some couple relationships have marriage information and some do not and I want to make sure the relationship with marriage information is on the left.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • 1
    In a situation like that, and only having done a very careful comparison with both records for a single child, I would use Choice 2, since the surviving record (to be merged into) is already in the correct family.

    I would set aside a significant amount of time, prepare a todo chart, and then work on one child at a time.

    Normally, I merge either from the newer to the older -- or the less complete to the more complete. This is indeed a special case because of family relationships, which is why any automated merging system needs to be avoided like the Black Plague. (I'm not saying it is being considered, at least, I hope not, but some users want to make merging easier.)

    I would probably merge from the older and more complete record into the newer and less complete record, cleaning up the incorrect parent relationships in the process by not moving them into the surviving (newer) record.

    But...

    Before merging, I would want to spend time going over the older record's change control to see if there was a merge that should not have taken place. If there was, I would probably temporarily restore the record (on the beta site) to look at its history. Currently the beta site is undergoing a lengthy update (probably moving the production database into the beta database), so not everything is available at this time.

    By the way, I am thinking that the current threads asking that everything be moved with the ability to opt-not accept available, during a merge, would go a long way to make this and other merge-related tasks a lot easier.

    Joe Martel outlined some of the options to be considered for reworking the merge process.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • Jeff,

    I just completed a similarly joined family a few days ago, using a combination of your choices. (but there were 'only' nine children, as I remember)

    There is also the decision of when to consider any possible record hints. that should be found with the various persons involved. I, generally, waited until the reorganization was done after a couple of trials. And, of course, adding hints also can create MORE duplicates.

    The process of separating can be even MORE complicated than merging. Either process needs a lot of checking and verification to ensure there are no hanging duplicates in the families.

    Solution, more merge training (certification??) and cautions and explanations, in my opinion. This may be another example of why the phone app merging might need some restrictions.

    As far as the change history, it's already difficult to decipher, especially when all of the PID's change to the most current one.

    More emphasis on "Worthy of all Acceptation"

    Do it CORRECTLY, not quickly
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • I need to say that I've never yet come across a situation as complex as Jeff's - though I live in dread of my having the bright idea one day to look at the families of John and Elizabeth Billington in Nantwich - there are 2 such - John Billington and Elizabeth Williams, m1818, and John Billington and Elizabeth Boffey, m1829. I know that people have mixed the families up in Ancestry so I daren't think what is in FS FT.

    To return to Jeff's conundrum though - my concern with Choice 2 is that it does two things at once for each child - allocates them to the correct parents and merges them with their duplicate already there. That makes the reason statement messier and for that reason, I'd be inclined to follow choice one and, effectively, do and explain one job at a time. Though I think I'm right in saying that a safer way is to add all of them to their new parents first and then detach them from their old (basically, as gasmodels suggests) - that way, at no point do I have orphaned PIDs. And then do the merges. At any rate, that's my gut feeling....
    • This was suggested by someone else above somewhere that separating the steps makes it easier to track the reasons.

      Although sometimes I'm tempted to enter the reasons as "Isn't it obvious?!"

      but apparently to someone out there at one time, it wasn't :-)
    • Yes, the problem with the "Isn't it obvious?!" statement is that we can't see what you were looking at, at the time. However, I admit that I do find it difficult to explain politely without saying, "Look the PIDs for the parents are the same, the 2 children have the same name and dates of baptisms, so isn't it ### obvious?" Ooops, I did it as well... Well, tempted to... :-)
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • But whatever decision you choose, make sure you document in each change what logic your mind was going thru to make the decision you made.

    I checked the family you identified, and didn't see any descriptions of why you decided to do what you did, and what sequence of changes that particular relationship change was part of.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated