nomStatus should be replaced with NOMEN

[mjy]

As it stands http://api.col.plus/vocab/nomStatus is a frankestein combination of values, it seems like it can be improved down the road

Some observations can be made:

• These codes seem to reference nomenclature exclusively
• The status only speak to taxonomists (no regular user of CoL will ever want to know, nor understand the terms there).
• If it is to speak to taxonomists then it should be specific to a Code of Nomenclature.
• If it is specific to a Code of Nomenclature then there should not be cross mappings across codes. Words and concepts differ between codes, and botanists need not confuse their code with taxonomists code. I.e. the shared word serves only obfuscates, not clarifies.
• Some of the terms are not used in their respective codes, but this can be cleaned up. For example in zoology "potentially valid" is likely "available".

Given all this, it seems like this should be replaced by references to NOMEN. NOMEN includes a range of both general and specific statuses, and is a much more robust context for nomenclature in general.

[mdoering]

Thanks Matt, we had discussed this in the beginning and specifically designed the vocabulary for a different purpose. It needs to work across codes and was meant to address only 2 key questions: The vocablary is kept minimal to basically answer two fundamental questions:

1. Has the name nomenclatural standing and should be considered in nomenclatural questions?
2. Can the name be used for a taxon?

All more and code specific details are supposed to go into an unstructured field for nomenclatural notes which can inform users, but will not necessarily be understood by machines.

As we strive for cross code values we decided to follow the BioCode terminology as much as possible instead of picking from various codes or invent sth new.

acceptable aka potentially valid is not the same as available. It corresponds to the botanical legitimate which is lacking in the strict sense from zoology. It is an available name and potentially valid, i.e. not otherwise invalid for any other objective reason, such as being a junior homonym.

Please see the NAMES.md document for more reasoning and the Java docs for the enumerations for more references.

[mdoering]

we should use suppressed in favor of rejected according to the BioCode

[mdoering]

and we might want to add established for available names if it is not know whether the name is acceptable (legitimate) or unacceptable (illegitimate).

[mjy]

Thanks for the quick response. This decision makes very little sense to me for many reasons, but I'll dig deeper and attempt to figure out the logic behind it before I spew further.

Until then two things: 1) NOMEN is designed to do exactly what you want (and much more IMO, perhaps this is the issue); and 2) can you point to Taxonomists who actually know Biocode let alone use it?

[mjy]

"4. Separate rules for organismal nomenclature, contained in the PhyloCode, are being established by analogy to those in the Special Codes but are based on different principles. Any names that may be proposed under the PhyloCode have no standing under the BioCode."

Perfect, many (other standards) exist, so let's make another. Fair enough, NOMEN is a similar attempt. :)

[mdoering]

@mjy the main reasons for not going with NOMEN to me are a) no cross code values and b) its complexity (because of the codes complexities). It might make sense to have an additional field that adhers to NOMEN? we can then easily derive our simpler one which seriously is just 5 very broad concepts found across codes.

The entries for chresonym and manuscript are values derived from very practical needs to deal with data outside the codes. The questionable entry doubtful is in between, with the initial desire to not include it even though it is found in codes. We ended up adding it so one can deal with real data that often is just that, doubtful and not fully investigated.

[mdoering]

How about adding a new nomenStatus field that takes a NOMEN URI? Or what is your expected values to share NOMEN states?

[mjy]

@mdoering More or less agreeing.

• There are cross code values. We wanted to be able to express things like "this is a name for a biological entity (NOMEN_0000030)", "this name is a scientific name (goverened by some rule) (NOMEN_0000036)", this name is a Latinized String (NOMEN_0000032), "this name is a vernacular name (not governed by some rule) etc. All these are independant of code rules, and all can be combined with other classes in logically validatable ways. You'll note at the base we even use a "string" concept in a very abstract way (some set of symbols tha represents a name).

• There is little reason we can't expand NOMEN to include ad-hoc categories if their concepts are clear.
• CoL is asking data providers to label their data (I assume, correct me if these codes are only applied after data are submitted!). Asking them to reference codes that they are unfamiliar with (we arguably have some expertise, and couldn't see the immediate logic) seems to be a pain point. Curators need their annotations to be understandable. In truly expert systems we routinely find they are using 60+ "status" codes, something like NOMEN is critical to clarify these so they can be naturally filtered down into subclasses such as you are interested in.
• Key concepts at the heart of a particular code are literally all that really matter (zoology = "available", "unavailable", "valid", "invalid"). In my mind these must have equivalence to some biocode values. If the code can't address these pillars/foundations it serves little purpose. In other words simply ensuring these 4 words for zoology are clearly mapped to the a biocode value would be enought to make me much, much happier (everything else is bonus).
• Of course everyone will have to map to CoL at some level. By using new codes we can expect developers everywhere to do somethign like this: https://github.com/SpeciesFileGroup/taxonworks/issues/1040. This seems to be a bandaid approach rather than a cure. NOMEN definitely has issues and room for improvement, but pointing at it seems to move us closer to a cure, requiring less ad-hoc mapping.

We'll proceed with our issue #1040. If we can satisfactorly map our logic to NOMEN then we'll update NOMEN with our mappings, if not we'll report here.

[mdoering]

For the CoL Clearinghouse we suggest to allow all NOMEN values to be used directly in coldps Name.status: https://github.com/CatalogueOfLife/backend/issues/716

[mdoering]

based on https://github.com/CatalogueOfLife/backend/issues/908 I feel we should consider to recommend NOMEN status values to be used for sharing. As URLs as values put many people off and we want ColDP to be a human readable format I would suggest we accept various forms of NOMEN values. These are currently all accepted by the ChecklistBank importer:

• http://purl.obolibrary.org/obo/NOMEN_0000217
• NOMEN_0000217
• ICZN incorrect original spelling

The importer could interpret incorrect original spelling alone only if also the nomenclatural code would be given for the name.