search

plazi / arcadia-project

2 stars 1 forks source link

meeting skype 20190924: treatment loose ends #97

Open myrmoteras opened 5 years ago

myrmoteras commented 5 years ago

Skype Tuesday 10:00 am, @gsautter @slint @myrmoteras

Agenda:

myrmoteras commented 5 years ago
myrmoteras commented 5 years ago

@tcatapano @mguidoti @slint can we agree to add this custom element for a taxon concept name https://github.com/plazi/arcadia-project/issues/46#issuecomment-494194212 "custom": { "obkms:taxonomicConceptLabel" : "Sphaerocysta globifera (Stal, 18xx) sec. Guidoti, 2019"

@gsautter is this doable from your side?

Please respond asap so, if it is feasable, can be added to the release of fixes to the taxonomic treatment by tomorrow

mguidoti commented 5 years ago

Hi @myrmoteras,

Yes, I think we'd agreed in this custom element for the taxon concept label, and that we would add it to every treatment. Guido, however, needed to see some examples on how to build the taxon concept label, which I can start working on if you will.

Moreover, two remaining decisions, related to this, are still pending:

1) Can we add the concept label in the GGI xml as well? 2) Can we add to the RDF, so Reto can readily access these labels and use in his apps (including the synospecies)?

Let me know if you want me to work on the document for @gsautter right now.

Best,

myrmoteras commented 5 years ago

@mguidoti write this up so we can make us of it.

  1. For the GGI: what does @gsautter suggest
  2. For the RDF: @gsautter reto and @tcatapano has to come to a conclusion
mguidoti commented 5 years ago

Ok, I'll work on this after lunch.

For the 2., please, keep in mind: synospecies has a big issue with taxa labels as right now, because Reto is building that string from a url included in the RDF (@gsautter can provide details). As right now, the issue jumps to the eye of the end user (taxonomist) because it creates artifacts that doesn't follow the nomenclatural code correctly, which is a pretty easy problem to catch/observe. By providing the taxon concept label in the RDF, Reto would be able to just use it, no string computing necessary and therefore, no further problems/mistakes. That's the rationale behind this suggestion.

One other side note: synospecies is, thus far, the most promissing tools using Plazi's data for taxonomists. That's important, in my opinion.

The rationale of making this available on the GGI xml is similar: to whoever is going to use the XML latter, the label will be readily available in there, no computing or understanding of taxonomy and its codes necessary.

gsautter commented 5 years ago

Regarding the RDF: should I hash the URI strings so they don't look "slightly off" any more? Would be completely insensible because it would (a) vastly complicate debugging, (b) incur the risk of hash collisions, and (c) complicate RDF generation, as there is no hashing functionality in XSLT. But I see the point, looks are everything.

They are really just intended as URI strings, the actual data comes up when you resolve them. I'd like to include the treatment label in the latter. But in the URIs, it's even better to keep the current form, so because it readily makes treatments of the same taxon concept meet under the same URI (e.g. a description and two inventory entries adding new occurrence data). The latter is the very reason we designed it the way it is.

myrmoteras commented 5 years ago

@mguidoti please do not confuse what is meant for machines with what is meant for human consumption. Lets focus on the label we need for now, and then get into the RDF together with Reto and Guido to understand its purpose.

mguidoti commented 5 years ago

Ok, but I honestly don't think I'm confusing what's for humans or machines.

Reto gets his data from the RDF, and he builts the string out of the URI (he doesn't load any metadata by resolving it). That's what he showed me (or I misundertood him).

On the other hand, labels can be useful for machines as well, which would make yet for another argument for adding to the RDFs.

I think this discussion is entirely within the scope of your initial question, and I think by postponing it, we might forget about this. But I'll not say anything else.

Working on the examples for Guido...

tcatapano commented 5 years ago

Yes, we want this. But it needs to be added as a custom element/schema on the Zenodo side, which we've requested. Let's follow up with Alex for the status

/Terry

myrmoteras commented 5 years ago

@slint can you please add as discussed this morning the following:

"custom": {
"obkms:taxonomicConceptLabel"
slint commented 5 years ago

@mguidoti @tcatapano Sure, we can add the field. Is there a vocabulary schema online, in a similar way as we have for DWC? The idea is to be able to render a link like e.g "https://obkms.org/terms/taxonomicConceptLabel".

myrmoteras commented 5 years ago

All I know https://github.com/vsenderov/openbiodiv-o/blob/master/openbiodiv-ontology.Rmd#L632 I guess not what's needed..

mguidoti commented 5 years ago

I think @tcatapano will solve that one for us.

tcatapano commented 5 years ago

@slint : the schema repo is here:

https://github.com/pensoft/OpenBiodiv

and the ontology is documented here:

http://openbiodiv.net/ontology

and in fact, since it employs literate programming practices, self documents here:

https://github.com/pensoft/OpenBiodiv/blob/master/ontology/openbiodiv-ontology.Rmd

and a derived turtle version of the ontology usable by machines is here:

https://raw.githubusercontent.com/pensoft/OpenBiodiv/master/ontology/openbiodiv-ontology.ttl

however, following the URI for the ontology term "http://openbiodiv.net/TaxonomicConceptLabel" will not actually resolve to anything on the web, though it is defined in the above turtle ontology

slint commented 5 years ago

Something I've seen being done in other definition pages is using an anchor tag (#) followed by the term, which basically jumps to the specific term in the page.

It would then be possible if the generated HTML on the http://openbiodiv.net/ontology page included an id=TaxonomicConceptLabel attribute, to generate a link like http://openbiodiv.net/ontology#TaxonomicConceptLabel. Currently the id attribute has the value id=user-content-class-taxonomic-concept-label which make e.g. the link http://openbiodiv.net/ontology#user-content-class-taxonomic-concept-label work. It would be fine on our side to add the obkms:taxonomicConceptLabel, if eventually, the generated link would properly "resolve" using the anchor. I guess @teodorgeorgiev (or Pensoft in general), might have some input on that.

Another small but important detail would be to discuss the capitalization of the terms. In Darwin Core, terms are camel-cased (i.e. collectionCode vs. CollectionCode). In the OpenBiodiv ontology the terms are Pascal-cased (i.e. TaxonomicConceptLabel vs. taxonomicConceptLabel). If that is the case (:man_facepalming:), then the correct term would be obkms:TaxonomicConceptLabel.

If we can agree on these two points, we can proceed with adding the obkms:TaxonomicConceptLabel custom term with http://openbiodiv.net/ontology# as the vocabulary's URL in Zenodo.

mdmtrv commented 5 years ago

Hi all! I (Mariya from Pensoft) am jumping late in this discussion but hopefully not too late to note a few things. Regarding capitalisation: every resource type in the OpenBiodiv ontology having an uppercase first letter openbiodiv:TaxonomicConceptLabel) is a class and everything with a lowercase first letter (e.g. openbiodiv:taxonomicConceptLabel) is a property in ontology terms. AFAIK, it's the same in Darwin Core.

Also, some of you mentioned obkms:taxonomicConceptLabel but maybe you meant openbiodiv:TaxonomicConceptLabel ?

mdmtrv commented 5 years ago

@slint The anchor tags have been changed now and http://openbiodiv.net/ontology#TaxonomicConceptLabel resolves correctly. I also changed all other tags in the same way.

myrmoteras commented 4 years ago

@gsautter @slint did you add the taxonomicConceptLabel to the custom metadata?

gsautter commented 4 years ago

Not yet on my end, waiting for a green light from @slint , as otherwise I'd produce incorrect metadata that would end up being rejected by the Zenodo API.

slint commented 4 years ago

Yes, it has been added to the custom keyword fields in the API. You can now also submit under the openbiodiv:TaxonomicConceptLabel (note that casing is important).

gsautter commented 4 years ago

Implemented, a first example is https://sandbox.zenodo.org/record/461836 ... let me know whether or not this is OK, and if so, I'll deploy the extended uploader and update all the treatments we have thus far.

myrmoteras commented 4 years ago

Shouldn't the value for 'taxonConcept Label be "syn. nov."?

tcatapano commented 4 years ago

@myrmoteras No, that would be the taxon status or something like that. The TaxonomicConceptLabel is the full, proper taxonomic name for a concept.

tcatapano commented 4 years ago

@myrmoteras

see the definition at: http://openbiodiv.net/ontology

Class: Taxonomic Concept Label

We further introduce the class of taxonomic concept labels, unknown to NOMEN that is a biological name plus a reference to its description, i.e. it is the label of taxonomic concept. A taxonomic concept label is a taxonomic name usage accompanied by an additional part, consisting of "sec." + an identifier or a literature reference of a work containing the expression of a taxonomic concept (for example a treatment).*

:TaxonomicConceptLabel rdf:type owl:Class ; 
rdfs:subClassOf :LatinName ; 
rdfs:label "Taxon Concept Label"@en ; 
rdfs:comment "A taxon concept label is a taxonomic name usage accompanied by an additional part, consisting of 'sec.' + an identifier or a literature reference of a work containing the expression of a taxon concept (treatment)."@en .
mguidoti commented 4 years ago

Two things that I don't quite remember what were the decisions made:

  1. Are we going to keep both dwc:eventDate and dwc:verbatimEventDate? I'm asking because they are showing the same information (in a slightly different manner), and thus, might pollute the view for the user.

  2. Aren't we going to present the custom metadata related to taxonomic ranking in a logical order (kingdon... genus... species) ?

The openbiodiv:TaxonomicConceptLabel looks great.

myrmoteras commented 4 years ago

I messed it up: not taxonomicConceptLabel, but treatentCiationLabel: which indicates that in this treatment there is a synonymy happening.

I thought we wanted to include it too.

I agree with Marcus, the taxonomicConceptLabel looks good

gsautter commented 4 years ago

Great, thanks for taking a look. Now I have a few additional questions:

mguidoti commented 4 years ago

Hi Guido,

I'll try my best to answer your questions:

  1. For original descriptions the TaxonomicConceptLabel would be just the Taxon Author, Year (e.g., Traumatomutilla ocellaris Klug, 1821). The 'sec.' part is not needed. So your current implementation is correct.

  2. I wouldn't add 'subsp.' because, for the code, this doesn't exist (to the best of my knowledge). It would just Aus bus cus, in your example, for the species name. Authority and 'sec.' part would follow the same rules.

  3. No, the label shouldn't include information regarding any status change or status in general, just the taxon, the authority of the taxon and the authority of the treatment. This means that if a taxon was described by A, transferred to a different genus by B (comb. nov.), and is being redescribed by C, only A and C should be included in this given TaxonomicConceptLabel. Parenthesis on the basionym author, on the other hand, makes sense because it has meaning defined/described by the code in the case of the Zoological code.

  4. The same logic applies, I guess. Taxon Author, Year sec. Author-of-treatment, Year.

gsautter commented 4 years ago

@mguidoti (1) OK, then that's fine. (2) Agreed maybe for subspecies, but then what to do about varieties, etc.? Keep in mind that we also need to handle botany, where there are a lot more ranks below species than in zoology even in the current codes ... (3) OK, implemented with the parentheses now for the (A) B sec. C case ... but then, there are a few more things to consider: (3.1) How about the treatment that performs the "comb. nov." acts? Reusing your authors A, B, and C, should that be (A) sec. B or simply (A) B? In fact, I'd prefer the latter, simply because it is distinct from the downstream (A) sec. C case in that B does perform a nomenclatorial act and thus doesn't deserve a sec.. (3.2) How to handle "Nom. nov.", "stat. nov.", etc., which also make changes to names proper, rather than merely to their validity ("syn. nov.")? (3.3) How to handle recombined names in botany? Based upon what I've been told about ICN compliant authorities, I tend to think it actually should be (A) B sec. C in that case ... (4) OK, good, then the logic remains the same.

mguidoti commented 4 years ago

(2) Varieties does have the 'var.' before, so you're absolutely right. I think at the end I would follow the codes to define whether to add these rank labels or not. We need to provide you with the list of cases, in both Zoological and Botanical code, in my opinion. Let's wait Donat's.

(3.1) The key factor here is how the different nomenclatural codes deal with authority names. For Zoology, the B shouldn't be there, just (A, year) sec. C, year - we simply don't use combination authors. For Botany, it would be A B sec. C, year, without the year for A B and with the year for C (I would say).

(3.2) I don't see use for taxonomic status labels in the TaxonomicConceptLabel. So I would simply ignore what is happening in the treatment (if it's a 'syn. nov.', 'comb. nov.', etc). The ONLY exception to this rule that I can think of would be Nom. nov. as the authority follows the name. So, if it's a new name for a given species concept, the new basionym author of that species is the author of the new name. Following our example, if D proposes a new name for what A described, the TaxonomicConceptLabel would be Genus species D, year. If E describes it again, then Genus species D, year sec. E., year.

(3.3) Botany adds comb. authors into the authority name already, and they don't use year for authority. So as I said on 3.1, I think it would be A B sec. C, year, with parenthesis whenever they use parenthesis. Note that C is not part of the authority of the species, but of the treatment, meaning that, the presence/absence of the year doesn't need to follow the code. As a meaningful piece of info as it is, I would keep it.

gsautter commented 4 years ago

Thanks, @mguidoti , but this is getting wild now (reusing your numbers up front) ... (3.1 and 3.3, my 3.3) I think we should add the years whenever we have them, as otherwise this ends up close to total chaos, especially for data people who are not as familiar with the codes (e.g. Reto). I think we agreed at some point that the taxon concept label need not necessarily be a code compliant treatment title ... or did we? (3.2.1) OK for both the handling of "nom. nov." (never meant to do anything on "syn. nov." anyway, maybe my wording was a bit unclear, just mentioned it for contrast as an act that doesn't change a name proper, but only its validity). (3.2.2, my 3.1) I still think "comb. nov." is a special case, and maybe "stat. nov." is as well ... consider Aus bus A, which would be Aus bus A sec. X in a later usage by X. Now B does a "comb. nov." making it Cus bus (A), which would be Cus bus (A) sec. B according to your proposal, and would be Cus bus (A) sec. Y in a later usage by Y, putting B and Y on the same level where imho they are not, as B modifies the name, and thus it should be Cus bus (A) B without the sec.. Most likely the same for an author D doing a "stat. nov." on Aus bus cus C by making it into Aus cus (C), which should have the label Aus cus (C) D rather than Aus cus (C) sec. D for the same reason.

gsautter commented 4 years ago

In brief, I might try and sum up (3.2.2) like this: Any author (with or without a year is an orthogonal issue) who coins a name or combination (including "stat. nov.") should not be behind a sec..

mguidoti commented 4 years ago

Hi Guido,

Sorry for my late reply on this one.

I don't remember discussing if the TaxonomicConceptLabel will or not comply with codes, but I'll again remember you all that the end user should be the main focus here. It's the end user - taxonomists - that will look and use this at the end of the day - and codes are burned into our memory, meaning that, anything odd will jump into our eyes. Moreover, you know that it takes only one little thing a bit off to discourage people of using something new. So, I would argue to comply with the code for the authority of the taxon in the TaxonomicConceptLabel, meaning that, no authority year for botany. But that's my two cents only.

Comb. nov. is not a special case within this context (TaxonomicConceptLabel), really. In your example, B and Y really are at the same level, because they are authors of treatments about a species concept originally described by A - and that's how we shoudl read the TaxonomicConceptLabel. If you add (A) B you will be using a botanical logic, which will make every zoologist roll their eyes - and again, we've to put the end user first in other to engage them.

Also, taxonomic status info will be available in a different metadata field anyways, so we can retrieve the info that you're trying to include in the TaxonomicConceptLabel.

So, believe me on this one, it's really Cus bus (A) sec. B, not Cus bus (A) B.

gsautter commented 4 years ago

OK, from that point of view I get your take, will finish the logic accordingly.

mguidoti commented 4 years ago

All right!

Thanks and good luck!

mguidoti commented 4 years ago

But I think you'll still find this list useful, right?

I can provide that, or ask someone here in the office. Just let me know.

(2) Varieties does have the 'var.' before, so you're absolutely right. I think at the end I would follow the codes to define whether to add these rank labels or not. We need to provide you with the list of cases, in both Zoological and Botanical code, in my opinion. Let's wait Donat's.