Difference between Displayed Place Name and "Standardized" Place Name Continues to Cause Confusion
Since I continue to run into people confused by the dual place name data entry used in Family Tree and who are convinced all place names must be "standardized," could the place name entry boxes be modified in some way to clarify intended practice? One though I have is to do something like this:
Having the explanation of what goes in each field should help people realized the two fields do not have to be the same and to realized that the words of the standardized value are just an easier to read version of latitude and longitude than having numbers.
Just the other day I spent half an hour restoring place names. Someone had wasted both his time and mine in going through and changing names like "Vikanes, Stord, Hordaland, Norway," "Eldøy, Stord, Hordaland, Norway," and "Dale, Stord, Hordaland, Norway," all to just "Stord, Hordaland, Norway" in the name of "standardization."
Early in Family Tree when the Place field and the Standardized Event Place field were both always present, it was a bit easier to convince people that these are two separate data items. Now when they happen to look the same, there is just one field which I am concerned leads people to think there should always be just one field.
Comments
-
Place Names MUST reflect the name of the place at the time of the event. Current name will change anyway and are only useful currently, not for research of history (History is any time before today) or in the future (Some time after today).
Example. in 1952 I moved to King George Road, Walderslade, Kent, England, United Kingdom.
In 1956 it became King George Road, Weedswood, Chatham, Kent, England, United Kingdom.
Currently it is King George Road, Medway ME50PS, United Kingdom.
It is the same place!!
The latest example means nothing except to the post office not even where it is in the United Kingdom, not even what country its in!
It was Walderslade from before Tudor Times and mean wooded valley between wooded hills Walde = Woods Slade = Valley
1 -
MartinCoull It sounds like a good idea to always use the historic place name, but that assumes you know what the location was called. I don't always, and most people will eventually have that issue. Requiring the use of historic place names also assumes everyone looking at your record knows the history of the location and it's various names in the past as well. THAT is certainly not true either. To make matters worse records are increasingly being found in collections where the political entity that created the record predates the political entity of the collection, and FamilySearch happily conforms by indexing them incorrectly. I have an example. Take a look at the two URLs below. The first is to an old marriage register which gives no hint that Virginia is the location of some of those marriages, but the FamilySearch indexed info says Kentucky. The second url is the original marriage document of one marriage in particular Aldert Plough, G91D-L6Z who is listed in the register. You can read "Commonwealth of Virginia", yet the collection is a Kentucky collection. This marriage took place 5 months before Kentucky became a state. Gordon Collett , your screen shot showing two locations, one standardized and one not, is not always offered. Look at the marriage information of Aldert Plough, G91D-L6Z. (I work in the new person page view). There are NOT two locations available, so when I standardized the location to Virginia, I went against all the FamilySearch indexed information and had to put the reason in a comment which does not display. I probably confused and inflamed some descendants who "know" he was married in Kentucky and all FamilySearch index information back that up. I suspect it is just a matter of time before someone changes that location back to Kentucky.
Aldut Ploegh, "Kentucky Marriages, 1785-1979" • FamilySearch Indexed incorrectly with a birth location of Kentucky
Kentucky, County Marriages, 1797-1954; https://familysearch.org/ark:/61903/3:1:3QS7-L93Y-46M1?cc=1804888&wc=QD3Q-H9M%3A1589735625. This is the original document showing that it is, in fact, a Commonwealth of Virginia legal marriage document, still housed in a Kentucky collection of marriages.
1 -
@Gail Swihart Watson, regarding not always knowing what a location was called, that is one of the purposes of the Places database. That is, to compile in one spot, as one massive reference database, what every spot on the earth was ever called, when it was called that, and what jurisdiction it was under at that time. This is a massive project and it is far from complete. But for many areas there is great information. For example, If I don't know the proper jurisdictions for the farm Brandasund, I can just check the database at https://www.familysearch.org/research/places/?searchTypeaheadInputText=brandasund&text=brandasund and see that through 1861 it was in Stord community, then from 1862 to 1994 it was in Fitjar, then in 1995 it was put under Bømlo.
When the database is complete, it will be easy for people to check and determine proper locations.
For example, the database clearly shows when Kentucky became a state so obviously it should not be used for places before that time:
Looking up your example, Woodford is shown as being in Virginia with an ending date of 1792 then being in Kentucky with a starting date of 1792. The time periods are just by year, not by month or day which puts a little fuzziness for your example since the event was in 1792, but having the creation date of Kentucky makes it clear which jurisdiction should be used.
Indexes have always had problems and always will, from bad transcriptions, to columns mixed up, to incorrect places, particularly since the recent attempt to assign standard places using the too incomplete database. People need to be taught over and over that indexes are not sources, only sources are sources. I have a few examples in which a marriage record is indexed as having taken place in one parish but when checking the actual record it states that the marriage took place far off in a different parish and this record was just the local priest's documentation that the couple had gotten married.
your screen shot showing two locations, one standardized and one not, is not always offered.
This is the common, incorrect misunderstanding of the whole system. It is not "two locations, one standardized and one not." We actually have "the correct location and the standardized version of that location that has been linked to it." Both are always present. However, if they happen to be spelled the same and look the same, as in your example, they collapse into one data field, which I think is a mistake. (see: https://community.familysearch.org/en/discussion/134531/editing-box-and-the-display-of-linked-standards#latest )
It would be good to be able to see the reason statement on marriage information, just as we can on other information when the Detail View is turned on, before getting all the way to the editing box. Looking at your example, I think your reason statement that anyone going in to edit the marriage place will easily see should keep people from changing the information. You could also repeat the information in a Note in the relationship pop up that is one step before the editing box.
1 -
There is a problem when the historical name of a place isn't likely to be known by the average person. For example, Tennessee was just "Southwest Territory" before 1796, and even though some cities do have pre-1796 location entries for that, entering something so generic for settlers who moved there just shortly before it became a state, especially when it bears no resemblance to the name it was soon given.
In some cases, the records are listed under the new place name and don't even mention the old place. For example, there are vital record catalogs for counties in West Virginia that date back a hundred years before there was a West Virginia -- the records name West Virginia as the place, either because they are indexes created later or because they are part of a collection for a county that became West Virginia later. And although, yes, they should be entered just as Virginia, it's a big ask to expect the average editor to know this and work against what the record itself says is the location.
The database has some well-deigned bits for date-based names for the same location, but the edit fields for location in the tree itself aren't built to take advantage of that: each historic place name is just another item in the list of possible locations, and there's no easy way for users to find out what the historic names are (short of going to the FS Place page, which most people don't even know about). It'd be better to have the historic names listed as alternate options when the location has been selected, like a submenu that appears when a location is selected.
Having the name change automatically based on the associated date would be great, but given how much room for improvement there is and how little improvement is actually happening, I kind of doubt we're going to get anything like that. Plus, the system isn't well designed to store when locations were split and new locations were formed from from pieces of old locations. Some of my NC ancestors lived in three different counties without having moved.
We should also have the system go through the dated indexed records and change the standardized location name to match what it was called during on that date.
1 -
Some of my ancestors lived in Maryland, then Pennsylvania, then Maryland, without moving.😉
And the US is fairly simple. I have ancestors in what is now Germany, who lived in several different countries during their lifetime, without ever moving.
Places are messy. Each situation in unique, and there is no rule that will work for all places. My ancestors lived in Ravensberg, but who ever heard of that? It later became part of Westphalia, so I use Westphalia so they can be found with searches.
0 -
@RTorchia, yeah, no, not another autostandardization mess... FS can't seem to do automated processes right to save its life.
One problem with the idea of choosing the location first and then the appropriate historical name and jurisdiction is that the database is not currently correctly set up for that. For example, probably well over 90% of places in Slovakia and Burgenland, and in the parts of Slovenia, Serbia, Croatia, Romania, and Ukraine that were in the Kingdom of Hungary, have two or more separate entries in the database, one for their current jurisdiction, and one for their historical jurisdiction(s). These entries aren't connected by anything other than alternate names that sometimes bring up both entries in the drop-down (if you type exactly the right portion of the name, no less, and no more). If the new name was invented by the successor state and the old name hasn't been entered under alternate names, then there isn't even that much connection.
Ideally, yes, one should be able to type in whatever the document says and get a list of suggestions of where on the map that is and what administrations it belonged to and when, but the fact is, it's never going to be that easy. You're always going to need to research which of the over a dozen places named Morton in the UK your document is referring to.
As for what placename appears in an index, leaving aside that currently on FS it generally says balderdash, the usual practice is to use the name and jurisdiction from the time when the index was made. This is of course almost always wrong for the time of the event, but it speeds up the index's publication.
3 -
Aren't we genealogists? Don't we do family history? Don't we as researchers do research?
We expect people to learn how to properly enter names. We expect people to make an effort to enter correct dates, not just make up something. We expect people to learn to read original sources and not rely on highly fallible indexes. Otherwise what is the point of all this if we are just going to pat people on the head and say, "this is too hard for you, just type in whatever you want."?
With the massive amount of online resources available, including the Places database, there is no excuse for not entering place names in a historically correct manner. If we don't know what a place was called at a certain time in history, then we need to start doing family history research. And then we need to document that research so the next person to come along does not need to repeat it but can read right in a person's profile the history of places names where they lived. That is one of the purposes of Family Tree. One person can do one portion of needed research, document it, and no one else needs to repeat that research ever again. This is the tremendous advantage we have now instead of in the past when hundreds of people with their private papers and private databases would all do the same research over and over and over again.
No one knows about Ravensburg? Put in the historical name and a good reason statement to teach the next person to come along the history of the place. Southwest Territory is too vague? Explain it. And put in a Residence event under Other information with the date of a state's creation as a new residence as of that date.
So people don't know about the Places database? Then teach everyone you can all about it. All they need to know about a place name might already be there. All the research needed to be done about a place name might be sitting in plain sight in Wikipedia.
Don't throw away all the great tools we have in Family Tree to fully and accurately record all the history of a person's life. The needed research only needs to be done once if it is fully documented.
4 -
One person can do one portion of needed research, document it, and no one else needs to repeat that research ever again.
Yes, exactly. So if entered correctly - why leave it open-edit so AI routine or the next record hint/person can change what is correct to something that isn't? Why not require the alternate (incorrect) proof to disprove read-only data (through discussion/collaboration)? Glad to see you agree with me @Gordon Collett
Or if I am entering something wrong or not fully documenting correctly - mark that with red exclamations and teach me how to do it correctly ... or even prevent me from entering it ... Don't leave it open-edit so that correct information can be changed for incorrect.
This thread is dealing with place names - but the same principle applies throughout the Tree.
0 -
Gordon Collett While I agree wholeheartedly with you in concept, your "let them learn history" approach is a bit too harsh for me. Reminds me a bit of "let them eat cake."
I want relatives to learn to love and enjoy their family history and the history that engulfed their ancestor's lives. Most of my family aren't going to become genealogists. Most aren't going to learn history unless I make it interesting and relevant. They are never going to do their own research, but they all love it when I spoon feed this stuff to them. They love pedigree screen shots. It's cool. So from MY perspective, I am working for MY family in FamilySearch to make it easy for them (and future family) to learn to enjoy it. I have a fair number of online meetings with family and it is so fascinating to see that as we enter a "family oriented" season of christmas, I'm getting LOTS of requests to tell stories and show "our history" to semi-interested audiences. So my moto? Make it fun to see and hear, make it easy to understand and make it personal. YOUR 5th great grandfather was here and did that!
I also do lineage research for others. I am somewhat more business like in my approach there, but I still find myself trying to make people enjoy learning about their family history even though it isn't part of the job description.
Again, your approach Gordon Collett is spot on when addressing an audience of researchers. Go for it!!! But what about a niece or nephew or son or daughter who approaches you? Do you want to scare them off or lure them in?
1 -
Do you want to scare them off or lure them in?
Does open-edit in the Tree lure them in to contribute error or correctness? Anyone can contribute anything (pretty much) - it's open-edit. I don't know how much more they could be lured?
Places database allows any submission, creates a provisional place that can then receive Accepted status by FamilySearch. Is this the model we need in Family Tree? (Oh boy ... Can't wait ...)
1 -
I'm a names geek at heart: I find it endlessly entertaining that (Czecho-)Slovakia's administrators proved that I'm not the only one who gets the water-adjacent mammals confused, when they renamed Hódos (derived from Hungarian hód: "beaver") as Vydrany (derived from Slovak vydra: "otter"), or that Szombathely ("Saturday-place") is called Steinamanger ("stone in the meadow") in German. Therefore, I am extremely appreciative of FamilySearch's dual-field setup for placenames, because it means that even if the database is or gets totally messed up, it doesn't prevent me from entering full and correct data.
For example, there was a period a while ago (earlier this year?) when for some unfathomable reason, "Sopron" wasn't available as a standard. Only its German name (Oedenburg) was available. This was especially infuriating given the fact that Sopron earned the designation of "most faithful city" by voting to stay Hungarian after the first world war. So I submitted a correction request, and in the meantime, I entered Sopron, associated it with Oedenburg, and forgot about the whole thing (until I had occasion to enter Sopron again recently, and discovered that the error has been fixed).
In contrast, on another family tree website, I cannot enter my grandfather's birthplace correctly. Their database only has modern placenames, so they insist that my grandfather was a time-traveler: he was born in a country that didn't exist until ninety years after his birth (and twenty-five years after his death). On FamilySearch, I can enter not only the correct country, county, and city, but also the name of the farm -- without needing to have anything added to or changed in the database.
That said, another thing I appreciate about FamilySearch's setup is that if my Slovak cousin can't remember the Hungarian name of Garamszeg, he can enter it as Hronsek, and when I can't remember how to spell its neighbor Veľká Lúka, I can enter it as Nagyrét, and the system will put the pins in the correct places on the map regardless, without complaining at either of us about choosing an unknown location. This flexibility is the system's strongest asset: it means that deficiencies in the database or user knowledge do not prevent good information from being entered. Making the flexibility more obvious, by showing both placename fields even if they're identical, would be a Good Thing.
3 -
@Gail Swihart Watson you stated:
I want relatives to learn to love and enjoy their family history and the history that engulfed their ancestor's lives. Most of my family aren't going to become genealogists. Most aren't going to learn history unless I make it interesting and relevant. They are never going to do their own research, but they all love it when I spoon feed this stuff to them.
That is exactly my point. If you do the research, you can put in the correct information, well documented, so that people coming after you do not need to spend the same hours you did figuring out that same history, but can just enjoy the real history you have provided.
To take @Cheryl Viering's example where she stated:
My ancestors lived in Ravensberg, but who ever heard of that? It later became part of Westphalia, so I use Westphalia so they can be found with searches.
You, Cheryl, do know that your ancestors lived in Ravensberg, so if you enter that and document in a reason statement or elsewhere how the name changed then everyone that comes to your joint ancestors will now know that Ravensberg existed. And how cool of a fact is that for your family to know regarding where their ancestors really lived.
1 -
Aren't we genealogists? Don't we do family history? Don't we as researchers do research?
If you mean "we" to mean "all users of this site", no, most of "us" are not and never will be, not as long as the administrators of this site refuse to place boundaries on anybody off the street entering basically anything they find from anywhere without explanations or sources. Once some sort of improved quality control happens, maybe this statement might approach reality. Until then, we can't pretend that any sort of idealistic expectations will accomplish anything other than raising our blood pressure. We need to think in terms of how do we make the site simple enough for uninformed hobbyists and/or how to make the site bulletproof enough to quickly and easily fix their inevitable mistakes. I don't like it, but clearly nobody with the ability to enforce such standards is interested in setting any.
If the location system defined will never be functional because it depends on a database that will never be complete, then it simply needs to be scrapped. What a specific location was named on a specific date is, in my mind, nowhere near as import ensuring that the actual location is adequately described. If it's by using modern names that may be easier to find and more granular than historic names, that's fine; that gives enough information so that somebody who wants to know what the place was named at that time can figure it out.
Really, the place name at the time isn't personal information; it's just historic trivia. A town changing its name or being moved into a different county probably had very little effect on most of the individuals who lived there, and just knowing the historical town name tells you nothing about what their actual lives were like. You'd give greater insight by including the system of government and the names of local and regional authorities.
0 -
If the location system defined will never be functional because it depends on a database that will never be complete, then it simply needs to be scrapped.
@RTorchia I believe I disagree here. The system allows the flexibility for the user to enter the place they know - the problem arises when someone else thinks that place is not Standardized according to how they understand Places should be entered (or perhaps a place they know) - and go ahead and change it to a Standard and remove the perfectly a good place.
On the other hand if it is a perfectly good place and can be attached to a Standard that exists for the timeframe - that can also be created as a Standardized place. But then someone more familiar with a different Standard - may want to change it ... Maybe Alternate Standard Names? 😐
I think perhaps part of the problem is that these perfectly good places do not ALL have a map pin or bounded area is part of the problem. Many places contain surface area - and most of those FamilySearch assumes control over entering. The categories of Places users can request to add are quite limited... and users can request changes/improvement to FamilySearch entries... I do agree that if people only 'know' a certain name for a place (perhaps more recent or what they grew up with it being called) - the system needs to help guide them to a correct Standard for the timeframe of the profile concerned.
I think the system is fine - there is just disagreement amongst users - go figure ... I am ok with it being a work in progress ... I've had good results at submitting/improving names.
0 -
You'd give greater insight by including the system of government and the names of local and regional authorities.
But that's exactly what using the name at the time of the event does. Placenames (entries in the Places database) on FamilySearch are actually multiple pieces of data. Even if you're standardizing to just a country, that includes a categorization by continent or part of the globe. If you're choosing a historical time period for a placename, you're also choosing the jurisdictions that went with it at the time. True, there might have been some simplification, to keep the number of time periods manageable, but choosing, say, "Garamszeg, Zólyom, Hungary" instead of "Hronsek, Banská Bystrica, Slovakia" also tells you the "local government and regional authorities" relevant to the event.
1 -
@Gordon Collett, I'd like to enter the correct place name, but there are problems.
The INDEX that I am using is not searchable. You can only search the tree, and only find records that are attached to someone in the tree. People searching for a person may not know about the details of the region yet. They may only know somewhere in Westphalia or Prussia. If I enter the place as Ravensberg, a search on Westphalia won't find it. A search on Ravensberg won't find anything entered as Westphalia. A few months ago the find was "improved" so that searching on "Versmold" finds nothing, but searching on "Versmold, Westphalia" does. One day the searches I had been using came up empty, and it took me a while to stumble upon a new search that would work.
It's hard enough to find these entries if you are familiar with the area. I'd like people to be able to find the information I've entered. All of the entries I've come across were entered as Westphalia, so I've followed the convention, and done the same. After they find the person they are interested in, they can then learn more details about the history of the area.
0 -
By my definitions, an unsearchable index is a contradiction in terms: the whole point of an index is to make a record set searchable.
If you enter an event place as "Ravensberg, Westphalia, Prussia, Germany" and associate it with "Westphalia, Prussia, Germany" for the standard, does the Find routine fail to find the profile?
(Granted, getting it to do that involved first typing it all in as "Ravensburg ..." so that it wouldn't come up with the two farms in Kreis Halle, plus strategic use of clicking outside the box.)
0 -
Really, the place name at the time isn't personal information; it's just historic trivia. A town changing its name or being moved into a different county probably had very little effect on most of the individuals who lived there, and just knowing the historical town name tells you nothing about what their actual lives were like.
It's far more than just trivia. It can be very important.
The 1875 census for Fitjar, Hordaland, Norway states that Ole Amundsen was born in 1843 in Fitjar. If I go to search for his birth record in Fitjar, I can't find it. In fact, searching in the Norwegian National archives, I find that there are no records for Fitjar for the 1840s.
This is because Fitjar municipality did not exist until 1862. Prior to this the area was all part of Stord, Hordaland, Norway. If I want to find Ole's birth record, I have to search the Stord records.
This can be a common issue in the United States as well as counties were divided. If you don't know the county someone lived in at the time of the event, you may waste a lot of time looking for records in the current county.
If the location system defined will never be functional because it depends on a database that will never be complete, then it simply needs to be scrapped. What a specific location was named on a specific date is, in my mind, nowhere near as import ensuring that the actual location is adequately described.
The current system works great when understood and properly used. It is fully functional. There is no need to scrap it. If you are having problems getting place names correctly entered, give me three examples and I will show you how to enter them and how well the system works.
0 -
@Cheryl Viering, One thing I really like about Family Tree is it's flexibility in allowing complete documentation for any situation we run into.
If you feel that for the present state of the Family Tree search engine and Places database to enter Westphalia for you family, as you have found, you can do that, even if it is not historically correct. But I would not let the fact that everyone else is doing that because that is what everyone has always done stop you from making the information in Family Tree be as accurate as possible.
I would suggest a multistep approach:
- Enter the place name in a way that you feel it needs to be for now.
- In the Reason Statement document in good detail what the place name actually was at the time of the event so no one has to repeat your research to find out what it was.
- Submit suggestions to the Places database to improve Ravensberg to the point that searches work correctly.
- Teach your family where they were really from as you shares your information with them.
0 -
Somewhere between the Places gazetteer team and Family Tree, massive changes are happening right now. Where many standard place names were ..., Germany, now they are ..., German Empire. And some places in Germany (er...) have seemingly duplicate standards in the pull-down menus on Family Tree.
So, perhaps take a break for a few days or weeks and let the dust settle.
2 -
Interesting. I wonder what type of update is being done. This brings up an important point about the nice features of the dual place names. Even if an update to the text associated with a specific latitude and longitude is updated, the existing text of the Displayed place name is not changed, it remains just the way it was entered, it is still standardized, and nothing needs to be done by us users even though the Displayed place name and the standardized version linked to it no longer look identical. The Displayed place name is still standardized.
1 -
Yes. Indexes are supposed to be searchable. This one was, until about a year ago. Then it wasn't, except for records after 1890.
These are the indexes I've been using, https://www.familysearch.org/search/catalog/182495?availability=Family%20History%20Library
I am updating/correcting the tree with a ton of information from the documents available from Archion. I've tried to inform the system about this problem, but never received any replies. I'm simply not going to do all the extra work of adding redundant notes to thousands of records if I can't find anyone interested in fixing the real problem.
1 -
@Cheryl Viering So you haven't received reply of acceptance of improvements to Places you've been trying to change? Yes, it makes sense if you can't receive a reply to those improvements then adding redundant notes that someone might change the place on anyway ... Doesn't make sense.
1 -
Wait time on my suggested improvements to Places has been weeks or months. In recent months I am holding off on making any suggestions because I see so many wholesale changes happening. The gazetteer team must be working flat out!
Rather than make work for myself or do sloppy work, when I see a collection needs gazetteer work I try to avoid it for a year or so.
1 -
The system allows the flexibility for the user to enter the place they know - the problem arises when someone else thinks that place is not Standardized according to how they understand
The system allows freeform entry, yes, but that's to compensate for the database being incomplete. Various help documents have clearly expressed a preference for standardization. The claim that the intent of allowing freeform entry was to allow entry down to an address level has yet to be supported by any documentation.
In any case, it goes back to the initial point that, if standardization is important, we at least need to know whether the standardized location is set correctly without opening up every single field to check it manually. If it's not even important enough for that, then the system is flawed and needs to be scrapped.
But that's exactly what using the name at the time of the event does.
At local levels, the name itself does not inform you of any of that. Countries, maybe, but most of the changes that affected average people on a daily basis had no effect on the name of the location they lived in, and a town being moved from one administrative district or county to another typically didn't affect them on an individual basis either.
To understand the history and living conditions for a certain place at a certain time, you still have to crack open a history book or encyclopedia, look up the place, usually by its modern name, and the first thing it'll tell you is what that place was named back then.
This can be a common issue in the United States as well as counties were divided. If you don't know the county someone lived in at the time of the event, you may waste a lot of time looking for records in the current county.
An example I provided earlier demonstrates the exact opposite of this, and I know two other examples off the top of my head where records from one county are included under another, one because it was moved into a new state, one simply because it was grouped that way. There is no consistency here with the way records are handled in circumstances like that, and there are plenty of cases where using a modern name that identifies the location more commonly and precisely is preferable to an older name that doesn't, such as before a town was incorporated or a state was formed.
And I stand by what I said: such specificity has nothing to do with the individual, which is what the profile page is about. What mattered most was the physical location, regardless of how we identify it. Given that and a date, we can always find out the historical conditions. The profile page is a high-level overview of an individual, not a toponymic dissertation.
0 -
I am not sure what you are suggesting. Are you saying you would rather Place just be a free-form text field only - with no lat./long. or map pin - only a required attached citation to a record? Or are you suggesting the opposite - that there should just be a pin on the map - but no database of possibly different/alternate names for different time periods? I agree that the first thing a person naturally does when reading a placename - is wonder "where is that?" and decide whether to look it up. So why not have a map with a link to that place built into the platform?
As far as Places database being incomplete - I would expect it to remain such - especially if there aren't enough dedicated people that know how/learn to fill out the form (which is quite simple). So an argument about an incomplete database seems 'chicken or egg' - users can help it become more complete - and that should be fine. But yes that does present a problem when the place one enters has multiple confusing options appear in a list. But what other approach would you suggest that would help users either select a proper standard from the Standardized list that appears, or pick 'none of the above', or enter the place (as they know it or see it recorded) as free-form/text?
if standardization is important, we at least need to know whether the standardized location is set correctly without opening up every single field to check it manually.
I suppose this means you're in favor of the map pin icon indicating a selected place matches a Standardized place? I don't have a problem with a pin - as long as people don't think a free-form entry without a pin means the place isn't Standard so they should change it - when it's correct already. This is one area where in my opinion if there is documentation attached/tagged with the place that is entered - as long as transcribed correctly - go ahead and read-only that place (it's entered correctly - unless the record is wrong ...). I'm all about getting correct information attached to profiles to meaningfully contribute to the individual's profile - whatever the level of specificity that is - either documented/sufficiently proven - and then remove that from open-edit (why change what is correct?). I could go on and on - as I have kind of done a little on other posts about why I believe this way - but such is not the FamilySearch platform - so we just have to make due - and do our best with the way the platform is. Sure we can submit Ideas about how we perceive it could be improved/better. For example
records from one county are included under another, one because it was moved into a new state, one simply because it was grouped that way. There is no consistency here with the way records are handled in circumstances like that, and there are plenty of cases where using a modern name that identifies the location more commonly and precisely is preferable to an older name that doesn't, such as before a town was incorporated or a state was formed.
I think this could be handled as I think was mentioned earlier - if a different jurisdiction has custody of records than the one that had jurisdiction at the time - that could be in a jurisdictional/custody chain field (probably by the dates associated with the places the jurisdiction(s) will need to change or be updated at least that often). I'm all about giving a researcher the best knowledge to get them to the records they should search. Yes, perhaps there was no consistency with how records ended up where they are - but there should be a way to point the researcher to those records. But if AI routines are allowed to change all the hard work (or lack thereof) that went into getting the record places set - that does not inspire confidence that places will get resolved successfully anytime soon. Having the database display the original place in addition to the AI/routine place I think is a good first step.
I don't have a problem with the way the platform implements places. I just need to do better about researching a place when entering places on a profile - or just enter what is on the record, select one of the matching standards from that timeframe and hope someone doesn't change it because they know the place differently. So i guess what I would suggest - read-only the user free-form contribution if there is attached record/memory - but allow other users to select a different Standard if it suits them (that way the map pin shouldn't be moving too far - it should still appear in the vicinity).?
0 -
So now we have come full circle back to the entire point of my initial post. The difference between and the purposes of the Display Freeform Place Name and the Standardized Menu-derived Place Name are not sufficiently explained and too often misunderstood.
To repeat with emphasis: every single place name everywhere in Family Tree is always entered twice. Once as the Displayed Freeform data and always a second time as the Standardized Menu-derived data.
The system allows freeform entry, yes, but that's to compensate for the database being incomplete.
The system does not just allow freeform entry it always includes the freeform entry. This is not to compensate for the database being incomplete but because of the inherent constraints of a menu-derived system that will never be sufficient for genealogical research. To point out some differences between the two:
• Freeform:
- Pros - allows precision, completeness, accuracy and the freedom to enter a place name however it needs to be entered, including historical variants, for a given situation to record correct genealogical data.
- Cons - a computer program can have no idea where a place is.
• Menu-derived:
- Pros - speedier entry of place names, eliminates typographical errors, allows latitude and longitude to be part of the definition for map placement and comparison routines, that is, a computer program can "know" where the place is.
- Cons - too prescriptive of what a place name must be, too limited in the number of place names included and always will be.
All other genealogical database I am aware of have either freeform or menu-derived place names. The beauty of Family Tree is that they have developed their system to include both by linking the user entered freeform text to a menu-driven equivalent text representation of the latitude and longitude of either the place itself or the jurisdictional level containing the place.
Various help documents have clearly expressed a preference for standardization.
Not a preference for standardization, but the requirement that all place names be standardized. This is very clearly demonstrated in Family Tree. The misunderstanding here is strictly due to continued misunderstanding of the definition of standardized. To quote the Merriam-Webster dictionary:
standardize
1: to bring into conformity with a standard especially in order to assure consistency and regularity.
2: to compare with a standard : to determine the strength, value, or quality of (something) by comparison with a standard.
FamilySearch is not using definition 1. They are using definition 2. The linking of the freeform text with the menu-derived text is their process of comparison to determine the value or meaning of the freeform text.
These two examples demonstrate that standardization in Family Tree refers only to the linking of the freeform data and the menu-derived data:
Here the freeform data, which is all that is ever displayed on the Detail page, is not linked to the menu-derived version in the first example but is in the second. Whether or not the freeform place name looks identical to the menu-derived place name has nothing to do with standardization definition 2 as used in Family Tree.
The claim that the intent of allowing freeform entry was to allow entry down to an address level has yet to be supported by any documentation.
Many of the best features of Family Tree are very poorly documented if they are documented at all. The claim is not limited to adding smaller jurisdictional levels such as addresses or cemetery plot designations, but that the freeform data allows even the jurisdictional levels included in the standardized version to be modified as needed, such as adding "Territory" to a place name when it should be there but the standardized version does not include it.
In any case, it goes back to the initial point that, if standardization is important, we at least need to know whether the standardized location is set correctly without opening up every single field to check it manually. If it's not even important enough for that, then the system is flawed and needs to be scrapped.
I have posted about once a year, if not every six months, for the past ten years a request to make the underlying linked menu-derived standardized version of the freeform place name easier to see than the very straight forward process of just overing over the name briefly with the mouse pointer, which is the current system. I do think it would be a good idea. My most recent request for this is here: https://community.familysearch.org/en/discussion/134525/display-of-standardized-values-of-dates-and-places#latest
But how often do people really need to check the linked menu-derived standardized version? I would be interested to see some examples of things that needed to be corrected and to hear an estimate of a percentage of errors found. How much time are people wasting checking unnecessarily? I think the most important things to do to cut down standardization errors, if they even exist in any appreciable number, is to improve the documentation and provide better instruction regarding:
- The fact that every place name is entered by the user twice.
- The use, benefits and features of entering place names twice.
- The fact that the user is completely responsible for entering both place names correctly.
- The fact that the user needs to proofread both place names.
1 -
(Sorry about that last, duplicate image if it is there at all. The system signed me out while I was typing and only saved a partial draft. I had to edit and paste in my final version but it won't let me get rid of the duplicate image. The pasting also went and shrunk the image that came in as a duplicate)
0 -
Opinion: From a practical point of view - the FamilySearch Places Database/Authority is what it is - that boat has sailed and you are late if you wanted to have input on initial design/implementation - and there won't be any scrapping of it.
Here is the best documentation for reference (at least what I can find to refer you):
It seems quite clear that the user can enter one place and associate it with a Standard from FamilySearch Places Authority. This seems to be in-line with what @Gordon Collett has said all along.
Every once in a while you see new FamilySearch developer/Solution partners in the Solutions Gallery. If you are a developer and want to make use of FamilySearch Places in your application you need to demonstrate how your application fills a need.
If you are a user and have an Idea how FamilySearch Places can improve - you can share your Idea to FamilySearch here in Community (just like this thread).
If you have a better solution - develop it.
0 -
Suggestion/Idea/Question (for further confusion): Entering the place in the display/free-form field has no option to enter Lat./Long. - only a named place. If the named place is an old Street now no longer in existence, there is no option for entering this street name as a new Standardized place. Fine, I can enter the name and Standardize a broader placename - but there is still no option to place a more exact pin/pointer on the map when such is found through research.
What would be the problem with having the option to enter such a pin/pointer on the map for the placename and have the Standardized place reflect that pin rather than the generic pin associated with the broader Standardized place? There would still only be one pin associated with the display/free-form placename.
Example: Bulldog Lane, Blackpool, Cork, Ireland is mentioned in some records 1860s and earlier. A researcher has compiled a google map of such old lanes with pins for their previous location:
Why cannot I be allowed to:
- Have an additional field to enter a Lat., Long. pin for this location on the display/free-form entry OR
- Standardize the place as a Street/Lane (no option exists in entering a new place for Street) OR
- enter display/free-form name, attach Lat., Long. sub-level pin (or more exact location - whatever you want to call it) for this place to existing Standardized place to reflect actual map location rather than the generic pin associated with the Standardized place?
With any of these options - the place would then have a pin - would that make people happy? It would me - or I'll just be happy without it...
0
