The other 7 are all in the Ribes genus:
– 3 at genus-level Ribes (support 0.875)
– 1 at species-level Ribes califorrnicum (support 0.8)
– 3 at infrataxa-level Ribes califorrnicum var. califorrnicum (support 0.5 because 2 of the genus-level IDs are seen as ancestor disagreements)
The observation is 11 years old and the observer did not opt out from community ID. I’m aware that “branch disagreement” logic may not work as people intended, and that iNat won’t change the observation taxon based on a single infrataxa ID following a higher-level ID. Neither seems to be the case here.
I removed and readded my genus-level ID and nothing changed.
Any thoughts on what’s happening, or is this a bug?
There are 2 Ribes IDs that disagree with finer identifications (i.e. the variant). The algorithm summary lists 2 ancestor disagreements with the variant IDs. I’m not sure how that would have happened because the community and observation taxon should have been much higher with the ID that is now a maverick. I’m guessing the user opted out of community taxon, the other 2 users both disagreed (they wouldn’t have been able to both disagree unless the user had opted out), and then the user opted back in later.
Note: I don’t think you can disagree with finer IDs if the user has opted out, but maybe you used to be able to.
Except that I don’t believe that’s the issue here. The observer’s initial ID is at infrataxa-level, and there are two concurring IDs at that level as well, plus four other supporting IDs at genus/species level (of which 2 may be counting as disagreements as @thomaseverest points out). Nevertheless the 2/3 threshold at species-level is exceeded.
Yes, it’s pretty hard (at least for me) to construct any sequence of events that created these ID disagreements.
Regardless, the Algorithm Summary shows 0 ancestor disagreements for the species-level ID Ribes californicum and a support level of 0.8 and yet both the observation taxon and community taxon are stuck at Genus Ribes. If it’s the “disagreeing” Ribes IDs that are causing that, then they should be counted as ancestor disagreements and it appears there’s a bug in the Algorithm Summary box.
The algorithm numbers look right to me. I think the sentence right before “Algorithm Summary” is the key: “For the identified taxa that have a score over 2/3 and at least 2 identifications, choose the lowest ranked taxon.” There is only one ID in this observation that is at Ribes californicum.
I’ve been trying to get this to “make sense” as well, but I can’t! The interaction between infrataxon IDs and ancestor disagreements is definitely adding complexity here. Let’s consider those factors separately.
We know that iNat won’t use an infrataxon ID to determine the community taxon when these things are true: (a) there’s only one ID of that infrataxon, (b) the infrataxon is not the first ID for the observation. Put another way, if an infrataxon ID is not the first ID suggested, then iNat requires a confirming ID for the same infrataxon before it even considers setting the community taxon to that subspecies (also requires > 2/3 support). However, in the observation at issue, the first identification is actually at infrataxon level and there is a total of three IDs at this infrataxon level. So this known issue doesn’t apply here.
We also know that iNat still interprets disagreeing IDs as “branch disagreements”, whereby the Ribes IDs by @glmory and @linaceae are interpreted as disagreeing with everything below Ribes. (For now, let’s leave aside the separate issue of how in the world iNat saw these IDs as potential disagreements when the community and observation taxon was presumably “Angiospermae” by that point.) Fair enough, then the Algorithm Summary should show a count of 2 for ancestor disagreements at the Ribes californicum level but in fact it shows 0. The score — 4 / (4+1+0=5) = 0.8 — is consistent with this, but this information does not seem to be feeding into the choice of community or observation taxon.
@sgene: You point to this part of the Algorithm Summary explanation
For the identified taxa that have a score over 2/3 and at least 2 identifications, choose the lowest ranked taxon
and I think you’re interpreting that to mean that iNat cannot select a taxon if there aren’t at least 2 identifications at exactly that level. But many other observations show that’s not how the logic works. For example, here’s an observation that is RG with species-level observation and community taxa based on just one species ID + one infrataxon ID.
At this point, I think there are probably two issues:
A “legacy data problem” with the two disagreeing Ribes IDs. I think iNat stores a hidden field to record what the community ID was that they disagreed with. We don’t know what this was, but it seems to be a disagreement with a more-specific Ribes community ID. That doesn’t make much sense, as the two IDs from earlier in the timeline would have a common parent of Angiospermae.
A UI bug in the Algorithm Summary pop-up. Whatever logic is being followed, it should at least be internally consistent. If we include the two disagreeing Ribes IDs, they should show as a count of 2 disagreements at the Ribes californicum level and we should see a score like this — 4 / (4+1+2=7) = 0.571. Alternatively, if the 4 / (4+1+0=5) = 0.8 scoring shown is correct, then the community and observation taxa should be Ribes californicum (and the observation should be RG).
I was reading this earlier https://www.inaturalist.org/blog/25514-clarifying-ancestor-disagreements, and I thought it was saying that ancestor disagreements are not necessarily branch disagreements, and that only branch disagreements are considered disagreements with all taxa in between. Also, the comments on the two IDs you mention is “disagrees with all previous finer identifications.” Since at the time those two IDs were made the only previous finer identification was at subspecies level, that seems maybe consistent with the algorithm assigning those disagreements to the subspecies level but not the species. But, on the other hand . . . the language for branch disagreements is not what we see in this observation, so I’m confused . . .
Right now iNat has two versions of ancestor disagreement: “branch disagreeing” and “not disagreeing”. In the latter case, these IDs would just show as Ribes with no mention of disagreement. Because disagreement is mentioned, I assumed they must be branch disagreements. We don’t get to see what taxon they were disagreeing with which makes interpretation hard.
I think you’re onto something there! If each of these IDs was recorded as disagreeing with the variety-level ID that could explain what we see in the Algorithm Summary dialog. That specific “disagrees with all previous finer identifications” phrasing seems to indicate the two disagreeing IDs date from a time when the community ID logic worked differently (before explicit “branch disagreement”) and are now treated as “implicit ancestor disagreements”. As @loarie’s blog post states, “They only disagree with taxa associated with previous finer identifications.”
There does still seem to be a bug whereby “implicit ancestor disagreements” can cause the Algorithm Summary dialog to conflict with the assigned observation and community taxa. Maybe this is something that the iNat team hopes will eventually fade away with sufficient new IDs.
It seems this still wasn’t enough, and if we figure the real logic is now 6 / (6+1+2=9) = 0.667 that must be because we still haven’t quite exceeded the 2/3 threshold (even though the score is displayed as 0.857).
It looks like it now reached RG at species level, thanks to an ID by @dianastuder. To be clear my concern wasn’t that the obs should get a particular ID, but that the reported score didn’t match the description of how iNat determines the community and observation taxa. I think this demonstrated that “implicit ancestor disagreements” don’t get accurately reflected in the UI.