Jump to content


Photo

Handling unknown last names


  • Please log in to reply
25 replies to this topic

#1 keithcstone

keithcstone

    Advanced Member

  • Members
  • PipPipPip
  • 99 posts

Posted 27 February 2018 - 08:11 AM

I'm trying to do some cleanup of names from various merges, and I'd like some opinions on how people handle unknown names in RM. Looking at https://www.tamurajo...yNameBasics.xmlthe opinion is just put nothing, but that doesn't work with TreeShare and makes reports look a bit squirrly. I've seen references to using [--?--].

 

So what is everyone else doing? Obviously I'd like a method that would work effectively with RM and with TreeShare.



#2 XFTMTeutopIL

XFTMTeutopIL

    Member

  • Members
  • PipPip
  • 28 posts

Posted 27 February 2018 - 12:11 PM

If I know the given name but not the surname, I just leave the surname blank. If I know the surname but not the given name, I use ? for the given name.  If I don't know either, I use Unknown A A, Unknown A B, and so on.  This helps in reports and false duplicates.



#3 Don Newcomb

Don Newcomb

    Advanced Member

  • Members
  • PipPipPip
  • 1011 posts

Posted 27 February 2018 - 05:28 PM

Particularly with women who have a married name but their maiden name is unknown, I prepend an asterisk to the name (e.g. Mary *Smith). I find that if I don't do this, RM tries to match this Mary to every other Mary in the database. I started doing this quite some time ago, before Name Find. It has the disadvantage that Name Find won't find Mary *Smith when looking for "Mary Smith".

 

I've asked if there was a standard or best practice for doing this and no one seemed to have one. I'd change my system if someone had one that worked better. 



#4 zhangrau

zhangrau

    Advanced Member

  • Members
  • PipPipPip
  • 1395 posts

Posted 27 February 2018 - 07:49 PM

I don't use either FS nor Ancestry TreeShare, so I honestly have no idea how my method is handled by those websites.

 

If I don't know a:

 - Given name, I use [Unknown] or [son] or [daughter] or[Infant]

 - Surname, I use [Unknown] if single (but then, why would they be in my database?) or [SpouseSurname]

 

I have found that the use of [square brackets] is visually distinctive, and is understood readily by the readers of my reports.



#5 BradleyinDC

BradleyinDC

    Advanced Member

  • Members
  • PipPipPip
  • 65 posts

Posted 27 February 2018 - 09:26 PM

I don't use TreeShare so not commenting there, but I put the surname of the spouse (or whomever) in [brackets] so that they show up in index searches, etc.



#6 Nettie

Nettie

    Advanced Member

  • Members
  • PipPipPip
  • 1573 posts

Posted 28 February 2018 - 08:12 AM

I do not use TreeShare or upload to any other tree on line family tree. 

But as I put in a another discussion

"A few maybe several years ago before RM 3, this was a big topic in either the email group or...  Don't remember which... 

But a lot of us choose to use the male surname in square brackets for unknown  married female surname.  I have used this consistently since then.  It has helped keeping the many Elizabeth's, Mary's female names together with their male spouse/partner in the Index list.  Have found many of those surnames and they were changed.  Has been a good choice for me.  Unknown place names, are usually blank.  Or if birth or census information is known then use the place name.  I do not like place names with a ? behind them as some people use."

Changing Death place and Burial place in my database are only changed if I find a valid source like obit, death certificate or on Find A Grave or other sites like this. Even "Find A Grave" can have mistakes or names added with no tombstone picture."


Genealogy:
"I work on genealogy only on days that end in "Y"." [Grin!!!]
from www.GenealogyDaily.com.
"Documentation....The hardest part of genealogy"
"Genealogy is like Hide & Seek: They Hide & I Seek!"
" Genealogists: People helping people.....that's what it's all about!"
from http://www.rootsweb....nry/gentags.htm
Using FO and RM since FO2.0 


#7 Don Newcomb

Don Newcomb

    Advanced Member

  • Members
  • PipPipPip
  • 1011 posts

Posted 28 February 2018 - 11:09 AM

I just did a test and it looks like [Surname] works with Name Find. I'll probably be converting all my *Surnames to [], now.



#8 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3173 posts

Posted 28 February 2018 - 11:52 AM

For truly unknown place names, I just leave the place name blank. It's hard to see how to improve on that. But here are some other examples of partially known place names or disputed place names that can be interesting challenges.

  • Died in the Civil War (or died in WWII etc.). "The Civil War" is not a place name, but it's the only information I have.
  • Probably born in Virginia. Born in probably Virginia. Born in [Virginia].  I actually use the square brackets because I don't know what else to do. One trouble with the square brackets is that the square brackets  can get stripped off by other software or by other users, thereby invalidly converting uncertainty into certainty.
  • Born in Virginia or Tennessee. E.g., the person was born just before or just before the family moved from Virginia to Tennessee, but neither the exact date of the move nor the exact date of the birth are known.

Jerry



#9 keithcstone

keithcstone

    Advanced Member

  • Members
  • PipPipPip
  • 99 posts

Posted 01 March 2018 - 08:00 AM

I really like the [surname] idea. I've tried it on a number of people in my database and it really works well for searching and reconciliation (much easier that digging through 20 Elizabeths and Elizabeth ULNs)



#10 Nettie

Nettie

    Advanced Member

  • Members
  • PipPipPip
  • 1573 posts

Posted 01 March 2018 - 08:29 AM

  • . One trouble with the square brackets is that the square brackets  can get stripped off by other software or by other users, thereby invalidly converting uncertainty into certainty. ......

Jerry

 I agree, I do not transfer my data via a gedcom.  I made that decision several years ago after a discussion on this forum. Also, because some times my own created facts also do not transfer correctly.  When my cousin asked  me to share what I had on a line, I asked what software they were using and talked them into using RootsMagic then the transfer went okay.   


Genealogy:
"I work on genealogy only on days that end in "Y"." [Grin!!!]
from www.GenealogyDaily.com.
"Documentation....The hardest part of genealogy"
"Genealogy is like Hide & Seek: They Hide & I Seek!"
" Genealogists: People helping people.....that's what it's all about!"
from http://www.rootsweb....nry/gentags.htm
Using FO and RM since FO2.0 


#11 BradleyinDC

BradleyinDC

    Advanced Member

  • Members
  • PipPipPip
  • 65 posts

Posted 01 March 2018 - 11:47 AM

 I agree, I do not transfer my data via a gedcom.  I made that decision several years ago after a discussion on this forum. Also, because some times my own created facts also do not transfer correctly.  When my cousin asked  me to share what I had on a line, I asked what software they were using and talked them into using RootsMagic then the transfer went okay.   

 

I've never had a problem with [Surnames] keeping the brackets when transferring info in a GEDCOM, and I've been testing this recently on several programs.  



#12 Nettie

Nettie

    Advanced Member

  • Members
  • PipPipPip
  • 1573 posts

Posted 01 March 2018 - 06:17 PM

BradleyinDC

 

If you are in DC, I am 30 miles from you.  Glad the square brackets have worked [surname].    


Genealogy:
"I work on genealogy only on days that end in "Y"." [Grin!!!]
from www.GenealogyDaily.com.
"Documentation....The hardest part of genealogy"
"Genealogy is like Hide & Seek: They Hide & I Seek!"
" Genealogists: People helping people.....that's what it's all about!"
from http://www.rootsweb....nry/gentags.htm
Using FO and RM since FO2.0 


#13 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3225 posts

Posted 03 March 2018 - 02:58 PM

If a Place or Name component is unknown then by definition that field should be blank any little codes adopted by me and another user will be mismatches.

 

I find these various personal and varying codes are mainly to fill gaps in reports with something and this need could be easily overcome. I have submitted an enhancement request recently to Rootsmagic for the software to provide user define text to insert in reports where Place or Name is blank. Alternate name overcomes the dated square bracket practice and after that Unknown sorts just as well as a blank field.

 

Rootsmagic should try to understand why users adopt these varying styles of entering erroneous information and overcome their need through a programmed solution in my opinion.


Nobody likes half baked food, so leave it in the oven and tend to it a bit longer till it's just perfect.....

 

 

Current user of Rootsmagic version 7.5.7.0, Family Tree Maker 2014 and Legacy 7.5 on Win 10

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#14 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3173 posts

Posted 03 March 2018 - 07:57 PM

I have submitted an enhancement request recently to Rootsmagic for the software to provide user define text to insert in reports where Place or Name is blank. 

 

I certainly agree that what you are proposing or something similar is needed. I think the more general need is a way to separate the way data is stored from the way data is displayed. There is another thread right now with the same basic problem where a FamilySearch user is using Portuguese and where dates coming in to RM from FamilySearch are therefore are in Portuguese and are not recognized by RM.

 

I think there should be a good quality standard for storage and interchange of dates (probably all numeric). The storage and interchange standard should be robust enough to handle "between dates" and Julian/Gregorian dates and Quaker dates and quarter dates and year dates, and many more. ("First quarter 1915" is no more 15 Feb 1915" than "1915" is "1 Jul 1915".)  Then, all the genealogy Websites and software could support date templates that could display dates by using the Portuguese month names or the Italian month names or what ever is require, and in accord with any other needed language or cultural customization such as the punctuation, the ordering of the month and day and year with respect to each other, etc.

 

Similarly, there could be a robust standard for storage and interchange of Place and Name, with Place using numeric codes to get around the language problem. Then, there could be Place templates and Name templates to control the display of blanks and languages and whether to use the word "county" and all those kinds of things. But this "robust" place standard would have to quit being so America-centric and deal with the way political subdivisions work in Germany or China or wherever. And even for American places, this "robust" standard would have to deal rationally with township names vs. town names and cities that span multiple counties and districts and cemetery names and hospital names and changes of names and boundaries over time and GPS and probably a lot of other things that I'm not even thinking of.

 

Nothing even remotely like this is going to happen, but one can dream.

 

Jerry



#15 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3225 posts

Posted 04 March 2018 - 09:07 AM

 

I certainly agree that what you are proposing or something similar is needed. I think the more general need is a way to separate the way data is stored from the way data is displayed. There is another thread right now with the same basic problem where a FamilySearch user is using Portuguese and where dates coming in to RM from FamilySearch are therefore are in Portuguese and are not recognized by RM.

 

 

Agree completely, the reference database is all important here.

 

Whilst we all work in our own insular ways with little personal systems we are in the business of compatibility and information exchange. It doesn't matter whether we use TreeShare or FS, we look for matches down the library and records office based on Name and Place matches. The question for any system’s analyst is "why did you feel the need to enter data in that way?... What were you trying to achieve?" then overcome it through a programmed solution.

I believe the square bracket system is outdated now and superseded by the Alternate Name fact which I have embraced. This caters for multiple Married names and also multiple Alternate spellings which is common with a few of my surnames and a common topic on here and Facebook.

Alternate Name "Married" will sort with the family name and the name the persons death is registered under and appears on the grave marker, "[]" just sorts with "[ ]" and then the name, separated in the index.

Alternate Name "Married" and "Other Spelling" allow for multiple entries all which will appear in the Index whereas "[ ]" only allows for one entry.

I know changing the direction and thinking of the herd is not an easy task but I am starting to wonder if there are downsides to the Alternate Name Fact I am not aware of?

 

I posted a rather rushed video on this about a year ago which included my observation on the need to user defined reporting options, link below;

 

https://youtu.be/j_JaStmYAp0


Nobody likes half baked food, so leave it in the oven and tend to it a bit longer till it's just perfect.....

 

 

Current user of Rootsmagic version 7.5.7.0, Family Tree Maker 2014 and Legacy 7.5 on Win 10

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#16 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 180 posts

Posted 04 March 2018 - 09:07 AM

Thank you Vyger and Jerry for your important comments regarding the separation between data storage and information display.

It is the job of the information display system to know, based on the data found in the data storage system, how a data point is to be displayed. It is the job of the data storage system to provide enough clues in its repository to tell displaying systems what data they have leaving the display system to determine what and how they are displaying the data.

Storing "unknown" or [unknown] in the surname field so that the display prints that value is unacceptable and should never be used.

If a surname is unknown, don't enter a surname, the database should record nothing in the surname field. The display system should display nothing when no surname is entered.

So, you ask: "what if the report reader wants a note in the name that states the surname is 'unknown'?" The database must then have a field to store the data, unknown surname, this way the display can assign a value to either the display field of the surname or a separate display area (this is the job of the display system).

The data storage system must understand enough about the data they are storing to understand what data-points they need to record so that the display systems can differentiate between the multiple options they could present.

Data storage vs data display with regard to surname should be separated because of the following reasons.
1. Order of display (Western vs Eastern order surname vs given name
2. Unknown surname vs No surname. (Many cultures, mine and probably yours have points in time when there was no surname custom. People did not always have a surname!)
3. Multiple surnames. Many cultures have multiple surname customs, data storage and data display must support this.
4. Surname root customs. A few cultures provide for two different variations of surnames base on the gender of the person. Again these need to be handled differently in the database vs the display.
5. Clan Names. Before surnames were used people where part of clans, these clan names in some cases became surnames, but in other cases became ways of identify connection.
6. Uppercase vs Lowercase surname. Because of item #1 and #3 many like to uppercase surnames.

Jerry, I agree that there should be standards in data storage, which of course is different than the way the data is displayed. GEDCOM has a fairly good standard for date storage, but is rarely used by genealogy programs. It takes into account the multiple calendar types including the Jewish calendar and others. It is up to the display system to know how to use them.

Several large genealogy groups in Europe (a German group who's name I forget comes to mind) are trying to standardize all the names of places they come across in the group as a call to their system for reference. It works but is not all inclusive yet.

Sorry for the long entry, it was actually longer, data storage/display and genealogy are passions as well as my vocation!

#17 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3225 posts

Posted 04 March 2018 - 09:08 AM

Similarly, there could be a robust standard for storage and interchange of Place and Name, with Place using numeric codes to get around the language problem. Then, there could be Place templates and Name templates to control the display of blanks and languages and whether to use the word "county" and all those kinds of things. But this "robust" place standard would have to quit being so America-centric and deal with the way political subdivisions work in Germany or China or wherever. And even for American places, this "robust" standard would have to deal rationally with township names vs. town names and cities that span multiple counties and districts and cemetery names and hospital names and changes of names and boundaries over time and GPS and probably a lot of other things that I'm not even thinking of.

 

Nothing even remotely like this is going to happen, but one can dream.

 

Jerry

 

Jerry, I was surprised you did not comment on my thread on Reverse Geocoding as you virtually suggested it, maybe you missed it.

The point was that we may going about things all wrong trying to define places accurately from multi varying text strings. Now if we just stick pins in maps then we are speaking the same language in other countries of the world that pin in the map will be described in local language. If your pin in the map is right by mine in the same time frame we may be cousins (-:

Many years ago (pre online services) and in the dark I was slightly off track in County May, Ireland. I stopped by a local and asked directions to my planned destination and it was not going well. I eventually grabbed the map from the back seat and a torch and pointed to my planned destination, it was 5 miles up the road. The point is my attempts to voice the place name through very poor pronunciation was not being understood locally, once I pointed to the map, all was well.
 


Nobody likes half baked food, so leave it in the oven and tend to it a bit longer till it's just perfect.....

 

 

Current user of Rootsmagic version 7.5.7.0, Family Tree Maker 2014 and Legacy 7.5 on Win 10

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#18 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3225 posts

Posted 04 March 2018 - 09:30 AM

Sorry for the long entry, it was actually longer, data storage/display and genealogy are passions as well as my vocation!

 

thumbs-up-emoticon.jpg


Nobody likes half baked food, so leave it in the oven and tend to it a bit longer till it's just perfect.....

 

 

Current user of Rootsmagic version 7.5.7.0, Family Tree Maker 2014 and Legacy 7.5 on Win 10

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#19 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 180 posts

Posted 04 March 2018 - 05:55 PM

 

I know changing the direction and thinking of the herd is not an easy task but I am starting to wonder if there are downsides to the Alternate Name Fact I am not aware of?

Vyger.  The only downside I know of is that not all genealogy programs support multiple name "facts". Or that they display them or index them in odd ways.   

 

One of the issues I do have with programs the do support multiple names facts is that they do not provide a standard way to indicate the type of name being entered.  We should be able to say "birth", "married", "immigrant" (We probably all have relatives that had letters in their names or spellings that were not support in the country they immigrated to).  This should also allow for some way to add types of names as well.  I personally have relatives that had either stage names or artistic names.  They could be entered "aka", but I like to "TYPE" the name fact to allow the name to be indexed better.  Thus, "Married" names could be reported/displayed differently than birth names.  Spellings (or those non-English letters) can be index in or out based on the name type as well. 

 

These NAME issues also hold true for place names.  Historically, Many places in Europe had two names at the same time depending on your religious community or ethnic background.



#20 Don Newcomb

Don Newcomb

    Advanced Member

  • Members
  • PipPipPip
  • 1011 posts

Posted 03 April 2018 - 07:37 AM

I just did a test and it looks like [Surname] works with Name Find. I'll probably be converting all my *Surnames to [], now.

 

FYI. For what it's worth. It appears that Ancestry believes "[" is an illegal character in a name but "*" is OK.