This person has a birth date of before 29 July 1821, which does not match the date 1822.
Well, yes. The year 'date' is from the census which is often a year out (surprisingly, even sometimes in the England 1939 Register with the full date*). The day-month-year 'before' date is from the baptism (29 July 1821, in this case).
Looking at the quality on the Birth entry, I have to edit the ones referring to the censuses cited as sources. But counting a one-year difference from a census as an error does make for a lot of extra work. Can this please be made less constrictive?
Similar comments apply to the birth place issue, I think: "This person has a birth place of Yorkshire, England, United Kingdom, which does not match the place Barningham, Yorkshire, England." I'm not really sure how to deal with imprecise census data; it diverges more often than not in some way with data from other sources.
Finally: "The birth date is imprecise." It's a true statement, but doesn't really help much since we do not have his actual birth date. At least the census data suggests that he wasn't born a very long time before the baptism took place.
I can't edit (read: dismiss with commentary) these quality notes directly from the Birth entry, which is a pity. Dismissing them from the Quality Score righthand pane under Source Consistency does get rid of them in the Birth entry, although the 'imprecise date' statement cannot be removed this way.
==*How can I be sure? By checking the quarter of the birth registration in the GRO England and Wales online index, or for more certainty, calling up a digital extract of the image of the return done from the local Register Office if it's for England and Wales (or paying for Scotland people access to an image there).
Comentarios
-
At least the wording in that callout has improved; formerly, it implied the census year of birth was the more reliable record.
1 -
🙄
0 -
Thank you for the feedback. In this case the DQS is working as it should by calling out an inconsistency. Once you have checked for accuracy. Please dismiss the issue :)
0 -
Thanks for the response, Rhonda. I believe that one year differences on census source / birth year entries are not inconsistencies worth registering for the reasons given, are extremely common (certainly for the England and Wales censuses 1851 through 1911*) and therefore do not add enough to the basic purpose of improving the evidence-based quality of an entry.
I appreciate the advantage offered by the DQS in suggesting one looks again at the evidence, and consider it a helpful improvement. Can you clarify what effect dismissing actually has ? And is it in fact always possible to dismiss (and under what conditions it is not possible; or is it bug-related)?
I also think that I was wrong and the DQS is not (always?) marking a one-year difference as an error.
*The 1841 census is a different question with the 5-year spread,a nd I believe it works OK. The 1921census gives month age as well as year, so like some USA censuses is a little more specific. In the 1939 Register it's an error on the part of the person when counting back in some cases; since it is a specific date in this case, the error is significant and requires checking, but the explanation in the dismissal needs to be a bit more rigorous I think.
0 -
Here's an example I just came across in which the algorithm (in this case applied on the merge process, but I would guess the same mechanism) suggests a mismatch and caution when imho it is not needed, because the calculated birth year from a census is within the normal range of possibilities. I realise I can ignore it and go ahead anyway.
0 -
and this one illustrates the issue too (I like "The birth dates are at least 0 days apart" ;-)
0 -
@FrankLittle thank you for your further comments. I will put this in the queue for another look :)
1 -
My thanks, Rhonda.
0 -
The algorithm - in fact, the entire tree - can't parse before/after/about.
1 -
https://community.familysearch.org/en/discussion/comment/607495#Comment_607495
I can understand this, but the difficulty is that a "before …" date may be the most accurate statement which can be made, depending on what is known, or even knowable.
0 -
I agree. I wasn't disagreeing with you, simply stating the Tree can't handle that information.
1 -
Thank you for the comments. A ticket has been created to see if this issue can be resolved :)
2 -
Thanks for being so patient, Rhonda. 😊
0
