Allow taxon curators to edit taxon names, reducing "pointless" taxon changes for fixes like epithet ending changes or adding hybrid symbols

Currently only staff or the user who created the taxon can edit the taxon name. All other curators must create a taxon change to edit the name.

This is good to document meaningful changes to taxonomy, such as something being transferred to a new genus, a taxon being split into 2 or more taxa, lumped, etc, so as to apply that change to how the observations are filed in the database, and to provide a notification and record to users when and why the change was done. But, it’s mostly messy and meaningless for things like updating the end of a specific epithet from -a to -us, to add a hybrid symbol, or change a hybrid symbol from x to ×.

Staff have also mentioned that taxon changes can be very burdensome on the website’s infrastructure. A taxon change withdraws all IDs, inactivates the old taxon, adds new IDs to all observations with the new taxon, updates all place checklists and life lists, and everyone who has used the taxon on an observation or checklist etc will be notified, among other changes.

The proposal is to allow taxon curators, who are selected by staff, to be trusted to use this power to make these types of small name edits without need for an actual taxon change.

image
current state

image
preferred option with editable text field for taxon curators

It would be ideal to still have an accessible change history list to indicate that something was done. (That would apply to all changes to a taxon, like changing geoprivacy settings, conservation status, etc.)

This was previously added to the list of potential improvements to taxonomic curation on iNat in July 2019.

i gave up today encountering this issue and left the epiphet as is when trying to change “sh” to “sch”

1 Like

Has my support 100%, thanks @bouteloua for putting it up for consideration.

2 Likes

In the time being, for taxa that were misspelled by the person (who we don’t know) who entered it in Inat (not a real synonym), should we do a taxon change or ask a staff member to correct the typo?

After dealing with a bunch of different species lists with variants like “Genus species”, “Genus × species”, “Genus x species”, “Genus X species”, “Genus ×species”, “Genus xspecies” and, last but not least, “Genus Xspecies”, I’ve arrived at the conclusion that the best practice is to abolish “×”. Use it in hybrid formulae, because you actually need it there, but purge it from everything else.

Now that we have Taxon History, I’d be for allowing curators to fix minor name issues like typos and gender agreements without resorting to a full-on taxon change.

11 Likes

Concerning plants:
Shenzhen Code (2018)
https://www.iapt-taxon.org/nomen/pages/main/art_h3.html
Recommendation H.3A
H.3A.1. In named hybrids, the multiplication sign × belongs with the name or epithet but is not actually part of it, and its placement should reflect that relation. The exact amount of space, if any, between the multiplication sign and the initial letter of the name or epithet should depend on what best serves readability.

Until 2004, the recommandation was the following:

Saint Louis Code (2000)
https://archive.bgbm.org/iapt/nomenclature/code/SaintLouis/0071AppendixINoHa003.htm
Recommendation H.3A
H.3A.1. The multiplication sign in the name of a nothotaxon should be placed against the initial letter of the name or epithet.

The best way, in my opinion, is to use × with space in hybrid formulae, and without space in notho-taxons, i.e. Genus ×species for a nothospecies or ×Genus for a nothogenus, but Genus speciesA × Genus speciesB for a hybrid formula.
A space in a nothospecies can be confusing because it can be read as a hybrid formula.

1 Like

Also:
"H.3.3. For purposes of homonymy and synonymy the multiplication sign × and the prefix “notho-” are disregarded.

Note 1. Taxa that are believed to be of hybrid origin need not be designated as nothotaxa."

The name with and without the “×” are nomenclaturally identical and the “×” is optional.

Also, personally I prefer a space between the “×” and the epithet. Using an “x” in place of “×”, while incorrect, is so common that we have to assume people will continue to do so regardless of the rules. With a space, we can still distinguish hybrid names from epithets beginning with “x”; without a space, we can’t.

3 Likes

The current process is error-prone too. Since no one mentioned this, I wanted to give a specific example. A recent name change from Trillium subgenus Sessilium to Trillium subgenus Sessilia withdrew a disagreeing ID from each of 682 observations. This introduced errors into the activity timelines of some of the observations.

Using a tool developed by @pisum:

https://jumear.github.io/stirfry/iNatAPIv1_identifications?taxon_id=1024476&rank=subgenus&taxon_active=false&current=false&disagreement=true&observation_hrank=species&per_page=200&page=1

I reviewed 430 observations and reissued 305 disagreeing IDs. Since I wase unable to use the Identify tool, this cleanup operation was expensive (in terms of tima and effort). In this case at least, the value of the name change turns out to be insignificantly small. In retrospect, I should not have asked for the name change.

5 Likes

I think you encountered an example of a systemic problem. Everything about the “update IDs with taxon changes” system is guaranteed to produce tons of automation errors that, just to compound the error, get attributed to people. It’s way too close to the worst-of-all-possible-worlds system for accuracy and transparency of identifications.

Your example is probably an outlier because you checked and fixed it, not because the magnitude of the problem was in any way unusual. Most of the time–and this is absolutely my own practice, because QA / QC on fundamentally mis-designed processes is not how I want to spend my free time–people are just hitting commit and not bothering to check.

2 Likes

I’ve just been frustrated for an age by wanting to make what seemed like a tiny edit to two scientific names - so they matched published catalogs where the formation of the epithets had been later ‘corrected’ (from original authors who malformed the latin adjectives). The ‘correction’ was made long before iNat, and before someone entered it here, so it surprised me the outdated names were entered - but then really surprised me that making an edit was not really simple!

2 Likes

I think it’d be good to have some sort of landing page of all recent taxon history changes though, so that abuse of such a system could be more easily monitored (e.g. if curators were doing name changes without conducting a taxon change where a taxon change would have actually been appropriate).

5 Likes

is there any sense of whether this will be implemented on a foreseeable timeframe, or way down the road? i.e. is there any sense in holding off on these minor edits like epithet changes and corrections, versus performing them now even if it’s an extra site infrastructure and clerical burden?

3 Likes

not to necessarily make this a quarterly reminder, but any update on the implementation of this? I have opted to hold off for now (per my previous post) on the unwieldy and, with hope, unnecessary in the future step of committing taxon swaps simply to make single-character corrections to names. even those one-character name variants complicate searches, make mismatches in matching POWO for example, and so on, however. thus I don’t know if my continuing to put them off is worthwhile without any sense of when, or even whether, any work is happening on this problem.

5 Likes

It seems like such a sensible change, too. Although @bouteloua 's concern is a valid one:

Could it be set up in such a way that only changes within a limited number of characters can be made in this way? The kinds of edits being described shouldn’t involve more than 2 or 3 characters per taxon.

I doubt that that concern would really apply to enough cases to seriously spike the proposal, though I definitely agree that some sort of low-ish character limit for edits would probably take care of most of these cases (adding a hybrid symbol, changing an ending, etc.)