INCORRECT INDEXING??
This vital record clearly shows that the record is in Culpeper , VA, and yes the person entering it states my relatives as getting married in Culpeper TN, and NOWHERE does it state this information. They were married in Chesterfield, Culpeper, VA. No wonder people are finding it more and more of mis- information on this site. Just SAD!!
Best Answer
-
This is not an example of an indexing error but, once again, placename standardization/corruption by the algorithm.
@N Tychonievich or @Mike357 please add to the ever-lengthening list of records that the algorithm has muddied. Thank you.
2
Answers
-
Thank you!
1 -
@Cynthia Elkins Vansil, just for your future reference, if you examine the indexed record closely, you can easily tell what was incorrectly indexed and what was the result of the automated post-processing computer standardization algorithm. The human indexer is responsible for the "Event Place (Original)." The automated routine that works quite well if the original index entry is complete and is included the the Places database but can cause terrible errors when it is not complete or not in the Places database is responsible for the "Event Place."
Fortunately the programmers did include both place names in the index.
Indexing errors usually just affect one record. This automated processing will affect every instance of the term in the entire record set. In your example, every instance of Culpepper will have been changed to Culpepper, TN. This unfortunate byproduct of trying to improve the index using automated routines makes what has been taught forever even more important: never trust an index, always check the original record.
2 -
To add to Gordon's comment - part of the issue, in this case, is the original indexed place was misspelled, in addition to being incomplete. In Virginia, the town is Culpeper.
1 -
@Cynthia Elkins Vansil, as you have already received some excellent answers regarding the nature of the computer generated, place standardization problem, let me just add that I will add this instance of the problem to queue for review and resolution. As the queue of these problems is somewhat large, it would be impossible to suggest when this problem will be fixed.
We do appreciate that you have taken the time to report this problem, and, with you, look forward to seeing it resolved.
1 -
I see an example here of why any standardization algorithm has to take into account the locale where the document is from. While I don't see the actual image here, it's common in many jurisdictions for records to omit a state/province when the locality is in that same state/province. The indexer should be entering what's on the document, and not embellish it with an assumed state or province so the standardization algorithm needs to take that into account.
Getting the spelling right would help but, again, the indexer should just transcribe what's there and the original clerk might have made the error (or it's difficult to read). Using some location awareness will simplify the task of correcting misspelled names.
0 -
https://www.familysearch.org/ark:/61903/1:1:6NV3-CT7Z has the correct location. Thanks.
0
