ERROR REPORT - Original Data in source supplanted by false data before display
In the following census record, the wife's relationship to the head is correctly shown as wife, but for some reason her gender has been transcribed as male.
In the displayed record, even though the machinery has correctly picked up the fact that she is a Wife, somehow the relationship presented on her line is shown as Husband. It appears that the relationship has been manufactured.
This should not be permissible. If the data in the original record is present, then that that is what should be displayed, otherwise how can the researcher trust the data in the record ?
Whether the machinery should be allowed to create artificial data has been discussed elsewhere, [occupation dates in censuses] but in this case it appears that the edict has been ignored and false data has been constructed.
https://www.familysearch.org/ark:/61903/1:1:SGT9-1Y2
Who makes the judgement about what data can be altered and what can't ?
Answers
-
I believe the reason for this is that what the index actually captures from an entry of "wife" or "husband" is just "spouse". The results display then uses the value of the "sex" field to determine whether that "spouse" should be shown as "wife" or "husband". Ditto for father/mother/parent and son/daughter/child.
Why they do it this way is a different question, but this is what I've observed in the index correction system.
0 -
It would be fantastic, and surely not impossible, to have full transparency on how the metadata is mapped and/or manually or automatically enhanced, starting from the record owner, passing through any third parties involved, such as FMP, taking into account FS' own indexing activities, and ending up with what FS provides to users as index metadata. That visibility would give us a much better idea of the level of trust to be placed in a particular collection's metadata (which is clearly separate to the level of trust we may have in the documents it indexes).
0 -
@Julia Szent-Györgyi It's a nice hypothesis, and would be reasonable except for the fact that the original record shows the relationship as wife, and the personas data also shows that. It seems that data in the original record is not being used.
In my opinion, the source data should always be used, but cross-checks between data items can be beneficial, and if they reveal a conflict, then it would be sensible to add a postem.
0 -
@Re Searching Your example comes from FindMyPast and TNA. The index was likely imported.
The index on FMP (what FMP calls the transcript) shows both Joseph Garside and wife Sarah as male. https://www.findmypast.com/transcript?id=GBC%2F1851%2F0002383999
First name(s)
Last name
Relationship
Marital status
Sex
Age
Birth year
Occupation
Birth place
Joseph
Garside
Head
Married
Male
55
1796
Baptist minister
Huddersfield, Yorkshire, England
Sarah
Garside
Wife
Married
Male
69
1782
-
Huddersfield, Yorkshire, England
The fault in this case would appear to be in the original indexing.
I've just submitted a correction through FMP's error reporting option.
1 -
I asked a friend to take a look at the actual record and what you say appears to be correct. The census document shows Sarah's relationship to the head as Wife and her age is written in the column for females, therefore the error that sets her gender to Male must have occurred at some time between the beginning of the original indexing to the import into the FS record. It doesn't really matter where, when or how the error in her gender occurred.
Although it seems that FMP have the gender wrong, they do show that the relationship is Wife.
The mechanism that changed her relationship to Husband is pure fabrication that cannot be substantiated by any facts. It is this invention of mock data that is of the greatest concern. It provides a clear example of manipulation of source data that happens automatically before it is presented to the user.
"So, on the whole, I'd have to say, not good."
0 -
I looked at the actual record before I posted, @Re Searching.
Since FMP's transcript (their word) has the gender as male, any algorithm used to import the index probably could not and should not change that.
1 -
So it seems that there is at least some agreement that data should not be changed.
1 -