Auto Indexing Errors ?
In this burial record https://www.familysearch.org/ark:/61903/1:1:QL7C-R5MY the person of interest is given two parents and a spouse with the surname Green.
Two of these are completly wrong.
Her surname at the time of death was Green, which differs from her maiden name in the person profile, but that's to be expected.
Her spouse was Green, that can be verified because it can be established with evidence that she was married.
However, neither of her parents were named Green, so these are wrong.
In my opinion, the only data that would lead to a named entry being created is the data associated with the focal person. All the others should not have been created because there is no evidence to support them (apart from the obvious, that a person must have parents). Creating an entry with a name which is incorrect without any evidence to support that name is just plain wrong.
Can this mechanism be halted ?
Answers
-
Looking at the extract on FindMyPast, the only name listed is that of the principal, Ann Green. The same is true of the image available on FMP.
First name(s)
Ann
Last name
Green
Birth year
1807
Age
71
Death year
1878
Death date
? ? 1878
Burial year
1878
Burial date
24 Jan 1878
Denomination
Anglican
Place
Lichfield, St Michael
County
Staffordshire
Country
England
Archive reference
D27/1/12
Register type
Burial
Page
135
Record set
Staffordshire Burials
Category
Birth, Marriage, Death & Parish Records
Subcategory
Parish Burials
Collections from
England, Great Britain
3 -
@Re Searching It appears that each of the entries in this record were given parents' names without corresponding data to back it up. I'm not sure whether this was an indexing error or something to do with how the information was imported into FamilySearch, but @SerraNola can tell us.
1 -
This is an extension of the creation (erroneous in my view) of missing mothers in the indexing of UK baptisms. In that error, a baptism of John Smith (say) to a named father (but no named mother) results in personas for the child (fine), the father (fine) but also a persona for the mother, who is not mentioned in the baptism (so not fine). I can't remember whether there is any consistent pattern for the naming of the mother, whether she is named as "Smith" or as "/", but since she is not mentioned in the original then she should not appear in the index. This has been raised in the Community at least twice.
The baptism error above has now (and for how long?), it appears, been extended to burials. In the example posted above by @Re Searching, a burial with just one name in the original, has created personas for Ann Green (fine), both of her parents (not fine since neither are mentioned) and a spouse (not fine since he is not mentioned). The creation of a spouse is particularly bad since the original shows zero evidence of any marriage so, whereas we know Ann Green had two parents, we do not know (from that index) whether she was married or not. If she wasn't married then there will be a distinct possibility that a researcher will create a profile in FamilyTree for the non-existent husband - and how does anyone then get rid of it?
Put simply, personas should not be created in index records for people who are not in the source record.
As a hugely vague indication of the numbers, I ran a search of England, Staffordshire, Church Records, 1538-1944 for one name in one parish from 1815 onwards and the first page of 20 results contains six erroneous creations of triples of parents and spouses. Four of those appear (based on the birth year derived from the age at burial) to have been infants but have, nonetheless, been given a spouse in the index record.
(Please note that it is perfectly possible to have husbands, fathers or even both parents appearing on the burial record - though seldom, I suspect, all three).
5 -
I wonder if this is another example of the index abhorring a vacuum - like those "unknowns" that are creeping in on some censuses when a man or woman is listed as widowed.
Example: the 1900 census for the widow of my 2nd great uncle: https://www.familysearch.org/ark:/61903/1:1:M3V3-PNG
4 -
I could understand a human adding a person to their tree as a spouse when they discover a woman shown as widowed. It might act as a placeholder until they can locate the appropriate records to attach. But there's no excuse for a machine ( assuming it is a function rather than an activity ) creating false entries when none are present in the source. I still think it must be a mechansim, I can't believe that a human would do it. In the example I showed, the surnames were all copied from the target person. A human would have known that her parents would [probably] not have the same surnames as each other. I wonder whether some keen programmer has presumed that a burial record will be associated with a family in the same grave all with the same surname and might be trying to help by creating the connections, but there are many example where this is not the case so the assistance is both unhelpful and wrong.
If the origins of the issue can be established and stopped then it will be very helpful.
1 -
My gut feeling is that there is no human indexing involved (it's just too weird for a human to do). Nor do I think AI indexing is involved because it looks like the basic index data comes from FindMyPast, so all that's needed is a simple automatic algorithm to reformat the FMP index into the FS format, including whatever process is involved to assign the standard dates and placenames. All logic driven.
If that is true (if) then the fault may be found in that reformat program, perhaps in the initialisation routine where something is (reasonably) set up for the parents etc, just in case, but never deleted when it isn't actually needed.
Hopefully someone can check the software on their return to work.
5 -
Here's something related - I think - that I've recently noticed in my Irish research. There is an older record set: Ireland, Births and Baptisms, 1620-1881, a Legacy Collection, meaning it is not updated.
The earlier ones, obviously, are from baptism records. From 1864 forward, when Ireland began civil registration of births, the records are primarily from the civil birth registers.A description has been added to the Christening field. I work to keep that description from transferring.
3 -
@Áine.ní.Donnghaile - that's, erm, interesting. While it's a good idea to have a mechanism in place that explains things, sticking it into an existing data item is somewhat perverse because we know that it will get transferred over in so many cases!
2 -
My feeling exactly @Adrian Bruce1
Possibly a good idea poorly implemented?1 -
@Áine.ní.Donnghaile - I would agree…
1 -
I've just made a related post in the Source Linker Feedback group, if anyone wishes to chime in. I'd been meaning to do so for some time, and this thread reminded me that I should.
https://community.familysearch.org/en/discussion/184290/strange-message-in-the-christening-field-in-irish-research1 -
@Re Searching @Adrian Bruce1 Just for the record, I have never been a fan of adding implied relationships to an index and this far surpasses what is reasonable. From a data integrity perspective, it is important to include only information present in the document image to avoid introducing inaccurate data into the tree. I'm sure engineers will agree that correcting this error is a high priority.
As indicated in the FMP transcription, this is a data processing matter within our system. The error stems from our persona indexing logic, which should restrict additions to only those personas listed in the third-party index.
@Áine.ní.Donnghaile I believe that implementing a warning about the Christening locality is not an issue related to Source Linker, as the problem originates within the index itself: https://www.familysearch.org/en/search/record/results?count=20&q.birthLikePlace=Clonavaddy%2C%20Dungannon%2C%20County%20Tyrone%2C%20Ireland&q.filmNumber=7718826&q.givenName=mary%20anne&q.surname=mckusker
As shown in the search results, there are two distinct personas (with different ARK numbers)—one affected by the error and one not. I'm guessing that the discrepancy likely emerged during migration to the current storage platform. This issue will be formally reported. Thank you all for your continued valuable feedback.
4 -
Thank you @SerraNola for listening to our worries and helping to preserve record integrity.
1 -
@SerraNola Thankyou.
1
