Home› Welcome to the FamilySearch Community!› Ask a Question› Search

ERROR REPORT - Original Data in source supplanted by false data before display

Re Searching
Re Searching ✭✭✭✭
October 10, 2024 edited March 13 in Search

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 ?

1

Answers

  • Julia Szent-Györgyi
    Julia Szent-Györgyi ✭✭✭✭✭
    October 10, 2024

    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
  • MandyShaw1
    MandyShaw1 ✭✭✭✭✭
    October 10, 2024 edited October 10, 2024

    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
  • Re Searching
    Re Searching ✭✭✭✭
    October 10, 2024

    @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
  • Áine Ní Donnghaile
    Áine Ní Donnghaile ✭✭✭✭✭
    October 10, 2024 edited October 10, 2024

    @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
  • Re Searching
    Re Searching ✭✭✭✭
    October 10, 2024

    @Áine Ní Donnghaile

    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
  • Áine Ní Donnghaile
    Áine Ní Donnghaile ✭✭✭✭✭
    October 10, 2024

    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
  • Re Searching
    Re Searching ✭✭✭✭
    October 10, 2024

    So it seems that there is at least some agreement that data should not be changed.

    1
  • Áine Ní Donnghaile
    Áine Ní Donnghaile ✭✭✭✭✭
    October 21, 2024 edited October 21, 2024

    FMP confirmed the correction from male to female in THEIR database. That change will not automatically drive a correction on FamilySearch.

    image.png

    2
This discussion has been closed.
Clear
No Groups Found

Categories

  • All Categories
  • 43K Ask a Question
  • 3.4K General Questions
  • 571 FamilySearch Center
  • 6.8K Get Involved/Indexing
  • 645 FamilySearch Account
  • 6.6K Family Tree
  • 5.2K Search
  • 1K Memories
  • 2 Suggest an Idea
  • 478 Other Languages
  • 62 Community News
  • Groups