curation - How should iNat curators treat two entries with different gender endings for one taxon?

113 views
Skip to first unread message

Roger Kendrick

unread,
Jan 20, 2018, 10:25:04 PM1/20/18
to iNaturalist
There are a large number of Lepidoptera taxa that exist on iNat in two forms, one male and one female gender taxon name, e.g. Celaenorrhinus aurivittata / C. aurivittatus.
ICZN states that the species epithet should agree in gender with the genus epithet (Articles 34.2 and 48). However, where a species has been transferred from one genus to another and the new genus is a different gender, many Lepidoptera taxonomists choose not to follow ICZN as the required change in gender for the species epithet can have unstable consequences for users of the name. It is also a pain for maintainers of digital data, as, for example, one has to constantly update species epithets on a database following revisions.
Where two iNat species entries exist, one will have to be taxon swapped with the other.
I would like to know what is the official iNat view on this issue, please. 
(1) Should curators defy ICZN and retain original spellings for species epithets, or (2) should curators tow the ICZN line and ensure gender agreement of species epithets with genus epithets in the knowledge that the spelling may change at some undefined point in the future?

cheers,
Roger (a.k.a. hkmoths)

tony rebelo

unread,
Jan 21, 2018, 4:35:34 AM1/21/18
to iNaturalist
There is no choice.  The ICZN is the rulebook and any other use is wrong.  

James Bailey

unread,
Jan 22, 2018, 4:29:32 PM1/22/18
to iNaturalist
Many plant taxonomy changes we make, as well as non-Lepidopteran insects, confirm with the correct gender agreement. So, I assume we will be following the same case with Lepidoptera.

Patrick Alexander

unread,
Jan 22, 2018, 6:25:07 PM1/22/18
to iNaturalist
I think the nomenclatural situation is fairly straightforward: Celaenorrhinus aurivittata is a misspelling of Celaenorrhinus aurivittatus. Taxonomists who intentionally spell scientific names so that the genus and specific epithet do not agree in gender are engaging in intentional misspelling. The right course of action is simply to use the correct spelling.

For iNaturalist, I guess there are two questions: First, if we are basing the iNaturalist names on a particular authority, and that authority disagrees with the relevant nomenclatural code, what do we do? This is an instance of the general problem of whether we want to be correct, or to follow a particular authority. Given that the guidance provided on the iNaturalist curator's guide focuses on following particular authorities and doesn't really say anything about being correct, I assume following an authority is intended to trump correctness whenever the two are in conflict. So then you just have to figure out what the appropriate authority is in this context and do whatever that authority does. Where there are multiple relevant authorities, I guess you just check them all. If they all agree, you go with that, and if they disagree, you pick one and then wait to see if anyone with a different preference stumbles into that particular little quagmire, at which point you use iNaturalist as a place to argue about taxonomy. :-)

Second, where should orthographic variants live in iNaturalist, how should we capture that information? So far as I can tell, the answer is that iNaturalist doesn't have any way of capturing the relevant concepts. There's nothing in the database that corresponds to a name or to a misspelled form of that name. Instead, you just use a taxon swap as the universal tool for resolving all cases where different things of one kind or another should point at the same taxon. So, assuming the authority / authorities use "Celaenorrhinus aurivittatus", we'd create a taxon swap in which "Celaenorrhinus aurivittata" points at Celaenorrhinus aurivittatus. This conflicts with my intuition, because I want to map what's going on in iNaturalist onto what's going on with the taxa and the nomenclature, and we've kind of got one blunt instrument at hand that doesn't really correspond with anything in the taxonomic realm, but the blunt instrument is what we've got and it is what it is.

bouteloua

unread,
Jan 22, 2018, 6:57:28 PM1/22/18
to iNaturalist
Also curious about the Lepidoptera taxonomy issue; I frequently avoid dealing with curating lep names because of this uncertainty.

Patrick, one can add an "invalid" scientific name to a taxon without creating a taxon swap (taxon page>Taxonomy>Add a name, see attached).

cassi
invalid-sci-name.png

Patrick Alexander

unread,
Jan 23, 2018, 1:46:51 AM1/23/18
to iNaturalist

Hello Cassi,


This has the same effect as creating a new taxon and then committing a taxon swap, right? It seems that way from what I can tell poking around and adding a couple of names that are in fact synonyms and did not exist in iNaturalist.


OK, this is way overkill for the purposes of the present discussion, but since trying to figure out the iNaturalist nomenclature and how it does / does not correspond with the nomenclatural codes is kind of a persistent preoccupation of mine, here’s the long-winded version. In the following, I’m only talking about relationships between taxa of the same rank.


iNaturalist really has its own parallel nomenclatural system (iNaturalist Code of Nomenclature, iNCN) that doesn't map onto ICZN or ICNafp. I know ICNafp much better, so I’ll try to be consistent in using the ICNafp terminology, but I think most of what I'm saying here applies to both. "Code name" in the following means "a name in the sense of the ICZN or ICNafp". The iNaturalist equivalent of a code name seems to be a number (e.g., 807779 for Celaenorrhinus aurivittata), and there isn't a one-to-one relationship between iNaturalist names and code names. You can have orthographic variants of a single code name (Celaenorrhinus aurivittata and Celaenorrhinus aurivittatus) that are treated as two separate names in iNaturalist (807779 and 763432). You can have a single code name that is treated as two separate iNaturalist names (e.g., Sceloporus undulatus is both 254178 and 54552) without any variation in spelling. I don't think there are any cases where a single iNaturalist name is intended to map onto two or more code names, although with homonymous code names it might not always be obvious which one an iNaturalist name corresponds to. 


In addition to iNaturalist names, there are also iNaturalist taxa. For instance, the code name Sceloporus undulatus has two iNaturalist names (254178 and 54552) corresponding with two iNaturalist taxa (153094 and 36142): https://www.inaturalist.org/taxon_changes?taxon_id=36142 This gets weird and I’m not sure what all is going on.


So far as I can tell, there are two kinds of relationships iNaturalist names can have with anything else. Most of the time, we only worry about a many-to-one relationship to iNaturalist taxa. So, for instance, 261480 (corresponds with code name “Bommeria hispida”) and 1090346 (corresponds with code name “Gymnogramma hispida”) are children of taxon 159309 (corresponds with code name “Bommeria hispida”): https://www.inaturalist.org/taxa/159309-Bommeria-hispida


Sometimes, there’s also a synonym status assigned to a particular iNaturalist name. This seems to be used only when the same code name is associated with multiple iNaturalist taxa. For instance, in Sceloporus undulatus, name 254178 is a child of (I’ll just use “—>”) taxon 153094, and it is also a synonym of taxon 54552.


So, when you do a taxon swap, you’ve got [iNaturalist name 1; corresponds with code name 1] —> [iNaturalist taxon 1; corresponds with code name 1] and you’re reassigning it to [iNaturalist name 1] —> [iNaturalist taxon 2; corresponds with code name 2], and deleting (or hiding, or something) [iNaturalist taxon 2]. Taxon merge just does that for a bunch of names at once; adding a name just creates a new name as a child of an existing name and skips any creation / deletion of an associated taxon. Both the iNaturalist names and the iNaturalist taxa correspond to code names.


When you do a taxon split, you start with [iNaturalist name 1; corresponds with code name 1] —> [iNaturalist taxon 1; corresponds with code name 1] and you create [iNaturalist name 2; corresponds with code name 1] —> [iNaturalist taxon 2; corresponds with code name 1] as well as [iNaturalist name 3; corresponds with code name 2] —> [iNaturalist taxon 3; corresponds with code name 2] and as many additional iNaturalist names and codes as you need. [iNaturalist name 1] becomes a synonym of [iNaturalist taxon 2].


These manipulations don’t map nicely onto anything in the codes. “[iNaturalist name] —> [iNaturalist taxon]” can mean:

 "[iNaturalist name] represents an orthographic variant of [code name corresponding to iNaturalist taxon]” or

”[code name corresponding to iNaturalist name] is a synonym of [code name corresponding to iNaturalist taxon]" or

“[code name corresponding to iNaturalist name] is the basionym of [code name corresponding to iNaturalist taxon]” or

“[code name corresponding to iNaturalist name] and [code name corresponding to iNaturalist taxon] are identical”.


If we want to talk about sibling relationships, it’s pretty much the same range of possibilities. “([iNaturalist name 1] & [iNaturalist name 2]) —> [iNaturalist taxon]” can mean:

”[code name corresponding to iNaturalist name 1] is a synonym of [code name corresponding to iNaturalist name 2]” and so on and so forth.


“[iNaturalist name] is a synonym of [iNaturalist taxon]” apparently always means “[code name corresponding to iNaturalist name] and [code name corresponding to iNaturalist taxon] are identical, and, by the way, [iNaturalist name] —> [some other iNaturalist taxon]”.


In short, the relationship between iNaturalist names, iNaturalist taxa, and code names is pretty sloppy and complicated and the only tools we have to capture the relationships between code names are “child of” and “synonym of” relationships between iNaturalist names and iNaturalist taxa.


In cases like the original Celaenorrhinus example, the intuitive approach would be to have one iNaturalist name that corresponds with one code name and has two potential spellings, one of which is marked as incorrect. Instead, I'm assuming the solution in the iNCN is something like “([iNaturalist name 1, corresponds to correct spelling of code name] & [iNaturalist name 2, corresponds to incorrect spelling of code name]) —> [iNaturalist taxon 1, corresponds to correct spelling of code name]”. If we try to translate the iNaturalist names / taxa to code names, we get something like: “Celaenorrhinus aurivittata [name] and Celaenorrhinus aurivittatus [name] are both children of Celaenorrhinus aurivittatus [taxon]”. There are a number of things about this that are weird. We have three different entities that all correspond with the same code name. We’re recording orthographic variants by having duplicate names that are children of the same taxon, so we’re using a taxon concept to express a nomenclatural relationship. However, that “child of” relationship could also mean a slew of other things, and so that “child of” relationship doesn’t, itself, tell us much about what’s going on and does not really correspond with any relationship between names that can exist in the codes.


What this kind of boils down to is that we're trying to express something about code names, but we're using a parallel nomenclatural system with fundamentally different concepts and rules. An iNCN name ≠ an ICNafp name; an iNCN taxon ≠ an ICNafp taxon; iNCN synonymy ≠ ICNafp synonymy; iNCN "child of" can mean a variety of different things depending on context. So, in my ideal world, iNCN would work enough like ICNafp that I wouldn't ever need to worry about the difference. Assuming that isn't going to happen in the near future, perhaps we should start documenting this thing.

Regards,

Patrick

krancmm

unread,
Jan 24, 2018, 10:17:51 AM1/24/18
to iNaturalist
If you're in the US and Canada, BugGuide is the official iNat reference for arthropod binomials.  Really pretty simple.

For Lepidoptera the epithet "ending" is not changing when the genus changes.  That's a decision that North American lep professionals have made citing the ICZN rule exception that "original combinations are as incorrectly-formed nouns, and therefore not mandated to be changed."

They're not "defying" ICZN, but interpreting the myriad ICZN rules.

Monica Krancevic
(iNat curator, BugGuide editor, recently became the Moth Photographers' Group Mapping Coordinator)

Patrick Alexander

unread,
Jan 24, 2018, 11:03:28 AM1/24/18
to inatu...@googlegroups.com
The ICZN bit is here:

http://www.nhm.ac.uk/hosted-sites/iczn/code/index.jsp?nfv=&article=32#2.2

" 34.2. Species-group names. The ending of a Latin or latinized adjectival or participial species-group name must agree in gender with the generic name with which it is at any time combined [Art. 31.2]; if the gender ending is incorrect it must be changed accordingly (the author and date of the name remain unchanged [Art. 50.3.2]).

34.2.1. If a species-group name is a noun in apposition its ending need not agree in gender with the generic name with which it is combined and must not be changed to agree in gender with the generic name [Art. 31.2.1]."

Having to worry about Latin grammar is unfortunate consequence of using scientific names; "aurivittata" is an adjectival species-group name and doesn't become a noun in apposition because someone doesn't want to bother changing the ending. I think we're stuck with deciding between correctness and consistency with an authority.

Celaenorrhinus aurivittatus isn't in BugGuide, by the way. The existing iNaturalist records are in southeastern Asia.
--
You received this message because you are subscribed to a topic in the Google Groups "iNaturalist" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/inaturalist/v7IX8mIj0_k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to inaturalist...@googlegroups.com.
To post to this group, send email to inatu...@googlegroups.com.
Visit this group at https://groups.google.com/group/inaturalist.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages