Home› Groups› Data Quality Score Feedback

Data Quality Score Feedback

Join

This person has a birth date of before 29 July 1821, which does not match the date 1822.

FrankLittle
FrankLittle ✭✭
August 18 in Social Groups

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).

0

Comments

  • Áine Ní Donnghaile
    Áine Ní Donnghaile ✭✭✭✭✭
    August 18

    At least the wording in that callout has improved; formerly, it implied the census year of birth was the more reliable record.

    1
  • FrankLittle
    FrankLittle ✭✭
    August 18

    🙄

    0
  • Rhonda Budvarson
    Rhonda Budvarson ✭✭✭✭
    September 3

    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
  • FrankLittle
    FrankLittle ✭✭
    September 4 edited September 4

    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
  • FrankLittle
    FrankLittle ✭✭
    September 4 edited September 4

    image.png

    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
  • FrankLittle
    FrankLittle ✭✭
    September 4 edited September 4

    and this one illustrates the issue too (I like "The birth dates are at least 0 days apart" ;-)

    image.png

    0
  • Rhonda Budvarson
    Rhonda Budvarson ✭✭✭✭
    September 10 edited September 10

    @FrankLittle thank you for your further comments. I will put this in the queue for another look :)

    1
  • FrankLittle
    FrankLittle ✭✭
    September 12

    My thanks, Rhonda.

    0
  • Áine Ní Donnghaile
    Áine Ní Donnghaile ✭✭✭✭✭
    September 12

    The algorithm - in fact, the entire tree - can't parse before/after/about.

    1
  • FrankLittle
    FrankLittle ✭✭
    September 14
    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
  • Áine Ní Donnghaile
    Áine Ní Donnghaile ✭✭✭✭✭
    September 14

    I agree. I wasn't disagreeing with you, simply stating the Tree can't handle that information.

    1
  • Rhonda Budvarson
    Rhonda Budvarson ✭✭✭✭
    September 17

    Thank you for the comments. A ticket has been created to see if this issue can be resolved :)

    2
  • FrankLittle
    FrankLittle ✭✭
    September 19

    Thanks for being so patient, Rhonda. 😊

    0
Clear
No Groups Found

Categories

  • All Categories