Another reason to allow exceptions to the "nothing else but a name in other last names" field

Question

I was soundly defeated in another thread about this same topic, but a review of my wikifeed today revealed another example of why we need some flexibility in the use of the Other Last Names field. Someone just removed "(of Boston)" from the OLN field of the profile linked to here. Probably a good soul, doing his part to clean up db_errors.

Especially in the PGM space, there are many cases where we have multiple people by the same name and the way we distinguish them is to add "(of Boston)" or "(of Weymouth)" to Other Last Names. It might be that some have used nickname field for this. 

If we do not have the flexibility to use the fields in this way, we are going to run into duplication and bad merges again, when someone, for example, tries to merge this Nathaniel Thayer  with another by the same name because it's not obvious that they are two different men.

PLEASE PLEASE allow some flexibility here. 

The thought of having to clean up bad merges again makes me physically ill.

Comments

And what happen if you have 5 people from Boston with the same name?

Isnt it easier to use sources to find if you are looking at the same person or not...

---

The family group sheet of Thayer-198 looks messy.  Not many sources and 17 childrens

1. Abigail Thayer [confident] 
   Born 1661 in Taunton, Massachusetts 
   Died 1745 in Taunton, Bristol, Massachusetts
2. Joanna Thayer 
   Born 13 Dec 1665 in Taunton, Bristol County, MA 
   Died 1734 [place of death?]
3. Nathaniel Thayer 
   Born 7 Mar 1668 in Taunton, Mass 
   Died before 12 Mar 1752 in Taunton, Bristol, Massachusetts, United States
4. Mary Thayer 
   Born 1669 in Taunton, Mass 
   Died after 19 Jul 1743 [place of death?]
5. Nathaniel Thayer 
   Born 28 Aug 1671 in Boston, Suffolk, Massachusetts 
   Died before 1680 in Boston, Suffolk, Massachusetts [uncertain]
6. Isaac Thayer 
   Born 1673 in Taunton, Mass 
   Died [death date?] [place of death?]
7. Elizabeth Thayer 
   Born 1677 in Taunton, Bristol, Massachusetts, USA 
   Died 1733 [place of death?]
8. William Thayer 
   Born about 1680 [uncertain] in Taunton, Mass 
   Died 27 Jan 1762 in Taunton, Bristol, Massachusetts
9. Nathaniel Thayer 
   Born 11 Jul 1681 in Boston, Suffolk, Massachusetts 
   Died [death date?] in Boston, Massachusetts [uncertain]
10. Deborah Thayer 
    Born 1682 in Taunton, Mass 
    Died [death date?] [place of death?]
11. Zachariah Thayer 
    Born 29 May 1682 [place of birth?] 
    Died [death date?] [place of death?]
12. Cornelius Thayer 
    Born 14 Nov 1684 [place of birth?] 
    Died [death date?] [place of death?]
13. Jonathan Thayer 
    Born 1685 in Taunton, Massachusetts 
    Died 1777 in Taunton, Massachusetts
14. John Thayer 
    Born 2 Apr 1687 in Boston, Massachusetts 
    Died [death date?] [place of death?]
15. John Thayer 
    Born 2 Jul 1688 in Boston, Massachusetts 
    Died [death date?] [place of death?]
16. Ebenezer Thayer 
    Born 1 Feb 1689 [place of birth?] 
    Died [death date?] [place of death?]
17. Deborah Thayer 
    Born 14 Oct 1691 [place of birth?] 
    Died [death date?] [place of death?]

---

I think this sort of info goes in the bio.

---

The birth and death dates alone show that he was from Boston.

Answer 1

Hi Jillaine,

Is there a reason you can't put "of Boston" or "of Weymouth" without the parentheses?

I'm not sure why a Data Doctor wouldn't just be removing the parentheses.

Chris

Comments

Which is my point of adding to the nickname field. It already adds the quotations marks for you. Problem solved and no db error.

---

A name is a name don't add other things in name fields that is not genealogy. 

If the problem is that people don't add sources and or don't check them add a sanity check when people are asking to do a merge like has been created when saving a profile. 

1. Is the father's name the same? 
   1. If not give a warning
2. As we now starts to get locations we can trust compare birth locations. Are the birth and death locations the same?
   1. If not give a warning
3. ???

If users still can't understand then WikiTree has a problem... maybe add more level of skills and that you need to be qualified before you are allowed to initiate merges...

Duplicate relations/locations in the names field is adding bad quality plus it looks odd and is wrong. Better do sanity check or change the user interfaces when merging....

As always if we do genealogy adding sources then we can easily check if we speak about the same person. If not we have sources and start guessing that is noy genealogy. If you do genealogy without good sources maybe the profiles should not have been added in the first place... 

Looking at the examples above Thayer-2528 too many profiles in the "family" seems to be GEDCOM imports with no sources.... which is for me an indication of lack of genealogy research and quality...


Big pic example how odd it looks like adding the father both in the fathers field and in the name field.... also adding locations in the name fields is not ok

If you do genealogy in a region with Patronymics you have this problem all the time with the same names. Names like Anders Andersson = the son of Anders on 100 of peoples.... ==> you must learn to use sources.... too many GEDCOM profiles for Sweden has been uploaded to WikiTree with no sources that has no genealogy value... because people do genealogy without sources....

Start learn users to compare sources and add sources and add sanity checks in WikiTree

---

Thank you Chris and Tony. So, I just want to be clear: Chris, you're saying we can use a non-name in the nickname field *when there is a need to distinguish someone from another of the same name/time period*? Can this be documented in the Help pages?

---

Strongly disagree

*when there is a need to distinguish someone from another of the same name/time period*

Add that to 

• the Biography
• Research Notes

but don't add things to the name field that is not a name.... it will just confuse people and GEDCOM export will be a mess, searching will be mess

---

Hi Jillaine,

No, I'm not inclined to believe that a name field should be used for something that is clearly not a name. Some people would have to consider it a name for it to be appropriate for a name field.

For the informal "Other Last Names" and "Nicknames" fields, this does not mean that there have to be contemporary documents for the use of the name. It could be that modern genealogists just confuse it with a name. For example, if some genealogists use "of Boston" as a last name, and would enter the person, search for them, etc. using that as a last name, it's appropriate for the Other Last Names field.

Chris

---

I'm specifically asking about the use of the Nicknames field for non-name entries such as "of Boston".

---

Hi Jillaine,

If you're going to call it a "non-name", then no, it does belong in a name field.

If someone thinks it is a name or it's been used as a name, it could go in the informal name fields, Other Last Names or Nicknames (aka Other First Names).

If you're asking me for an opinion on whether "of Boston" has ever been used as a name, I won't give it. :-)

Chris

---

Ah, I think I'm seeing your distinction.

If someone in his life was referred to as "Nathaniel Thayer of Boston" to distinguish him from someone who was similarly referred to as "Nathaniel Thayer of Taunton", then that might be considered a "name". 

But then someone like Magnus would come along and say "prove to me with a contemporaneous source that he was actually referred to that way" and if Jillaine couldn't prove it, then Magnus would feel free to remove "of Boston" from the nickname.

And then a few weeks later, someone would come along and merge Nathaniel of Boston with Nathaniel of Taunton, or attach the wrong spouse or children, and some number of us would give up.

I hope you can understand my concern and frustration.

 

 

---

Hi Jillaine,

I don't think there's any burden of proof like what you're describing, even for the formal name fields. If you're not confident about sources you just mark a field as "uncertain" and explain it in Research Notes, you don't delete the contents of the field.

With the informal name fields, Other Last Names and Other First Names, I don't even think we say the name has to have been used during their lives.

Chris

---

Jillaine,

I understand your worry that two people with the same name might be incorrectly merged, but I think it is absolutely incorrect to put notes in a name field to distinguish them.  It's just a fact that names are not unique and there are literally hundreds of thousands of people in history who have the same name.  They need to be distinguished by dates, parents and well-written biographies which make clear the difference between two individuals with the same name.  The information you want to put in a name field belongs in the biography.

With specific regard to Thayer family, as it stands right now it is a big pile of internet rubbish.  It needs to be re-done following modern research, specifically The American Genealogist articles from 1998.

---

The 1998 TAG article by Stott does not reach into New England, except for Cicely, daughter of John Taylor and Joane Lawrence. Cicely m. James Davis and died in Haverill MA 28 May 1673. 

For the male Thayers who emigrated, the 1998 article references Mary Lovering Holman's 1938 work, Ancestry of Charles Stinson Pillsbury... vol 1:443-49, some of which Stott, in 1998, says relied on the inaccurate data in Ojeda's 1906 work, but that her theory about Richard might be accurate.

 

 

---

Joe, I've returned to working on this family based on Holman and Stott. It's a nightmare.

Would appreciate some help.

---

Yes, I can help with this Jillaine.  The English portion at least is in my ancestry.  I didn't do it last year I think because it was such a mess.  I trust Holman and Stott, and Ojeda less so.  This best approach is probably to just to start at the top and work down.

Answer 2

I say use the "nickname" field so it's prominently displayed on the profile and does not create a database error. Just my opinion and what I do. I have a line where the same name is used very often as well.

Comments

So are you saying that we can use non-alpha characters, and non-surname/firstname/nickname words in the "nicknames" field and db_errors won't find it?

If that's true, then I would ask that people fixing the db_error with a non-alpha / non-name word in Other Last Names kindly move said words to the nicknames field.

---

You know more about this place than I do as you have been here much longer. All I am saying is that I am from the south and the nicknames are quite bazar. I have yet to get a db error on one. I would think that the nickname field parameters would have to be quite broad to allow unconventional naming to happen without throwing errors.

---

I believe when you use the nickname field it automatically put's " " or ( ) around the nickname so you don't need to add them

---

But please use the nickname fields for nicknames and not for WikiTree hacks

See Joe Cochoit excellent explanation above 

Answer 3

Jillaine, would this profile fall into the category of problems you're talking about?  I used the nicknames field here for a similar case, but I did this back in my rookie year, when I was often just winging it, and I haven't gotten back to it yet.  (See the note at the top of the Bio.)  There may be some other approach to this that would be more suitable, including just ignoring the problem.  (But it does seem like that could produce duplicates or possible commingling of data with others of the same name.)  Most other sites where you would find the name do, in fact, show the parenthetical expression after the surname, but I'm not sure the Other Last Names field would really be appropriate.  So how do we do this within the current rules?  I haven't gotten an error on it.

https://www.wikitree.com/wiki/Buhrman-10

Comments

Surely, you can do this.  Just don't put the parentheses in there.  Then
of Poorman
would come out as "of Poorman".  The individuals would be easy to identify when comparing for a match.

---

Agree Ros, that can be done.  I can't remember for sure, but I'm guessing that at the time I was probably thinking that it wasn't the real purpose of that field, and I was looking for some way to distinguish it from an actual nickname.

---

Dennis, because the father's name is right up there, not sure I'd use the nickname field for this purpose. But generally speaking yes.

---

Please explain what is the added value of duplicate fathers name?

Isnt the problem the user initiating the merge that need to get warnings from the WikiTree software you have the following problems

Maybe add a check when merging that its ok and if not warn the users that they are doing something stupid... 

1. Name is equal check
2. Fathers name is equal false
3. Mothers name is equal  check
4. Birth location is equal or not far from each other check
5. Death date is equal check 
6. Fathers birth dates are equal check 
7. Mothers birth dates are equal check
8. .....
9. .....
10. You are merging two profiles without sources are you sure to continue warning

---

OK, OK, OK, I get it!  Just to make it clear, the sample Jacob Buhrman profile has never been involved in a merge, or proposed for one, so that specific issue has not surfaced here.  I suppose the only possible value added by having a descriptor like that as part of the bold name field is that it could alert casual readers, or people looking for sources, to be careful since there are others out there with the same name.  But yes, I yield, there are probably other, better ways to do it.

---

@Dennis ;-) 

I think best is to track each possible area of problem and see how to solve those issues.... 

Maybe just adding the fathers field in a list or add a new field that contains issues like this profile has a lot of false merges please check parents etc..... as WikiTree grows it will have more problems like this and the genealogy skill level will also differ a lot so I think its important to find a better solution than we maybe have today.... 

Starting adding non name info to names will just kill GEDCOM export, search etc....

There is a famous quote "A Rose is a rose is a rose" and its the same with name fields it's just for names ....

A Name field contains names that are names that are names ;-)

Answer 4

First of all error for the profile was 761 Separators in Suffix  Parentheses are no longer allowed in names. 

Second: Boston was in Suffix field. It definitely doesn't belong there. Suffix is also limited to 10 characters, so there are many places, that wouldn't fit it that field.

Third: If birth location is entered it is unlikely that the profile will be merged with someone from another state or place. Those Merge messes were done between profiles with no or very little data.

Fourth: Correction was not done by data doctor. Jim Angelo Jr. Acording to his change log on 15. jan, he was doing some mege cleanups and also corrected this profile. It is not always Data doctor's fault.

Comments

Plus with the new location lookup in WikiTree the quality of location data will be better and consistent ==> if 2 people are born at the same place it will be easier to understand that

---

Often times on PGM profiles, we don't have specific birth dates or places-- they're often "about 1601" in England. So we need alternative ways to flag and make obviously visible when we know a distinctive characteristic.

I'm not faulting Jim or data doctors. I'm asking for exceptions to the rules in whatever field we can agree on.

---

@Jillaine how do you know it's an unique persons. Please give examples...

1. Do you have sources?
   1. If yes compare sources
      In Swedish Genealogy we have the same name problem all the time because of Patronymic ==>
      we use sources to see if its different people
       
      We have just in WikiTree 815 Anders Andersson

Ps. a source is not a gedcom imported file its church books or something else with genealogy proven value

---

I don't understand what you want. 

Do you want to put "about 1601" Or England in Other last name or nickname? You have date and location fields for that. Also in Bio, you can write some remarks. While doing any merge, Bio must also be looked at. 

---

Magnus, please stop checking best answer. I'm the one who asked the question.

---

?!?!? ok you are the boss...
Normal is that a community agree what is the best answer or not.... not that the person asking the query decide what answer you like or not.... The idea with best answer is so other people dont have to read everything...

Status right now is that most people disagree that a name field should be used for other things than names - inventing new names in WikiTree using locations or fathers name in names is a ”hack"  -). My feeling is that what Aleš explain in a good way...

@Jillaine Hope you agree

---

Aleš, I want to be able to place "of Boston" in the Nicknames field. (Previously was using either suffix -- if room-- or other last names; now okay with nickname field for this purpose.)

---

I agree with Jillaine. An attribute, preferably one that already exists, is hugely helpful to distinguish "of Boston" or some other brief descriptive. This is a long standing method of communication of noted genealogists. Most of the wiki-tree fields are defined to fit the definitions of gedcom files. Wiki-tree can use the power of the validation software to allow the use of a 'name' field as a descriptive so that the thousands of members who are computer novices will understand the profiles, particular when the attribute is included in the basic profile display screens.

---

I really don't know where to put of Boston. My guess is Location, In nickname it messes with gender errors and 511 Unique name spelling.

But you can put it anywhere you want, I will not delete it "for now".

---

I have two lines with three to five generations with the same name.  No Jr, Sr, I, II, III, or middle initial.  Welsh coal miners who all lived in the same town.  I object when other genealogist add false info to ID them.  That's what birth/death date is for.  I check dates before adding a source, which does not prevent my from screwing up from time to time.  I'm still trying to find out where a middle initial came from just so I can source it and delete it.  PS - I am a rank amateur.

Answer 5

I have to agree with Aleš that it's not appropriate to put non-name information in a name field just like it's not appropriate to put personal codes in suffix fields and other bits of information where they don't fit.

I think we need to be consistent in order to encourage people to develop good habits for how they are using the website. If we make an exception like this, it's going to be hard to enforce any standards that have been developed for any field.

If there is a profile that is consistently being proposed for bad merges, shouldn't it be Project Protected??

Comments

Julie of Chicago you are so right and I feel Aleš of Ljubljana has explained the reason. If we try to solve all problems with WikiTree by creating new names of profiles then WikiTree has a problem... 

Regards
Magnus of Stockholm, Gävle, Achern

Ps. if WikiTree continue add a new name if you have a problem it will in the end be difficult to know my own name am I 

• Magnus of Stockholm
  or
• Magnus of Akalla
  or 
• Magnus of Sweden
  or 
• Magnus has been working in Ohio

Lesson learned: genealogy based on no sources is difficult

Before this get too crazy maybe we should go back and use facts we can confirm with sources....

Best practice when doing software development

Explain the problem and what you would like to achieve and not start with a solution to a non defined problem....
 

---

Julie, yes we try to project-protect where we can. But we miss some.

And I've even seen well-intentioned Leaders remove PPP believing they're doing the right thing. It's so easy to make a mistake especially when the birth dates are estimates and close, and when there aren't sufficient distinguishing characteristics.

In PGM, we don't use non-name terminology in name fields very often-- mostly on those rare occasions where, for example, there has been published incorrect information subsequently disproven, but still out there taking people down the wrong path. It's pretty rare to need to use this exception, but when we need to use it, we really need to use it.