TG2-VALIDATION_STARTDAYOFYEAR_INRANGE

[pzermoglio]

TestField	Value
GUID	85803c7e-2a5a-42e1-b8d3-299a44cafc46
Label	VALIDATION_STARTDAYOFYEAR_INRANGE
Description	Is the value of dwc:startDayOfYear an integer between 1 and 365 inclusive, or 366 if a leap year?
TestType	Validation
Darwin Core Class	Event
Information Elements ActedUpon	dwc:startDayOfYear
Information Elements Consulted	dwc:eventDate
Expected Response	INTERNAL_PREREQUISITES_NOT_MET if dwc:startDayOfYear is EMPTY or if the value of dwc:startDayOfYear is equal to 366 and (dwc:eventDate is EMPTY or the value of dwc:eventDate cannot be interpreted to find single year or a start year in a range); COMPLIANT if the value of dwc:startDayOfYear is an integer between 1 and 365, inclusive, or if the value of dwc:startDayOfYear is 366 and the start year interpreted from dwc:eventDate is a leap year; otherwise NOT_COMPLIANT
Data Quality Dimension	Conformance
Term-Actions	STARTDAYOFYEAR_INRANGE
Parameter(s)
Source Authority
Specification Last Updated	2023-09-18
Examples	[dwc:eventDate="", dwc:startDayOfYear="15": Response.status=RUN_HAS_RESULT, Response.result=COMPLIANT, Response.comment="dwc:startDayOfYear is in range"]
	[dwc:eventDate="", dwc:startDayOfYear="0": Response.status=RUN_HAS_RESULT, Response.result=NOT_COMPLIANT, Response.comment="dwc:startDayOfYear is not in range"]
Source	TG2-Gainesville
References
Example Implementations (Mechanisms)	Kurator:event_date_qc
Link to Specification Source Code	https://github.com/FilteredPush/event_date_qc/blob/23e4139d7f0ef71736f7fc7e984cfd2d0bfea093/src/main/java/org/filteredpush/qc/date/DwCEventDQ.java#L832 Unit test at https://github.com/FilteredPush/event_date_qc/blob/5f2e7b30f8a8076977b2a609e0318068db80599a/src/test/java/org/filteredpush/qc/date/DwcEventDQTest.java#L609
Notes	See test VALIDATION_DAY_INRANGE (8d787cb5-73e2-4c39-9cd1-67c7361dc02e). This test only asks if dwc:startDayOfYear is a valid value for the relevant year, not if it is consistent with the start day of the range specified in dwc:eventDate. In a non-leap year, the valid range is 1-365 inclusive, in a leap year 366 is also valid. This test should be run after the series of tests that assure that dwc:eventDate is populated, if possible (i.e., AMENDMENT_EVENTDATE_FROM_VERBATIM (6d0a0c10-5e4a-4759-b448-88932f399812), AMENDMENT_EVENTDATE_STANDARDIZED (718dfc3c-cb52-4fca-b8e2-0e722f375da7), and AMENDMENT_EVENT_DATE_FROM_YEARMONTHDAY (3892f432-ddd0-4a0a-b713-f2e2ecbd879d)).

[chicoreus]

Like #131, the information element should not include dwc:eventDate.

[Tasilee]

As per #131, given the noted dependency on prior run of #52, dwc:eventDate is not required.

[chicoreus]

Note that the current specification will lead to a very large number of cases of internal prerequisites not met that can be asserted as compliant. We really only need to evaluate year when start day of year = 366.

I would advocate changing from:

INTERNAL_PREREQUISITES_NOT_MET if the fields dwc:year or dwc:startDayOfYear are either not present or are EMPTY; COMPLIANT if the value of the field dwc:startDayOfYear is a valid day given the year; otherwise NOT_COMPLIANT

to:

INTERNAL_PREREQUISITES_NOT_MET if the field dwc:startDayOfYear is either not present or is EMPTY, or if the value of dwc:startDayOfYear = 365 and dwc:year is either not present or is EMPTY; COMPLIANT if the value of the field dwc:startDayOfYear is a valid day given the year; otherwise NOT_COMPLIANT

This lets startDayOfYear=5, year=null be reported as compliant, matching the intent of the test to assess whether startDayOfYear is inside a valid range. Year only needs to be examined if day is 366.

[ArthurChapman]

Makes sense to me @chicoreus

[ArthurChapman]

@chicoreus Do you mean 366 and not 365 in your new text of Expected Response? We have assumed you meant 366

[chicoreus]

@ArthurChapman yes, 366.

[tucotuco]

On further consideration, this one still has problems. I would replace the current Expected response

"INTERNAL_PREREQUISITES_NOT_MET if dwc:startDayOfYear is EMPTY, or if the value of dwc:startDayOfYear = 366 and the value of dwc:year is EMPTY; COMPLIANT if the value of dwc:startDayOfYear is a valid day given the year; otherwise NOT_COMPLIANT"

with

"INTERNAL_PREREQUISITES_NOT_MET if dwc:startDayOfYear is EMPTY or if the value of dwc:startDayOfYear is equal to 366 and (dwc:eventDate is EMPTY or the value of dwc:eventDate can not be interpreted to find single year or a start year in a range); COMPLIANT if the value of dwc:startDayOfYear is an integer between 1 and 365, inclusive, or if the value of dwc:startDayOfYear is 366 and the start year interpreted from dwc:eventDate is a leap year (see test VALIDATION_DAY_OUTOFRANGE); otherwise NOT_COMPLIANT"

I would change the example from

dwc:startDayOfYear="451"; dwc:startDayOfYear="366" with dwc:year="2017"

to

dwc:startDayOfYear="451"; dwc:startDayOfYear="366" with dwc:eventDate="2017"

I would change the Note from:

"This test must take into account the given year, if present, to account for leap years. This is part of a group of similar tests (#125, #130, #131). This test should be run after the test TG2-AMENDMENT_EVENT_FROM_EVENTDATE (#52)"

to

"This test only asks if startDayOfYear is a valid value for the relevant year, not if it is consistent with the start day of the range specified in dwc:eventDate. In a non-leap year, the valid range is 1-365 inclusive, in a leap year 366 is also valid. This test should be run after the series of tests that assure that dwc:eventDate is populated, if possible (i.e., AMENDMENT_EVENTDATE_FROM_VERBATIM , AMENDMENT_EVENTDATE_STANDARDIZED, and AMENDMENT_EVENT_DATE_FROM_YEARMONTHDAY)."

For Information Elements I would remove dwc:year and instead include dwc:eventDate.

I would also remove the following from References (see issue #184),

dwc:startDayOfYear (https://rs.tdwg.org/dwc/terms/index.htm#startDayOfYear)

[Tasilee]

Thanks @tucotuco. As this is at least closer to 'reality', I'll edit as proposed, with the amendments as per #131, which it needs to align with.

[ArthurChapman]

Under #125 we go into great detail on what constitutes a Leap Year - but here we just say "start year interpreted from dwc:eventDate is a leap year"

Should we be consistent?

[ArthurChapman]

Looking back at @tucotuco's last comment - ideally we would have an order in which tests are run, but we decided against that and that every test had to be standalone.

[ArthurChapman]

Looking at the test dataset - as written leap year is only determined from dwc:eventDate - should we not include "or year".

For example - in the test data we currently have an example

dwc:dateIdentified="", dwc:day="", dwc:month="", dwc:year="2004", dwc:eventDate="", dwc:verbatimEventDate="", dwc:startDayOfYear="366", dwc:endDayOfYear="366"

@Tasilee had this as COMPLIANT - but from the wording above is INTERNAL_PREREQUISTES_NOT_MET because dwc:eventDate is EMPTY

[chicoreus]

There was a diagram we drew in Ganesville that lead us to the conclusion - test a term against eventDate, not all of the other possible places where date data might be stored. Then separately test for consistency among the Event terms, and separately try to fill in an empty eventDate from the other event terms. If we follow this pattern (as we do) across the tests, then the tests become much more easily defined, and still work well, particularly when run in pre-amendment, amendment, and post-amendment phases.

So I'd say the @ArthurChapman example from @Tasilee should indeed assert INTERNAL_PREREQUISITES_NOT_MET, not compliant.

[Tasilee]

I concur.

[ArthurChapman]

Changed Note - changed "VALIDATION_DAY_OUTOFRANGE to VALIDATION_DAY_INRANGE", added GUIDs to all the references to tests and changed "startDayOfYear" to "dwc:startDayOfYear"

[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"