bdq
bdq copied to clipboard
tdwg
TG2-MEASURE_AMENDMENTS_PROPOSED
| TestField | Value |
|---|---|
| GUID | 03049fe5-a575-404f-b564-ae63f5a1cf8b |
| Label | MEASURE_AMENDMENTS_PROPOSED |
| Description | A count of the number of distinct AMENDMENT tests that have a Response.status="AMENDED" for a given record. |
| TestType | Measure |
| Darwin Core Class | bdq:Amendment |
| Information Elements ActedUpon | |
| Information Elements Consulted | bdq:AllAmendmentTestsRunOnSingleRecord" |
| Expected Response | The number of tests of output type AMENDMENT that have been run against the record and have proposed changes to the record (Result.status="AMENDED") |
| Data Quality Dimension | Completeness |
| Term-Actions | AMENDMENTS_PROPOSED |
| Parameter(s) | |
| Source Authority | |
| Specification Last Updated | 2024-08-18 |
| Examples | [Response.status=RUN_HAS_RESULT, Response.result="17", Response.comment="17 tests of TYPE AMENDMENT were run and proposed changes to the record."] |
| Source | John Wieczorek |
| References | |
| Example Implementations (Mechanisms) | |
| Link to Specification Source Code | |
| Notes |
Comment by Paul Morris (@chicoreus) migrated from spreadsheet: This test and TESTS_FLAGGED_REPORT neatly combine to a measure: single_record_proportion_of_validations_compliant, and a measure at the dataset level; multi_record_average_compliant_validations.
Comment by Paul Morris (@chicoreus) migrated from spreadsheet: Here is where it becomes very important to think in terms of the framework: Tests total, where tests = validations results in entirely different calculations than if tests=validations+measures, or tests=validations+measures+amendments. This test should be split into at least two: SINGLE_RECORD_VALIDATIONS_ATTEMPTED, and SINGLE_RECORD_MEASURES_ATTEMPTED
Comment by Paul Morris (@chicoreus) migrated from spreadsheet: Needs to be split into two measures.
Amendments are proposals, they may or may not affect data (they may be proposals to change mappings or to change procedures). Original sense of this test was a description of how many amendments were run. Current sense appears to have changed to the number of amendments that propose changes to a single record. If there is agreement that this should be the case (as opposed, for example, to counting the number of terms to which changes are proposed (an amendment could propose changes to more than one term, and amendments could overlap, etc), as opposed to the original sense (which describes the test suite almost as much as the results).
I'll propose changing the name to measure_amendments_singlerecord_proposed, and defining the number of amendments proposed to a single record as the number of amendments on that record which returned a result state of CHANGED or FILLED_IN, excluding the number of amendments that did not execute, had a result state of NOT_RUN, or PREREQUISITES_NOT_MET. Amendments could have a result state of AMBIGUOUS (indicating a change was proposed, but it has ambiguity (with the nature of the ambiguity described in the result comments)). These should also probably be counted as proposed.
We had quite some discussion on these - and this flag just counts the changes made due to an amendment - i.e. how many Annotations of Type Amendment were created. So NOT RUN or PREREQUISITES_NOT_MET don't come into it. We decided we didn't need other tests for NOT RUN or PREREQUISITES_NOT_MET. We have tests for the VALIDATIONS failed and passed and pre-requisties not met (#31, #135, #134). We didn't include Validations run as this is a sum of those three. We then agreed that we only needed a count of the Amendments that made a change and for which there would be a corresponding Annotation
@ArthurChapman Sounds good. I've modified the description to reflect that. I'll still suggest the name change from _MADE to _PROPOSED. We should also consider how results with a status AMBIGUOUS should be handled (this might need defining another attribute of the result state to flag ambiguity instead of using the result state).
Agreed at TDWG 2018 DQIG meeting that the name TG2-MEASURE_AMENDMENTS_PROPOSED is satisfactory.
A tweak to the Expected Response (@chicoreus - please check as I am unsure on REPORT/NOT_REPORTED)
REPORT the number of tests of output type AMENDMENT that have been run against the record and have proposed changes to the record (Result.status="AMENDED"); otherwise NOT_REPORTED
I suggest the Description:
'The number of distinct AMENDMENT tests that have a Response.status="AMENDED" for a given record.'
in place of:
'The number of AMENDMENT type tests run on a record that have a Response.status="AMENDED".'
From Zoom 30th May 2022, change the Expected Response from
REPORT the number of tests of output type AMENDMENT that have been run against the record and have proposed changes to the record (Result.status="AMENDED"); otherwise NOT_REPORTED
to
The number of tests of output type AMENDMENT that have been run against the record and have proposed changes to the record (Result.status="AMENDED")
Splitting bdqffdq:Information Elements into "Information Elements ActedUpon" and "Information Elements Consulted": I'm unsure about how we deal with MEASUREs. I used "Consulted".
Also changed "Field" to "TestField", "Output Type" to "TestType" and updated "Specification Last Updated"