bdq
bdq copied to clipboard
TG2-AMENDMENT_MONTH_STANDARDIZED
TestField | Value |
---|---|
GUID | 2e371d57-1eb3-4fe3-8a61-dff43ced50cf |
Label | AMENDMENT_MONTH_STANDARDIZED |
Description | Proposes an amendment to the value of dwc:month as an integer between 1 and 12 inclusive. |
TestType | Amendment |
Darwin Core Class | dwc:Event |
Information Elements ActedUpon | dwc:month |
Information Elements Consulted | |
Expected Response | INTERNAL_PREREQUISITES_NOT_MET if dwc:month is bdq:Empty; AMENDED the value of dwc:month if it can be unambiguously interpreted as an integer between 1 and 12 inclusive; otherwise NOT_AMENDED |
Data Quality Dimension | Conformance |
Term-Actions | MONTH_STANDARDIZED |
Parameter(s) | |
Source Authority | |
Specification Last Updated | 2023-09-18 |
Examples | [dwc:month="IV": Response.status=AMENDED, Response.result=dwc:month="4", Response.comment="dwc:month interpreted as roman numerals "] |
[dwc:month="October": Response.status=NOT_AMENDED, Response.result=, Response.comment="dwc:month contains an uninterpretable value"] | |
Source | TG2-Gainesville |
References | |
Example Implementations (Mechanisms) | Kurator:event_date_qc |
Link to Specification Source Code | https://github.com/FilteredPush/event_date_qc/blob/f224e5a1e6db81bc6ca725f520dd06a71fcfb54e/src/main/java/org/filteredpush/qc/date/DwCEventDQ.java#L1055 with unit test at https://github.com/FilteredPush/event_date_qc/blob/f224e5a1e6db81bc6ca725f520dd06a71fcfb54e/src/test/java/org/filteredpush/qc/date/DwcEventDQTest.java#L671 Internals of recognized string values (roman numerals, month names and abbreviations in multiple languages) use a combination of event_date_qc's DateUtils.cleanMonth() (see https://github.com/FilteredPush/event_date_qc/blob/23e4139d7f0ef71736f7fc7e984cfd2d0bfea093/src/main/java/org/filteredpush/qc/date/DateUtils.java#L2111 and Joda time's month recognition) |
Notes | Implementations should translate interpretable Roman numerals in the range I-XII in dwc:month as integer month values 1-12, as some natural science domains use roman numeral months to avoid language and day/month vs moth/day order. In these cases, the result will be AMENDED numeric equivalents. |
I would suggest explicitly including roman numerals as month numbers as a conversion to be made by this amendment.
Similarly to the AMENDMENT for DAY (https://github.com/tdwg/bdq/issues/127) this was not in our original suite of tests, and like Paul, I question their value as CORE. I know some good arguments were put forward in Gainesville where some easy one may be corrected (as in example), but we excluded a number of other tests on Day and Month as we didn't regard those fields as CORE (other than helping to populate eventDate. I can see arguments for keeping YEAR as I know a lot of people use this on its own, but DAY and MONTH less so. I agree with @chicoreus - move to SUPPLEMENTAL
I agree with SUPPLEMENTAL for the same reasons as for dwc:day
In the light of recent comments, I have this to Notes, but feel free to edit:
"We make the assumption that interpretable Roman numerals in dwc:month are valid as some data sources support this. In these cases, the result will be AMENDED numeric equivalents."
@Tasilee Great. I've rephrased as:
"Implementations should interpret strings interpretable Roman numerals in the range I-XII in dwc:month as integer month of the year values, as some natural science domains use roman numeral months to avoid language and d/m vs m/d order issues, and this information could be mapped into dwc:month (which, by definition, should only contain integers in the range 1-12). In these cases, the result will be AMENDED numeric equivalents"
I have edited the Notes to "Implementations should translate interpretable Roman numerals in the range I-XII in dwc:month as integer month values 1-12, as some natural science domains use roman numeral months to avoid language and day/month vs moth/day order. In these cases, the result will be AMENDED numeric equivalents."
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"
@Tasilee pointed to the GBIF API in #126, i.e. https://api.gbif.org/v1/vocabularies/Month/concepts/September/ This isn't adequate here (yet), as (1) the GBIF API does not provide the integer values 1-12 for a given month, (2) The GBIF API doesn't include roman numeral months as alternatives, and (3), the GBIF API currently only provides a small number of alternative languages for month names, and does not currently provide abbreviations. If (1) were addressed, it would provide a potential resource for implementors to consult, though currently more limited than some internationalized time libraries.