The reason behind MERGES and identifying the lowest numbered profile with the correct last name at birth.

+61 votes
2.5k views

To answer your question in regards to the lowest numbered original profile.  I will try.

Deep breath.  Exhale.  (it is confusing)

We have the following profiles:

  • John Pike [Pike-214] (November 1, 1572 - May 26, 1654)
    John Pike [Pike-52] (1574 - May 26, 1654)
    John Pike [Pike-49 PPP] (November 1, 1572 - May 26, 1654)
    John Pike [Pike-320] (1574 - May 26, 1654)

And previously, there was a Pyke-20 (I don't remember the real ID number but for an example this purpose will work).

 So, if we look at these, and do a little research, we find that the original and correct spelling is PIKE.  From there, the first profile made with the correct name is Pike-49 (this after searching through Pik, Picke, Pyk and going through known spouses to locate perhaps other spellings and profiles), so I Project Protected the Profile (PPP)  it to keep it stable while merges go through and for the project.  If it didn't fit into a project, I remove the PPP once the merges are all completed.

 All of the duplicates including Pyke-20 need to go directly into the lowest numbered, ie originally created profile that has the correct last name at birth.  Even though it appears that since Pyke 20 has a lower number and ergo was probably created BEFORE Pike 49, it's the wrong last name, so merges are set up for 214 into 49, 52 into 49, 320 into 49, and Pyke 20 into Pike 49.  Preferably not 214 into 52 and then into 49.

 Okay, Deep breath.  Exhale.  Did that make any sense?

 The technical reason for this (for those of you that have that question....why, what difference does it make...I should have been from the "Show Me" state too) is that each profile has a URL or http:// address associated with it that is unique.  When a merge is completed, the software searches for the first URL and then redirects it to the one that it was merged into.  Now, if that profile is merged, and merged again, and again, the software is redirecting multiple times to the final merged profile.  Ever see that little circle running for a long time, and wonder what is going on?  Probably multiple merges back and forth rather than into the final correct profile.

 So, in conclusion, it may take a little bit more time to find the first profile (and if you need to protect it because of a bunch of duplicates, contact a supervisor at:http://http://www.wikitree.com/index.php?title=Special:Badges&b=supervisor ), but it will save all of us a great deal of time in the long run as we watch that little wheel going round and round.......

I would like to take a moment to personally thank Robin Kabrich-1 for asking this question.  laugh

in Policy and Style by Living X G2G6 Mach 5 (57.6k points)
edited by Keith Hathaway
I just have a couple of questions, the first regarding the merging Pyke-20 and Pike-49. While I am Stuckenborg-1, my great grandfather is Stukenborg-1. If I were to merge these two, I would be Amercinizing my ancestors name. Obviosly I would not knowingly do this, but this can get very confussing as vital records list him with his American name, but he's tombstone has his German name. Which should we use?

The second question is more of a proposal. If the goal is to have the lower numbered matching surname be the one we merge into, wouldn't it be easier to force this behavior instead of relying on us very fallible humans for this task?

I forgot to add that having the original id number for the profile helps us identify suspected duplicates in our watchlist. If someone transfered Smith-143 to Smith-59432 duplicates would be harder to spot. I actually used a spreadsheet to sort by these numbers as the larger id's are likly to have a matching lower id.

Mark, I'm not sure why you'd merge your profile with your fathers.  So not sure what you're getting at with that question. 

The profile name uses the last name at birth so for your father, he should remain Stukenborg.  Current last name is the spelling at the time of death or currently used if still living.  If there was more than one spelling, use the one found most frequently in records contemporary to the time of the person's life.  

Wikitree does "force" merging profiles with the same spelling into the lowest number.  Where it gets tricky and careful human consideration is required, is when the spelling is different. See Nae's explanation above about Pike and Pyke.  

Okay.  The last name at birth or LNAB is where the ID comes from.

Grandfather was born Stukenborg, but throughout his life it was "Americanized" to Stuckenborg, and yet when he died, the family spelled it as it originally was.  So the correct LNAB is Stukenborg.  Current last name would be Stuckenborg (even though his gravestone says otherwise).

Two important reasons for this.

If one searches for grandfather Stuckenborg or Stukenborg, he will show up in a search.  It will also reflect that both names were used in his lifetime.

 

If you found a duplicate for grandfather, let's say Stuckenborg-23 (which indicates his LNAB was with the letter C) and you find Stukenborg-1 (which you have identified and documented as the actual correct LNAB) the merge should be set up to have Stuckenborg-23 go into Stukenborg-1.  The alternate spelling can still be listed in the current field to enable finding either spelling for grandfather in a search.  Does that make sense?

And as Jillaine said, it does get tricky when alternate spellings or even unknowns are involved and the "human" factor comes in to play.  I have done this myself, with a Known LNAB went into the Unknown LNAB, so mistakes happen, we just try not to do this too often. LOL.

And also regarding the Smith-45678 and Smith-123, the system will automatically prompt you to reroute it to the lowest numbered profille.  Smyth verses Smith or Smythe is another story though.  :)

Jillaine said: "Mark, I'm not sure why you'd merge your profile with your fathers.  So not sure what you're getting at with that question. "

cuz I am a noob and I don't know fully how to express myself yet. Nae answered my question, albeit slightly confusing, I do not believe there is a better way of explaining it than when it comes from him. I belive he knows how us rookies thinkcheeky

Over the past week that I've been active at wikitree, I've been asked several times to reverse the order in which someone else has suggested the merege. Obviously we are not being 'forced' to adopt the lower LNAB(hope I used that right). When I reversed my first with the same spelling to merge the higher with the lower LNAB, I was hesitant as I knew this rule, but could not figure out why someone would intentanally do this or, better yet, why am I even given this option? Am I wrong for reversing the numbers to the 'proper' order and why am I given this option?

Edit: I just found out Nae is a she. So a few more edits, and an appology goes out to her.

I updated my last post. Last name at birth = LNAB, got it. I did not read through a second time before posting. If I did I would have seen my answer right above were I was typing. You see what I mean about Nae thinking like a rookie, yet has killer skills.
Let's use grandfather again.  I will try and clear it up a bit.  We have several profiles (Imaginary)

Stuckenborg-26

Stukenborg-30

Stukenborg-14

Stuckenborge-10

Stuckenbourg-12.

At first glance the Stuckenborge-10 is the lowest numbered profile, but you have determined and documented that grandfather's correct last name at birth (LNAB) is Stukenborg.

The merges should all go directly into the profile with the correct LNAB and the lowest ID number.

So with this Identified as Stukenborg-14, all of the other duplicates should be merged directly into Stukenborg-14.

Stuckenborg-26 gets merged into Stukenborg-14

Stukenborg-30 gets merged into Stukenborg-14

Stuckenborge-10 gets merged into Stukenborg-14

Stuckenbourg-12 gets merged into Stukenborg-14

This is a very complex issue, so I hope this helps.  :)

To answer your last question of why it would let you set it up say Stukenborg-14 into Stukenborg-30 is that it has to do with how you enter it in the boxes.  If you are on the propose a merge screen the top profile goes into the lower profile.

If you are under the EDIT tab and then the subscreen MERGE, it depends on which profile you "check" first to compare, and likewise on a name search page.

 

If you go to a Stukenborg-14s profile page and scroll all the way to the bottom, on the left is a link where you can "initiate" a merge.

If you do it from Stukenborg-14 and intiate a merge with Stukenborg-30, it will initially be set up for 14 to go into 30, but the system will prompt you to reverse it before allowing it to go through since the last names are exactly the same.

Now if you are on the profile page for Stukenborg-14 and initiate a merge with Stuckenbourg-12, it will not prompt you to reverse it.  WHENEVER the last name is different, THAT is when you have to be sure to have it set up in the right order.

Now if I find a duplicate which I have no clue as to which is correct, and don't want to delve into the research, in the message box for the merge proposal I always have the first word be "STOP! " With a detailed explanation.  (I do this also when there are other discrepencies such as dates or parents).  I don't know if it works but it seems to from the response I have had.

No apologies needed.  :)
Got it. Thank you. I knew the general rules of a merge, I'm just trying to understand some of them. I read your post twice this time so I feel better prepared to ask questions in the future. I know I have taken up much of your time and your patience is on a whole other level Zen Master Nae.
I'm liking this new guy...
Awesome explanation!! Thanks.

Great post and answer(s).  Thanks for a clear example of an important issue!♥!

4 Answers

+17 votes
 
Best answer
Thanks for a clear and concise answer with a great example.
by Robin Lee G2G6 Pilot (846k points)
selected by Living Cassel
Thanks!
One of the best answers I have ever seen for a very complicated issue! Thank you for providing a better understanding.
Yes, thank you! Sometimes I see several profiles that appear to be duplicates, especially for my older ancestors, and I haven't been sure how a merge would work on those when I get the time to try to clean them up. Thanks for clarifying.
This is great. Starts at the beginning, then step by step follow thru. Thank you all.
+21 votes
Another reason to avoid multiple merges, like 214 into 52 then into 49, from your example is that Google only follows six redirects before it gives up, this means your profile has less chance of being found by searches, and less oportunity to find cousins.
by Living Geleick G2G6 Pilot (222k points)
+6 votes
As said before, it is likely that a bot can clean the multiple redirects and all these efforts are well intended, but basically useless.
by Living Pictet G2G6 Mach 3 (31.5k points)
+7 votes
I got lost half way thru!
by Nola Moses G2G6 Mach 1 (12.8k points)
1. Identify the lowest numbered profile with the correct last name at birth

2.PPP that profile

3. Identify all other duplicates (including other spellings of last names)  and merge them directly into the PPPd profile

4.Clean up the BIO section

5.You are done...except now you will probably need to merge spouses/children
I learn something new here everyday ! Thanks, Nae.
i will work it out . It just takes a bit longer when one is 74  .Thanks for reply.
PPP profile designations are supposed to be used for profiles managed by a project (i.e. euro-aristicratic, puritan, mayflower, 1776, etc). What used to be called 'historically gignificant profiles'. I don't think we're supposed to change a profile to PPP just because there are multiple variations of the LNAB spelling. See http://www.wikitree.com/wiki/Project_protection. What I find works pretty well is a GREAT BIG comment at the very top of the profile clarifying the correct LNAB (even unknown), disputed parentage, etc.
Bob, Just saw your note.

Project Protection can be applied to any profile that may currently belong in a project or to a future project, and you have to admit that some of our more popular ancestors are an ongoing project in and of themselves due to the various spellings and prolific descendants.

So with the guidelines that a profile may be protected if it may belong to a future project is sufficient reason to protect the correctly identified correct last name at birth with the lowest numbered profile, and no harm is done, but the correct profile is protected from taking it away along with the multiple redirects, url's, etc originally associated with them.

If we lose that correct profile that has 30 other's merged into it, and now it's a redirect, everyone's careful hard works goes away and the servers are not happy.  :)
We have this problem constantly with Dutch and Huguenot project profiles.  One internet source lists  25 (twenty-five) spelling variations of one early New York name.

Example:  "Ooybauwe"  = "Wibault".

 

My suggestions are: one, on family names have all possible spelling variations listed at someplace, which is already done on some pages here, and 2) I wonder if there is some way we can program in Soundex into our system, like is used in the National Archives for the USA:

Related questions

+7 votes
3 answers
351 views asked Sep 30, 2020 in Genealogy Help by Ed Visser G2G1 (1.4k points)
+14 votes
1 answer
+15 votes
11 answers
+36 votes
1 answer
+10 votes
1 answer
348 views asked Feb 1, 2022 in Genealogy Help by N Gauthier G2G6 Pilot (286k points)

WikiTree  ~  About  ~  Help Help  ~  Search Person Search  ~  Surname:

disclaimer - terms - copyright

...