-
Notifications
You must be signed in to change notification settings - Fork 7
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_POLYNOMIAL_CONSISTENT #101
Comments
See Positive description - do we need to add "scientificNameAuthorship" to fields? |
Comment by Arthur Chapman (@ArthurChapman) migrated from spreadsheet: |
Comment by Paul Morris (@chicoreus) migrated from spreadsheet: |
Comment by Arthur Chapman (@ArthurChapman) migrated from spreadsheet: |
We haven't addressed the point from @ArthurChapman that the authorship needs to be included, as scientificNameAuthorship may (incorrectly) differ from the authorship parsed out of scientificName. |
This is another one that was originally called (pre-Gainesville) "TG2-VALIDATION_SCIENTIFICNAME_INCONSISTENT". I can't see my discussion on including Authorship @chicoreus - I believe Authorship may complicate things (as the many different spellings and inconsistencies) - I am thinking that is maybe why we changed the naming of these three to POLYNOMIAL from SCIENTIFICNAME - i.e. to basically exclude authorship in the Scientific Name. |
I believe that is correct, we wanted to distinguish explicitly in the name
of the test that the authorship was not included.
…On Wed, Jun 24, 2020 at 10:15 PM Arthur Chapman ***@***.***> wrote:
This is another one that was originally called (pre-Gainesville)
"TG2-VALIDATION_SCIENTIFICNAME_INCONSISTENT". I can't see my discussion on
including Authorship @chicoreus <https://github.com/chicoreus> - I
believe Authorship may complicate things (as the many different spellings
and inconsistencies) - I am thinking that is maybe why we changed the
naming of these three to POLYNOMIAL from SCIENTIFICNAME - i.e. to basically
exclude authorship in the Scientific Name.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#101 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADQ725DWYXVTIYLNNZHDVDRYKQLVANCNFSM4EKSRXMA>
.
|
Trying to look at a test dataset for this test At present we say "INTERNAL_PREREQUISITES_NOT_MET if all of the component terms are EMPTY" but surely INTERNAL_PREREQUISITES_NOT_MET if dwc:scientificName is EMPTY and/or if dwc:genus is EMPTY. dwc:infraspecificEpithet or specificEpithet on their own are not sufficient to be able to compare Scientific Name against genus, species, infraspecies. If you have a scientificName and a genus (but no specificEpithet or infraspecificEpithet) then you can still compare |
As a followup from my last comment - you may like to look at the DRAFT test data file I have created on my interpretation |
@ArthurChapman see the description of the logic in the notes. dwc:genus can be empty and dwc:specificEpithet can still be checked against dwc:scientificName for consistency. See note in #82 these tests are along different axies in the framework, and test order is not specified, so some overlap is expected, especially in complex sets of interrelated terms like these. |
@chicoreus OK - but that still means that INTERNAL_PREREQUISITES_NOT_MET if dwc:scientificName is EMPTY or if all of dwc:genus, dwc:specificEpithet or dwc:infraspecificEpithet are empty OK - I didn't read the notes - I will change my tests data file to concur with the notes (once this discussion is finished) Interesting though, if we say that the test is COMPLIANT if you have a scientific name with Aus Bus Cus and the genus is empty and the species is empty but you have Cus in the infraspecific epithet. Would not logic say that it is NOT_COMPLIANT because the genus and species aren't compliant with the scientificName because they don't have values. |
In the light of recent discussions, I have added the specific dwc terms to the Expected Response. |
Examining test data, the following would return NOT_COMPLIANT when I think it should be INTERNAL_PREREQUISITES_NOT_MET dwc:scientificName="", dwc:genus="Hakea", dwc:specificEpithet="decurrens", dwc:infraspecificEpithet="physocarpa" ?? |
Agreed. |
OK, so could we have a taxon guru adapt the Expected response? These epithet things scare me. Names scare me. |
Agreed - probably needs rewording INTERNAL_PREREQUISITES_NOT_MET if dwc:scientificName, and all of dwc:genus, dwc:specificEpithet and dwc:infraspecificEpithet are EMPTY; COMPLIANT if the polynomial, as represented in dwc:scientificName, is consistent with the atomic parts dwc:genus, dwc:specificEpithet, dwc:infraspecificEpithet; otherwise NOT_COMPLIANT |
Hmm, maybe INTERNAL_PREREQUISITES_NOT_MET if dwc:scientificName is EMPTY, or all of dwc:genus, dwc:specificEpithet and dwc:infraspecificEpithet are EMPTY; COMPLIANT if the polynomial, as represented in dwc:scientificName, is consistent with the atomic parts dwc:genus, dwc:specificEpithet, dwc:infraspecificEpithet; otherwise NOT_COMPLIANT |
+1 to what @Tasilee said. |
1 + @tucotuco is a majority :) CHANGED |
Changed dwc:genus to dwc:genericName throughout this test in line with recent changes to Darwin Core. |
As noted by @tucotuco the acceptance of https://dwc.tdwg.org/terms/#dwc:genericName resolves the potential ambiguity of dwc:genus with it's definition as the generic placement in the taxonomy from dwc:genericName as a parse of the first word of the scientific name. |
In the Expected Response ..."COMPLIANT if the polynomial, as represented in dwc:scientificName, is consistent with the atomic parts dwc:genericName, dwc:specificEpithet, dwc:infraspecificEpithet" do we need the words "with the atomic parts" Would not: "COMPLIANT if the polynomial, as represented in dwc:scientificName, is consistent with dwc:genericName, dwc:specificEpithet, dwc:infraspecificEpithet" be sufficient |
Are all happy with the specifications on this one now? |
…rrent TG2 Specifications. DESCRIPTION: Adding an implementation of VALIDATION_POLYNOMIAL_CONSISTENT along with unit test. Closing gbif parser instances to prevent resource leaks (need to move to centralized management of gbif parser for threading).
…ntation of tdwg/bdq#101 VALIDATION_POLYNOMIAL_CONSISTENT, also adding test cases from current validation data csv file that were failing, along with commented out case that may be in error in the validation data. Conforming implementation of tdwg/bdq#121 VALIDATION_TAXONID_COMPLETE to current specification for handling empty taxonID, also adding test cases from current validation data csv file that were failing. Fixing methods that should be static but aren't.
Getting this 'on the record' for all to consider: Email with @chicoreus yesterday. I suggested for the Expected Response- INTERNAL_PREREQUISITES_NOT_MET if dwc:scientificName is EMPTY, or all of dwc:genericName, dwc:specificEpithet and dwc:infraspecificEpithet are EMPTY; COMPLIANT if the polynomial, as represented in dwc:scientificName, is consistent with NOT_EMPTY values of dwc:genericName, dwc:specificEpithet, dwc:infraspecificEpithet; otherwise NOT_COMPLIANT. @chicoreus response: "That is more explicit that the current separate (and not formalized yet) general guidance on handling "consistent". But if we we are explicit in this way here, we may need to be in other tests invoking "consistent"." Thoughts? |
I like it, but not sure of other implications |
After discussion on the Zoom today, we agreed that using the current Test Data format for examples would seem expedient. We also previously agreed that a "COMPLIANT" and "NOT_COMPLIANT" or equivalents was appropriate. I think the examples of INTERNAL/EXTERNAL_PREREQUISITES_NOT_MET would be overkill here? What I have added in Examples is a for a check on formatting. |
I don't see how the test can accommodate for interpolated names part of a polynomial dwc:scientificName. |
@chicoreus ? We need your expertise on this question. This may also need to be another general principle? |
…tdwg/bdq specifications. Updated metadata (added ProvidesVersion and Specification) for tdwg/bdq#77 tdwg/bdq#83 tdwg/bdq#28 tdwg/bdq#101 VALIDATION_POLYNOMIAL_CONSISTENT. Updated metadata. removing reviewed stub method. Added test cases to conirm expected NOT_EMPTY comparison behavior.
…ISTENT revealed from investigation of failure case for validation dataID 125. Fixing handling of comparisons with isEmpty rather than comparing to empty string, adding handling of parser returing a uninomial.
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" |
…h current specification, adding a couple of simpler regex cases for evaluation without invoking parser, adding unit test cases matching examples in the issue.
The text was updated successfully, but these errors were encountered: