Please help merge Col Timothy Pierce

Hi G. I merged the 2 profiles, and I noticed a third that what a duplicate who just had daughter Phebe linked, so I put in a request to that manager since it is still marked as private. So when you go to the main profile main for him, you will see

Review Requested Merge

I also merged the duplicates for his parents that were created when merged.

Erica Howton

there seem to be some conflicts on his father Erica has to look at (any curator) due to some profile locks. FYI.

Private User also there were a couple of kids/grandkid duplicates I merged...
His son Benjamin has a number of wives linked. If you are working that family group, the one named Hannah (Smith) Pierce has a son Nehemiah who is young enough to be his grandson... but there is always one named that with a slightly different birth date and wife... FYI

son of Col Timothy Pierce
Benjamin Pierce, Fr/Ind. War Vet.
here is 1st wife Hannah with son Nehemiah b. in 1730s (seems reasonable)
Hannah Pierce
but she also is linked to a Nehemiah as a son who was born in 1780s after she died. Maybe you can figure it out... or if not, just unlink him from her and let him float to find his family.

Thanks Dean, I will clean up what I can

best, G

Hi Dean,

I cleaned up as many duplicates as I could find. The only loose end is the following:
Jonas Whitmore Shepard
Jonas Shepard needs duplicate parents merged, but one set are MP. I'm always hesitant to merge onto an MP.

Thanks,
Greg

Thanks :)

Private User Merging a profile into a MP is actually "easier" and I think better than when two 'normal' profiles are merges. At least most of the MP (should be all, but some might have been 100% correct when made into a MP but have since changed due to later revisions. However, the locked ones are the best, because you have to assume that someone did some type of research prior to making it MP. Although not guaranteed.

When merging the 'standard' into the MP, all the data in the MP fields overwrite the other. The problem comes if the 'standard' has some other fields filled in and the MP is not locked at those fields... then it starts getting potentially more corrupted. But at least someone is looking at the potential match before accepting the merge.

Conversely, when you just merge two 'standard' profiles, it happens immediately with no one else having a look at it. Just be careful on every profile you check about merging. I use the Descendants and Ancestors comparison everytime to see how much green text I see (exact same profile connected).

Where I get tripped up is when I stack, say, a bunch of siblings and as I go through them, I am not paying that close attention because I already knew when stacking that they are the same -- but sometimes the software is 'sticky', and the wrong sibling gets put together.

That or when I see that they are NOT the same, If I have had a long run of say 50 to 60 profiles in a family group where I come across a couple of intersecting branches that aren't completely merged... I will just automatically hit Merge out of habit instead of NOT a MATCH. Then I have to ask for help to unmerge what I did.

Erica Howton I was thinking that keeping the "data conflict" would help future researchers see what others have used. A lot of times I come across Merge Conflicts that are obvious to fix (parents date too young, or obvious duplicates but, say, one is using the Old Style date and another person used the New Style. Typically, for those that I don't have to do any additional research and then keep moving through the conflicts to get the family group or whereever the unmerged branches take me until I can get to the end of the new tree.

Otherwise, I would only know which to select if I was researching. It leaving it there after merging is bad, then I should not be merging those unless I am willing to take the time to research. Many unrelated profiles I move on if it isn't obvious or I wasn't the cause.

Thanks for your insights Dean. I have merged MPs before, but have also messed up & received some nasty correspondence, so I have become hesitant. Especially when I first made my tree public I didn't quite understand how to properly make revisions. I always wondered how it decides which information is accurate when it does not ask you to compare the merges.

thanks, again,
G

Private User What exactly do you mean by this. who is "it decides", what is it deciding on, and when does it NOT ask you to compare profiles.

I mostly use the horizontal tree view to move through the tree because I can see family groups, generations with grandkids, etc, many of which are sometimes linked to the wrong parent.

If I see a yellow triangle with a Merge Conflict lower left of the profile box, it automatically compares the profiles side by side. At that screen you can look at ancestors and descendants (links at bottom left). and she how much text is in green. Green means either similar in terms of date ranges when none are given (Geni estimates a date based on the linked family members) or exactly the same profile that is already shared. Red means trouble.. so pay attention.

Or if I see the blue box upper left, clicking that opens up a side by side comparison.

I don't understand what you would be doing or looking at that you can merge a profile withouth looking at them side by side. Even if you are in the main profile page, and pull down Merge Duplicate from menu upper right... and then type in a name,, even that way shows them side by side before the merge. So you can reject it or accept it. And when you reject it, you can take the additional step of marking that "not a match" for everyone in Geni, so it goes away. For ones I am not sure, I just click on "will consider later". and it leaves the conflict and/or possible duplicate signal for others to see in the future.

The other part of your question is "how it decides which information is accurate". YOU are the one making that decision. So you need to research unless the duplication (or not a match) is so obviously that you can immediately say No.

When merging, the profile on the left when compared side by side is the one where it will overwright any fields filled in... but if there are blank fields and the one of the right being merging into it has different things, it will pull over that info... so you still need to be paying attention when you compare.

Occasionally, I see during the comparison that the dominant one on the left is wrong, so it is quicker for me to go back to the tree, edit that profile (or just make it blank), and the 'correct' info from the one on the right will fill that field. Differences in dates, name spellings, and names of locations will vary widely because of the details but actually be the same. When those are the same, I just leave the data conflict, since someone researching in the future can pick which is the one they want on the profile. Sometimes there has to be a consensus of the managers. With some info, there is still disagreement over what it should be, so those things definitely need to be explained in the About Comments.

Also, Old Style and New Style dates, and Quaker dating will always be problematic because so many people are confused by that and there is so much info already floating around that it is hard to say what is the "correct" one without looking at the original doc. (and by original I mean hand written by a clerk and NOT the later copying, transcription, or computer scanning that can get numbers and letters wrong. This is important in wills, deeds,... I have even found mistakes in transcription when I looked at my 4th great grandparents marriage intentions and later marriage recordation. When you look at the original, you can see clearly that the info chosen has extended from the adjacent entry and does not apply to the people I am looking at. There info is clearly something else, but whatever transcribed the info took the part from the adjacent entry that fell down onto my ancestors' entry line. You can tell lookinp at the original, but not anything else because it gives the false info as 'fact' and doesn't contain the actual info.

For example.
Plymouth Colony, Mass
Plymouth, Plymouth County, MA, US
Plymouth, Mass
Plymouth, Plymouth, Mass
Plimouth Plantation, Colonial Massachusetts

Those are the same but will create data conflicts.
For locations, the GENI program requires current locations to enable the mapping feature to operate correctly. Some people think they need to use the location name at the time (but those have changed so much over time, that many people lived in multiple counties (or states like VA then West VA) that you would have to include all of the names and then it doesn't make sense.

In my personal tree at Ancestry, I use the name of the place where the records are found if I know it, even though the county name might have changed and later info at the new county location, but the older records remain at the old county. This is for purposes of research. Otherwise, in Geni, I use the current name to be able to map them... but so many people don't do that, that the mapping features isn't useful unless you have confirmed each profile.

I just meant that sometimes when I do a merge I am not presented with the side-by-side comparison. I am thinking it is because I was merging to a master profile & it defaults to the info in the master profile, but perhaps I'm wrong. I know that it is up to me to determine the correct info when it differs. When there are glaring differences I generally do not complete the merge unless I am completely certain.

Private User My understanding is that it will always give you the side by side so that you can say Yes, No, or Will Look Later.. AND you have to remove the notice for everyone or just you.

Maybe they were 2 profiles you managed by yourself?

I just know that some people are confused by merging because they don't know exactly how the parts function, and with the database management aspect to GENI, it is many times better to merge even with differences if you can tell that they are meant to be the same person, than to leave both separately linked. It affects future links to the family group and potential conflicts.