What (if anything) can be done about widespread metadata errors in indexes of multi-part films?
On the indexes of Hungarian civil registrations in Szabolcs county and environs, the event location was assigned by a post-processing step. (The indexers had and have zero input on the location field.)
The problem is, this process Did It Wrong a fairly significant portion of the time, because on multi-part films, it assigned the location of the first part to every entry on every image on the whole film. This means that often, the location is in entirely the wrong county, many miles away from the correct place.
For example, Film # 004531463 has three parts. Part 1 (images 1 to 99) is death registrations from Rudabánya in Borsod county, so that's what's under "Birthplace" for all of part 2 (images 100 to 407) and part 3 (images 408 to 786), which are actually birth registrations from Gönc in Abaúj-Torna county (https://www.familysearch.org/ark:/61903/3:1:9Q97-Y337-PL6?i=101&cc=1452460). Gönc is 30 miles east of Rudabánya as the crow flies. (The records ended up on the same film because the places are now both in the combined-remnant county of Borsod-Abaúj-Zemplén.)
I have two questions:
1. What can be done about these widespread errors? The civil registration indexes are (inexplicably) not correctable, so going at it piecemeal is (perhaps luckily) not an option, but it is disheartening to know that large parts of this index have been rendered essentially useless by this post-processing error.
2. Has this post-processing step been corrected, or is the first part's location still being assigned to the whole film in the ongoing indexing of Budapest civil registrations?
Answers
-
(Can someone please explain to me why my question is now listed twice under Q and A (or "Help Center Categories") - Search, once with my name, and once with a "moved" label and "Closed Started by MDR MT | 1:09PM"? Did the moderator move my question to the same place where I had posted it?)
0 -
I cannot speak to the move issue, but I am told the automated indexing errors I have been reporting here are being dealt with.
0 -
Film 2204574 (DGS 4838099) is another multi-part film with the first part's place erroneously applied to all index entries for the entire film. 749 images, two-thirds of them with the wrong place attached in the index.
I really, really hope they've fixed the post-processing and aren't doing this any more, but I'm afraid to check.
0 -
The discussion is not closed. You probably see closed on the entry that shows it was moved. When we move a post, it shows as closed and moved in the spot where it was initially posted. The question is being correctly dealt with.
1 -
Linda, my point was that both the post and the "moved" breadcrumb are in the same place. The "spot where it was initially posted" is exactly the same as its current location. My question was moved in place, as near as I can tell, and I don't understand why.
And I would appreciate some sort of reply about my actual question(s). Has the process been fixed, or are newly-indexed images still getting their locations from the first part of the film? Can existing errors be fixed? Have any of them been fixed?
2 -
Can existing errors be fixed? Have any of them been fixed?
This is my concern as well. Those errors affect thousands to hundreds of thousands, perhaps even millions of records, which are being attached to person pages often without checking the images.
0 -
Hi @Julia Szent-Györgyi and @dontiknowyou. You are correct about seeing many collections that contain a title on the FamilySearch Catalog page that identifies only one of the items that might be part of a microfilm.
When microfilming was done, if a collection did not use an entire film, other records were also included on the film. That is why many films show "Part 1", "Part 2", etc. This was done to keep filming costs down since FamilySearch is a free website with limited resources that have been used over the years to further family history efforts world-wide.
We are certain that you are aware that the FamilySearch Catalog is currently "read only". This information is in a knowledge article in our Help Center which explains why:
FamilySearch engineers are transitioning the Catalog to new hardware and software. During the transition, the catalog is locked. We are not able to make corrections at this time. When the transition is complete, we will update this help article with instruction to report errors. Thank you for your patience.
Since your initial post was about changes that would need to be reflected in the FamilySearch Catalog, nothing can be done at the present time to address this concern. We are hopeful that when the transition is complete and we can work with the Catalog again that many of the problems that have been identified with using the catalog [such as this one] can or perhaps will be resolved.
The best place to share your feedback and suggestions about improvements you would like to see is by clicking Ideas instead of Q&A. Post your suggestions in this location and other users may find and vote on your suggestions. These suggestions are reviewed and some of them actually become enhancements here at FamilySearch.
Your concerns are valid and much appreciated. Thank you for your desire to make finding and using records easier for everyone.
0 -
Appreciate the update.
On Family Tree, it possible to make those problem collections unavailable for the time being, so that many erroneous attachments are not created?
0 -
@CDBurk, no, this is NOT a catalog error. It has absolutely nothing to do with the catalog, in fact.
Once again, in case the different wording gets through this time:
On most indexing projects, the location of the event is not part of the indexing -- there is no location field, and the indexers have no input on how the location is identified. Instead, an automated process attaches a location to each index entry associated with a particular film. At least in the past, the SAME location was assigned to EVERY SINGLE ENTRY on the whole entire film.
For single-part films, this works fine. On multi-part films, the process has the effect of rendering most of the index utterly useless. The indexers who worked on batches from the later parts of the film may as well have thrown their work straight into the trashcan.
My questions are: (1) can these currently-useless indexes be corrected, and (2) has the process been fixed, or are films still treated as single, homogenous units by the location-assigning algorithm?
0
