TG2-AMENDMENT_DATEIDENTIFIED_STANDARDIZED about bdq HOT 38 OPEN

How about:

INTERNAL_PREREQUISITES_NOT_MET if dwc:dateIdentified is EMPTY;
AMENDED if the value of dwc:dateIdentified was not a properly
formatted ISO 8601-1 date but was unambiguous and was altered to be a
valid ISO 8601-1 date; otherwise NOT_AMENDED.

from bdq.

Counter offer...

INTERNAL_PREREQUISITES_NOT_MET if dwc:dateIdentified is EMPTY; AMENDED the value of dwc:dateIdentified if it was unambiguous and formatted as a valid ISO 8601-1 date; otherwise NOT_AMENDED

from bdq.

Paralleling the proposal in #61

Propose changing to:

INTERNAL_PREREQUISITES_NOT_MET if dwc:dateIdentified is EMPTY; AMENDED the value of dwc:dateIdentified if it was not a properly formatted ISO 8601-1 date but was unambiguous and was altered to be a valid ISO 8601-1 date;
otherwise NOT_AMENDED.

Both here and in #61 we want to amend if:

1. the existing value was not a correctly formatted data
2. the existing value was unambiguous (e.g. not a 2 digit year, not nn-nn-yyyy where nn are both below 12).
3. the value could be transformed into an ISO date.

from bdq.

Actually, making one change (adding unambigous) to conform with language in #61

From:

INTERNAL_PREREQUISITES_NOT_MET if the field dwc:dateIdentified was not present or is EMPTY; AMENDED if the value of dwc:dateIdentified was altered to conform with the ISO 8601-1:2019 date format; otherwise NOT_CHANGED

To:

INTERNAL_PREREQUISITES_NOT_MET if the field dwc:dateIdentified was not present or is EMPTY; AMENDED if the value of dwc:dateIdentified was altered to unambiguously conform with the ISO 8601-1:2019 date format; otherwise NOT_CHANGED

from bdq.

This seems wrong to me now. "dwc:dateIdentified if can be unambiguously interpreted as valid ISO 8601-1 date" says to me that dwc:dateIdentified already is a valid ISO 8601-1 date, in which case no amendment would be needed. How about,

"INTERNAL_PREREQUISITES_NOT_MET if dwc:dateIdentified is EMPTY; AMENDED the value of dwc:dateIdentified if it can be unambiguously formatted as a valid ISO 8601-1 date; otherwise NOT_AMENDED"

from bdq.

Comment by Paul Morris (@chicoreus) migrated from spreadsheet:
Corresponding ammendment for IDENTIFIED_DATE_INVALID (VALIDATION_DATEIDENTIFIED_INVALID)

from bdq.

There appears to be a copy/paste error in the specification,

EXTERNAL_PREREQUESITES_NOT_MET if the specified target source authority was not found;

This test does not involve a query on any external source authority such as a list of taxonomic names.

from bdq.

@chicoreus This probably refers to the ISO 8601-1:2019 that is needed. But you probably don't need to go to the actual Standard to use the format, so probably unnecessary. This may apply to other date tests?

from bdq.

If it doesn't have a Parameter, then there is no "specified target authority"?

from bdq.

EXTERNAL{PREREQUISITES_NOT_MET should signal that the test must connect to an external resource in order to perform the test, this test would be expected to be implemented strictly with local code that doesn't need to do a network lookup each time the test is run, so no. need for this assertion in the specification.

@Tasilee A test might have a parameter and not need to connect to an external source (such as earliest date as a parameter), or a test might specify some authority to be used by implementors (such as the ISO date format specified here), but not need to connect to an external source on each run, and it might do so with or without taking the source authority as a parameter (though I expect our likely taxonomic cases that would take a taxonmic authority as a source would typically need to do a lookup for each test run - the relationship is logical, but isn't necessaraly present).

from bdq.

@chicoreus your comment would apply to all that are tagged ISO/DCMI Standard. To date we have only used the Parameter field to define default minimum and maximums and source Authorities (the later using bdq:sourceAuthority (defalt=xxxxx)) in Paramaterized tests. Perhaps we should extend that to include standard source authorities such as ISO and DCMI Standards using bdq:sourceAuthority=ISO 8601-1:2019 etc. under the Parameter field ?? What do others think?

from bdq.

I agree with @chicoreus: If there is no (EXTERNAL) source authority, then we remove that part of the Expected Responses. Other comments?

@ArthurChapman: Hopefully quoting @chicoreus - If there is only one obvious bdq:sourceAuthority or maybe value, it is not a Parameter?

Then it is a demarcation between a bdq:sourceAuthority Parameter API-type lookup vs a Reference to a standard that the test relies on (as the latter is here). The ISO/DCMI STANDARD flag is visible evidence of the use of a particular standard but is not needed as a Parameter.

from bdq.

@ArthurChapman Parameter should not be specified for cases like this where there is a standardized source authority that implementors would be expected to embed in their code. Parameter should only be used when different use cases would call for different limits (such as a national data set wishing to use elevation/depth limits that apply to their country and a national taxonomic authority file or species list).

Issue looking good, removing the needs work label.

from bdq.

Due to recent discussions, changed

INTERNAL_PREREQUISITES_NOT_MET if dwc:dateIdentified is EMPTY; AMENDED the value of dwc:dateIdentified if it can be unambiguously interpreted as valid using bdq:sourceAuthority; otherwise NOT_AMENDED

to

INTERNAL_PREREQUISITES_NOT_MET if dwc:dateIdentified is EMPTY; AMENDED the value of dwc:dateIdentified if can be unambiguously interpreted as valid ISO 8601-1 date; otherwise NOT_AMENDED

...and also removed bdq:sourceAuthority

from bdq.

Interesting suggestion @tucotuco - I think formatted is better than interpreted here.

One decision we have to make - discussed briefly elsewhere is do we use:
ISO 8601
ISO 8601-1
ISO 8601-1:2019
ISO 8601-1:2019/Amd 1:2022

For the tests, I am inclined to just use either ISO 8601 or ISO 8601-1 this saves having to change all the tests if there is a later version of ISO 8601, and we assume that everyone will use the latest version. Incidentally the Amendment allows for midnight to be either 00:00 or 24:00 (previous versions allowed both, but ISO 8601:2019 only allowed 00:00). ISO 8601-1 is the Rules ISO 8601-2 is the Extensions

from bdq.

I like "the latest version of ISO 8601-1".

from bdq.

I like that solution @tucotuco

from bdq.

@chicoreus - do you agree with that re-wording to "the latest version of ISO 8601-1" to be applied across all relevant tests?

from bdq.

Do we have an issue as the reference remains specific:

"ISO (2019). ISO 8601-1:2019(en) Date and time — Representations for information interchange — Part 1: Basic rules (https://www.iso.org/obp/ui/)

Would it be better to simplify to using "ISO 8601-1" in the Expected Responses and refer to "latest version" in the References?

"ISO 8601-1: Latest version (currently 2019(en)) Date and time — Representations for information interchange — Part 1: Basic rules (https://www.iso.org/obp/ui/)"

?

from bdq.

I like "the latest version of ISO 8601-1" that allows the use of amendments etc. but I'd accept either way

from bdq.

I agree with Arthur. Sufficient that the user knows where to go to see what we're talking about while minimizing standard maintenance. I think this would be a good thing to recommend in DwC term change requests as well.

from bdq.

I have amended the Reference and corrected a typo in the Expected response. Please check.

from bdq.

I've edited the Expected Response according to @tucotuco suggestion:

From

INTERNAL_PREREQUISITES_NOT_MET if dwc:dateIdentified is EMPTY; AMENDED the value of dwc:dateIdentified if it can be unambiguously formatted as a valid ISO 8601-1 date; otherwise NOT_AMENDED

to

INTERNAL_PREREQUISITES_NOT_MET if dwc:dateIdentified is EMPTY; AMENDED the value of dwc:dateIdentified if it was unambiguously formatted as a valid ISO 8601-1 date; otherwise NOT_AMENDED

from bdq.

Sorry - I am not sure that the new wording reads well. How about:

INTERNAL_PREREQUISITES_NOT_MET if dwc:dateIdentified is EMPTY; AMENDED the value of dwc:dateIdentified if it could be unambiguously formatted as a valid ISO 8601-1 date; otherwise NOT_AMENDED

from bdq.

After discussion with @Tasilee - I am not sure, but can accept was. It just doesn't seem to read well. I am not sure with "was", if unambiguously is in the right place - my thinking is that if it is unambiguous (i.e. 3 April rather than 03-04) then you format it there is then nothing ambiguous or unambiguous about the formatting - if it is ambiguous (i.e. 03-04) then it is NOT_AMENDED

INTERNAL_PREREQUISITES_NOT_MET if dwc:dateIdentified is EMPTY; AMENDED the value of dwc:dateIdentified if it was unambiguous by formatting as a valid ISO 8601-1 date; otherwise NOT_AMENDED

from bdq.

I have updated the Expected Response (as suggested) and the ISO reference (and while it looks odd, it works).

from bdq.

What is the thumbs down symbol in the middle of the reference?

from bdq.

Some form of markdown I presume, but as I said, it works as a link.

from bdq.

It appears that ":-" appears as a thumbs down sign in GitHub

from bdq.

Current phrasing is not readily iterpretable by implementors. It implies AMENDED if the value already conforms, not if it has been changed to conform. Amendments should be explicit about changing values. The text "if it was
unambiguous and formatted" means to an implementor that the text was, past tense, prior to any action, unambigous and formatted (noun) in the expected form. We should be using explicit "altered to conform" not "formatted, which could be read as either the data having had that that state in the past or having been changed to that state. Other amendments need review to make sure that this form of ambiguity has not crept into them.

Very strongly recommend that we return to the previous phrasing.

Changing back from:

INTERNAL_PREREQUISITES_NOT_MET if dwc:dateIdentified is
EMPTY; AMENDED the value of dwc:dateIdentified if it was
unambiguous and formatted as a valid ISO 8601-1 date; otherwise
NOT_AMENDED

to:

INTERNAL_PREREQUISITES_NOT_MET if dwc:dateIdentified is
EMPTY; AMENDED if the value of dwc:dateIdentified was altered
to unambiguously conform with the ISO 8601-1:2019 date format;
otherwise NOT_AMENDED

from bdq.

@Tasilee my feeling is that we should reference ISO 8601-1:2019, not the latest version, as the latest version could change the nature of the specifications, with the potential of making test cases and implementations diverge. Referencing a standard set of data values (as in a list taxon names) carries with it the expectation that the data will change, and thus that test cases that test implementations are validated against may need to be changed over time without either the specification for a test or implementations of the test changing, but referencing a standard for the format of data carries the expectation that the format won't change, and that neither test cases nor implementation should change over time without a change in the specification for the test.

from bdq.

Whether that is a practical issue for latest version of ISO 8601-1 vs ISO 8601-1:2019 is another question. @ArthurChapman 's note about introduction of validity of 24:00 in a subsequent amendment is relevant....

from bdq.

Thanks @chicoreus. While your logic is good, there is repetition and therefore ambiguity. Suggest changing

INTERNAL_PREREQUISITES_NOT_MET if dwc:dateIdentified is EMPTY; AMENDED the value of dwc:dateIdentified if it was not a properly formatted ISO 8601-1 date but was unambiguous and was altered to be a valid ISO 8601-1 date;
otherwise NOT_AMENDED.

to

INTERNAL_PREREQUISITES_NOT_MET if dwc:dateIdentified is EMPTY; AMENDED the value of dwc:dateIdentified if it was not a properly formatted ISO 8601-1 date but was unambiguously interpreted as a valid ISO 8601-1 date; otherwise NOT_AMENDED.

from bdq.

from bdq.

Expected response, and Specification last updated amended accordingly. I will search for other tests that may require a change.

from bdq.

Add bdq:souceAuthority value "bdq:sourceAuthority is "ISO 8601-1:2019" [https://www.iso.org/obp/ui/]" to align with related tests.

from bdq.

Due to recent discussions, changed

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

to

bdq:sourceAuthority = "ISO 8601-1:2019" {[https://www.iso.org/iso-8601-date-and-time-format.html]}

I don't see a great need to change the references in the Expected response to bdq:sourceAuthority.

from bdq.

Splitting bdqffdq:Information Elements into "Information Elements ActedUpon" and "Information Elements Consulted"

from bdq.