Data conflict on a two-digit year?
I encountered a data conflict message on 94LY-ZGY that stated that the 1907 census gave a birth date of 54 which conflicted with the stated birthdate of 1854. (Sorry I don't have a screen shot - I fixed it before submitting this feedback.) It seems reasonable to expect the quality checker to interpret two-digit years as the most recent occurrence in the current or past century before the record date.
Best Answers
-
@RasmussenDavidE1 - thanks for the link.
I can't explain the Data Quality conflict message.
But, as background… The idea that the items behind the drop down arrow represent a history of manual edits is prevalent, not least because that's what it says it is! However, it is evident that this simply isn't true - the values of those edits, if made manually, would be weird. It appears to many of us, myself included, that the values behind the drop down arrow represent different choices that the data standardisation algorithm has put forward at presumably the same time - 1st choice, 2nd choice, etc.
For whatever reason, the 1954 is currently first choice - no idea why. That is basically an error but you've dealt with it.
0 -
I only meant to bring this to the attention, somehow, of the software team as it's a bug and they will want to deal with it. You do not mention if you are part of the team, but I hope this feedback is useful. As you say, I have dealt with this instance of it.
0
Answers
-
Where exactly was the "54"?
Difficult to know without seeing the original, but I would have thought that a birth date of "54" shouldn't be on the index record or whatever in the first place - it should surely have been interpreted to "1854" long before the Data Quality routine came along? If it's been left as "54" then that suggests an issue with whatever software creates that index and chooses between (say) 1954, 1854, 1754, 54… etc.
0 -
The record is here: https://www.familysearch.org/ark:/61903/1:1:QLXC-7MWN?lang=en
The Birth Date was originally indexed as 20 Jan 54. It has been edited multiple times. Here is the history:
Birth Date
- januar 1954
- januar 1854
- januar 0054
20 Jan 54
So despite its having been corrected, the Quality Score must have been looking at the original, or an earlier edit.
1 -
@RasmussenDavidE1 - I'm just another member of the community. If I can help by explaining how things might work so far as we know from our experience, then I'll do so (e.g. what the drop-down list appears to actually be in a case such as this). You raised the issue in the right place, so far as I can see, because Data Quality was where the issue appeared. Exactly where the techies want to fix the code is absolutely up to them.
0 -
@RasmussenDavidE1 the purpose of the Data Quality tool is to call out record inconsistencies so the the patron can evaluate and either correct or dismiss the issue. In this case the tool is doing what it is supposed to do :)
0 -
@Rhonda Budvarson - while the Data Quality tool is working as intended (as I suspected), we still have the underlying issue that a legitimate birth date of 20/1 54 (for 20 January 1854) on a "Denmark, Census, 1906" page, has come through on the source record https://www.familysearch.org/ark:/61903/1:1:QLXC-7MWN as (currently) 20 January 1954 and may also have been 20 January 54 (i.e. 54 AD) at some point in the proceedings. (I'm only saying "may" because I didn't see it)
Neither 1954 nor 54 AD make much sense for the birth of a human being in the 1906 census who is not in possession of a time machine 😉
This sounds like a regrettably typical problem with the date standardisation routine - do you know how we can alert someone to add this to their (probably large) pile of similar issues? Thanks
0 -
Thank you for the feedback. We will look at this :)
1 -
Update: this issue has been sent to an indexing group for review/correction. Thank you for your feedback, and patience :)
1
