Ambiguous Rank field in Name 'table': Nomenclatural vs. Taxonomic Information

[dimus]

Body:

The Name 'table' rank field currently seem to serve a dual purpose, leading to ambiguity and a potential violation of the intended separation between nomenclatural and taxonomic data.

Problem:

The rank field in the Name table appears to represent two distinct concepts:

1. Nomenclatural Rank (Part of Name String): The rank explicitly included within the name string itself, as parsed or determined. For example, in "Aus bus var. cus," "var." indicates the nomenclatural rank of "variety." This information is intrinsic to the name and belongs in the Name table.

2. Taxonomic Rank (of Associated Taxon): The rank of the taxon to which the name potentially refers. For instance, a name "Diptera" might have a rank of "order" when referring to the insect order Diptera, but it also could have a different meaning and rank if used in a different taxonomic context (e.g., as a synonym for Saxifraga genus).

This duality conflates the name's inherent structure (nomenclatural rank) with the taxonomic classification of a potentially associated taxon. While the Name and Taxon tables seemed to be designed to decouple nomenclatural and taxonomic information, the current Rank field in Name introduces a coupling. I think the taxonomic rank information should be taken from the Taxon table and not from the Name table, while in the Name table's Rank would then contain only rank of a name-string.

Proposed Solutions:

To resolve this ambiguity and maintain a clean separation of concerns, it seem to be reasonable to:

• Clarify rank in Name: Restrict the rank field in the Name table to strictly represent the nomenclatural rank as it appears within the name string itself, if present.

• Remove taxonomic rank from Name: Remove the representation of the associated taxon's rank from the Name 'table' and place it in the Rank field of Taxon 'table'.

In case when NameUsage blends Name, Taxon and Synonym tables, there could be distinction in naming, similar to Remarks and NameRemarks: Rank and NameRank

[mdoering]

I guess the conflation you refer to comes from zoological nomenclature, in particular the Principle of Coordination? This principle does not exist in botany it is problematic for computing on names. The entire ColDP/CLB data model is build around the botanical idea of a name being a fixed binomial with a fixed rank:

For that reason I see moving Name.rank to Taxon/Synonym.rank as very problematic.
See CatalogueOfLife/general#35 as the main discussion, but also CatalogueOfLife/general#43

[dimus]

Thanks for the fast reply @mdoering, may be I do not understand why name was separated from taxon. I see that currently Rank in Name contains taxonomic classification rank, and it seems strange.

When I parse NameUsage from the Catalogue of Life CoLDP file, there is no way to place taxonomic rank together with other taxonomic things, as there is no Rank field in Taxon.

[mdoering]

The rank is nomenclaturally relevant as well. A genus or subgenus is not the same thing in botany. Neither is a variety or form. Zoology and botany are unfortunately rather different in some aspects of the code.

[dimus]

I do agree @mdoering, this is why it makes sense to me to have it in both Taxon and Name, but may be with slightly different name for the field?

[mdoering]

I did this in the first iteration of ChecklistBank and it only caused me trouble. What happens if the name and taxon entry disagrees?

[mjy]

The entire ColDP/CLB data model is build around the botanical idea of a name being a fixed binomial with a fixed rank:

If this is true and adhered to then for binomials you should never need a rank field, it could always be inferred?

[mdoering]

sorry, obviously not only binomials

[dimus]

I see what you are saying @mdoering . I think, from practical perspective, the way it is now will work for us, as long as people make sure the Taxon rank corresponds to the Rank field in the Name table. Although, I wonder if it creates some 'soft' circular dependency between Name and Taxon, because Taxon connects to Name via name_id, and Name must provide correct Rank that corresponds to the Taxon.

[mdoering]

Well, in this model the rank belongs to the name. There is nothing to make sure taxon and name match up as the taxon does not have a separate rank. If the rank of a taxon changes, the name has to change. In botany a comb.nov.stat.

[dimus]

So, as I understand, if an author of an archive makes sure that a Taxon "row" points to the correct name_id, the Name.rank should reflect the rank of the taxon accurately.