Best practices for curating 'Additional' taxonomic levels

The full guidelines on this are here:
https://www.inaturalist.org/pages/curator+guide#nodes

Key takeaways;

  • should only be added if you can ensure all child taxa can be placed
  • “Properly curated nodes on iNaturalist should have all of their children grafted beneath them”
  • “As a rule of thumb, not including additional nodes in iNaturalist is preferable to including but only partially curating additional nodes as in the middle tree above. Please consider before introducing additional nodes: (1) are there global references that will enable curators to properly determine whether other taxa are siblings or descendants of the node? (2) are you willing to take the time to fully curate these other taxa? If during your curation you encounter partially curated nodes, it may be preferable to remove them rather than to fully curate around them if it is not possible or practical to fully curate them.”

While the guidelines above seem quite clearly written, it does not take into consideration the sheer number of these that are added by users. Many of the references the site defers to do not include these levels which make finding viable sources difficult and time consuming.

However, deactivating them will anger users.

Discussion topic to talk about best practices to manage these…

5 Likes

I would argue that adding many of these isn’t really necessary, especially for higher order taxa. There’s some utility to be gained by being able to ID an observation to a subfamily or tribe or whatever but usually only for a small subset of users. Most users don’t explicitly benefit from these (and probably aren’t even aware of them), and the info there isn’t being exported to GBIF (for observations only IDable above genus), which limits the potential benefit further.

iNat’s primary purpose is to be a way for people to interact with nature, not a constantly updating approximation of The Tree of Life. The taxonomic backbone is a support for that (people need to be able to ID things properly), but if the addition of extra levels compromises that or takes so much energy away from accomplishing other things, then in my mind it isn’t worth it.

I feel like I mostly just paraphrased ideas that are already in the Curator Guide, but just expressing my opinion that it is worth keeping the number of these down to those with the clearest benefit and easiest implementation and erring on the side of simplicity.

I have wished for some subgeneric categories in taxa I work with, but you bring up good considerations that help me see the potential pitfalls. One alternative for me would be to use tags as subgenus designators. It wouldn’t automatically update as observations are added, but that wouldn’t make much difference to me.

This happens a lot:

Someone wants a well-understood crown group to be an option (perhaps its members are visually distinctive), but doesn’t want to deal with the paraphyletic grades basal to it.

Is it okay to make such a crown group and leave the rest of the taxa direct descendants of the parent taxon?

This doesn’t seem explicitly disallowed by the curator guide.

1 Like

Maybe not explicitly disallowed, but definitely explicitly discouraged. But I see your point. Dodecatheon within Primula is an example that comes to mind.

That said, I generally agree with the previous points and the thoughts behind the Curator Guide. One place where I see some minor benefit to additional taxonomic levels when well-curated (at least below family level), is that they can serve as the Community ID when there are disagreeing IDs within a tribe, subgenus, etc, allowing the ID to be a little more specific than just a Genus ID or Family ID, and maybe helping to guide further ID work on the observation.

1 Like