Taxonomic Swap 123184 (Committed on 2023-02-24)

unknown
Added by bdagley on February 24, 2023 11:36 PM | Committed by bdagley on February 24, 2023
replaced with

Comments

This should have been set up as a taxonomic split rather than a swap, especially given the large number of observations that now need to be manually updated.

Posted by jakob about 1 year ago

Can you explain why in more detail, concerning the taxon change and what observations needed to be manually updated. My understanding was that a subspecies was elevated to specific rank in literature, and so that a taxon swap would automatically replace all those subspecies IDs with the new species IDs. Is that not correct and not what happened? I only checked one, but it looks correct. In the event that that portion of the change was correct, I'd assume you may be referring to species-rank IDs that now are being manually updated to this specific subspecies. If you meant that there may be additional taxon changes that can be made, but it wouldn't seem to make this change incorrect. I'd need to know what exactly is being claimed wrong about this change to comment further.

Posted by bdagley about 1 year ago

The issue is that not all observations of this taxon will have been identified to subspecies level, and only those with subspecies IDs have been transferred to the new species. This swap is not incorrect but it is incomplete - a spilt of terea s.l. into terea s.s. and elgiva is also needed, with atlases for the new taxa.

Posted by rjq about 1 year ago

Exactly, it was inaccurate to say I did something wrong. Adding onto that though, I also found that the original request description was somewhat vague or unclear, so it wasn't clear to me that this additional taxon split was needed. Because in some similar cases, all that is or can be done is to do the first step as I did, not all cases necessarily involve or allow an additional step of a split.

Posted by bdagley about 1 year ago

Neither did I say that it was inaccurate or wrong. However, it is important to understand what the taxonomic change means. If you're swapping Junonia terea elgiva with Junonia elgiva because the taxon elgiva has been elevated to species level, then this means that the original concept of Junonia terea has been changed. To reflect that change, the old concept of J. terea needs to be split into a new J. terea and J. elgiva, ideally by atlassing both taxa so that the IDs of the old J. terea will be automatically replaced by the new taxa.

This approach should be always taken where a species A is being split into species A' and species B.

Posted by jakob about 1 year ago

Actually, your first comment does suggest that I did something in a wrong or at least unideal way and which had some bad extra consequence ("This should have been set up as a taxonomic split rather than a swap, especially given the large number of observations that now need to be manually updated." [italics added]).

Anyway, I don't entirely agree with the rest either. As said for one thing, the original request was somewhat vague ("Junonia elgiva Hewitson, [1864]. Pyrcz et al., 2021. Stat. rev. [with a link to an article]"). Technically or ideally, the requesting users are supposed to more clearly indicate what changes are needed and (for those who know curation) the best way to implement them on iNat. In requests I've implemented atlasing often hasn't been involved, and is almost always discussed upfront if it is because it can be complicated or time-consuming. The related thing I mentioned is I also think that in some similar cases (involving subspecies) atlasing isn't even possible, e.g. if subspecies co-occur in the same locations, or isn't necessary, e.g. if taxa haven't been observed or are impossible to ID to species or subspecies level. Or, sometimes atlasing is just too messy geographically or simply takes to long to setup to be feasible, depending ont the specific case. Anyway, I haven't looked back at that publication source, but potentially could agree that an additional step of atlasing could now be done and would be useful, and anyone's welcome to implement that. I'll only consider implementing it if the atlasing instructions are given in full.

Posted by bdagley about 1 year ago

I do find the isolated taxon swap problematic for the reasons outlined above as the basic change should be a taxonomic split. I recommend looking into relevant paragraphs of the curator guide and further background in the iNat forum. Atlasing is indeed not always possible, but in such cases the previous species IDs should fall back to genus level as the concept what that species means has been changed. As a side note, there's usually something wrong if 2 subspecies supposedly occur in the same location.

Posted by jakob about 1 year ago

Btw, I wouldn't expect users flagging taxa for taxon changes to specify in detail how the taxon change should be made - it's the role of curators to understand the appropriate changes and steps if they are willing to implement the suggested update.

Posted by jakob about 1 year ago

Replying to the first part, I don't see how the taxon swap I completed (automatically replacing prior subspecies IDs with the new species IDs) was wrong. It in fact seems like the only way to correctly deal with those subspecies IDs (particularly), no? This shouldn't be conflated with how you also next mentioned a second taxon change yet to make. I have agreed that the additional step may be best although the first step didn't detract from it. In other words, there are two steps required and you mean to say the second step is missing, but incorrectly said the first step was wrong. Also, two subspecies do co-occur enough for it not to be uncommon. You next suggested that species IDs should become genus IDs in the taxon change to come. I actually am familiar with this and have used it in a bee taxon change before. Yet, I haven't at the moment looked back into the article or changes at all, since I'm unsure if I'm going to make them. But to clarify, I didn't express any disagreement on what to do for the second taxon change, I didn't express any opinion.

Posted by bdagley about 1 year ago

Re: should requesting users give info, I've thought about this recently so will give my take on this here also as a website suggestion if additional people read this. The guidelines ask users to include a source, which is often left out. Also, sometimes flagging users misinterpret a source, i.e. make an actually incorrect request. That makes the curator's task more difficult. Website docs (in discussing why iNat uses Authority sources) suggest curators or staff shouldn't need to read academic papers at all, to avoid paywall/equal access issues. Yet, it often is actually necessary to check them, because a flagging user could misinterpret sources, and to determine ideal taxon changes.

What this seems to suggest is it would be more helpful, faster, and accurate to require as much info. upfront as possible. I'd prefer a new guideline that asks flagging users to give a source (ideally full-text link), summarize the changes needed, and suggest ideal taxon changes to use (if known), such as if they were required to enter the info. into fields of a new form, or just to write flags as usual but in that format. Also, users should indicate if (and only if) they have uncertainty, to allow curators not to have to fact check/doubt every request (although curators may still need to fact check some). On that note, I consider flags stated to be uncertain (e.g. "is this taxon a synonym"?) to be have more downsides than uses, because curators need to fact check them even though the change may not turn out to be needed, and often no one determines the solution so curators just keep accidentally re-reading the same open flags. Also, I suggest that especially users who make many requests consider applying to be become curators, given their interest in taxonomy. A final matter that users could be better informed about is that requests should in most cases be for identifiable taxa which have or will soon be observed. Currently, there are numerous flags saying "such and such species is missing," which leads me to wonder if some of those requests are to "complete the database" (which isn't what iNat currently wants).

Posted by bdagley about 1 year ago

@bdagley The key point, as noted above, is that it is generally wrong to raise subspecies to species level without also splitting the ancestor species. An exception could be if all observations in the range of the new split species had been already identified to subspecies level, so would be transferred across (though even then it is better to carry out the split), or if there are no observations of the subspecies to be split. Neither was the case here, so only partly carrying out the taxon change process left many observations of elgiva wrongly identified as terea. I have added the split to complete the process https://www.inaturalist.org/taxon_changes/124510

Posted by rjq about 1 year ago

More generally, there is no requirement for curators to enact a split just because a user has requested it - users are not always correct. It would be great if users could provide all necessary details, but often they will not be specialists and may have just seen the split on the web or a field guide. Especially where there is no taxon framework, it's hard to know if a split should be carried out, so I usually leave these for taxon specialists. Here there was a reference provided in the flag , but it doesn't look like the right reference. However there is another paper that supports the split, and it does seem to be accepted.

Posted by rjq about 1 year ago

Actually the key point as noted above is that my first taxon change wasn't wrong. It was the only correct way to modify the subspecies, so your statement describing it as wrong is incorrect.

Posted by bdagley about 1 year ago

Add a Comment

Sign In or Sign Up to add comments