Code Table Request - make "scientificNameID" an identification attribute value #6532
Closed
1 of 8 tasks
Labels
Aggregator issues
e.g., GBIF, iDigBio, etc
Enhancement
I think this would make Arctos even awesomer!
Function-CodeTables
Function-Taxonomy/Identification
Priority-High (Needed for work)
High because this is causing a delay in important collection work..
Milestone
Comments
genevieve-anderegg
added
Function-CodeTables
Function-Taxonomy/Identification
Enhancement
|
@Jegelewicz @dustymc @sharpphyl Please edit as needed |
|
Before proceeding (unless there's some other reason to proceed, this request seems fine by itself), see if this can be magicked out of data as a column in DWC. Next release will cache all "classification as preferred by collection for involved names" data with the record, so this will become accessible (but may require more resources than we have to extract - it won't necessarily be flat or predictable, particularly at scale). Also worth exploring, particularly if this turns out to be nontrivial to extract as part of the all-Arctos DWC packaging:
EDIT: added classification_id Example: https://arctos-test.tacc.utexas.edu/guid/DMNS:Inv:23162 
|
Jegelewicz
added
the
Priority-High (Needed for work)
Closed
|
I don't think we can expect anyone to find and associate that with dwc: scientificNameID. We are going to have to do that and present it directly as "dwc:scientificNameID":"urn:lsid:marinespecies.org:taxname:857376" I don't know the most efficient way to do it, but this is what we need to do. I also think that asking every publishing collection to run a script or do some OpenRefine task every month in order to publish to OBIS makes Arctos even more difficult to use. This seems like it deserves a technical solution - not a manual one. One thing seems like it should be easy. We should be able to pass the "Arctos Identifier" for a given classification in dwc:scientificNameID. If that worked something like Sorry for rambling - this may all be pie-in-the-sky or complete nonsense, just thought I'd lay it out here for consideration. |
That may be the compelling reason to NOT do #6532 (comment) (make this my problem) and DO do #6532 (comment) (initial request, require collections to specify). Just considering the possibility of trying to extract a single value out of what's going to be possible as identifications (which isn't what you said, I hadn't even considered that possibility) is making my head hurt!
It's the social aspect I'm worried about, but there's a technical bit too. I assume the technical bits would be straightforward (albeit probably resource-hungry) given a sufficiently-robust description of what's needed.
There is no "the" - these data (as I understand them, which might be just wrong) assume a very limited relationship between catalog records and taxon names. Arctos has no such limitations.
It is possible to make identifications to names with no classifications from preferred sources (eg
Next release includes them in the cache, not sure how that could be seen as anything but using them! |
|
What a timely discussion we had this week - see tdwg/dwc-qa#203 and despair. |
So will we still be able to implement what we discussed in this issue? |
Ugh, Arctos isn't that simple!
Three things:
|
What happens when there are multiple identifications? a complex ID (A x B or A or B)? |
|
This isn't some off-topic thing. This is an important part of the DES. Being able to unambiguously point to a taxon name AND it's classification is something we should be supporting. |
Exactly! I'm already including those data in the only container than can carry them. (It can be shaped differently, but it can't be simplified without losing functionality.) You're asking me to do some impossible task and smoosh 'em all into a single container. (And the linked discussion is asking for information that I can't possibly have - how the heck would I know - or care! - why someone's involved some taxon in some identification!?) I'm trying - not very successfully - to balance those clearly conflicting goals. The ONLY possible way I can see to do that is to have the user pick some taxon and just roll with it, and record attributes are a convenient place to store the results of that flattening.
Then why is everyone refusing to deal with the actual data?! I don't think "this is important!" and "must stuff it into a spreadsheet cell" are in any way compatible.... |
We are trying to use the ACTUAL DATA but there is nowhere to put it in Arctos! |
That is absolutely not true. https://arctos.database.museum/guid/DMNS:Inv:21694 for example: |
|
OK - so it is there - how do we get it into dwc:scientificNameID? This is all we are asking for. |
|
AWG discussion
right? |
|
I think this is working as proposed at test, but it's near impossible to test at scale at the moment (growing pains...) - I'm relatively sure the cost isn't going to be prohibitive in prod, but that needs confirmed before this is closed. I updated https://arctos-test.tacc.utexas.edu/guid/DMNS:Inv:11276 (one order>0 ID) and https://arctos-test.tacc.utexas.edu/guid/DMNS:Inv:10808 (>1 order>0 ID), which results in.... |
Is the record at test supposed to show the LSID as a separate field or is it all behind the scenes? And do we need to do anything except check all the homonyms that OBIS excluded and make sure WoRMS (via Arctos) has the correct URL/LSID selected? I cleaned up https://arctos.database.museum/guid/DMNS:Inv:21694 referenced above. I have no idea how that happened but thanks for pointing it out. |
Sorta? Like all "flattened terms" it'll be a concatenation of select taxa-stuff used in accepted identifications, and you can see that on the guid pages by clicking the eyeballs 
It'd be nice to know if I'm doing something useful before I do it in production, but I'm also not sure what I'd do about it if I'm not. (Took us long enough to get here!) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Initial Request
Goal
As discussed in Taxonomy Committee today:
#4776 #5814 #5814 (comment)
Be able to link LSIDs to catalog records (vs a classification) so that database aggregators (OBIS) can directly read the LSID (which is already stored in the classification metadata in the WoRMS via Arctos taxonomy source) instead of relying only on the scientific name, which omits taxon concept data
Context
This value will allow scientific name IDs to be directly linked to catalog records. This will allow OBIS to distinguish between homonyms #4794, which it currently cannot and is currently limiting the publishing of hundreds of DMNS:Inv records to OBIS. Currently the LSID is contained within the JSON in a catalog record, and @dustymc may be able to extract it and present it to the IPT after the next release #6518 , but by manually pushing the LSID to aggregators we can determine how the data are behaving. Additionally, this capability may become increasingly necessary with initiatives such as Ocean Genome Legacy #4776 (comment)
Table
(forthingcoming in next release) https://arctos-test.tacc.utexas.edu/info/ctDocumentation.cfm?table=ctidentification_attribute_code_tables
Proposed Value
scientificNameID
Proposed Definition
https://dwc.tdwg.org/list/#dwc_scientificNameID
An identifier for the nomenclatural (not taxonomic) details of a scientific name.
Collection type
All
Attribute Extras
Attribute data type
Free text
Attribute units
None
Priority
A method for linking LSID (and other scientificnameIDs) to catalog records will likely become more and more necessary. Piloting methods for doing that are of medium importance. Useful!
Example Data
Requests with clarifying sample data are generally much easier to understand and prioritize. Please attach or link to any representative data, in any form or format, which might help clarify the request.
Available for Public View
Yes
Helpful Actions
Add the issue to the Code Table Management Project.
Please reach out to anyone who might be affected by this change. Leave a comment or add this to the Committee agenda if you believe more focused conversation is necessary.
@ArctosDB/arctos-code-table-administrators
Approval
All of the following must be checked before this may proceed.
The How-To Document should be followed. Pay particular attention to terminology (with emphasis on consistency) and documentation (with emphasis on functionality). No person should act in multiple roles; the submitter cannot also serve as a Code Table Administrator, for example.
Rejection
If you believe this request should not proceed, explain why here. Suggest any changes that would make the change acceptable, alternate (usually existing) paths to the same goals, etc.
Implementation
Once all of the Approval Checklist is appropriately checked and there are no Rejection comments, or in special circumstances by decree of the Arctos Working Group, the change may be made.
Review everything one last time. Ensure the How-To has been followed. Ensure all checks have been made by appropriate personnel.
Add or revise the code table term/definition as described above. Ensure the URL of this Issue is included in the definition.
Close this Issue.
DO NOT modify Arctos Authorities in any way before all points in this Issue have been fully addressed; data loss may result.
Special Exemptions
In very specific cases and by prior approval of The Committee, the approval process may be skipped, and implementation requirements may be slightly altered. Please note here if you are proceeding under one of these use cases.
The text was updated successfully, but these errors were encountered: