Browser: Chrome 104.0.5112.101 (Official Build) (64-bit)
URLs (aka web addresses) of any relevant observations or pages: https://www.inaturalist.org/observations/123194570
Screenshots of what you are seeing
Description of problem:
(I assume the problem is as generic as below, but I have not tested that aspect)
Find an observation incorrectly identified as taxon A
Add an identification of taxon B (with B not a parent taxon of A; this automatically disagrees with the first identification)
Have 2+ people add identifications of taxon C, a subtaxon of taxon B
See that your identification is recorded in disagreement with taxon C
(Withdraw, or make a new identification of taxon B explicitly stating no disagreement with taxon C, and observe that the disagreement in the community taxon disappears)
I think it would be more natural to agree by default (this is what normally happens when you’re the first to add an identification and others add more narrow identifications) in these situations.
This is not a bug, but I agree it’s not intuitive. I know there are other threads discussing this, but I’m not sure where.
I might add that I’ve had situations where this was helpful because one person adding repeated IDs had no idea what they were doing.
Yes, this is a ridiculous situation.
I also had it happen to a large number of unique identifications (endangered species, highly endemic, first observations) recently where the data was actually lost/removed from the platform at least in terms of the publicly visible rendered pages.
The official iNat staff response is “as-designed”.
As a programmer I find this blood-curdling. I can’t understand how they can be so head-in-sand about it. I am certain they could deploy a technical solution to but apparently people factors are preventing them from considering this course of action.
I guess we can only hope they change their minds over time, maybe when the people change.
There’re only a few people working on this huge website, so maybe focusing on bugs and big updates (for years) is all they can do.
It’s actually woul be nice to see the same situation but when it’s showing as disagreement, never seen it happen when your disagreement isn’t really disagreeing with future ids (so not like you ided Elaterioidea and it was lampyrid, you chose the correct family).
Does this look like the same issue? https://www.inaturalist.org/observations/6778229 I don’t think I received any notification about a disagreement when the plant went to species, just a message this morning asking me to delete my ID. I knew about ancestor disagreements, but didn’t understand this aspect. I would go back and delete all my IDs causing problems like this if I knew how to search for the observations.
have you seen another case of this kind of issue? i tried to reproduce the issue, and i was not able to:
here’s another unsuccessful attempt to reproduce the issue:
no, i’m asking the original poster.
for what it’s worth,
this looks like a different issue. i think yours is the kind of issue that is described here: https://forum.inaturalist.org/t/community-taxon-algorithm-tweaks/28583. i suspect that others in this thread are confusing this other kind of issue for the issue being described in the thread.
Can you link one of the other threads discussing it? I had a quick search but couldn’t find anything. Tjis behaviour is not something I’ve encounteredt before, even in almost identical situations, so I’d be keen to read a bit more.
That message was from me. Since iNat Won’t Dragon insists that this is - Working as Intended, I am finding workarounds which fly in the face of - only add IDs you are confident of.
I have a hopeful Feature Request in waiting …
I was thinking about this type of scenario:
But maybe it is different if the disagreeing ID is a parent of the initial ID?
That is weird, perhaps I diagnosed the issue wrong. I can however assure you that the red bar was for my identification.
i believe your original assessment. sometimes individual observations sometimes get just stuck in strange situations, and it’s hard to figure out exactly what caused the problem. often, making any update to the observation will sort out these gremlins, and then the best thing is just to move on, since it can’t be reproduced and therefore will be nearly impossible to identify and address the root cause.
unless you have other examples of this problem or know how to reproduce it, i suggest we just move on in this case, too.