talk · Tuesday 22 September · 11:34–⁠11:48 · ODIN

Interpreting the Responses from BDQ Tests

Arthur Chapman · Data Quality: From Standard to Practice

Recording time 3:03:22–3:16:26Open on Vimeo ↗

Summaries and key moments are machine-produced. Check the recording for the speaker’s exact words.

The short versionEvery BDQ test returns a status, result and comment, and understanding these lets users decide fitness for their own use.

Overview

What this was about

Arthur Chapman explains how to interpret the reports and responses produced by BDQ tests. The only normative output is the response, consisting of a status (e.g. run has result, internal or external prerequisites not met, amended, not amended), a result (compliant/not compliant, potential issue, a value) and a human-readable comment, plus an optional qualifier. Worked examples cover day-in-range validation, data-generalizations issue flags, day amendments and measures, with emphasis that amendments should never enter a database of record without human checking.

Why it matters. Implementers and data users need to read BDQ outputs correctly, e.g. distinguishing data problems from temporary external failures.

Key ideas

In the room

  • Report form is not specified by BDQ, but a report should include a response for every test run, in a strict order.
  • Response = status (operational metadata), result (core assertion from controlled vocabulary), comment (human-readable), optional qualifier.
  • Internal prerequisites not met: the data cannot be evaluated and will always give this result until the record changes.
  • External prerequisites not met: an external authority (e.g. a GBIF vocabulary) was unavailable; rerunning may succeed.
  • Validation example: day 30 with month 2 of 1952 is not compliant; day 31 without a month cannot be evaluated.
  • Issue tests (e.g. data generalizations not empty) raise warnings for human judgement.
  • Measures: single-record direct, single-record derived and multi-record.
Jump in

Notable moments

In their words

Transcript

Automatically generated captions can contain mistakes, especially in names and technical terms. Times are relative to the room recording.

Read the transcript ↓
Loading transcript…
Programme abstract

Interpreting the Responses from BDQ Tests

Arthur Chapman

BDQ (Biodiversity Data Quality) is a standard designed to facilitate the consistent development and use of a set of biodiversity data quality tests and responses from these tests.

The Standard takes Darwin Core (Wieczorek et al., 2011) encoded data, evaluates quality using data quality Tests and produces a report. The reporting from of BDQ Tests is the focus of this presentation (see User’s Guide to the Standard).

Tests for data quality may serve two purposes: Quality Control and Quality Assurance.

In Quality Assurance (QA), data are evaluated for fitness for use and are filtered down to those data that are fit for that use. In Quality Control (QC), tests are used to identify data that are not fit for a specific use. The goal is to improve data quality by proposing changes to the data.

A Data Quality Report, produced from running a BDQ Tests is expected to include a Response for each Test run.

In brief, each Response consists of the following elements:

Response.status - Metadata describing the status of the Test run, including whether the Test was executed successfully. Values include RUN_HAS_RESULT, INTERNAL_PREREQUISITES_NOT_MET and EXTERNAL_PREREQUISITES_NOT_MET. Response.result - The result of the evaluation of the Test against the input data. Values include "COMPLIANT", "NOT_COMPLIANT", "COMPLETE", "NOT_COMPLETE", or data values depending on the type of Test. Response.comment - A human-readable comment providing additional context or information to assist users in the interpretation of the Test result.

These responses are dependant of the type of Test - Validation, Amendment, Issue or Measure.

The presentation will discuss these issues, and various pitfalls, especially with Amendment Tests, in using the data to improve databases of record.

Submitted to the conference programme before the talk, so the talk itself may differ.