Index dates n places standardized
As I go through my FS pages, I find dates and places non standardized, and hints that they are not standardized, so I have to standardize them myself, which takes extra time with a large tree. Why not put them stanardardized directly into the database from indexing, which would surely save time.
Comments
-
The list of standardized places is not complete, and when I tried to enter a new standardized place (you are allowed to do that), I realized I did not have enough information because the province name as I knew it, for a location in what was Empire of Russia at the time of my record, apparently was called something else at that time, and I did not know what the province name was. Standardized places are a lot more complex than people realize. We have records going back two thousand years. Is it reasonable to have a complete list of global standard place names going back two thousand years? No, it is not. Plus, I see so much compliance with the standardized places that is wrong, such as people born in places that didn't exist. I'm kind of curious why the push for standardized places at all, other than perhaps, the last hundred years.
0 -
They are attempting to make places in the indexes standardized and because of the complexity in several of the collections it is causing quite the mess. See: https://community.familysearch.org/en/discussion/comment/416721#Comment_416721 and https://community.familysearch.org/en/discussion/102829/errors-in-indexed-record-updated-place-names/p1 We as users who know the records and have studied out the place names will do a far better job of standardizing those place names than an automated routine ever will.
Regarding a "push for standardized places at all," having a standard linked to a place name is very important because that standard has two rolls. Most importantly, it tells the computer program what is actually meant by a place name. Each standard has one and only one latitude and longitude. It is the standard that allows mapping of a place name to one particular square foot on the globe. Using this, I hope that someday FamilySearch will be able to build in error checking for places such as they now do in merging for dates. We are warned if two people being merged have different birth dates. It would be great if they could warn that two people being merged were born more than ten miles apart.
Of secondary importance, is that if you happen to be entering a place name that matches a existing standard, it speeds up data entry a bit and prevents spelling errors.
"Is it reasonable to have a complete list of global standard place names going back two thousand years?" Maybe not, but that is what the Places database is working towards. In the meantime, that is why all place names consist of a pair of data entries: the place name as entered by the user and the textual geocode for that place aka its latitude and longitude aka the best standardized form of that name currently available.
0 -
FamilySearch has been adding standardized places to its indexes over the past year or so, but the automated process Gets It Wrong much of the time. The failures are often spectacular: Kenya instead of Kentucky, or Trieste, Italy instead of a farm in Norway abbreviated as T.S.
As background for why the automated process fails, one needs to consider the nature of placename fields in indexes. Most indexing projects follow one overarching tenet: "type what you see". This means that in projects with variable places that are supplied by indexers, those fields will always be incomplete, because documents almost never include the full jurisdictional information to go with a place's name. That is, for example, a register will name a person's birthplace as "Eperjes", not as "Eperjes, Sáros, Hungary" -- so the auto-standardizer will likely put it in the tiny village of Eperjes, Csongrád county (southeastern Hungary), instead of the city of Eperjes (now Prešov in eastern Slovakia) where it belongs.
Many indexing projects don't actually have any indexer-supplied place fields: the location is assigned wholesale in a pre- or post-processing step, based on the location of the first indexed page of the film or image group. These places are generally more complete than indexed ones, but they can still easily end up mis-standardized. For example, entire films of records from Lipova, Baranya, Hungary (which was later Hungarianized to Lippó) have been standardized as Lipova, Temes, Hungary (hundreds of miles away), because the place in Baranya is only in the database under its later name.
Another thing to add to the equation is a recurring bug in Source Linker, where a transferred conclusion is standardized, but when it's saved, the standardization isn't, and ends up needing to be re-done in the profile. I don't know whether it has been fixed, but even if it has, its previous existence has doubtless caused many unstandardized dates and places in the Tree.
0 -
I understand it is complex - and I still believe it will never be right, even if regional experts take ownership of creating standardized place names for their geographic areas of expertise. Also, I have another question. Will there be an editing function between date and place that will disallow the submission of incompatible dates and locations? Or a series of locations that did not exist together? That will be cool for those in the know but will drive most users crazy. For example, will there be check that will see an 1740 birth in Fauquier County, Virginia is invalid and cannot be submitted because Fauquier County was not created until 1759? Or another good example: will Selz, Odessa, Ukraine cause an error because Selz was renamed Lymans'ke during the Soviet era and was called that when the Ukraine was established? I just corrected a marriage record yesterday from Kentucky to Virginia that took place 16 January 1792 because Kentucky wasn't established until 1 June 1792. The marriage document even has "Commonwealth of Virginia" in it but I'm still waiting for the hate mail. Is it a plan to make sure any incompatible date/place or place/place will be stopped as an error until fixed?
If the answer is no, then what are you really fixing?
0 -
Good questions. I'm not sure the debate between people who use the historical place name "because that is correct" vs. the people who use the current place name "because that is the only way to find it" will ever be settled.
Looking at how dates are handled now might be how places will always be handled. The Family Tree program doesn't care how you enter dates. April 10, 1800; Thursday, April 10, 1800; 1800-04-10, Skjærtorsdag 1800; 4/10/1800; 10/4/1800 are all acceptable and you can put in any of them as long as you link them to the correct standard. As you are entering them, you are presented with the possible standards so you can use one if it is sufficient.
FamilySearch gives such huge leeway in how data is entered, as long as we also tell the program what we mean, I suspect the program will never force the use of a particular place name, but as the Places database gets more complete, it makes it easy for people to use the historically correct place name without having to research from scratch what it is.
For example, lets say that I have a relative who was born on the Brakestad farm in Vaksdal, Vestland, Norway in 1890. I know only because family still lives there and they told me so. I do want to enter the place name using the historical name but this is the first time I have worked in this area and really don't know what it is. So to start with I just enter the current name. As I do, I see this:
The date ranges don't fit. But I can go to the Places database at https://www.familysearch.org/research/places/?pagenum=1&pagesize=20 and find out what it should be.
I search for the place:
And when I click on the result I can see the various historical time periods for its names, including the one I want:
Choosing it, I see the information for that time period:
Now I can enter that into Family Tree:
but even more importantly, I now know that if I want to find information about this person, I need to search the Evanger parish records, not the Vaksdal parish registers. Which is the whole point of knowing where someone lived anyway.
So I would say that what is being fixed, is that the Places database will be a great tool to enable even beginning researchers to enter historically correct place names without first spending hours researching the history of the geography of an area.
Even now, if someone questions your correction from Kentucky to Virginia all you have to do is point out:
and that is the end of the discussion.
Your example of Fauquier County is another good example of the usefulness of the Places database in determining the best place names to use:
It allows us to quickly find the historically correct place name for any place at any time. Or will when it is completed in a few decades. I just wish it was better advertised and easier to find.
If someone complains that they want to use the current place name so other family can find it on the map, I just point out that because the place names include latitude and longitude, to find the place on a current map, you don't have to search at all. Just click on Timeline to see right where it is:
My other wish is that there would be a link on all place names that would take you right to that location in the Places database and easily see all the information entered there about the place.
0 -
@Gordon Collett , I think we have bantered before. Thank you for your very good explanation, but you approached the research a bit backwards. People are almost always stumped about what a place used to be called before it was called what I know it to be now. That website, while very nice, does not give predecessor information and will not help the person who has the 1740 birth record to attach to sources. As with your example in Norway, the more we get into our genealogy research, the more complex this is, and knowing how to find records gets more and more messy and more and more related to place names as they existed at the time. I guess I still do not understood how a database of standardized place names will make things better. In your example you site the problem created with Evanger parish records vs Vaksdal parish registers. Only the deep divers will know the truth and everyone else will skim by without understanding and THEN what kind of data base are we really creating? Lots of standardized errors.
Sorry I feel like I am beating a dead horse. My grouchiness is definitely related to the wibbly wobbly boundaries of Virginia colonial and state history, as well as Russian history for the past 500 years.
0 -
Gail, try working in central Europe, where whole entire countries changed.
Many (most?) of the old name versus current name entities are not currently linked in the database, except by the map pin and the modern labels on the map. For example, Nagyrét, Zólyom, Hungary is now Veľká Lúka, Zvolen, Banská Bystrica, Slovakia, but Nagyrét is a separate entity from Veľká Lúka -- you can't choose one and then go to the other, like you ought to be able to do. (This is due to the way the database was populated, based on official placename publications of various current and historical jurisdictions.)
Other genealogical sites -- such as MyHeritage -- try to force the use of current placenames, which I find infuriating (my grandparents were NOT born in Slovakia, as no such country existed then!) as well as nonsensical -- what about the towns that no longer exist, because they built a dam and it's all underwater, or because the entire village pulled up stakes and moved three miles inland after a historic flood?
I think it is exceedingly unlikely that the time periods for jurisdictional or name changes will ever be enforced. That's not how the whole display-versus-standard setup is designed: the computer doesn't know or care what extra information you've stored in the display value, so why should it care which time period you assign to the coordinates? They all point to the same place on the map, and that's really the only important thing, programming-wise.
0 -
I feel your pain @Julia Szent-Györgyi ! I have an in-law who is interested in having me do his tree. His ancestors are not far from yours. I dipped my big toe in for one research session and realized I'm going to have to take webinars or go to conferences. Oh my. His tree is a future endeavor. Not only are place names difficult, but ethnic groups kept their identity even after mass relocations. Yes, I hear you. Good luck!
0 -
@sharonODonnal1 - Thank you for bringing this to our attention and providing feedback.
0
