Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TG2-VALIDATION_ENDDAYOFYEAR_INRANGE #131

Open
pzermoglio opened this issue Jan 19, 2018 · 18 comments
Open

TG2-VALIDATION_ENDDAYOFYEAR_INRANGE #131

pzermoglio opened this issue Jan 19, 2018 · 18 comments
Labels
Conformance CORE TG2 CORE tests Test Tests created by TG2, either CORE, Supplementary or DO NOT IMPLEMENT TG2 TIME Validation

Comments

@pzermoglio
Copy link
Member

pzermoglio commented Jan 19, 2018

TestField Value
GUID 9a39d88c-7eee-46df-b32a-c109f9f81fb8
Label VALIDATION_ENDDAYOFYEAR_INRANGE
Description Is the value of dwc:endDayOfYear an integer between 1 and 365 inclusive, or 366 if a leap year?
TestType Validation
Darwin Core Class dwc:Event
Information Elements ActedUpon dwc:endDayOfYear
Information Elements Consulted dwc:eventDate
Expected Response INTERNAL_PREREQUISITES_NOT_MET if dwc:endDayOfYear is bdq:Empty or if the value of dwc:endDayOfYear is equal to 366 and (dwc:eventDate is bdq:Empty or the value of dwc:eventDate cannot be interpreted to find a single year or an end year in a range); COMPLIANT if the value of dwc:endDayOfYear is an integer between 1 and 365 inclusive, or if the value of dwc:endDayOfYear is 366 and the end year interpreted from dwc:eventDate is a leap year; otherwise NOT_COMPLIANT
Data Quality Dimension Conformance
Term-Actions ENDDAYOFYEAR_INRANGE
Parameter(s)
Source Authority
Specification Last Updated 2023-09-18
Examples [dwc:eventDate="1949-01-15T12:34/1949-01-20T17:00", dwc:endDayOfYear="20": Response.status=RUN_HAS_RESULT, Response.result=COMPLIANT, Response.comment="dwc:endDayOfYear is in range"]
[dwc:eventDate="", dwc:endDayOfYear="x": Response.status=RUN_HAS_RESULT, Response.result=NOT_COMPLIANT, Response.comment="dwc:endDayOfYear is ambiguous, either "X" or "No data" or "10"]
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#L888 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:endDayOfYear is a valid value for the relevant year, not if it is consistent with the end 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)).
@tucotuco tucotuco changed the title TG2-VALIDATION_STARTDAYOFYEAR_OUTOFRANGE TG2-VALIDATION_ENDDAYOFYEAR_OUTOFRANGE Jan 19, 2018
@ArthurChapman ArthurChapman added Test Tests created by TG2, either CORE, Supplementary or DO NOT IMPLEMENT and removed NEEDS WORK labels Jan 19, 2018
@chicoreus
Copy link
Collaborator

chicoreus commented Jan 25, 2018

Expanding the set of information elements to include dwc:eventDate as a field consulted is problematic (the test has to include logic to assess priority or consistency of the year and the event date and has to understand how to extract a year from an event date (which may be a range of years). This test should examine only relevant elements in the cluster year/startDayOfYear/endDayOfYear (to work with #132) and leave assessment of consistency with eventDate to the general event consistency validation test #67. This test should be phrased in similar terms to #130

@Tasilee
Copy link
Collaborator

Tasilee commented Jan 28, 2018

I agree with Paul that given noted dependency of a prior run #52, we should not be referencing dwc:eventDate.

@chicoreus
Copy link
Collaborator

Using year instead of eventDate has an unintended consequence in interaction with #52 in cases where the eventDate spans more than one year, the end of the range is Dec. 31, and the start year does not have a leap day and the end year has a leap day, such that a filled in year is the start year, while the filled in endDayOfYear is 366.

We may be able to resolve this without changing the definition of this test (as noted above, we explicitly chose year instead of having to parse eventDate for an endYear), by modifying #52.

chicoreus added a commit to FilteredPush/event_date_qc that referenced this issue Aug 29, 2019
…harness following Arthur Chapman's iterative reviews of the results of test runs. DESCRIPTION: Fixed a bug in Runner where non-null Event terms were being overwritten with nulls on invocation of amendmentEventFromEventDate. Fixed bugs in validationDateidentifiedNotstandard resulting from copy/paste errors and changed logic. Fixed some other bugs, added a unit test, results now appear sane.
@Tasilee
Copy link
Collaborator

Tasilee commented Aug 29, 2019

@chicoreus: Agreed and edited #52 accordingly

@Tasilee
Copy link
Collaborator

Tasilee commented Apr 6, 2020

I have amended the Expected response to "INTERNAL_PREREQUISITES_NOT_MET if the fields dwc:year or dwc:endDayOfYear year are EMPTY; COMPLIANT if the value of the field dwc:endDayOfYear is a valid day given dwc:year; otherwise NOT_COMPLIANT".

I think this doesn't need more work?

@Tasilee Tasilee removed the NEEDS WORK label Apr 6, 2020
@tucotuco
Copy link
Member

tucotuco commented Apr 8, 2020

The current Expected Response "INTERNAL_PREREQUISITES_NOT_MET if dwc:endDayOfYear is EMPTY; COMPLIANT if the value of dwc:endDayOfYear is a valid day for (1) the year of dwc:eventDate if dwc:eventDate is single date or, (2) end year of a range in dwc:eventDate if dwc:eventDate contains a range; otherwise NOT_COMPLIANT" looks right to me.

@tucotuco
Copy link
Member

tucotuco commented Apr 8, 2020

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

"INTERNAL_PREREQUISITES_NOT_MET if dwc:endDayOfYear is EMPTY; COMPLIANT if the value of dwc:endDayOfYear is a valid day for (1) the year of dwc:eventDate if dwc:eventDate is single date or, (2) end year of a range in dwc:eventDate if dwc:eventDate contains a range; otherwise NOT_COMPLIANT"

with

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

I would change the example from

dwc:endDayOfYear="367" with dwc:year="2017"

to

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

I would change the Note from:

"This is part of a group of similar tests (#125#130#131). Unlike #130 where dwc:startDayOfYear pairs with dwc:year, dwc:endDayOfYear reflects the end day of a date range present in dwc:eventDate, and thus makes the comparison with eventDate rather than year. Note that this test only asks if endDayOfYear is a valid value for the relevant year, not if it is the end day of the range specified in dwc:eventDate. In non-leap years, the values will be 1-365 inclusive, in leap year 1-366 inclusive, thus for both this test and #130, a year must be examined for values of 366. This test should be run after the test TG2-AMENDMENT_EVENT_FROM_EVENTDATE (#52)"

to

"This test only asks if endDayOfYear is a valid value for the relevant year, not if it is consistent with the end 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)."

Information Elements already includes dwc:eventDate. This is good.

I would also remove the following from References

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

Not only does it not resolve (the correct link is https://dwc.tdwg.org/terms/#dwc:endDayOfYear), but also we do not systematically include Darwin Core term links in References. Not sure why there should be an exception here.

@chicoreus
Copy link
Collaborator

I like everything @tucotuco is proposing.

Perhaps make the example or add an example:

dwc:endDayOfYear="366" with dwc:eventDate="2014/2015"

@ArthurChapman
Copy link
Collaborator

@tucotuco There are a number of References that reference a Darwin Core Term. I wondered when I did the references why they were there, but usually, it was where there was a definition that may be valuable in the references. Most occur where there are no other references. I can go through and delete these if it is thought that is what we should do.

@Tasilee
Copy link
Collaborator

Tasilee commented Apr 8, 2020

The Gods have spoken. I will edit this one accordingly and add the additional example.

@ArthurChapman on References: I defer to the Gods.

@Tasilee
Copy link
Collaborator

Tasilee commented Apr 8, 2020

I have edited the expected response, and in doing so a) removed a comma and b) removed the "See test VALIDATION_DAY_OUTOFRANGE" to the Notes as it won't be canonical I presume. This may however need a tad more context now?

Second example added.

@tucotuco
Copy link
Member

tucotuco commented Apr 8, 2020

@Tasilee Note that I made a few amendments to my last comment right after I first submitted it, so use that rather than any comment received by email.

@ArthurChapman
Copy link
Collaborator

This one looks good - I think the Example needs looking at - I don't think we need "with dwc:year="2017"". Otherwise I am happy with this and "Needs Work" can be removed once fixed.

@Tasilee
Copy link
Collaborator

Tasilee commented Apr 13, 2020

Thanks @ArthurChapman. If dwc:year is indeed no longer an Information element, I will remove that example.

@ArthurChapman
Copy link
Collaborator

See comments (09 Feb 2022) under Test #130

chicoreus added a commit to FilteredPush/event_date_qc that referenced this issue Mar 11, 2022
…t specifications. DESCRIPTION: Updating implementation of VALIDATION_ENDDAYOFYEAR_OUTOFRANGE to updated (2022-03-10) specification, adding and fixing unit tests to confirm with current specification. Removing instead of deprecating and using as wrapper previous isEndDayOfYearInRangeForYear() method, as it takes year instead of eventDate and can't conform to the current specification.
@Tasilee Tasilee changed the title TG2-VALIDATION_ENDDAYOFYEAR_OUTOFRANGE TG2-VALIDATION_ENDDAYOFYEAR_INRANGE Mar 22, 2022
@ArthurChapman
Copy link
Collaborator

Changed Note - changed "VALIDATION_DAY_OUTOFRANGE to VALIDATION_DAY_INRANGE" and added GUIDs to all the references tests

@ArthurChapman
Copy link
Collaborator

Also changed "endDayOfYear" in nNotes to "dwc:endDayOfYear"

@Tasilee
Copy link
Collaborator

Tasilee commented Sep 18, 2023

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"

@chicoreus chicoreus added the CORE TG2 CORE tests label Sep 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Conformance CORE TG2 CORE tests Test Tests created by TG2, either CORE, Supplementary or DO NOT IMPLEMENT TG2 TIME Validation
Projects
None yet
Development

No branches or pull requests

6 participants