Conflict-free data: "The christening happened before the birth
See ID: KVYZ-749 (https://www.familysearch.org/en/tree/person/details/KVYZ-749).
This issue has been raised before, I think, but I couldn't find it.
The birth is only the year, 1823, (and should perhaps better be 'before <date of baptism>' rather than only giving the year.
However, I don't find it invalid to give a year when the source is a census in England and Wales for 1851 through 1911—note that 1921 gives age in years and months; the 1939 Register gives a day-month-year birth, which may be a year out due to a 'counting-back' error).
The Birth entry for ID: KVYZ-749 has three census sources : 1841 (age may be given to a 5-year increments, so it represents usually a range of years), 1851, and 1861 (ages effectively to a birth year +/- 1).
The christening has a date: 27 May 1823 and is sourced.
The Quality Score for Conflict-free Data is I believe incorrect. When a year is given, there is no reason to assume it should be treated as the end of the year and lead to a low score.
The Birth has a 'low quality' score which I believe is incorrect. There are three sources, two of which give ages from which the year (usually +/- 1 year) can be calculated. For this combination I'd say it should have an individual element quality score of at least 'medium'
Comments
-
@FrankLittle
Although the birth is showing as 1823 in the Birth box, it has been standardized to 1824. That's why you are seeing "christening before birth."
If you edit the date to show 1823, then the problem will disappear.
Hope this helps.1 -
Ah, many thanks. I didn't notice that the standardized date was being used regardless of the entered date. (And indeed hadn't noticed that the entered date had not been set as standardized).
It does of course raise a new question. Perhaps it would help if the quality-related comments made this more explicit, pointing to the issue of a mismatch between the entered date and the standardized date?
And magically, if the standardized date is reset to 1823, the score on both the specific Birth entry and the general quality jumps to 'High'.
1 -
I've noted that a record conflict with a birth or death date has a higher impact on the DQS than other measures. For example, a residence date after the date of death (often from an obituary) will push the DQS to Low.
A number of users have called for more information about what specifically is impacting the DQS. Hopefully, the engineers have heeded those requests and are working as we speak.
0 -
That makes a lot of sense. Especially the birth date is an indicator that we might have two different people, However, a one-year difference is in my opinion too small a difference to give so much weight to causing a jump from 'High' to 'Low'. Census dates especially are very often a year off, which is the reason most programs/platforms work with two-year either side matching.
Also, any registration index date (as found in GRO England and Wales online indexes for birth or death (or marriage, though currently not available) or in FreeBMD etc. can easily be a year off (a very late November or December birth date registered in the following January will always give an offset.
Perhaps the "before <baptism date> for a birth 'date' or ditto for a burial would be a good thing to promote in the explanatory text. It does mean thatm for instance, baptisms without birth dates should be tagged as sources for such a birth date, etc., and receive commensurate quality scores.
1 -
"A number of users have called for more information about what specifically is impacting the DQS. Hopefully, the engineers have heeded those requests and are working as we speak."
The DQS is potentially an extremely useful addition to family history research, but indeed only helpful if it points one in the right direction on resolving poor scores beyond the obvious deficiencies. I hope this work will continue in future and become even more refined. Thanks for this, in any case, so far to all concerned.
1 -
In nearly every routine in FamilySearch only the standard linked to the displayed data is used. The displayed data, such as the 1823 in your example is a meaningless jumble of random 0s and 1s to a computer program. Only the standard 1824 has meaning. But having that double entry allows valuable additional information that other humans need to know even though it is meaningless to the computer, like this:
A good rule of thumb is to always keep in mind that if something doesn't make sense in a notification from the computer, check the underlying linked standard.
I'll also mention that the data entry routines have been updated so that these days it is, as far as I can tell, impossible to standardize 1823 as 1824. Looking at Hannah's change log, the standardization error occurred back in 2019 when such a thing was still fairly easy to do. That was when the displayed birth year was updated but the linked standard was not.
2 -
Thanks for this advice. It is indeed very easy to miss (if you don't expect the mismatch.)
The warning is of course helpful in any case, and would be even more helpful if it indicated the issue which caused the lower score.
Could I repeat my point about the quality score itself: "However, a one-year difference is in my opinion too small a difference to give so much weight to causing a jump from 'High' to 'Low'. "
1
