Lee Belbin

Amended Source Authority values to align with @chicoreus syntax From bdq:sourceAuthority default = "GBIF Backbone Taxonomy" [https://doi.org/10.15468/39omei] | | | API endpoint [https://api.gbif.org/v1/species?datasetKey=d7dddbf4-2cf0-4f39-9b2a-bb099caae36c&name=] to bdq:sourceAuthority default = "GBIF Backbone Taxonomy"...

Splitting bdqffdq:Information Elements into "Information Elements ActedUpon" and "Information Elements Consulted". Also changed "Field" to "TestField", "Output Type" to "TestType" and updated "Specification Last Updated"

Splitting bdqffdq:Information Elements into "Information Elements ActedUpon" and "Information Elements Consulted". Also changed "Field" to "TestField", "Output Type" to "TestType" and updated "Specification Last Updated"

The Expected Response on this test looks like it may need a change due to recent discussions re "invalid" values. That is, do we run the test if dwc:month contains...

Splitting bdqffdq:Information Elements into "Information Elements ActedUpon" and "Information Elements Consulted". Also changed "Field" to "TestField", "Output Type" to "TestType" and updated "Specification Last Updated"

Do we modify this test and #128 to use the GBIF vocabulary? This would mean adding a bdq:sourceAuthority and rewording the Expected Response to something like EXTERNAL_PREREQUISITES_NOT_MET if the bdq:sourceAuthority...

I think we need affiliation as in "TDWG DQ Test Parameters". I don't think it applies to the assertions as such?

The abbreviations would be rightfully NOT_COMPLIANT.

That type of issue aligns with my conclusion about assumed, increasingly 'smarter' bdq:sourceAuthorities in handling variants - and this is what I remember @tucotuco suggesting regarding vocabs on values on...

I would also try to stick with “bdq:sourceAuthority” everywhere. In this case a) it is Parameterized and b) is a vocabulary