Why is it that the software developers who design FamilySearch think they are all knowing?
There are restrictions to being able to edit source dates and places within FamilySearch that have not been anticipated and there are also items recorded in indexed entries that are wrong but uncorrectable. When software designers enforce their limited ideas to restricted conditions (such as standard dates and places), some records become uncorrectable until such limitations are removed. For example, I find a relative who is recorded in an index entry of a christening record, but the child was actually never christened (see Josefa Petrine Jensen GD4V-SQ8). When one tries to point out the error, the software requires a standard date and a standard place when it is currently impossible to indicate there was neither a date nor a place! Also, I found a immigration index entry which indicates a woman is married when she is actually listed as a widow (wd) Maria Pacula 1913 New York, New York. There is currently no way to correct this. Also it is generally not wise to require exact standard place names when the user has little or no idea where the place actually lies, such as when there are more than one place names for a place in Galicia, where one place is now in Poland and the other is in Ukraine (and the user doesn't have enough experience how to determine which or where the correct place is). I have stated in years past that it is dangerous or at least unwise to FORCE the process of correcting place names because such is often as likely to produce errors as it is to correct them.
Best Answers
-
Allan, sounds like you are having a terrible time here. May I suggest that you can't drain a bathtub faster by agitating it.
It might help to understand the how and why of indexing. As to the Why, I think that the purpose of indexing is mainly to help people find documents. Then when you the researcher come along and use this to find the document, you should study it more closely than the indexers did.
As to the how, when I was doing it awhile back, two independent indexers would view the document and record certain limited info from it, like names and dates. If their results are the same, it's accepted without further ado. If the two don't agree, then a 3rd person squints at it and makes a decision. That will get 99% of the job done, and 99% of the errors caught.
In the case of your Josefa's christening, I think the indexers did indeed miss it. For those who wonder, on the image, the first column is the line number (=2, in the lower half which is the girls) Next, the date of birth =26/5-09; next, date of 'baptism'. There are two clues here for Josefa: first, the date of baptism is empty. Second, there's a cross out in the left margin. I think that means the baby died before she could be christened. It's confirmed by the 2nd source there, with death and burial dates a month later.
Correcting the index might be desired, but if they won't let you, all is not lost. When you attach the source there's two places to make annotations: "Describe the record" and "Why are you attaching this source". There is where you can add 'the index says A but the actual document really sez B.' You can also come back later and edit those notes. Further, there's a tab called Collaborate where you can put more explanations and even try to start a discussion, altho this is almost always an exercise in futility.
Now, when you attach the document to a dossier, the Attach Source just blithely scoots the indexed data in there, but then after it's attached, you can go into the "Vitals" under the "Details" tab and edit the info and put rationale as to why.
2 -
In addition to Woody's excellent points, I'd like to comment that the correctability of any particular index or field in an index has nothing to do with software designers or programmers. They can only influence the "how" (the layout and input mechanisms), not the "what".
I think the root of such strong negative reactions to indexing errors -- the anger about them -- is a misunderstanding of what an index actually is. This misunderstanding is unfortunately reinforced by FamilySearch's data setup, which puts the index ahead of everything else, as if it were The Word Of God Embodied -- but it emphatically is not. Indexes are not the data. They're merely finding aids for the data. So the marital status was indexed wrong, and it can't be fixed -- but you found the record anyway. In other words, the index served its purpose.
1
Answers
-
My apologies for my exaggerated wording of these matters. Those who are in charge of the FamilySearch software programming are clearly assigned and authorized to do so. It is just frustrating to run into problems contributing corrections wherein the contributions cannot be received by the software designed to accept corrections. I would certainly be glad if there were accommodations in the software to accept the unexpected exceptions to normally expectable corrections, rather than the impossibility to correctly pose exceptions to the expected answers. May I humbly suggest including software options allowing for unexpected comments to attempted corrections? This is really more towards what I want, hopefully avoiding frustrations to users caused by overlooked options, limited thinking, and closed-minded rules. Thank you.
0 -
Allan
I am just another 'lowly' User/Patron ...
Further to what 'Woody' and 'Julie' have already proffered ...
FYI
Here is a "Knowledge Article", in 'FamilySearch':
Why can't I fix indexing or transcription errors?
Where is states, among other things:
Quote
------------------
Here are a few common reasons why you cannot correct a transcription error that you find.
- As of March 2020, the capability to edit incorrect dates and places can depend on language, location, and the collection where the record is stored. If you are unable to edit a date or place, please be patient. The capability is forthcoming.
- Some of the indexed records on FamilySearch.org lack a corresponding image that can be used to validate the correction.
- FamilySearch does not own the index, and our agreement with the index owner does not allow for user-submitted corrections.
------------------
Just providing this, in support, of what has already been proffered.
Brett
0 -
Thinking further about such problems, I had an idea that could help from the start, which I suggest to FamilySearch software developers. That is, an "exception or exceptions" field should be made available from the start of the indexing, which should allow the indexer to flag problems from the start. This could make it possible to include unexpected exceptions to persons who are assigned to fill in data that does not conform to expected required fields, and could obviate problems of events that never happened, such as an unaccomplished christening due to death of child or a missing date of burial in a death & burial record. Once a date and place have been entered, there is presently no option furnished for deleting it (except maybe explaining it after it is attached to a person). The initial indexers often have enough time to note such problems and could possibly solve them before they become incorrectable. I suggest also that such "exception" fields should also be flexible enough to at least allow explanations for the exception.
0
