Can Someone Explain This Quirk of the Community ID Formula?

User uploads an observation identified as Genus A. User then disagrees with their initial ID, bumping it to Order A.
Different users identify this as Genus B, belonging to Order A.
But this observation is stuck at Order A instead of Genus B. Why?

Here’s a link to a specific example of this.

Is this the intended functionality, and, if so, what is the reasoning here? These subsequent IDs are not in disagreement with the original user’s ID.

1 Like

The issue here is that a “disagreement” disagrees with ALL intermediate taxa, in this case including the family Faviidae. Because the new species is also in Faviidae, it reads as disagreement.

The alternative would be that disagreements only disagree with the specific taxon in question, but that causes other problems. It’s been discussed on this forum before, and I think the general sense is that the current implementation causes less issues. As there are many cases where you do want to disagree with the intermediate taxa.


See more details here.


This seems like a very inelegant solution. In going through some older observations just now, I’ve found multiple instance of this problem.

There’s more here:
Around post 60 the discussion moves to “branch” vs “leading” disagreements.

1 Like

Does this also happen if an ID is first withdrawn, then replaced by the same user? It sounds like it shouldn’t, based on the rationale for how disagreement works, but I’m not sure how to find an example to check.

No, it doesn’t. So in theory a solution for this problem is to first withdraw and then add a new ID.


This is literally the example I provided above. The original user uploaded, identified, then disagreed to Order-level.

That is, manually withdraw the ID, then add a new ID. Just adding a new ID without withdrawing first will pop up the disagreeing text can result in your example. If you manually withdraw the original ID first, it doesn’t cause this issue, because there’s nothing to disagree with.

I agree that reidentifying your own observation before anyone else has added an ID should withdraw, then ID, to prevent this disagreeing ID confusion.


Would just removing the ability to “disagree” with your own ID solve this issue?

1 Like

That does seem to be the most direct way to deal with this. I suspect though that now we’d have to keep track of three separate ID’s for each observation. The observation ID (displayed on top), the community ID (displayed to the right), and then “one’s own ID”. I wonder if there are any objections from the code side.

That wouldn’t solve the problem where the disagreement is with a different user’s earlier ID, as here:

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.