TG2-AMENDMENT_YEAR_STANDARDIZED

[pzermoglio]

TestField	Value
GUID	baf2a90b-af45-4f1a-839f-47126743a48a
Label	AMENDMENT_YEAR_STANDARDIZED
Description	Attempt to amend the year
TestType	Amendment
Darwin Core Class	Event
Information Elements ActedUpon	dwc:year
Information Elements Consulted
Expected Response	INTERNAL_PREREQUISITES_NOT_MET if the field dwc:year is bdq:Empty or if the predefined default value is bdq:Empty; AMENDED if the value of dwc:year is unambiguously interpreted to be an integer less than the current year, and optionally not extending before a year designated when the test is run; otherwise NOT_CHANGED
Data Quality Dimension	Conformance
Term-Actions	YEAR_STANDARDIZED
Parameter(s)	Default value for minimum year = 1753
Source Authority
Specification Last Updated	2024-02-23
Examples	[dwc:year="MCMXVII": Response.status=AMENDED, Response.result=dwc:year="1917", Response.comment="The text in year was able to be amended to a valid value"]
	[dwc:year="X": Response.status=_NOT_AMENDED, Response.result="", Response.comment="The text in year was not able to be amended to a valid value"]
Source	TG2-Gainesville
References	http://rs.tdwg.org/dwc/terms/index.htm#year
Example Implementations (Mechanisms)	Kurator/FilteredPush event_date_qc Library
Link to Specification Source Code
Notes

[chicoreus]

It doesn't feel like there is sufficient information here to implement. Is this only a translation from roman numerals into a 4 digit integer? What values exist in the wild which could be translated with little ambiguity? Would a roman numeral in the range I to XII be translated to a year near 0, or would these be more likely seen as errors placing a roman numeral month in the year term?

[ArthurChapman]

Perhaps needs someone to extract what variations occur in dwc:year and decide then if worth keeping this test

[Tasilee]

This does beg the question on what text/number would be interpreted and transformed to a valid year. I had a scan of what is currently in dwc:year in the ALA and no 'odd' entry could be 'standardized' (as they may have already been 'processed'). Here are the first numbers

EMPTY | 3743922
1 | 21
2 | 69
3 | 59
4 | 50
5 | 49
6 | 30
7 | 30
8 | 47
9 | 33
10 | 67
11 | 61
12 | 35
13 | 1
18 | 1
20 | 3
30 | 2
31 | 1
195 | 1
313 | 4
612 | 1
1008 | 7
1193 | 2
1208 | 1
1629 | 1
1634 | 12
1636 | 1
1648 | 1
1652 | 2
1654 | 1
1668 | 2
...

[Tasilee]

After 'sleeping on this' for a while, I'm inclined to agree with @chicoreus. The test seems to have little utility except for the odd Roman numeral, which we would hopefully flag. While this will lose @pzermoglio symmetry, rationality should prevail? Any strong arguments before I close this one. One less test?

[ArthurChapman]

I agree Lee - leave as DO NOT IMPLEMENT at this stage - if someone comes up with good examples (can't think of any) at a later date - it can always be reinstalled. I am sure there are other tests like that (probably in the SUPPLEMENTAL).

[ArthurChapman]

I still have some problem with this one. I can see the direct translation from roman numerals and I am happy for it to remain, but there are a couple of things I do not understand as we have it written.

e.g. What is the “Pre-defined default value” that we mention? It is listed as Parameterized – what parameter needs to be set? (I guess for the predefined default value - but what is this default value - I can't possibly see how we can have a default value for a year (is it the current year?) - I don't understand!

[Tasilee]

I have to agree @ArthurChapman as I noted previously.

[chicoreus]

I also still have problems with this one. @ArthurChapman I think the pre-defined value is attempting to get around the risk of interpreting months as a year. A pre-defined value that is taken as the minimum possible year to translate might be a value such as 1000 or 1700, and XII, translating to 12, would fall below this threshold and not be translated. I think that was the intent. Still problematic, and I find @Tasilee 's list of values in the wild good evidence for not implementing this one.

[Tasilee]

Forget any concept of defaults. We cannot LOWER the 'quality' by making an AMENDMENT that may be a guess. IF (and it is a guess at this point) we can only interpret Romans, I suggest we are better off with one less 'test'

[ArthurChapman]

In discussion with @Tasilee - the only examples we can think of are translations from Roman years. Is it likely that there are significant numbers of these? (i.e. can we do a search of GBIF/iDigBio/VertNet to see if this occurs). There do not appear to be any cases in the ALA. If it is not a common occurrence, @Tasilee and I believe we should remove this test

[Tasilee]

...and remember that we have the VALIDATION anyway. Best leave it at that.

[chicoreus]

@Tasilee I concur.

[tucotuco]

There are no instances of Roman years in VertNet. @Tasilee I concur with dropping the test.

[chicoreus]

This test is still showing up in the csv generated from the issues by bdq_issue_to_csv code, adding the do not implement label back in as this appears to be the consensus.

[Tasilee]

@chicoreus - We have previously 'Closed' test issues when we have judged them as not being CORE. That way, such issues won't by default turn up on dumps. The history of such actions will still be available. What do others think? We should try for consistency wherever possible.

[ArthurChapman]

Should Parameter be earliest year (not minimum year) and note that #141 has "Default values: earliest year = 1600" - we have an inconsistency

[Tasilee]

@ArthurChapman - we also have reference to 'begin' and 'end years' in #141

[Tasilee]

Specifications updated to align with the current template