At what point are these impossible people created ?
Example: https://www.familysearch.org/ark:/61903/1:1:N4JH-T2F?lang=en
In the above case it is obvious that a child who died at 1 year of age could not have been married, so how does this entry for a spouse get inserted into the record.
There are many other similar records which, when presented, show one or more 'manufactured' entries when no such thing exists in the original source.
It is not sensible to corrupt information in this manner.
What's going on ?
How can it be prevented ?
Answers
-
The index change history for the whole of this document looks odd, spurious Unknown people pop up multiple times: https://www.familysearch.org/ark:/61903/3:1:S3HY-DHF3-NMY?view=history&lang=en
The change history as above shows all the changes as happening on the same day, but the underlying data for Edith White shows a date of 31 Aug 2024 for her Unknown spouse persona (and, I bet, for the other spurious Unknown people on this document, though I admit I haven't checked) - maybe some sort of automated update that went wrong?
@SerraNola one for you I fear.
1 -
To be quite honest, the simple answer here is, "people fail to pay attention." Some users are in such a hurry to make a tree that they just roll with the first name that looks like "could" be their family and they start merging incorrect profiles and attaching wrong documents without first looking to see what is already there or what location the person lived in to begin with. At least dig in and read or look at documentation that exists before assuming. I have had numerous occasions where I've had to fix my own branches due to careless mistakes like this and attaching spouses to deceased children or people who were living 150 years prior. I get it, some folks are new at this, but come on, pay attention! I feel like I spend more time playing security guard over some branches of my tree versus doing any constructive research with them.
2 -
@StephenDespot for the avoidance of doubt this problem is with Record indexing, not Family Tree profiles.
3 -
I haven't checked many but all the real people also seem to have started with 13 June 2024 (I didn't see an August date???) . So I'd suggest that's when this bit of the data was indexed, including the empty personas.
This is all very reminiscent of those baptisms where the original shows the child and only their father - no mother is mentioned - but the index is set up with three personas - child, father and a persona for the mother which contains nothing other than a name containing only the character normally referred to as a "back slash". This is a pain in the proverbial as we seem to often end up with a profile in FSFT containing only that single character name, which needs to be merged away into the actual mother. Why on earth those indexers couldn't just omit the mother's entry like other indexers did elsewhere, I don't know.
Maybe "indexers" (or rather, those who set the indexing up?) are like nature and abhor a vacuum?
Maybe there is an idea somewhere that having a profile with nothing other than a single character (nonsense) name is better than no profile at all? It absolutely isn't because it has to be merged away when you have the real profile. (As I think you would agree @MandyShaw1 given ongoing correspondence elsewhere?)
So I think it's the indexing set up that's wrong…
0 -
On further investigation It looks from the underlying json as if Edith's persona was created on 13 June 2024 along with all her data except PR_SEX_CODE (31 August), and her corresponding Unknown persona was also created on 13 June 2024, with SP_SEX_CODE similarly appearing on 31 August. So as you say @Adrian Bruce1 the main error was clearly made on 13 June (presumably indexing time) as indicated on the index data change history I linked to above. The change history could do with a lot more detail in my opinion (more like a profile change log - I guess I can see why it doesn't identify the contributing user as happens everywhere else in FS, but it could differentiate indexing vs reviewing vs index editing, or whatever).
0 -
Thanks for the input, but I'm still struggling to understand the working of all the chains and spockets that led to the 'impossible' person spontaneously appearing when there is nothing in the record to tag.
If someone is indexing an image of a page then I'm fairly sure that they wouldn't be allowed to get away with selecting an ink blot and calling it George. But for the sake of argument lets say they could, and if they did, and left it at that, then it seems that some impersonal mechanism will follow after them and give George a spouse called UNKNOWN.
That's what I can't fathom. If this is the result of some automatic function that's intended to be helpful by auto-creating a spouse, then whoever produced it should have included some 'coding 101' validity tests to ensure that it only does it when it's appropriate. A person who died at one year old can't have a spouse. A human indexer would have known that, so I don't think it's occurred during indexing.
Regardless of that mechanical analysis, I still hold the view that if the source record doesn't contain an entry for a spouse, then the spouse should not be created. Otherwise where would it end? auto-created parents, children, in-laws ?
1 -
What you're talking about might be the extension of the DQS (checks and balances) concept to indexing, which I would have thought essential now that AI or 'computer aided indexing' is the main focus.
It's not clear to me whether this particular document was indexed by AI or by a careless human, probably the latter given the June 2024 date. Either way the reviewer was clearly equally careless.
I know there's an argument that indexing is just for search/retrieval and therefore this sort of thing doesn't matter, but I disagree, given the number of automated or semi-automated ways in which data travels from indexes into FT.
0 -
@MandyShaw1 My understanding of Checks and Balances is that you tot up all the entries, and then you compare with the total number that you've got.
1000 people identified in the records 1000 personas created - OK
1000 people identified in the records 1001 personas created - NOK
0 -
Sorry to be unclear, I meant it more generally. The DQS flags profiles where people get married when they are one year old, etc.; record indexes could surely be checked similarly, and we could then even have a Get Involved opportunity to clean them up.
1 -
@MandyShaw1 Ok Got it. Thanks.
0 -
@Re Searching said
"… If this is the result of some automatic function that's intended to be helpful by auto-creating a spouse, then whoever produced it should have included some 'coding 101' validity tests to ensure that it only does it when it's appropriate. …"
My personal belief is that it's not a coding situation. It's just a dumb template for the burial record that includes a slot for the spouse that cannot be skipped. So no validity tests, etc.
0 -
Is there any way we can look at the original Project Instructions for indexing this collection?
1 -
@MandyShaw1 - or at least, the instructions applicable at the time of indexing… Since Cheshire is one of my counties, I know that the original indexing was years ago as FS first indexed the images under "contract" to FindMyPast and / or Chester Record Office.
1 -
It could be an indexer marked backslash when the original record actually had ditto marks or perhaps only an ink blot that appeared to be a backslash — my experience in reviewing/indexing suggests lack of ability in reading/understanding cursive or an innate desire to put something in every box or even a don't care attitude — unfortunate, but possible as "we" are all human or at least subject to error 😂
0 -
Yes, exactly.
0 -
Thanks to all for the views.
I guess I was hoping that it was some form of software issue so that it could be corrected with a relatively easy tweak. From what has been said, it appears that the task of removing all these non-existent impossible people will need more than a tweak.
The annoying side-effect of these things is that sources in a person profile now show "UNFINISHED ATTACHMENTS" which keeps needling me that more work is required on the profile, when in reality it's complete.
I wonder whether the same function that automatically marks people as deceased when they're over 110 years old can also remove these UNKNOWN spouses of people who were too young have married. I suspect it's more awkard, because the 'over 110' function works on profiles, and this topic would need to work on the indexed sources.
May be it'll just get dropped in the "Not worth the Effort" bin.
0 -
At the very least they should emphasize to the people doing the indexing not to create index points for non-people going forward. In addition to a lot of "/" index points in old English birth and christening records for mothers that aren't named, I've seen a lot of various death records that index the year of death as the spouse of somebody who died unmarried, and a lot of places of employment indexed in Draft cards.
Hopefully at some point a lot of these records will be reindexed with more complete information. Those old christening records really need residence and father's occupation if it's included.
0
