Allow us to change locations on indexes also

LegacyUser

David Wynn said: I know we're testing out and slowly implementing the ability to change the name of a person as it was indexed in a document. I'd like to request that we also allow changes to pretty much any inaccurate data on a document. Just as I've indicated with the names, I don't think this should be able to be changed by a single person on a whim. But each change, whether names or any other data, should be first sent to a validation group (similar to the indexers themselves) that will verify whether the proposed change is supported by the document itself.

I've seen too many instances where a location in the index does not match what the record clearly states. Here's one example. The index:


And the original document:


Take a look at the Event Place (Original). I'm baffled as to why the indexer would list the City, and County, but neglect to include the State. Granted, there is no handwritten entry for the State, because the State is listed, in print, at the top of the document. So, they should have known that the state was Iowa. The indexer mis-read the county name. But had they entered their misread into a place name field, they (likely) would have seen the following:


The indexer chose the top option (Washington County) for the Event Place. Why choose that option when the third option (Pottawattamie County) is a far better match to what was printed on the document?

This just illustrates that, in the rush to index, indexers make mistakes. And even validators can overlook details. We need a system that allows us to correct the indexes to match the original document. In order to do this safely, every change needs to be sent to a review panel of verified users that are committed to seeing that any change to the indexes (names, places, or any other details) truly can be supported by the original document itself.

LegacyUser

Juli said: There is a 99.999% chance that the indexer did not have access to the places database in any form, and not typing in the state may have been part of the instructions. (Most indexing projects have some variation on the "type what you see" rule.) You're automatically blaming the indexer(s) for a standardization error that was likely made by an automated procedure in post-processing.

Naturally I can't find it, but someone posted on GetSat about a blog post earlier this month which promised editing of places and dates in indexed records. The blog implied that this feature was coming Real Soon Now.

LegacyUser

Lundgren said: Juli is correct, it's coming.

LegacyUser

David Wynn said: Thank you. Great to hear.

LegacyUser

Adrian Bruce said: I have a feeling that there is something we're missing about the difference between "Event Place (Original)" and "Event Place". Though Juli alludes to it.

This is a guess on my part but I'm going to suggest that "Event Place (Original)" is completed by the indexer and "Event Place" is completed not by the indexer but by the computer using (a) the meta-data for the collection being indexed and (b) the placename standards database - with no human intervention unless the computer algorithm fails.

So, think about "Event Place (Original)" - this only needs to cover the handwritten text because the "Iowa, United States" is fixed for every single entry in this collection, so can be added in the post-index-processing.

Hence, "Event Place (Original)" ends up with "Valley, Pottammatamie".

Now it goes into the post-index-processing to create "Event Place" and, as Juli suggests, I believe that this is totally automatic. "Iowa, United States" is put into the mix from the collection meta data and the automatic processing looks for the first(?????) item in the standard place-names that matches the text string "Valley, Pottammatamie, Iowa, United States" - as we see from your investigation (thanks!) that happens to be the "Valley, Washington" version - possibly because "Valley," sorts before "Valley Township,"

Please note that I'm absolutely not defending what's happened - I'm trying to understand it. Your suggestion, David, of updating place-names in indexes is absolutely what's needed.

So, can anyone from FS confirm our suspicion that the creation of "Event Place" from "Event Place (Original)" is normally totally automatic? (Presumably there is a back-up manual if the automatic process fails? Or is there?)

Apologies for the bolding of the request!

LegacyUser

David Wynn said: This makes sense. I believe your hunches are likely spot-on. I've found that the place lookups don't allow any room for misspellings. Thus, if the original document or the original index doesn't get the spelling quite right, I've often found that Google can do a far better match of finding the intended location than the place name suggestions.

If there's any FS employees reading this, please see what you can do to improve the place name lookups, and allow some amount of grace for location misspellings.

LegacyUser

Juli said: The places database includes a name type of "misspelling", but it's semi-deprecated: there's just no way to predict all the ways people misread or misremember stuff. That sort of variance has to be built into the search engine, not the database. FS keeps tweaking the matching algorithms and other mechanics of the places feature, and it works a whole lot better than, say, MyHeritage's "PedigreeMap", but as you say, Google Maps is better at it.

LegacyUser

Ken G Moyer said: I too use Google search to find the correct spelling of place names that are hand written on documents. Like figure out "Tamahamannah"