Unfortunately, I know a couple of cases (including this one), where POWO is either not up-to-date, or its concept is debatable. Ideally, such changes should be made first at the level of POWO. However, sometimes POWO makes decisions which might be reasonable from some scientific viewpoint, but less so from data management. From a scientific viewpoint, lumping or splitting taxa can be equally reasonable, and either decision can be easily reverted. But from the side of data management on iNaturalist, reverting lumps once committed is next to hopeless, since it can require the revision of all observations of all involved taxa. On iNaturalist we should consider this danger, and not simply follow what is on POWO, because POWO doesnât care what happens to our data. It is better to keep a lag behind what is on POWO in order not to lose the biological interpretation of the data.
See the current flag here: [link removed by moderator].
Of course, they are volunteers with the best intentions but sometimes informed decisions are needed that are not expected from volunteers who are not trained to do them. And they might not even know how messy a case they are about to curate.
Perhaps it would make sense to develop some strategy for providing curators with more formal guidance on how to curate responsibly. Just because someone is a volunteer doesnât mean that they canât be expected to complete training before engaging in their volunteer duties.
Lack of onboarding is an issue for regular users (not just technical aspects of how to use a complex website, but also becoming familiar with the culture of the community); it seems to me that part of what is happening with curation that is causing tensions is a result of lack of more comprehensive onboarding for curators.
I removed the link, since we have a policy here on the Forum of not publicly singling out other individual users for perceived negative behavior. You have already flagged the issue, and if you need further follow-up, please submit a help ticket.
I understand and I agree with your reasons. As far as I am concerned, I think It is very annoying to read curators stating that the a given taxon is treated this or that way in the backbone and we must comply. On the other hand, I also think that what you propose could just end up causing the impossibility to curate some taxa.
In the end, it is a matter that should be dealt with common sense by those who want to treat a given taxonomic issue. In this case common sense means to verify if what proposed by the backbone has a sense, is supported by robust and recent literature, is agreed by top observers/identifiers/experts and is adopted in many countries where the taxon occurs.
PS: I am not saying that I am better than other curators. I have made my mistakes as a curator in treating some taxa.
Sorry, thank you for removing the link.
That would be worth a feature request? To retain the history of what taxon was IDed before. It could be an Observation Field - so the info remains visible and useful.
Indeed that would be very helpful!
I appreciate the added context. In my view, you and others have identified a better approach than attempting to define and confine expertise among pseudonymous and non-pseudonymous curatorial staff: rely on time and consensus among lead identifiers or curators for irreversible taxon swaps. A related suggestion by DianaStuder seems more aligned with the root issue: retain previous epithets assigned to observations if a synonymy is made.
I find it surprising that these taxon changes are so irreversible. Perhaps Iâm missing something, but that seems to be the main problem here. If the preferred secondary resource for a taxon is incorrect, as appears to be the case in these examples, thatâs unfortunate. Still, I donât fault any curator following common practices in a well-informed and well-intentioned way. Instead, I see these errors as an expected outcome of how iNaturalist is structured, and the focus should be on enabling mechanisms to undo mistakes rather than solely preventing them.
For example - my issue with - iNat deletes Placeholder text as soon as ANY ID is added - had to be resolved by creating the Placeholder Backup project.
It would be better all round if iNat had a way to retain useful info so it is accessible and visible. It does not have to be - we can reverse this ID - but easier to sort manually if you can see, this one was peanut and that one was walnut.
Reverting a merge of the past is, in essence, a split. As is common after a split, it requires identifiers to identify again all observations devoid of a âhistory of taxon changesâ or not auto-identifiable by atlas. The focus should be on enabling mechanisms to limit undue taxon changes, rather than (or as much as?) making them reversible afterwards.
@ShotShot Respectfully, no. I realize the issue results because IDs are dropped after a split or merge, so suggested the focus be on preserving ID history or making ID changes to some degree revertible, along with requiring more time if there are irreversible data management changes.
It is silly to police expertise and experience on iNaturalist users as youâre suggesting; the system is transparently built to use laypersons and âexpertsâ alike to get data in the right position. Policing expertise and experience on iNaturalist as a preventative measure is unenforceable and ignorant to iNaturalistâs aims as I interpret them.
Edit: not to forget, this curator in question totally followed the proscribed directions, and were totally maintaining correct practice. It would have required some âexpertsâ to arrive, self proclaim their expertise, and explain why the secondary source is incorrect. The latter cannot be expected on iNat, but the former is the status quo. No matter how you shake it, this was (1) a fair taxon change from the perspective of the curator, (2) it will happen again because it exactly follows curation guidelines (3) you cannot expect expertise among iNaturalist users to prevent current curation guidelines.
That does not appear to have been the case, according the original post:
The curator guide says:
Collaborate
Try to@mention others to review your changes for potential errors and to discuss whether or not theyâre appropriate. This is especially important if youâre changing a taxon based on a regional authority and it has observations outside that region. Curators have a lot of power to act unilaterally because sometimes itâs just hard or impossible to get others to vet your work, but we (the site staff) would prefer a more collaborative process whenever possible.
and
If a taxon change is likely to be controversial, starting a discussion before rather than after the change is prudent.
All evidence indicates this was a controversial change and the curator went ahead unilaterally anyway.
If I understand correctly how things work, when it comes to the Taxonomic Scheme in use at iNat, this is currently not the case since:
(a) only a limited fraction of users --no matter their âexpertiseâ-- are given the possibility to âget data in the right positionâ, and
(b) the system and guidelines make no explicit provision for non-curators (laypersons and âexpertsâ alike) to have a say, it is at the curatorâs discretion.
Hence various requests --many now dead on water-- to improve things through technical âchecks and balancesâ to their, I quote, âact[ing] unilaterallyâ.
Or maybe revisiting the guidelines could do, I donât know.
(Correct me if Iâm wrong: curators donât formally/technically have to wait any delay, or gather inputs from anyone, or dig into the taxonomic issue at hand, before committing a taxon change, right? In which case exerting caution is left to their sound judgment and good will â and good will there is, fortunately! and yet mistakes do happen, and tricky to fix too, as noted)
@deboas Thank you for pointing that out. I can acknowledge in this special case, apparently in reference to plant subspecies designations, that the curator was too expeditious and didnât technically follow the guidelines. I am surprised they committed a taxon change following contrary advice of several experts. Though, I wonder how often the secondary points can be applied, because it is the very nature of this platform to be dealing with taxa that have no qualified expert available to detect these changes and assert their opinion.
@ShotShot i agree with your sentiment; I acknowledge I may be wrong here. Though, my understanding is that a curatorâs my main requisite is having suggested (3?) previous successful iNaturalist taxonomy changes. So:
iNaturalist appears to me that you only need to make a pseudonymous account, know how to use iNaturalist effectively, and you can affect research grade, open source data at the level of observer, identifier, and/or curator. Even if curators are a limited fraction of users, philosophically, I give no special expectation of âexpertiseâ to curators. I expect them only to follow guidelines, and expect they may not have been trained in the taxa theyâre dealing with, but doing their part to put each observation in a taxon it is accessible.
I also do not think curators are required to wait, as deboas mentioned, they seem instead urged to collaborate and be prudent (hopefully, encapsulating a time delay?). It is not always obvious what taxon shifts are going to be controversial. I maintain a simple system to impose a time constraint or consensus would be an effective preventative measure.
Enforcing technical measures (safe delay, a few notifications etc.) before the âtrickyâ operations makes a lot of sense, I agree, definitely. Letâs take it the other way around - could we imagine relaxing (to some extent) such heavy technical safeguards, based on an estimate of a curatorâs familiarity with the curation process (e.g. how many taxa they have successfully processed⌠without causing a mess/reversal), and/or familiarity (not necessarily âexpertiseâ in an academic way) with the taxonomic issue at hand (e.g. if among top identifiers for the genus/family/whatnot)?
yazh but the thing is⌠some of them SHOULD never happen.
This is very similar to my thread i already made so iâm sure people are already aware of my opinion butâŚ
iNat is not âin dire needâ of more curators changing and splitting taxon faster than the users can keep up.
That all being said iâm not sure number of observations is the best way to account for this. I could see cases where it might not make sense. Broadly it seems a good idea to have some requirement that curators participate in the community before changing our taxonomy. But, as others have pointed out, some species are very rare and couldnât easily be curated if no one is observing very many of them, but they still are important.
Disagree, genus level changes can cause a lot of problems too.
Not always true. In a dataset without photos or specimens, which is common in many cases albeit not on iNat, a split can make older pre-split data unusable beyond genus level in some cases, thus resulting in a loss of information. Itâs true lumping can be more destructive in some ways, but from what iâve seen itâs so rare on iNat that itâs barely worth worrying about. The curators who do plant taxonomy at least, are mostly solidly in the âsplitterâ camp.
Iâll leave it at this because everyone is already pretty familiar with my views⌠but it would be nice if some of the really pushy curators who act like iâm the only one with these concerns would recognize that many others have them as well.
That is conceivable and reasonable. I would vote in favor of a preventative measure that implements those proposed guidelines, particularly, the point about previous curatorial history
This is a terrible idea.
I recently got involved in the 2024 taxonomic update of birds (there is an annual update of Clements/eBird, which is the reference iNat uses). There were literally hundreds of changes to make, including species splits, lumps, changes at the family and even order level. This took more than a month to several people to make all the changes.
People have (rightfully) pointed out how that proposal would be impractical for invertebrates or other taxa with few identifiers. But even for birds, that include some of the most commonly observed and IDd taxa, many of the newly-split species have been observed by less than 100 people, some have no observation at all. Should we not follow the taxonomic updates because noone is an identification expert of every species?
Moreover, the bird changes (and the fish ones, that I also help in curating) are following well-respected databases, with each taxonomic change being supported by scientific litterature that is systematically referred to in the database. I know itâs the case for many other taxa as well.
Should we refrain to make changes because we donât âtrustâ the experts that maintain these databases? Besides, most of us also are experts. Iâm a systematic zoologist myself. Even if I canât ID most birds or fishes, Iâm both familiar enough with the groups and with the scientific litterature to critically assess the litterature on contentious changes.
Maybe OPâs suggestion is that changes are too often and are disruptive for users (I had a few users complaining on the bird changes). I wholeheartedly disagree with that: one of iNatâs strengths is that it closely follows the scientific consensus on taxonomy, via these databases. It makes it a precious ressource, not only for IDing and recording observations, but also to have up-to-date information on e.g. the taxon list in a given area.
This is essentially the root of the problem as we canât revert destructive taxon changes. I recently made a feature request asking all IDs to be stored in one field that did not change and a second field could display the current iNat name, which would change whenever there are lumps or splits related to the name. The response I got was âThanks for the request but I didnât approve it. Storing, displaying, and calculating each ID in two fields isnât feasible for us.â Thatâs the simplest and most logical solution I could think of, so seems like someone needs to come up with a more feasible solution, but I donât know if there is actually a more feasible solution than the one I proposed.