Include invalid protonym in combination chain and render ex

[camwebb]

@mjy @proceps Following from our workshop (on #4088) just now here's a proposal you might want to reject immediately, but I think it's worth raising:

The want/goal: At the moment, to auto-generate an ex in the author string, two protonyms are created and then linked with relationship 'validly published as'. This works well. However, I'm in agreement with @rogerhyam that it would be better ('tidier', 'more consistent') to keep an invalidly published name in the same combination chain as the first validly published instance of the name. The advantage of this is that the invalid first use of the name would automatically be a homotypic synonym of the final accepted name, and if the UI was later adjusted to add a homotypic synonymy list to the heterotypic synonyms, then the invalidly published name would appear as a (≡ ...) homotypic synonym.

The solution: This seems only to be a matter of rendering, not model. One would create the protonym (author, e.g., X) and give it status 'invalidly published', then create a homotypic synonym (= combination) with the same parent and rank which would be validly published (author, e.g., Y). The rendering engine would then join the two authors with an 'ex' (e.g., X ex Y) rather than parenthesizing the first author (X) Y.

I realize that the valid first publication of the name is not truly a combination of the preexisting invalid name, and so maybe should not be part of the combination chain. But on the other hand it is the true basionym, albeit not validly published. It seems to be an issue of semantic models, which of course we can debate until the cows come home. So if this suggestion does not seem worth discussing further, no problem, and please close it.

[rogerhyam]

Just so they don't fall through the cracks in implementation (better said than not):

1. Zoology and Botany put the ex authors the opposite way round I believe. Earlier author first in botany and second in zoology?
2. It is often common for the ex authors to be dropped when citing the name. I'm not sure if the code has or does mandate they must be included. This is relevant for name matching against literature.
3. People get confused and drop the wrong author. (I can never remember which comes first!). Thus creating what appear to be homonyms and complicating name matching of literature.
4. ex authorship is functionally very similar to isonyms (same author publishing the same name on same type multiple times - often in a paper and flora). The way we work it in Rhakhis is isonyms and ex author names are one name (perhaps with two publications) but homonyms are two names (different types) but sometime these can't be distinguished until later so you need to be able change between them as knowledge is acquired. We do this my merging name records if necessary (keeping the IDs obviously).

[
Side box:
Two prefixes meaning "the same" to any educated person but the Latin prefix (homo) is use to indicate words are written the same and the Greek prefix (iso) used to indicate they refer to the same name object (or is it type). If I were a conspiracy theorist I'd believe this was deliberate gatekeeping through obscure terminology! We could have used is homograph (homographic names) for the first and homonym for the second but it's a bit late for that now.
]

[proceps]

In zoology, we do not use 'ex' author strings. The reference is always to the original source (where the name became available: validly published in botanical sense).
At the moment, you can already put a status of invalidly published to each combination. You would not get nice 'ex' autogenerated, but you can do it using verbatim author string. At the same time, I would not feel comfortable to treat invalidly published name as a homotypic synonym. First of all, as invalidly published, the name does not have the type, and as such you cannot speak about homotypy. Second, what prevents me to validate the name with a different spelling. It is still 'ex' but now it has different epithet. And lastly, we also have a group of replacement names. Which are technically homotypic synonyms, but they would not appear in the same list of homonyms. Remember, everything on the edit form is designed for faster data entry, it is not necessarily the proper display of the name. The Browse nomenclature gives you the better visualization, and even this may not be the final result of the monographic publication.
One thing to consider, we have a number of statuses which could be applied to a TaxonName in TaxonWorks. The statuses could be taxonomic (synonym, homonym, etc.) and nomenclatural (e.g., invalidly published). But we divide the statuses differently. In TW all statuses divided into two categories. Statuses applied to a single name, mostly nomenclatural statuses, but not always. And statuses which require two names, for example synonym, the name could be a synonym of something, without second name, the status is useless, and we cannot properly display it in the system. The same apply to homonyms, replacement names etc. All of those require a second name and in TW, you cannot assign those before you pick a second name.

[mjy]

invalid first use of the name would automatically be a homotypic synonym of the final accepted name

I think this has the feel of going against our persistence design goals, it overloads meaning based (re)use of the same, not addition of differentiating facts. I.e. this has a lot of smell as saying things like "names with the same parent_id are synonyms of that parent", as we discussed this AM, that's not good, because now 1 thing means two things, synonyms, and classification. Yes, we may have to add duplicate monomials, but also yes, if we want to "cite-everything" we need to have to places to add the citations to, etc.

I agree with @proceps that this feels like a rendering issue, do we have enough facts to (alternatively) render the names with the desired format. If we do, we're solid, if we don't, we need to add "bits" to the persistence layer.

Going back to Cam, in this context, is it important to see "ex" everywhere when curating data (and things otherwise not be differentiated when adding data "in the right place", and/or at the time of summary, to provide broader context?

For what it's worth these discussions are very paralell to what we discussed when we came up with the curent browse-nomenclature interface. It had to fulfill multiple puproses, but all those were curation-facilitating based. People asked why things were duplicated, why thed didn't look like catalog X or Y, why it was time-line based, etc. etc. I think it's actually been very effecitive as a curatorial interface, it faciliates projects that are almost completely new, and almost completely "done", etc.

@camwebb Please don't take "push-back" as "we're not doing it", this needs time "to cook" as the kids say, keep it coming.

[mjy]

One other point of guidance that crossed my mind regarding what is in/out of scope within TaxonName in TW.

Nomenclature in TaxonWorks is focused on applying the rules of nomenclature. This guides what is in and out of scope. For example, if we read in the Botanical code that "names must appear in this way", then we are green-lit to encode that logic. While of course there is some lee-way with this the data/model and logic (i.e. foudnation behind the UI in New/Edit taoxn name) should focus on capturing data pertaining to rules.

If the code says nothing about how authors should be persented, then functionality may either 1) belong elsewhere in the system (rendering layers) or 2) not be a priority.

TaxonWorks is also, as I'm sure you've seen, opinionated. @rogerhyam mentioned "do we really want to capture all history?". While we almost never say "we won't do that" we do try to inject (and discuss) best-practices and we discuss, a lot, why we do things and whether we should keep doing things. One example here is that we have explicitly left out variously functionality for higher-level names that exists in some systems because they are not governed by the rules of nomenclature. Another example is that TypeMaterial can not reference type-types (e.g. co-types) that are not goverened. Most systems have some hybrid of this, we formally limit the scope.

[camwebb]

Good thoughts! Thanks for engaging with this. I think there may be no need to pursue this suggestion further - I agree with almost all of the points made, and do see the value of keeping 'combination graphs' limited to validly published names, with invalidly published names living as separate entities.

is it important to see "ex" everywhere when curating data

I think this would be up to the user. It's often dropped, as Roger points out, and is not required ("authorship as ascribed, followed by “ex”, may be inserted" Art 46.5). But 'ex's appear in a lot of names that need to be matched and should probably be included in nomenclaturally-focussed projects. The ability to 'hack' the display name via the verbatim box always allows people to make these citations without having to add the older illegitimate name independently.

(For housekeeping, I should have referenced #3315)

[rogerhyam]

In zoology, we do not use 'ex' author strings.

Does someone with more zoological knowledge/authority than me want to update the botany Wikipedia page about this. It is clearly propagating a myth amongst botanists :)

https://en.wikipedia.org/wiki/Author_citation_(botany)#Usage_of_the_term_%22ex%22

[proceps]

in zoology, the regulation of "in" authors is identical to botanical names and is used to indicate a subset of authors in the original publication. The use of "in" is optional and primary used in catalogues and checklists. The use of "ex" is not regulated in zoological nomenclature. I was able to find a few incstances of the use of "ex" in some older literature. It is duplicated in some online databases mostly for synonymic names, probably just copied from old catalogues without special meaning. And yes, the position of authors could be reversed to the botanical names. The author before "ex" would be the one who validated the older nomen nudum. It is not regulated in the present edition of ICZN and use of additional abbreviation and additional authors is not recommended in the author string.
The author string is regulated by Arts. 50-51 (Chapter 11) of ICZN: https://www.iczn.org/the-code/the-code-online/