TG2-VALIDATION_DAY_INRANGE

[pzermoglio]

TestField	Value
GUID	8d787cb5-73e2-4c39-9cd1-67c7361dc02e
Label	VALIDATION_DAY_INRANGE
Description	Is the value of dwc:day interpretable as a valid integer between 1 and 28 inclusive or 29, 30 or 31 given the relative month and year?
TestType	Validation
Darwin Core Class	dwc:Event
Information Elements ActedUpon	dwc:day
	dwc:month
	dwc:year
Information Elements Consulted
Expected Response	INTERNAL_PREREQUISITES_NOT_MET if (1) dwc:day is bdq:Empty, or (2) dwc:day is not interpretable as an integer, or (3) dwc:day is interpretable as an integer between 29 and 31 inclusive and dwc:month is not interpretable as an integer between 1 and 12, or (4) dwc:month is interpretable as the integer 2 and dwc:day is interpretable as the integer 29 and dwc:year is not interpretable as a valid ISO 8601 year; COMPLIANT if (1) the value of dwc:day is interpretable as an integer between 1 and 28 inclusive, or (2) dwc:day is interpretable as an integer between 29 and 30 and dwc:month is interpretable as an integer in the set (4,6,9,11), or (3) dwc:day is interpretable as an integer between 29 and 31 and dwc:month is interpretable as an integer in the set (1,3,5,7,8,10,12), or (4) dwc:day is interpretable as the integer 29 and dwc:month is interpretable as the integer 2 and dwc:year is interpretable as is a valid leap year (evenly divisible by 400 or (evenly divisible by 4 but not evenly divisible by 100)); otherwise NOT_COMPLIANT.
Data Quality Dimension	Conformance
Term-Actions	DAY_INRANGE
Parameter(s)
Source Authority
Specification Last Updated	2024-09-16
Examples	[dwc:day="15", dwc:month="", dwc:year="": Response.status=RUN_HAS_RESULT, Response.result=COMPLIANT, Response.comment="dwc:day is in range"]
	[dwc:day="30", dwc:month="2", dwc:year="1952": Response.status=RUN_HAS_RESULT, Response.result=NOT_COMPLIANT, Response.comment="dwc:day is not in range"]
Source	TG2-Gainesville
References	ISO (2019) ISO 8601-1:2019(en) Date and time — Representations for information interchange — Part 1: Basic rules. https://www.iso.org/obp/ui/ Wikipedia (2020) ISO 8601. https://en.wikipedia.org/wiki/ISO_8601 Library of Congress (2019) Extended Date/Time Format (EDTF). https://www.loc.gov/standards/datetime/
Example Implementations (Mechanisms)	event_date_qc
Link to Specification Source Code	event_date_qc DwCEventDQ.validationDayInrange()
Notes	This test must take into account the given month and year, if present, to account for leap years. This is part of a group of similar tests (VALIDATION_DAY_INRANGE (8d787cb5-73e2-4c39-9cd1-67c7361dc02e, #VALIDATION_STARTDAYOFYEAR_INRANGE (85803c7e-2a5a-42e1-b8d3-299a44cafc46), VALIDATION_ENDDAYOFYEAR_INRANGE9a39d88c-7eee-46df-b32a-c109f9f81fb8)).

[chicoreus]

Pass and fail descriptions aren't congruent. Fail description specifies a failure for all days with a value of 29 in a non-leap year. As described in pass description this is equivalent to https://github.com/FilteredPush/event_date_qc/blob/1abbd3f02eb6c28129764defab78f72156972864/src/main/java/org/filteredpush/qc/date/DwCEventDQ.java#L702 DAY_POSSIBLE_FOR_MONTH_YEAR urn:uuid:5618f083-d55a-4ac2-92b5-b9fb227b832f which was termed RECORDED_DATE_MISMATCH at some point in the spreadsheet.

Prerequisites for validations should not include references to amendments - validations are all run in a pre-amendment phase and again in a post-amendment phase.

[ArthurChapman]

I also see a problem with the description "OR the value of dwc:day is 29 in a non-leap year" this part must add "and dwc:month=2"

[chicoreus]

Check earlier versions of spreadsheet. This appears to be a renamed version of another test which has a guid. See note above. Source is probably ALA or GBIF, but check spreadsheet. Name is confusing, as this is a check for day relative to month and year, not if day is an integer in the range 1 to 31.

[ArthurChapman]

@chicoreus Line 18 in the spreadsheet SUPPLEMENTAL, This is another test like #127 that we previously had in SUPPLEMENTAL as it was said that DAY and MONTH weren't CORE fields other than for filling in the eventDate. I would suggest putting back into SUPPLEMENTAL

[Tasilee]

I would agree with SUPPLEMENTAL

[chicoreus]

It looks like this one should have the guid: 5618f083-d55a-4ac2-92b5-b9fb227b832f (RECORDED_DATE_MISMATCH). I would propose renaming this test as VALIDATION_DAY_POSSIBLE_FOR_MONTH_YEAR, or something like that to clarify that month and year are terms consulted.

This is not the same as 48aa7d66-36d1-4662-a503-df170f11b03f DAY_INVALID/DAY_IN_RANGE which only evaluated dwc:day.

[Tasilee]

I see this as a simple test for numeric 1-31 inclusive as #36 covers the temporal logic. If so, I can simplify the descriptions.

[ArthurChapman]

Except that this is testing DAY and #36 is testing eventDate. I know arguments were put forward for keeping this test for consistency, but I have my doubts as to whether it should be CORE. Who queries just "Day" and not "eventDate"?

[Tasilee]

The issue is beyond querying dwc:day. The ability of tests to flag issues remains important for building evidence of overall 'record utility', either as a simple flag or as a contribution to record summaries as in #31

'Record utility' is not something we have put much effort into, but it must happen. For example, I can readily see the utility of stats or algorithms that cluster/classify records on 'flag' combinations. I'd like to try using (for example) http://www.patn.com.au to classify a collection of records to see if fitness-for-use categories or dataset origins emerged.

[tucotuco]

Agreed at TDWG 2018 DQIG meeting that this test is correct as written and that another test to validate the day (TG2-VALIDATION_DAY_NOTSTANDARD) is necessary to be able to know if the prerequisite is met. That test specifically tests that the day is an integer. To meet the prerequisites, similar tests must exist for month and year (TG2-VALIDATION_MONTH_NOTSTANDARD, TG2-VALIDATION_YEAR_NOTSTANDARD).

[ArthurChapman]

also from @Tasilee Test #127 description states "The value of dwc:day was unambiguously interpreted to be an integer between 1 and 31 inclusive"

Do we get rid of #127 but needed to trigger the Amendment - or do we delete the first sentence of this tests description? Otherwise we appear to have tests testing the same thing (Integer in range)

@chicoreus please respond!

[chicoreus]

@Tasilee I think your comment about #36 is relevant. It makes sense to have a test for day is an integer in the range 1-31 as a test (this one), and leave the logic of are the date terms consistent to other tests. It makes sense to me if this test parallels #126.

[chicoreus]

Discussion Thursday 5:30 at TDWG 2017.

Separate #147 as covering day as integer in range 1-31, independent of month or year. That issue only takes day as information element.

This test assesses day as integer in range 1-28, with 29-31 dependent on month and year. This test takes day, month, year as information element.

[chicoreus]

I've corrected what must be a typo in the INTERNAL_PREREQUISITES_NOT_MET section (can't tell if Feb 29 is valid without the year:

dwc:month is not the integer 2 and dwc:day is the integer 29 and dwc:year is not a valid ISO 8601 year;

to

dwc:month is the integer 2 and dwc:day is the integer 29 and dwc:year is not a valid ISO 8601 year;

[ArthurChapman]

I probably should read back through all the comments but don't points c) and d) under INTERNAL_PREREQUISITES_NOT_MET really NOT_COMPLIANT than INTERNAL_PREREQUISITES_NOT_MET?

The examples in the test dataset are treating those values as NOT_COMPLIANT rather than INTYERNAL_PREREQUISITES_NOT_MET

[chicoreus]

Cases c) and d) are cases where we can't tell from the information given. The value of day may well be in range, but we can't tell from the information given in the other fields, thus the internal prefrequsites for testing dwc:day are not met.

[Tasilee]

I have tested an amendment to the Expected Response to incorporate the use of "Interpreted as..". This makes it messy but the intent is clear.

[ArthurChapman]

I am not sure "interpreted as" is best in all those cases, for example "dwc:year is not interpretable as a valid ISO 8601 year" wouldn't that just be " dwc:year is not a valid ISO 8601 yeara valid ISO 8601 year" Are we not making it a little too complicated? Happy to accept whatever @tucotuco suggests.

[Tasilee]

Admitted, this was the extreme example :)

[tucotuco]

Tough call. Is there an outside chance that an ancient specimen might have a year in Roman numerals? Unlikely, but does it hurt to leave "interpretable as" since it is strewn throughout the expected response. In any case, the current Expected Response needs an amendment (extraneous "an" in COMPLIANT (a). Suggest to change from

"INTERNAL_PREREQUISITES_NOT_MET if (a) dwc:day is EMPTY, or (b) if dwc:day is not interpretable as an integer, or (c) dwc:day is interpretable as an integer between 29 and 31 inclusive and dwc:month is not interpretable as an integer between 1 and 12, or (d) dwc:month is interpretable as the integer 2 and dwc:day is interpretable as the integer 29 and dwc:year is not interpretable as a valid ISO 8601 year; COMPLIANT (a) if the value of dwc:day is an interpretable as an integer between 1 and 28 inclusive, or (b) dwc:day is interpretable as an integer between 29 and 30 and dwc:month is interpretable as an integer in the set (4,6,9,11), or (c) dwc:day is interpretable as an integer between 29 and 31 and dwc:month is interpretable as an integer in the set (1,3,5,7,8,10,12), or (d) dwc:day is interpretable as the integer 29 and dwc:month is interpretable as the integer 2 and dwc:year is interpretable as is a valid leap year (evenly divisible by 400 or (evenly divisible by 4 but not evenly divisible by 100)); otherwise NOT_COMPLIANT."

to

"INTERNAL_PREREQUISITES_NOT_MET if (a) dwc:day is EMPTY, or (b) if dwc:day is not interpretable as an integer, or (c) dwc:day is interpretable as an integer between 29 and 31 inclusive and dwc:month is not interpretable as an integer between 1 and 12, or (d) dwc:month is interpretable as the integer 2 and dwc:day is interpretable as the integer 29 and dwc:year is not interpretable as a valid ISO 8601 year; COMPLIANT (a) if the value of dwc:day is interpretable as an integer between 1 and 28 inclusive, or (b) dwc:day is interpretable as an integer between 29 and 30 and dwc:month is interpretable as an integer in the set (4,6,9,11), or (c) dwc:day is interpretable as an integer between 29 and 31 and dwc:month is interpretable as an integer in the set (1,3,5,7,8,10,12), or (d) dwc:day is interpretable as the integer 29 and dwc:month is interpretable as the integer 2 and dwc:year is interpretable as is a valid leap year (evenly divisible by 400 or (evenly divisible by 4 but not evenly divisible by 100)); otherwise NOT_COMPLIANT."

[Tasilee]

This will easily be the longest (1042 characters) and most complicated Expect Response. Minor syntax issues (use of "if") would suggest

INTERNAL_PREREQUISITES_NOT_MET if (a) dwc:day is EMPTY, or (b) dwc:day is not interpretable as an integer, or (c) dwc:day is interpretable as an integer between 29 and 31 inclusive and dwc:month is not interpretable as an integer between 1 and 12, or (d) dwc:month is interpretable as the integer 2 and dwc:day is interpretable as the integer 29 and dwc:year is not interpretable as a valid ISO 8601 year; COMPLIANT if (a) the value of dwc:day is interpretable as an integer between 1 and 28 inclusive, or (b) dwc:day is interpretable as an integer between 29 and 30 and dwc:month is interpretable as an integer in the set (4,6,9,11), or (c) dwc:day is interpretable as an integer between 29 and 31 and dwc:month is interpretable as an integer in the set (1,3,5,7,8,10,12), or (d) dwc:day is interpretable as the integer 29 and dwc:month is interpretable as the integer 2 and dwc:year is interpretable as is a valid leap year (evenly divisible by 400 or (evenly divisible by 4 but not evenly divisible by 100)); otherwise NOT_COMPLIANT."

Edited accordingly.

Now only 1037 characters!

[chicoreus]

GUID 5618f083-d55a-4ac2-92b5-b9fb227b832f duplicates that of #67 VALIDATION_EVENT_INCONSISTENT. Changing here (in this higher numbered issue that probably represents an issue derived from VALIDATION_EVENT_INCONSISTENT) to 8d787cb5-73e2-4c39-9cd1-67c7361dc02e.

Note to @Tasilee the GUID for rows for #125 in the test validation data master spreadsheet will need to be changed to 8d787cb5-73e2-4c39-9cd1-67c7361dc02e.

[Tasilee]

Thanks @chicoreus. Changed in V14 Tests worksheet accordingly (which is referenced by the test data worksheet).

[Tasilee]

Shouldn't we have an entry

| Source Authority | bdq:sourceAuthority is "ISO 8601-1:2019" [https://www.iso.org/obp/ui/] |

?

[tucotuco]

I wouldn't think so if we are agreed that bdq:sourceAuthority should be used for vocabularies.

[Tasilee]

I have updated the ISO Reference link

[Tasilee]

Amended Expected response "(a)" etc to "(1)" etc and updated Specification Last Updated.

[ArthurChapman]

Note updated to replace internal GitHub references to other tests

[Tasilee]

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]

Changed reference in Expected Response from ISO 8601-1 to ISO 8601