The observation is https://www.inaturalist.org/observations/2020348 , somebody ID’d it as a beetle and somebody else refined it to Bruchinae. The observer didn’t opt out of community IDs. Despite that, the thing stayed at beetles.
Here is the “What’s this?” popup.
What created the disagreements in lines 8-11 which are intermediate clades between beetles and seedbeetles?
I toggled an item the DQA which at least made it update the leading ID at the top of the page to Bruchinae, so that was obviously just some sort of indexing issue. The reason that the Community ID remains at Coleoptera is because that is the best ID that has the support of >2/3 of >= 2 IDs (Bruchinae only has 1 ID in support of it at the moment). Someone else would need to agree with Bruchinae to make that the Community ID. I’m a bit confused by how that is presented in the breakdown, because of course Coleoptera does not ‘disagree’ with Bruchinae, it just doesn’t support it either.
5 Likes
I see you incremented “Recent evidence of an organism”, but I still fail to understand why this is necessary. In all other obs I’ve seen so far, one coarse ID plus one later finer ID immediately makes the latter one appear as the Community ID, if there is no conflict. Bruchinae would win 1:0 which should be enough, even if Coleoptera has 2:0 (otherwise, a finer ID would never end up as the result because it would always also support the coarser one which would then have one vote more). I hope it’s me who doesn’t understand something, otherwise it might be a bug.
I just went to https://www.inaturalist.org/observations/329110851 which was Arachnida and immediately became Araneomorphae when I said so. The only difference visible to me between this and the beetle is that there is only one intermediate clade (spiders) instead of four.
That’s not what I’m seeing,
Interesting. It is Philodromus now so I can’t check. But the behavior I described is normal and expected, unlike that of the beetle.
I can’t tell the difference between the two observations to be honest. The CID behaves exactly the same between the two of them.
There is a difference between community taxon (the taxon shown on the side panel) and observation taxon (the taxon shown at the top of the page and used in searches etc.)
The observation taxon is, broadly speaking, the most specific ID for which there are no disagreements
The community taxon is the most specific ID for which there is at least 2/3+1 community agreement
So in some cases, the observation taxon may be more specific than the community taxon. (The recent change to how the DQA “ID cannot be improved” button works affects precisely those cases where the community taxon and the observation taxon are different.)
As Matthew noted, forcing a reindex of the observation in question updated the observation ID, so there is not really an explanation why the ID had not updated before except some idiosyncratic error on the backend.
3 Likes
I wonder if this has changed recently, perhaps in connection with the DQA change I mentioned above. Recently when I’ve added ID’s to observations I’ve noticed that a refining ID will briefly be displayed in red on the side bar before turning green, so there seems to be something nonintuitive going on.
1 Like
In the beetle it only happened after Matthew incremented “recent evidence”.
AKA force a reindex, then the DQA can be deleted again.
I’ve never (consciously) encountered a case where the two IDs were different (and therefore didn’t know that they are different concepts). The spider is now Philodromus at the top and Araneomorphae in the community ID.
It happens any time the initial ID is broader than species-level. That doesn’t mean you’ll notice it - but if the initial ID is Family, followed by Genus, Species, then Species again, CID will be nothing (because it takes 2 IDs to make a CID), Family, Genus, Species (RG), always lagging a step behind.
Once you get disagreement, things are different but still follow the same principles (namely, CID is the lowest level that more than 2/3 of IDs agree on).
2 Likes