search

tdwg / tnc

Taxonomic Names and Concepts Interest Group
22 stars 7 forks source link

Proposed: 'protonym' property on TaxonomicNameUsage #46

Closed nielsklazenga closed 4 years ago

nielsklazenga commented 4 years ago

I was just going to reopen issue #32, as the concept of protonym came up again in the discussion around issue #45, but the proposal has significantly changed, so I thought it best to open a new issue.

The protonym property was not included in the draft specification that was presented at the workshop at Biidiversity_Next, but I think we should include it. Earlier discussions were influenced by discussion around issue #34 to merge TaxonomicName into TaxonomicNameUsage and the idea that the protonym property could replace the basionym (and replaced synonym) property. I think we should completely separate these things. basionym and replaced synonyms are properties for names and have to be in accordance with the relevant nomenclatural code, while protonym is used to link Taxonomic Name Usages to an "original" Name Usage in a data graph. While in many cases the protonym can be inferred from the basionym or replaced synonym (I find myself doing coalesce(basionym_id, replaced_synonym_id, id) a lot), in non-trivial name histories – where either the protonym name or the taxonomic name are illegitimate or invalid, or where a name is accepted in a genus where the combination is not available – it cannot (or rather, the inference would be incorrect). In any case, protonym and basionym are different concepts. Having the protonym property allows us to use the basionym property exactly in accordance with the nomenclatural codes, without having to stretch the definitions to accommodate e.g. invalid names.

While the original proposal had protonym as a property of a TaxonomicName, @deepreef always intended it to be a property of a TaxonomicNameUsage and this proposal follows him. With this we will have separated concerns and made the TaxonomicNameUsage class independent of the TaxonomicName class: we could use e.g. a SKOS Extended Label (#25) instead of a TaxonomicName and everything would still work.

deepreef commented 4 years ago

I'll need to review the draft and prior discussions to comment more meaningfully, but in general, I agree. Specifically, the reason I felt the need to coin protonym in this context in the first place (as opposed to simply adopting basionym) was because they have subtly (but technically important) different meanings. The term basionym refers to a relationship between a subsequent combination (name), and its original combination (name). An original combination is not, by itself, a basionym (especially if no subsequent combinations exist).

By contrast, as @nielsklazenga points out, a protonym refers to a TNU (not a name), and is itself a protonym regardless of whether there are any subsequent usages (representing different combinations or otherwise) that refer to it. So I support them not being conflated. (Pedantic Note: some properties of the 'name' itself -- like gender and other strictly nomenclatural properties -- are best represented in the the context of a protonym as a 'name', rather than as a usage.)

Also, I would like to review the definition of protonym as we present it. It is sometimes mistaken as the first 'Code compliant' usage of a name (epithet, not combination); when in fact it is the first chronological usage of a name (epithet, not combination) -- independent of whether that usage established the name in a code-compliant way.

Along these lines, do we need another term (maybe something like combonym) that represents a TNU that is not a protonym, but rather is the code-compliant (botanical) establishment of a formal new combination? Zoology doesn't need this for code purposes, but could certainly use it; and we need some way of flagging those specific TNUs that represent the first Code-compliant (botanical) TNU establishing a new combination.