iNat doesn't seem to update community ID (the one displayed for an observation) properly in certain cases

I have encountered the following problem several times. Not sure if it is a bug or by design, but it seems to contradict iNat’s approach to picking the ID for an observation. An example with some detailed comments is
It happens if the original ID suggestion is incorrect by a lot, that is, the organism actually belongs to a different higher-order taxon. I, as a reviewer, may recognize this, but I’m not an expert of what the observation shows, so I suggest the highest-order taxon that I believe the organism belongs to, and “disagree” with the original ID.
This usually alerts other reviewers to take a look, and additional suggestions then narrow down the ID while AGREEING with my higher-order taxon suggestion. What doesn’t seem to make sense is that iNat then treats my suggestion as if it disagrees with the later IDs, even though it does not. I actually have to “withdraw” my (correct!) ID suggestion in such cases in order to have iNat update the displayed ID.
This is completely different from the behavior when the first ID suggestion is a high-order taxon that successively gets improved by later suggestions (in which case iNat automatically adopts the most precise suggestion).
Hard to explain, but the example referred to above should make it clear, I hope.

1 Like

Welcome to the forum!
It’s intentional, but there has been a lot of discussion about potentially changing it. You made a “branch disagreement”, but expected a “leading disagreement”.

See related topic and blog post.


Thank you for the quick reply! I’m glad to see that you understood exactly what I was trying to explain.
I’m still not clear though how I can indicate that I’m intending to make a “leading disagreement” rather than a “branch disagreement”.
When making my suggestion (disagreeing with a previous incorrect ID), I only have two options. Obviously, in a case like this I will choose the one that says, “this is definitely not the above taxon”, because that’s what I’m quite certain about. The other option would not change the displayed ID (right?), so other reviewers would be much less likely to stumble on the observation. (Some reviewers actually specialize on trying to narrow down higher-order taxon suggestions.) So that option is neither practical nor would it agree with my notion of scientific integrity.
So, if I understand correctly, the current process forces the reviewer to choose a “branch disagreement” even though in most cases, this is not at all their intention. I agree that this is internally inconsistent with iNat’s logic.
Essentially, the way it works now, the process forces me to withdraw a correct choice for which I had no alternative, and that was made with the intention to help another user as well as iNat’s database. This doesn’t sound right to me (of course, unless I misunderstand this).

1 Like

You can’t, all you can do is withdraw after more ids are added or add another id. Usually people tag others in such situations, so you’re less likely to miss a disagreement that doesn’t allow CT to refine, another way is to either try adding ids of lower level taxa or tag experts in those, so they add their disagreement of a lower group.
That’s how current system counts weight of each id, if staff will be able to create a better one, they definitely will, but it’s not as easy as it may sound.


Yes (@marina_gorbunova ), that’s what I understand now.
I’m probably missing various other perspectives on this, but based on my experience, it seems very (maybe extremely) unlikely for a reviewer to make a higher-taxon suggestion with the intention to declare, “I am preemptively disagreeing with ANYTHING below the taxon I am suggesting”. The only case I can think of is when it seems clear that the photos simply don’t allow for a more exact ID. But that would still be a subjective opinion, so in such cases I usually do add a comment in this regard, – but without excluding the possibility that another reviewer will be able to narrow it down some more.
In other words (and in my experience), a “branch disagreement” seems to be a very rare thing. Instead, I assume that in almost all such cases, the reviewer’s intention is a “leading disagreement”. So the fix seems straightforward: just make the assumption of a “leading disagreement” the default (rather than the other option).

1 Like

I agree with both your opinion (that almost all users in this situation intend to make a “leading disagreement” not a “branch disagreement”) and your surprise that this bug hasn’t been fixed.

When @loarie posted his blog post in 2019, clearly there was an intention to fix this issue. TBH, without his great illustrations I don’t know that I would be able to get my head around the distinction between these styles of ancestor disagreement.

His proposed remedy was to allow identifiers to explicitly choose one or other type of ancestor disagreement. While that seems fine in principle, there was some debate about how to phrase the three choices so that they would be clear to identifiers and I’m guessing that confusion may have stalled the plan to fix the underlying issue.

My feeling is that there are very few cases when identifiers want to say “By adding the ID ‘Insect’ I disagree that this is a Seven-spotted Lady Beetle or any other taxon on the branch that leads from Insect to Seven-spotted Lady Beetle”. There’s a pretty simple reason for this. If I’m knowledgeable enough to be able to confidently exclude all the taxa on the branch between Insect and Seven-spotted Lady Beetle, I’m almost certain to be able to select some order or family that’s a better fit. Conversely, if I can’t be confident of any ID below Insecta, how come I’m so sure that it’s not anything within Pterygota?

The whole “branch disagreement” thing seems like such an edge case that it doesn’t merit any special functionality. Can’t iNat just switch to treat these ancestor disagreements as leading disagreements? I can see there might be a case for genus- and family-level IDs where the identifier believes that the observation cannot be identified more precisely. However, for that purpose we do already have this DQA flag: “Based on the evidence, can the Community Taxon still be confirmed or improved? No, it’s as good as it can be.”

Another possible issue is that iNat staff are reluctant to re-interpret previous branch disagreement IDs. Maybe someone who gave an “Insecta” disagreement in the past really didn’t think any ID on the path through Pterygota was plausible. I think that’s unlikely, but I do accept that’s the logic of how iNat has always treated an ancestor disagreement and perhaps we shouldn’t disregard that. If so, maybe new disagreeing IDs can be treated as “leading disagreements” and old ones as “branch disagreements” (while they still exist).

Whatever the cause, I feel that the lack of resolution of this issue has a definite degrading impact on the efficiency of the identification process. A small, but finite percentage of iNat observations spend a long time stuck in ID limbo because identifiers often have no choice but to add a high level “branch disagreement” ID that they can’t reliably find and fix later.