report error
how do you report an error, a very clear error
Thousand Oaks is not in Alameda county
No Image Available
Document Information
Collection Information
United States Public Records, 1970-2009
Cite This Record
"United States Public Records, 1970-2009", database, FamilySearch(https://familysearch.org/ark:/61903/1:1:KTLW-N8H : 23 December 2019), Charlene R Keady, 2003-2007.
Copy Citation
NameCr KeadyAliasCharlene R KeadyPrevious ResidenceThousand Oaks, California 91360Previous Residence Postal Code91360Second Previous Residence PlaceThousand Oaks, California 91360Third Previous Residence PlaceCanoga Park, California 91304Residence Datefrom 18 Feb 2003 to 29 Oct 2007Residence PlaceThousand Oaks, Alameda, California, United StatesResidence Place (Original)Thousand Oaks, California, United StatesBirth Date1 Nov 1939Household Identifier155971338
Other People on This Record
OPEN ALL
Answers
-
I think the records you refer to are Public Records and there is really no place to 'correct' or Edit them per se. These are supplied by a third party -"Citing this Collection
"United States Public Records, 1970-2009." Database. FamilySearch. http://FamilySearch.org : 22 October 2021. A third party aggregator of publicly available information".
I am not sure whether FamilySearch place names is at fault for changing the record place incorrectly or if it was received that way from a third party. Either way they are not editable... currently...
Perhaps the following wiki page will help:
1 -
I consider the ubiquitous errors in the "U.S. Public Records" collection to be a security feature. As a source of actual genealogical information, the collection is basically completely useless, and should be ignored. (I do wonder how they got "Alameda" out of "Ventura", though.)
0 -
@donna gatts Thank you for providing complete information that made it easy for us to find the US Public Records entry that inaccurately identified Thousand Oaks as being in Alamea County. This looks like one of the auto-standardization errors we have been seeing in our historical records. We will report it to engineering. They are getting these worked through and corrected, but it takes a while. We have reported a lot of them. Meanwhile, you can use the record as a source and note the error in county.
0 -
One problem I see occasionally in the US Public Records collection is that place names are incorrect. For example:
(Field) Residence Place (original): Westbury, New York, United States
(Field) Residence Place: Westbury, Cayuga, New York, United States
(Field) Previous Residence: Westbury, New York 11590
The Zip Code 11590, is for the town of Westbury, NASSAU COUNTY, New York
Cayuga county and Nassau county are very far from each other, and it is highly unlikely that this person moved from one town named Westbury to another town named Westbury in a different part of the state.
So the problem is the Residence place (original) field does not include the zip code. Either it is not collected, or not part of the data set that familysearch makes use of to determine place names.
But it should be.
The workaround here is to always look at ALL the information on the public records. Once you attach the public record to the person record, you can always correct the place name on the person record, even if the field on the public record is not able to be edited. And if it is wrong, you should change it on the person record, for more accurate future hints.
Here is the citation for the familysearch programmers to look at:
"United States Public Records, 1970-2009", database, FamilySearch (https://familysearch.org/ark:/61903/1:1:K539-PV3 : 24 November 2019), Robert Herlithy, 2007.
Good luck with your research everybody!
0 -
@PattiG36021, see the explanation of auto-standardization errors in this thread: https://community.familysearch.org/en/discussion/116253/existing-historical-records-issues#latest
The clue that the wrong county comes from this bot is that parenthetical "original": that's what was actually in the index. The "Event Place" field not marked as original is what the bot came up with.
I keep saying that this problem is too large to fix piecemeal like this. FamilySearch needs to revert ALL of the changes made by the auto-standardization routine, and start over with a process that not only takes the collection's information into account, but also is verified by a human being.
2 -
Julia, I agree it is too much to fix piecemeal.
For the US public records database, FamilySearch should ask the data aggregator to provide the current zip code field, and then use that field to determine an accurate place name. This seems simple enough to fix with an automated batch process. I am not a programmer, but surely there must be an existing database of the place names associated with every zip code in a standardized form. (Aside from the one at the post office.)
For other less contemporary records, you really do need human interpretation. Cursive handwriting and spelling errors present a significant challenge, by themselves. I really like the feature on some records that allows you to make changes to the field. It keeps both the original "interpretation", and any changes, and searches on both. This is a great improvement when it is an option. I only wish more records and fields could be edited.
0 -
I attach these records but I do not add any of the addresses to the person's profile.
Attaching the records effectively takes them out of the FT Hints system, so they won't be attached in error by other contributors.
1
