Error Report - Auto Standardization - Record correct, Search Result List Incorrect
In this search result: https://www.familysearch.org/search/record/results?count=20&q.anyPlace=hordaland&q.givenName=a%2A&c.collectionId=on&f.collectionId=4237104&c.birthLikePlace1=on&f.birthLikePlace0=0
I have checked the first twenty results and in every one the birth place, entered as only the name of the farm, shows in the results list as an incorrect full place name.
For example, the first result shows the birth place to be Kørbø. This was auto standardized to Korbo, Guéra, Chad. This should have been standardized to Kårbø, Herdla, Hordaland, Norway which is an entry in the Places database. I realize the incorrect transcription probably didn't help in this case.
The second entry has a birth place of Tana. This was auto standardized to Tana, Kanem, Chad. In this case, there was again a mis-transcription. This should have been Fana and been standardized to Fana, Hordaland, Norway. This set of death records lists just the parish the person was born in, not which farm.
The third result was transcribed correctly when it gives the birth place of Bua which was auto standardized to Bua, Northern, Fiji. It should have been standardized to Bua, Sveio, Hordaland, Norway.
A general rule for these Norwegian parish records is that if a place name is recorded as just a single word, then the place is located within the parish the the record book is for. There are exceptions, such as my second example above, but probably well over 90% of the time, if not over 99%, to list the next four errors here:
- In parish records for Masfjorden, Fes will be in Masfjorden, not Morocco.
- In parish records for Sveio, Reia will be in Sveio, not Mozambique.
- In parish records for Fitjar, Brakke will be in Fitjar, not South Africa.
- In parish records for Herdla, Sale will be in Herdla, not Morocco.
@N Tychonievich, I know you said these did not need to be directed to you, that others are working on these as well, but since you have been involved in this reporting process, I did want to ask, without any urgency in getting an answer, how many examples do the engineers really want of this specific type of error? I could supply an endless number of these "Farm with no other information" standardized to "Similar place name, incorrect random appearing county, state, country."
I say these are random appearing, but they really are not random. They are very predictable in that if you take the single word place name and put it in the Places database, the incorrect standardization is nearly always the first result in the list of possible places, as with Reia:
Answers
-
The results display is essentially choosing a place at random: it's finding a random place somewhere on the globe that has a coincidentally-similar string of letters associated with it. The suprising thing isn't that it gets it wrong; the astonishing thing is when it happens to get it right.
This applies across the board: single-element placenames in records from Place X are always referring to a place somewhere within Place X. They're never in some other country on some other continent.
So, for example, Norwegian parish records should fill in the last element of the jurisdiction with Norway. Mozambique, Morocco, South Africa, Chad, and Fiji will never, ever be the correct top jurisdiction for an incomplete placename in these records.
Without this basic, essential data validation step, whatever process is "completing" placenames for the search results display is just playing a ridiculous parlor game with the data, and making a total laughingstock of FamilySearch.
0 -
@Gordon Collett I sent your question to the engineers along with a report of the badly standardized farm names you reported. I'm bookmarking this discussion so I can find it again to update you when I get a response.
Just a comment about using these records as sources in Family Tree. I notice, that when you click to view the indexed information, the inaccurate standardization does not appear. Take a look at this page: https://www.familysearch.org/ark:/61903/1:1:68QH-ZPCQ. If you choose to attach to Family Tree as a source, this is what other users will see--not the error in the search results. So, while we wait for engineers to decide what to do, you can use these sources without worrying about confusing other users.
0 -
@N Tychonievich, Thank you for your reply. I do always just attach these source and make sure the information all gets recorded properly.
However, there is a significant problem with these records that impacts the view users have of each other and impacts the reputation of Family Tree. You would be surprised, or maybe not, by the number of users who just attach a source, hardly look at what they are doing, and go on their merry way not doing any proof-reading or cleaning up of data. Then other users come here to Communities and complain loudly about Family Tree having a rotten core because the poor data.
Here is what happens.
I created a Family Tree profile for Anna Malena Johnsen, the first person in my example search result list. When I open Source Linker to attach that first source I see this which looks just fine:
So I move all the new data over to get this:
Far too many people don't bother to review what is showing here or just don't understand what is going on or what to do about it and just click attach to get this:
Which again looks fine so they just leave without even bothering to notice the data error of birth after death that is now on the record or the weird appearance of the Time Line map.
The next user comes by and mutters under his breath about bad websites and crazy users and newbies that need to have their accounts blocked because he opens the birth editing box and sees this:
and opens the death editing box and sees this:
Not knowing what is really going on here, that user passes on to all his friends his poor opinion of Family Tree.
That is why I do get as many of these sources attached and correctly standardized as I can as I work through my wife's Norwegian family and correct these errors as I find them in the tree. Personally I'm not all that bothered by all this even though it really increases the amount of work I have to do, because I do know what is going on, that this is temporary (fingers crossed here), and I know how to correctly standardize this data.
(I have deleted Anna Malena.)
2 -
@Gordon Collett Oh, I am painfully aware of the potential problems these errors can cause. I hope you don't think I am trying to excuse the problems within the collections. Just trying to be sure folks who are careful and trying to get things entered as accurately as possible know ways to get the source entered in a way that is less likely to cause confusion to other users. Hopefully our overworked and understaffed engineers will be able to find some permanent solutions relatively soon. Thanks for hanging in there with us while we wait for corrections.
0
