Genealogy from the perspective of a member of The Church of Jesus Christ of Latter-day Saints (Mormon, LDS)

Monday, September 25, 2017

USA vs. United States: Standardization?


When I was in high school, back before the war, there was a lot of discussion about converting from the "English System" of measurements to the metric system. My contemporaries and I thought that the metric system was harder to understand than the "foot, pound" units we were accustomed to. By the way, the United States is now the only industrialized country in the world that does not use the metric system as its predominant system of measurement. Most of the children now in school are taught to use the metric system. My introduction came when I lived outside of the United States for many years.

Now, what does this have to do with genealogy? Presently and for some time now, FamilySearch.org has implemented a system of "Standardization" for the dates and places in the Family Tree. More recently, FamilySearch started to mark the "non-standard" dates and places with red error icons.


As a result, my portion of the Family Tree program is now well decorated with red icons. However, how standard is the FamilySearch standard? You don't have to look very far to discover that it is not a standard outside of the FamilySearch.org website. Here is an example from Ancestry.com from the same family.


First of all, Ancestry.com accepts the entry of "Harrison County" and also "standardizes" its entries to "USA" instead of "United States." Granted, both entries in both programs are "messed up" and likely inaccurate. This example happens to come from a part of my own pedigree that has yet been researched fully and corrected. It is not too hard to find these examples because there are perhaps thousands of them (millions?).

In another example, rather than take sides in this "standardization" issue, programs such as RootsMagic provide a way to standardize on either "United States" or "USA" depending on personal preference. One effect of this issue is that every time I migrate a date or time from Ancestry.com to FamilySearch.org, the date and place are automatically marked as non-standard. All my entries in my family tree on Ancestry.com are "standardized" to "USA."

What about MyHeritage.com?

MyHeritage.com accepts both USA and United States and also accept "Co." for the county. By the way, I realize that Kentucky is misspelled. Actually, the entry in the Family Tree on FamilySearch.org for Thomas Hamilton is more than messed up. For example, look at the birthplace and the christening place.


It would seem to me that a missing standardized birthplace is pretty trivial when the birthplace is listed in Massachusetts and the Christening is shown as occurring in "Butterton Par.Ch, Hulme End, Staffs." However, FamilySearch does not mark christening dates and places as non-standard, even when they are probably impossible, such as being born in America and being christened in England. It could have happened by not likely in the 1700s. Of course, the example above of a birthdate in 1720 in "Kentuckey" is also impossible because Kentucky did not exist as a state until 1792 and the first settlement in what is now called Kentucky took place in 1774 at Fort Harrod, one year before Boonesboro.

It seems to me that "standardization" should go a little deeper than merely satisfying some engineering issues with search engines.

Comment: Will I now try to fix the mess with the Hamiltons in the Family Tree? Probably not for a while because I don't think that this line is even correct and I may just have to cut off the line and leave it out there for someone else to deal with.





9 comments:

  1. Once again, Family Search’s non-standard use of the term “standardize” is causing confusion. Family Tree does not care in the least whether one uses United States, United States of America, USA, US, or leaves it off all together. The style of place name entry is completely up to the family doing the research. There is no required standard for place name entry. Should there be? That is debatable. I really like the flexibility the lack of one allows. The artificial conformity of a standard will never fit all of the complexities of historical place names.

    The red data error icon means one thing and one thing only. Namely, the bar that should be green is yellow.

    “Burnstable, MA” is not “Missing Standardized Birthplace” because the state name is not spelled out or because a country name is missing. The red icon is there only because the standard bar, what I like to call “the pin on the map,” is yellow and says “No Standard Selected. Click here to select a place.”

    Click there, select an appropriate “pin,” watch the bar turn green, observe that “Burnstable, MA” does not change, click save, and watch the red icon disappear.

    Likewise, the christening place “Butterton Par.Ch, Hulme End, Staffs” does not have a red error icon because it is standardized, that is, marked on the map. Open to the editing box to see that the green bar is nicely green and states, “Standard: Butterton, Staffordshire, England, United Kingdom.”

    As I tell people every chance I get:

    White box = what you want other people to read and should be, preferably, accurate and comprehensible but the final result is totally up to you and your personal standards.

    Green box = GPS location on map you want computer routines to use.

    If you get a bunch of red icons every time you migrate data to Family Tree, that means the migration routine is not writing properly to both boxes and you need to complain to whoever is writing that routine until they fix it.

    ReplyDelete
    Replies
    1. I can see your point, but many of the designations are inaccurate and do need to be edited.

      Delete
    2. Designations in the green bar or designations that people type in? The green bar can have additional choices added by sending requests to the Family Search team in charge of that. People do that frequently. The white box can only be fixed by the individual researcher.

      Delete
  2. So how exactly are people not from the US supposed to decode what "Burnstable, MA" means? Firstly there is no such place as "Burnstable". The correct place name is Barnstable. Secondly is that referring to the city or the county? Since that is the difference between a place covering 76 square miles v a place 1,306 square miles it's a pretty important distinction. Also is it referring to Burnstable after US independence or during the colonial period?

    So how exactly are people not from the UK supposed to decode what "Butterton Par.Ch, Hulme End, Staffs" means? Again there is no such place. Butterton and Hulme End are two separate villages some 3.5 miles apart. I know that Par.Ch stands for parish church, but how is someone from Russia supposed to know that? I know that Staffs is the abbreviation for Staffordshire, but how is someone from Russia supposed to know that?

    The building that a particular event took place in and/or the street that building is on are NOT things that belong in the place field. They belong in the description field. It is most unfortunate that the four vital events fields in the Familysearch tree do not actually have a place description bit and is one of the things that Familysearch needs to fix about the data structures in the program.

    When you are putting data in the Familysearch Family Tree are are NOT doing for yourself. You are doing it for the whole world. It's not "my tree", it is everyone's tree. Therefore the standard place name should be what appears in both the standardised text and the actual field contents if at all possible. Only if a place does not appear should they differ, such as when a hamlet is not in the place database or when referring to something like an English registration district, none of which are in the standard place database at the moment.

    Suppose I were to put 10, SW1A 2AA, United Kingdom into the residence field for someone in the Familysearch Family Tree? That is an address which is perfectly valid for post to reach correctly and pinpoints the exact building I am talking about. How is that useful for anyone? Suppose I were to put 20500, United States into the residence field for someone in the Familysearch Family Tree? Again it is an address which would lead to post reaching its desired destination and pinpoints the exact building I am talking about. How is that useful for anyone?

    For an exercise try and work out which, extremely famous, buildings I am referring to in the last paragraph. Then reconsider the necessity for standard place names as the actual field contents, not just in the background.

    ReplyDelete
    Replies
    1. You bring up some excellent points and it looks like I have one or more posts suggested from your comment. Thanks for the questions.

      Delete
  3. If this discussion goes forward, can we please use correct, precise vocabulary as used in the context of Family Tree?

    1) To enter a standard place name - To record in the white data entry box a correct, accurate, clearly understandable, unambiguous, complete place name. Family Tree has recommendations but no requirements as to how such a place name is entered. There is no data checking provided as to whether an entered place name meets anyone’s definition of standard. There are no research suggestion flags for this field at this time.

    2) To standardize a place name - To pick from the menu of place names in the FamilySearch place name authority list, or standards list, a name to be shown in the green standard bar. A short list of suggestions is given in the drop down menu associated with the green bar. One of these must be picked. A red data error icon appears in under Research Help if one is not picked. This list of names is incomplete and will be for a long time.

    I agree completely that “Butterton Par.Ch, Hulme End, Staffs” is a horrible entry. It is incorrect, inaccurate, not understandable, ambiguous, and incomplete. But it is standardized. That is why, when discussing Family Tree, we need to be clear what we are talking about when discussing standard place names and standardization.

    Currently the FamilySearch list of standardized place names is very inadequate but is slowly improving. Once, not a single cemetery was included. Now, almost every one I want to enter is included in the standards list.

    The main place I run into problems with their standards list is in recording place names for my wife’s Norwegian relatives. Currently the standards list usually provides two choices. 1) Farm, County, Country or 2) Parish, County, Country. Using the first choice is very ambiguous because there can be a couple of dozen farms with the same name in the same county. The second choice is very ambiguous because the parishes can be very large and the number of names people used was relatively limited. My practice is to enter Farm, Parish, County, County in the white displayed text data entry box and pick Parish, County, Country for the standardized form.

    It’s always fun to learn something new. Where are place description fields hiding? I’ve worked on paper family group sheets, in PAF for Mac, in Reunion, on Ancestry, and on My Heritage and never seen anything labeled that.

    Did someone develop a place description field because of the limitations of the place name field prior to Family Tree? In PAF for Mac we were limited to 16 characters each for the four components of the place name, a total of 64 characters. Abbreviations were often needed. In Family Tree, the place name field can contain 200 characters. That is plenty of room to describe almost anywhere precisely. There is no need for a separate place description field.

    (I tried creating a mailing label to send something to the White House using just 20500 and the postal service’s website stated that was a non-deliverable address. It required full street name, city and state.)

    ReplyDelete
    Replies
    1. Put 20500, United States on an envelope and it will likely end up in the White House mail room. The USPS works out the proper addresses for all sorts of weird stuff as do all postal services the world over. If you haven't guessed the other famous address, it's 10, Downing Street.

      Turning to the description field, as I said the four vital events of birth, christening, death and burial don't have such a field. They only have date and place fields (plus of course the fairly useless "reason" field). However add a residence to someone and three fields come into being; namely date, place and description fields. That's true of all other event types in the tree. Like I said I believe that a building name, building number or street belong in that field. The same is true of a cemetery name as well. Cemeteries are not "places" in the sense that I think is properly meant by place in that database. I would define a "place" in that context as an administrative unit that is unique identifiable within a particular jurisdiction. So a county, city, town, village, hamlet, region, parish or registration district fulfill that criterion. A cemetery is a particular geographical location within a "place", just as a street or a building or a square are. Geographical locations with a "place" should all be linked to that place semantically within the database.

      In fact what I would ideally like is the Rootsmagic solution which is to have four fields. That would be date, place, place detail and description. That way the separation between a place and part of a place is maintained and the description can be used for something else than the most precise geographical pinpointing if so desired.

      Beyond that proper, consistent field structure for events there are a couple of other things that I think Familysearch need to do to the data structures of the tree. The first is to make it so that all events can have sources tagged to them. I referred to the reason field as "fairly useless" above as I believe that a breakdown of why an individual person came to a particular conclusion about data is widely misunderstood and far too flat a structure. Conclusions that lead to the creation of events are supported by source citations. Linking the source citations to the event they support uses the capabilities of a database for more than just having a wall of text or the particularly stupid "GEDCOM information" as a reason.

      The third alteration that is needed is to the couples field. There are several types of events to do with marriage that are completely unsupported such as marriage banns. That is a couple-level event and yet it is completely absent from the database. Add marriage bann, marriage licence, civil partnership and separation to the events supported there and things would be a lot better. Oh and also distinguish between marriages and marriage banns in the record transcripts that are created. There are lots of "marriages" which are nothing of the sort in many of the record transcription databases which therefore make those record transcription databases a trap for the unwary.

      Your point Norwegian and Danish farms is well taken. They are quite the conundrum for the foreigner. I remember watching James' video about Danish places and records which clued me into this particular little geographical horror of a problem.

      Delete
    2. Oh, that place description field!

      From the position of the place description field in Family Tree, which is before the date, I have always assumed that that field was completely equivalent to the Birth, Christening, Death, and Burial titles in the Vital information section. The only thing I would have ever thought to put in that field was a description of why that place was entered as part of someone’s history, such as “Boarding School,” “Canadian Census of 1916,” or “Wheelwright Apprenticeship.”

      I have always defined “place” as that red cross you see on buried treasure maps. Not wanting to dig a bigger hole than necessary, I am perfectly happy having a place name narrow down a location to a 6 inch square patch of earth. So I am completely fine with having in the Vital Information section or the Other Information section in Family Tree entries such as:

      Description of Custom Event: Marriage Proposal
      Date of Custom Event: 12 May 1954
      Place of Custom Event: Park bench next to Three Sturgeons Fountain, Butchart Gardens, 800 Benvenuto Avenue, Brentwood Bay, South Saanich 1, Capital Regional District, British Columbia, Canada

      Delete
  4. Thanks for giving me more work to do. :-)

    ReplyDelete