bdq
bdq copied to clipboard
tdwg
TG2-VALIDATION_BASISOFRECORD_NOTEMPTY
| TestField | Value |
|---|---|
| GUID | ac2b7648-d5f9-48ca-9b07-8ad5879a2536 |
| Label | VALIDATION_BASISOFRECORD_NOTEMPTY |
| Description | Is there a value in dwc:basisOfRecord? |
| TestType | Validation |
| Darwin Core Class | Record-level |
| Information Elements ActedUpon | dwc:basisOfRecord |
| Information Elements Consulted | |
| Expected Response | COMPLIANT if dwc:basisOfRecord is bdq:NotEmpty; otherwise NOT_COMPLIANT |
| Data Quality Dimension | Completeness |
| Term-Actions | BASISOFRECORD_NOTEMPTY |
| Parameter(s) | |
| Source Authority | |
| Specification Last Updated | 2023-09-17 |
| Examples | [dwc:basisOfRecord="PreservedSpecimen": Response.status=RUN_HAS_RESULT, Response.result=COMPLIANT, Response.comment="dwc:basisOfRecord is bdq:NotEmpty"] |
| [dwc:basisOfRecord="": Response.status=RUN_HAS_RESULT, Response.result=NOT_COMPLIANT, Response.comment="dwc:basisOfRecord is bdq:Empty"] | |
| Source | TG2 |
| References | |
| Example Implementations (Mechanisms) | |
| Link to Specification Source Code | |
| Notes |
Comment by Lee Belbin (@Tasilee) migrated from spreadsheet: Added post scoring for consistency
Agreed at TDWG 2018 DQIG meeting that the test is a Validation and the name TG2-VALIDATION_BASISOFRECORD_EMPTY is satisfactory.
Generating test data for this and wonder if we should have an 'INTERNAL_PREREQUISITES_NOTMET if dwc:basisOfRecord is not provided'? My feeling is "no" as this would be equivalent to EMPTY?
@Tasilee I concur. To allow for implementations where the test is unable to tell if the field was provided as a data element for a record or not, we've included term not provided within the definition of empty, so tests should simply specify what state should be returned for empty and not separately make an assertion about a term not being provided.
Going through the test data, dwc:basisOfRecord="[non-printing characters]" with the current Expected Response would suggest to me to return "COMPLIANT": A sort of false positive (which is sort of ok :). Are we happy with that or are we suggesting something like "interpreted as a text string"...or similar? I want to keep this simple.
With all the "[non-printing characters]" we have treated them as EMPTY (and therefore NON_COMPLIANT) - we have been consistent - I guess it is because a human can't see them - they don't print. They would be easy to fix if we change that as they are all treated exactly the same in the EMPTY/NOT_EMPTY tests. This is different to "[Null]" where there is something - like "-n/", "null", "NULL", "9999", etc. where this a value and thus it is NOT_EMPTY and thus COMPLIANT
I prefer to keep them as EMPTY.
On Tue, Mar 1, 2022 at 11:53 PM Arthur Chapman @.***> wrote:
With all the "[non-printing characters]" we have treated them as EMPTY (and therefore NON_COMPLIANT) - we have been consistent - I guess it is because a human can't see them - they don't print. They would be easy to fix if we change that as they are all treated exactly the same in the EMPTY/NOT_EMPTY tests. This is different to "[Null]" where there is something - like "-n/", "null", "NULL", "9999", etc. where this a value and thus it is NOT_EMPTY and thus COMPLIANT
— Reply to this email directly, view it on GitHub https://github.com/tdwg/bdq/issues/58#issuecomment-1056096429, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADQ722SYOPTQGN374CRLUDU53J2NANCNFSM4EKSMW6Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>
Splitting bdqffdq:Information Elements into "Information Elements ActedUpon" and "Information Elements Consulted". Also changed "Field" to "TestField" and "Output Type" to "TestType".