TG2-MEASURE_AMENDMENTS_PROPOSED

[iDigBioBot]

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

[iDigBioBot]

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.

[iDigBioBot]

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

[iDigBioBot]

Comment by Paul Morris (@chicoreus) migrated from spreadsheet:
Needs to be split into two measures.

[chicoreus]

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.

[ArthurChapman]

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

[chicoreus]

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

[tucotuco]

Agreed at TDWG 2018 DQIG meeting that the name TG2-MEASURE_AMENDMENTS_PROPOSED is satisfactory.

[Tasilee]

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

[tucotuco]

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".'

[Tasilee]

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

[Tasilee]

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"

[chicoreus]

As with #31, #134, and #135:

AllDarwinCoreTerms needs to be replaced by a list of relevant validations, in the form (used in the multirecord measures):

bdq:AMENDMENT_BASISOFRECORD_STANDARDIZED.Response, as it is the results of validations on the single records that are the information elements for this test, not the darwin core terms.

We should probably also split this test into one test for each use case, with information elements matching the validations found in that use case.

[Tasilee]

I agree @chicoreus , but there are two issue. First up, we probably should not list CORE AMENDMENTS as these may change depending on context. Second, we don't agree about splitting on use case.

I have changed Information Element Consulted from "All DarinCoreTerms" to "All CORE tests of type AMENDMENT that were run"

[Tasilee]

Changed Information Elements Consulted to "bdq:AllAmendmentTestsRunOnSingleRecord"