Change term - geodeticDatum

[ArthurChapman]

Term change

• Submitter: @ArthurChapman on behalf of the Biodiversity Data Quality Interest Group TG2: Tests and Assertions
• Efficacy Justification (why is this change necessary?): The Georeferencing Best Practices (https://doi.org/10.15468/doc-gg7h-s853) recommends the use of "not recorded" rather than "unknown"
• Demand Justification (if the change is semantic in nature, name at least two organizations that independently need this term): It has implications in several tests for the proposed BDQ Standard - see comments under TG2-VALIDATION_GEODETICDATUM_STANDARD bdq#59 and TG2-AMENDMENT_GEODETICDATUM_STANDARDIZED bdq#60.
• Stability Justification (what concerns are there that this might affect existing implementations?): See Recommendations on missing/unknown/not recorded data in Darwin Core #437
• Implications for dwciri: namespace (does this change affect a dwciri term version)?: None

Current Term definition: https://dwc.tdwg.org/terms/#dwc:geodeticDatum

Proposed attributes of the new term version (Please put actual changes to be implemented in bold and strikethrough):

• Term name (in lowerCamelCase for properties, UpperCamelCase for classes): geodeticDatum
• Term label (English, not normative): Geodetic Datum
• Organized in Class (e.g., Occurrence, Event, Location, Taxon): Location
• Definition of the term (normative): The ellipsoid, geodetic datum, or spatial reference system (SRS) upon which the geographic coordinates given in dwc:decimalLatitude and dwc:decimalLongitude are based.
• Usage comments (recommendations regarding content, etc., not normative): Recommended best practice is to use the EPSG code of the SRS, if known. Otherwise use a controlled vocabulary for the name or code of the geodetic datum, if known. Otherwise use a controlled vocabulary for the name or code of the ellipsoid, if known. If none of these is known, use the value unknown not recorded. This term has an equivalent in the dwciri: namespace that allows only an IRI as a value, whereas this term allows for any string literal value.
• Examples (not normative): EPSG:4326; WGS84; NAD27; Campo Inchauspe; European 1950; Clarke 1866
unknown not recorded
• Refines (identifier of the broader term this term refines; normative): None
• Replaces (identifier of the existing term that would be deprecated and replaced by this term; normative): http://rs.tdwg.org/dwc/terms/version/geodeticDatum-2023-06-28
• ABCD 2.06 (XPATH of the equivalent term in ABCD or EFG; not normative): DataSets/DataSet/Units/Unit/Gathering/SiteCoordinateSets/SiteCoordinates/CoordinatesLatLon/SpatialDatum

[matdillen]

We proposed a vocabulary in a paper a few years ago (see table 2): https://doi.org/10.1093/database/baz129

For this value, it would fit either unknown:undigitized or unknown:missing. Would it make sense to align vocabularies for missing values, or at least include this distinction in the examples? It could be important from a digitization point of view.

[tucotuco]

@ArthurChapman For the sake of consistency, would it be reasonable to change the usage comments to:

"Recommended best practice is to use the EPSG code of the SRS, if known. Otherwise use a controlled vocabulary for the name or code of the geodetic datum, if known. Otherwise use a controlled vocabulary for the name or code of the ellipsoid, if known. If none of these is known, use the value an appropriate value for unknown (unknown:not digitized, unknown:missing). This term has an equivalent in the dwciri: namespace that allows only an IRI as a value, whereas this term allows for any string literal value." And then update theexamples with these values and change the recommendations in Georeferencing Best Practices (https://doi.org/10.15468/doc-gg7h-s853) and the Biodiversity Data Quality Tests and Assertions to match?

[ArthurChapman]

@tucotuco - will need to check that with @chicoreus to see how that affects the Data Quality checking programming

[chicoreus]

@ArthurChapman straightforward to switch out a vocabulary of unknowns for the value "not recorded".

@matdillen yes, standardizing on one vocabulary for unknowns would be good. I would read "not recorded" as most closely matching unknown:missing, but with very slightly broader scope, in that the unknown vocabulary proposed in https://academic.oup.com/view-large/187108161 is explicitly about digitization, and "not recorded" carries the implication of the observation never having been made so that there was nothing to digitize. But that difference is a small price to pay for adopting something that is intended as a standard vocabulary.

Probably worth linking to the vocabulary specifically in the usage comments (and in the georeferencing best practice guide):

"Recommended best practice is to use the EPSG code of the SRS, if known. Otherwise use a controlled vocabulary for the name or code of the geodetic datum, if known. Otherwise use a controlled vocabulary for the name or code of the ellipsoid, if known. If none of these is known, use as the value the appropriate value 'unknown:missing' from the vocabulary in table 2 of https://doi.org/10.1093/database/baz129 https://academic.oup.com/view-large/187108161. This term has an equivalent in the dwciri: namespace that allows only an IRI as a value, whereas this term allows for any string literal value."

@matdillen if we further standardize the vocabulary, probably change "unknown" to "unknown:not_otherwise_specified", or "unknown:unknown" with unknown: representing the namespace for the vocabulary.

[ArthurChapman]

@chicoreus - the suggestion above is for two unknowns: (unknown:not digitized and unknown:missing)

[tucotuco]

I don't think unknown:not digitized would be a reasonable value to have for geodeticDatum. If the georeference wasn't digitized, everything else about the georeference would be blank and the geodeticDatum should be too.

[chicoreus]

I think @tucotuco is right here, of the vocabulary proposed for unknowns in https://doi.org/10.1093/database/baz129, only unknown:missing makes sense here. In addition, alone of them, it seems actionable when dwc:decimalLatitude and dwc:decimalLongitude are used spatially to provide a basis for inferring a minimum value for the dwc:coordinateUncertaintyInMeters.

[chicoreus]

Key element here is aligning the guidance in Darwin Core, the Georeferencing Best Practices Guide, and the proposed BDQ Core tests, further alignment to the proposed unknown vocabulary in https://doi.org/10.1093/database/baz129 is very good as well.

[ArthurChapman]

After discussions with @chicoreus and others, the wording "not recorded" has a different meaning to "unknown:not digitized" and "unknown:missing" and as @tucotuco has said above "unknown:not digitized" is not a reasonable value for dwc:geodeticDatum. We believe that the simple "not recorded" is the simplest solution and reports on what we are really reporting for geodetic datums. A datum has either been recorded and we know what to do with that, or it has not been recorded. I see little value in making it more complicated. I agree with what @chicoreus has said above with respect to the proposed vocabulary of unknowns. In the Data Quality Interest Group, we have discussed this issue at length, and looked at many examples. Our conclusion was that in testing for Data Quality the use of "not recorded" as suggested in the Georeferencing Best Practices was the the best testable solution. I would strongly support the original proposal