property:{TO BE NAMED} to indicate the novel status of a taxon in a publication

[afuchs1]

I have been trying to map the new TCS terms to a ingesting a bibliographic resource, the accepted taxonomic name (accepted TNU) and any synonyms (related TNU's) and cannot find anywhere to map something to indicate this taxonomic name is being published for the first time.
ICN : Recommendation 45A
45A.1. A new name should be followed by a direct citation indicating its novel status, including the word "novus" (-a, -um) or its abbreviation, e.g. genus novum (gen. nov.), species nova (sp. nov.), combinatio nova (comb. nov.), nomen novum (nom. nov.), or status novus (stat. nov.).

Example : Calytrix insperata Rye sp.nov in https://florabase.dpaw.wa.gov.au/nuytsia/article/939

[mdoering]

That is highly linked to designating the protonym or a combonym as Rich proposes in #46

[deepreef]

Yeah, I was thinking along those lines. But there is a subtle but important distinction: Protonyms are the first chronoloogical use of a name, not necessarily the first Code-compliant establishment of a name. The right way to do this is with a 1:M relationship to something like "nomenclaturalEvents" (term we came up with to apply Code-relevant actions to TNUs). But I wasn't sure if that's a box we're ready to open yet, and also might be more relevant to implementations, rather than exchange standards. But don't we have something along the lines of dwc:nomenclaturalStatus in TCS? I'd check, but am just ending my day here, and brain too tired to think about that stuff in too much detail.

[deepreef]

Also, the equivalent of dwc:taxonomicStatus for the taxonomic qualifiers.

[mdoering]

In the COL API I have a field nomenclaturalNote and taxonomicNote which holds all the verbatim bits found in the authorship string of names s.l. I found that very useful to deduce the actual status but verbatimly represent a given full name

[nielsklazenga]

@afuchs1, what you are looking for is the inverse of namePublishedIn. Of the names that are published in the publication, the ones that have neither basionym nor replacedName (or 'ReplacementNameFor' in TCS 1) are new taxa ('tax. nov.'), the ones with a basionym are new combinations ('comb. nov.') and the ones with a replacedName avowed substitutes ('nom. nov.'). If the name has a different rank than its basionym, it's a 'stat. nov.'.

As @deepreef already suggests, we can also add these terms to the vocabulary of nomenclaturalStatus (TCS 1 'PublicationStatus'), as subtypes of 'valid' (the botanical 'valid').

[ghwhitbread]

In the NSL we capture these status values within the vocabulary (for our equivalent) of TNU-type. So much of how we consume, store, use, transform and disseminate TNU data depends on this unambiguous typing.

Both nomenclaturalStatus (standing in nomenclature) and taxonomicStatus (standing within a classification) are properties of a Name, with values derived independently of the act (and intention) of publication.

This is important stuff ... A robust and extensible type-vocabulary for the TNU could well be our most important contribution.

[deepreef]

This is important stuff ... A robust and extensible type-vocabulary for the TNU could well be our most important contribution.

I completely agree! But we'll need a system that allows more than one "type" to be applied to a TNU, as many of them are not mutually exclusive.

@ghwhitbread : you may recall one of those NOMINA meetings in Hawaii, where we were in the fish collection office with a whiteboard along with the usual NOMINA suspects (Paul, Nicky, Paddy, etc. -- @mdoering, were you at that one?) and we diagrammed out the idea of "NomenclaturalEvents" (ways of "tagging" TNUs with specific Code-relevant "events" to characterize things like Nomenclatural Acts). We never really implemented it, but I plan to implement it in a big way for the next-gen ZooBank. So perhaps it would be worth visiting now. See the attached diagram, which was the outcome of that NOMINA discussion.

[afuchs1]

I am just looking at this from the point of the view of the data to be moved around, in this use case - what we need to ingest from a publication (how do we identify it as the publication event for a new taxonomic name? and hope I've used the right words here).

From the data we work with (which I accept may be skewed) I see this as a property of the act of publishing a bibliographic resource for a 'new' taxonomic name which is expressed as the accepted taxonomic name usage in the set of TNU's in that resource.

BR: Nuytsia _Calytrix insperata_ (Myrtaceae: Chamelaucieae), a new Western Australian species opportunistically discovered on vacation
---
Has TNU1 : acceptedName **_Calytrix insperata_** Rye, is published for the first time as **sp.nov**  
has TN : _Calytrix insperata_ Rye
---
Has TNU2 : has synonym _Calytrix _sp._ Kennedy Range (A. Markey & S. Dillon 6301) of accepted name _Calytrix insperata_
has TN : Calytrix _sp._ Kennedy Range (A. Markey & S. Dillon 6301)
--

From this point of view the attribute of 'sp.nov' is specific to this name in this publication event. Subsequent events will determine the validity of the status of the name. ie. whether it is invalid etc - this status is then a property of the name (nomenclaturalStatus)

Are the nomenclaturalEvents the intersection between the taxonomic name of interest and the TNU's in different BibliographicResources?

Excuse my lack of knowledge, but are changes to the nomenclatural status of the name (valid, invalid etc) 'documented' via another publication event or is the status assigned as part of assessing against the relevant nomenclatural act and so the name becomes 'invalid' without a published reference? Thinking about it I presume people don't necessarily agree whether a name is invalid...?

In BR1 --> TNUa (sp.nov) --> for TN1
In BR2 --> TNUb says --> TN1 is invalid therefore TN becomes (nom.illeg)

Please note, this use case is about extracting data from publications, I would like to see if the nomenclatural and taxonomic information contained in them can be expressed using the TNC model.

[mdoering]

thanks @afuchs1 this is very helpful. Even if nomenclatural data wants to be objective and rule based there might be different opinions and for sure wrong evaluations of rules or simple data errors. I would think like with other data the different opinions are mostly covered by having distinct datasets. But when one wants to capture exactly what was published and aggregate these statements we have to deal with concurrent opinions on the same "name". Subsequent publications could assert some other nomenclatural status, but I guess in many cases the status is nowhere published in literature. I would think IPNI evaluates a status for example. @deepreef does ZooBank evaluate or capture a status? I think I never saw that. The example of Cancer strigosus given in ICZN as a homonym example is in ZooBank, but none is marked as such.

[deepreef]

@mdoering :

does ZooBank evaluate or capture a status?
The data model supports it (via NomenclaturalEvents), but we have not yet implemented this on the ZooBank website. This will definitely be part of the "next generation" ZooBank, after we can get some funding. The Commission has for a very long time (since before ZooBank was even created) discussed how we would add a "verification" layer confirming the nomenclatural status of each name, as established through TNUs (including Protonyms). But it would be impossible for the Commission itself to do that work for so many names. Some nomenclators have already done the work, so certainly we would want to accept those status values when they already exist. But the only way to ascribe such status with confidence to names will be to mobilize the army of existing ZooBank users to crowdsource it.

It's all very doable -- just needs some policies, a reasonable workflow, and a clean UI.

[afuchs1]

thank you @mdoering and @deepreef - trying to summarise so far

• a taxonomicName (TN) is published in a bibliographicResource (BR) with a status of ('tax. nov' ,'sp. nov', 'gen.nov', etc). As intersection data of a TN in a BR it is a property of a TNU.
• the nomenclaturalStatus of the taxonomicName is subsequently designated as part of the overall process of publishing, verifying and accepting the taxonomicName and is not always supported by a bibliographicResource.

It also does not map to https://dwc.tdwg.org/list/#dwc_taxonomicStatus nor to the draft biocode (http://www.plantsystematics.org/reveal/pbio/nomcl/mcnet3.html)

so going full circle, no resolution.....so if we are ingesting a publication of a new taxa (via a bibliographicResource) where should this data be captured? Still hopeful the TCS model will accommodate this use case and not require another standard.

[mdoering]

My immediate reaction would be to place the novum status on the TN as it comes in from the TNU.
The problem only arises if the TN is normalised; shared between several TNUs and thus can only have a single status. In that case sp.nov. is not appropriate.

As the status is an assertion we might also be interested in who asserted it when and allow for multiple assertions. That sounds an awful lot like a TNU and the nomStatus might be needed on a TNU. Also how would you represent faithfully a publication that asserts a name is a nom.illeg. but which might turn out to be wrong? Thats the crux of strongly normalized data. But isn't this problem the same other TN properties like the scientific name? The exact spelling of the name could be different from TNU to TNU. This makes me wonder how useful the separation between TN and TNU really is. In my work on COL ChecklistBank which collates various datasets I have troubles finding the separation very useful as you need to mint separate TNs for every dataset anyways in order to faithfully represent what the name is in each list. And at that stage I could as well merge all TN properties into TNU and have a simpler model to work with.