Apologies if this is something obvious, but I cannot work out why the community taxa for these two observations are behaving completely differently.
In this sighting, there is an initial ID of Argiope aetherea followed by two subsequent identifications of A. keyserlingi. All three are treated as ‘Leading’ IDs and the community taxon is Argiope:
In this sighting, there is an initial ID of Edessa rufomarginata followed by two subsequent identifications of Musgraveia sulciventris. But in this case, the first is treated as a ‘Maverick’ ID and the second as ‘Improving’, and the community taxon is M. sulciventris:
Why are these two different?? The algorithm summary shows the same disagreement proportions, and nothing has been changed in the Data Quality Assessment for either sighting. Other than the specific taxa in question, the observations seem to be identical, so why are they behaving so differently?
One difference is that in the spider case, both IDs are in the same genus. The community taxon at the genus level therefore agrees with both IDs.
But I’m not sure why in the bug case, the community taxon isn’t the nearest common ancestor of both ID’ed species (which in this case would be superfamily Pentatomoidea). I guess there’s some cutoff for how closely the different IDs have to be related for the community taxon to be the nearest common ancestor, and superfamily is too distant.
Hopefully someone who knows the details can chime in.
It’s even weirder than that, because this is the heading of the bug observation: It is “Superfamily Pentatomoidea (Stink Bugs, Shield Bugs, and Allies) - Research Grade.” If this insect is only identified to the superfamily level it would not be considered research grade.
A piece of information that might have been relevant to this discussion but I don’t think was included in the discussion is whether the initial ID was made by the observer or by someone else. I think iNat treats IDs by the observer differently than IDs by anyone else. In this particular case for both the observations, the initial identifier is the observer, so it’s irrelevant.
Could it have anything to do with the timing of the identifications? In one case, the first disagreement occurred 8 months ago and in the other it occurred 3 months ago. Maybe the algorithm changed some time between 8 months and 3 months ago, but it doesn’t make changes retroactively? Just guessing here.
Yeah, that is definitely weird. Just now I checked “Yes” for “Based on the evidence, can the Community Taxon still be confirmed or improved?”, and that changed the Research Grade back to Needs ID. Maybe somebody had previously checked “No” for that question, but if so, I didn’t see any evidence of it.
This does appear to be a bug, so to speak. The Edessa rufomarginata ID should not be indicated as “Maverick” until there is one more ID agreeing with Musgraveia sulciventris (or at least Musgraveia). The Community Taxon should be matching the Observation Taxon (Subfamily Pentatomoidea) instead of Musgraveia sulciventris.
There is a known issue in iNaturalist where sometimes an observation will fail to re-index after an ID is added or removed. The usual work-around to fix it is to upvote then downvote again one of the Data Quality Assessment items at the bottom of the page, which forces the observation to re-index. That should have happened when
(it appears to have been unchecked again thereafter) – but apparently it did not help in this case. It would be good to avoid any further activity on this observation until Staff can get a look at it.
