Another example of errors being made when records come across from Find My Past
LegacyUser
✭✭✭✭
Paul said: I have spent several hours trying to figure out how a distant relative could have died in Richmond, Surrey when he and his family had no known connection to the south of England. The answer proves to be that he died in Richmond, North Yorkshire.
FamilySearch shows the index for the relevant collection is provided "courtesy of Findmypast.com", yet the indexed record on that website clearly shows a Richmond, Yorkshire death. (Ref. https://www.findmypast.co.uk/search/r...)
Obviously, this error (see https://www.familysearch.org/ark:/619...) is unlikely just apply to the example in question. Due to errors like this, many users are probably being baffled as to how their relative came to have died at the other end of the country - or thought they had not found the correct record, when they had!
I have encountered many other (usually census related) errors in FamilySearch, which appear perfectly fine in FMP. Again, this shows the need for more care to be taken when these records come across from FMP to FamilySearch, to ensure the correct detail (often involving a place name) is not lost.
FamilySearch shows the index for the relevant collection is provided "courtesy of Findmypast.com", yet the indexed record on that website clearly shows a Richmond, Yorkshire death. (Ref. https://www.findmypast.co.uk/search/r...)
Obviously, this error (see https://www.familysearch.org/ark:/619...) is unlikely just apply to the example in question. Due to errors like this, many users are probably being baffled as to how their relative came to have died at the other end of the country - or thought they had not found the correct record, when they had!
I have encountered many other (usually census related) errors in FamilySearch, which appear perfectly fine in FMP. Again, this shows the need for more care to be taken when these records come across from FMP to FamilySearch, to ensure the correct detail (often involving a place name) is not lost.
Tagged:
0
Comments
-
Adrian Bruce said: I have difficulty in seeing how that ended up like that. Or do I?
We'll assume that the translation to the Event Place is automatic. FMP has
District Richmond (Yorkshire)
County Yorkshire
If I look in the Standard Places, it's virtually impossible to see how any combination of "Richmond" and "Yorkshire" ends up as Richmond, Surrey. "Virtually impossible" means that if I just try "Richmond", the first in the list is Richmond, Virginia. And we're not that bad yet...
Re "Or do I?"
The only way that I can see is that the list of Registration Districts in England & Wales includes:
Richmond (Surrey)
Richmond (Yorkshire)
Richmond upon Thames
(Thanks to https://www.ukbmd.org.uk/reg/district...)
If the processing on this file from FMP looks for a District just equal to "Richmond" then "Richmond (Surrey)" is first on the list. But since it starts out with "Richmond (Yorkshire)" why would it just look for Richmond?
The only possibility that I can see as to why it would look for just "Richmond" is that this event takes place in 1988 and the FS Standard Places has this entry:
Richmond, Yorkshire, England, United Kingdom
Civil Registration District 1837-1974
That end date is wrong. Richmond didn't end in 1974, but its registration county got amended from Yorkshire North Riding (which applied 1837-1974) to North Yorkshire (1974-98).
If the FS processing looked at this record for "Richmond (Yorkshire)" and checked the date, then it wouldn't find an entry and would default to searching wider. Maybe!!!
The above analysis is just a theory to explain why we have ended up in Surrey. It requires me to mentally reverse engineer the FS load processing and I could be way off beam. It is, however, the second oddity I've seen that makes me think that dates are part of the algorithm for assigning places. Not sure whether my conclusion is true but...
As Paul says, this isn't going to be a one-off.0 -
Jeff Wiseman said: Adrian,
We have also recently seen evidence of how the contents of some index files (E.g., Find A Grave Index) are tweaked by FS prior to installing in the FS website. The actual index data on other sites is sometimes different. Also FS has inserted unsourced information into those indexes as well (e.g., the burial dates in Find A Grave--a headstone never shows the burial date of a person).
Index files on FS actually DO differ from the originals in many cases.0 -
Tom Huber said: That is very true, Jeff.
I don't like FamilySearch's habit of manipulating the data that comes from another site.
Adding information in the index for a record (that was not included in the originating site's information) is not good because it means that FamilySearch is speculating on the added information.0 -
Adrian Bruce said: Either that or Find A Grave is sending an interface file with stuff that isn't immediately visible on the site. I've no idea if it's possible to get other data into those sites other than via the obvious screen but wouldn't write anything out.0
This discussion has been closed.