A method to change (or report) an error in the transcribed record search event data
I'm not sure how often this sort of thing happens, but here's an example:
Record citation: "Michigan, Eastern and Western Districts, Naturalization Records, 1837-1993", database, FamilySearch (https://www.familysearch.org/ark:/61903/1:1:Z4VG-RR2M : 2 December 2021), Patrick Corbett, 1931.
An entry that reads "Ballykearney, Mitchelstown,Ireland" on the original document,
and the same on the transcribed data from that document,
appears incorrectly in the record search results (found using the following search details - it's about the 20th result)
as "Mitchelstown, County Meath, Ireland"
when it's actually Mitchelstown, County Cork.
There are a couple of Mitchelstown's in different counties and I think the transcriber simply clicked the wrong one from a drop-down list.
There's no way that I can see for me to correct this, or even to report that it needs correcting. This needs to be added.
Comments
-
And there's another example for the same chap. 1901 census, born in "Co Cork"
not "Colombia" !
This would also appear to be a case of the transcriber typing "Co" and accidentally clicking the wrong one from a drop-down list of suggestions.
Once again, no way I can see to correct or report this.
0 -
When the word Original appears, it is usually an indicator of the automated placename standardization doing damage. It's not fault of the original indexer but of a post-processing algorithm poorly programmed. The worst issues seem to derive from an original index that is incomplete - just a town, with no county or country, for example. The algorithm grabs the first placename that sort of matches.
If you search in the community, you'll find many similar threads on "placename standardization."
@N Tychonievich please and thanks - another one for your growing file of placename standardization problems.
1 -
The "transcriber" (more correctly: indexer) had absolutely nothing to do with those errors. That's the autostandardization bot, hard at work.
FamilySearch continues to believe that these errors can reasonably be fixed piecemeal, based on individual user reports here in the Community. If you see two place fields in an index entry, believe the one that's labeled "(Original)". That's what the indexer actually typed. The other one was picked by the computer, without reference to the collection or any other available metadata. The results list for a search of indexed records unfortunately only shows the computer's choice, so nothing on that screen can be taken at face value.
4 -
@kob3203 Thank you for reporting the errors. I have reported them to the team that is working on corrections.. Unfortunately, we can't predict how long it will take for things to get corrected. The inaccuracy in the search results for the Michigan naturalization, fortunately, does not shows when you look at the record details, so won't be carried over if you attach the source to an ancestor in Family Tree. The error on the Ireland 1901 census is on the record details page. So, when you use that one as a source, you will want to note the error, to prevent confusion when others look at the tree profile and sources.
0 -
Thanks for the replies. So it seems that this sort of thing happens more frequently than one would hope - placename standardization.
Good to know that something's being done about it, and that reported errors should be corrected at some time.
By the way that second example, the 1901 Irish census record showing 'Colombia' in the search result, has exactly the same 'Event Place' and ' Event Place (Original)' appearing in the indexed results as for the other five household members.
But in the search results they all show up as born in Colombia.
And many, but not all, others residing in Mitchelstown, County Cork in that census also show in the search results as being born in Colombia (I just picked a random year of birth and searched for anybody born in that year residing in Mitchelstown, County Cork in the 1901 census.
0 -
The on-the-fly autostandardizer that the search results list uses is taking the index's Birthplace field of "Co Cork" and turning it into Columbia. The index detail page, on the other hand, only shows the bot's actions on the main Event Place field, so there's no sign of Columbia there.
This situation demonstrates that FamilySearch doesn't believe us when we try to tell them that the bot needs to be chucked, its actions reverted, and the whole process completely redesigned, with robust data validation steps. The current process apparently doesn't have any data validation whatsoever, leading to the current state of affairs, in which we cannot trust anything that the indexed records database says about "where". It's basically only ever correct by complete accident.
2 -
After a bit more checking it appears, as Julia says, that it's ONLY people whose birthplace has been (manually?) transcribed/indexed as 'Co Cork' (but NOT 'County Cork' or 'Cork') who appear in search results as born in Colombia.
But it's NOT EVERY person - e.g. Julia here seems to be unaffected.
0 -
If you search all Ireland records for people born in Colombia there are 534,112 results.
There's no way that fixing those one by one will work.
And just from a cursory look at a few results it appears that the word 'Co' anywhere in the birthplace causes it.
0 -
And don't forget 'Caramana, Kings, Ireland'
0
