User A identifies an observation as genus G1, which belongs to family F.
User B identifies the observation as family F, but disagrees with genus G1.
A new subfamily of F is created, containing genera G1 and G2.
Users C, D, and E identify the observation as genus G2.
Assuming the true ID is G2, at the time user B disagreed with G1, disagreeing at the family level was completely correct: F was the nearest common ancestor of G1 and G2. If users C, D, and E had added their IDs then, user A’s ID would have become maverick.
However, when a subfamily was added user B’s ID was reinterpreted as being a disagreement with the subfamily. This is the bug. User B could not have known a subfamily would be added at some time in the future. As a result, 5 IDs are needed before the community ID changes to G1.
Suggested fix: when tallying disagreements, check whether any relevant taxa were created after any of the relevant identifications, and do the right thing.
I doubt this is a bug and assume it is intended behavior (but will leave listed as a bug report for now for other feedback). I understand the idea behind this, but I think there are at least two problems.
It would seem to require keeping a string of archived updates of the state of iNat taxonomy in perpetuity and then checking each ID against the state of iNat taxonomy at the time it was made. This seems like it would be very complex and resource intensive.
It would make understanding the ID string and CID nearly impossible for users who wouldn’t be able to see what the taxonomy was at the time an ID was made and figure out how the ID is calculated now.
While the current system isn’t perfect, I think it’s a reasonable approach. The only feasible way to address it would I think be to change how disagreements themselves are calculated/administered generally as opposed to having a specific check against different taxonomy states for each ID. There’s been a fair amount of discussion about different ways to handle disagreements on the forum, but they all have various tradeoffs.
iNat already stores the date each ID and taxa were created. Comparing the two dates while calculating the CID is neither complex nor resource intensive.
That’s a point. But I think it’s more important in this case to do the right thing than to be transparently wrong, and probably easier than you expect to be both correct and transparent.
Ancestor Disagreement. iNat decrees that ‘you disagree with future IDs, despite the fact that you have not even SEEN them, to decide whether or not you agree or disagree’. That’s a logic fail.
Seven years ago it was an issue that many taxa were missing in iNaturalist in my area.
Why not solve this by adding these taxa? This problem will become smaller in the future as more taxa are added.
In case it is your own observation that got a hard disagreement from somebody else. Your fly is now back to arthropods and you need 5 people to bring it back to Diptera. Start new: Duplicate the observation and delete the old version that has the disagreeing ID.
In case you want to disagree on somebody elses observation: Avoid hard ancester disagreements. In case you think you really have to put a hard ancestor disagreement - put then at the lowest taxonomic level 1) and stay vigillant 2)!!
If it is clearly a fly, but not a housefly, don’t disagree using the ID arthropods!
Take your ancestor disagreement back, as soon as new identifications come in.
Opt out of Community ID for that one - until enough better IDs roll in. If the CID is correct, then it will be easier to get the first or second agreement. @mention the DISagreeer, if they are still active.
Delete and start again doubles the work for your identifiers.
This might result in the observation reverting to the initial incorrect ID, in case the other identifiers provided ancestor IDs. In the Diptera example, if a fly is incorrectly IDed as Drosophila and you disagree by saying ‘insect’ and the next two identifiers leave IDs of Diptera and Acalyptratae - when you withdraw, the ID will be back to Drosophila.
You would have to withdraw AND after the community ID changed, disagree again, on a lower level (if you feel comfortable to do so)
I would wish that subsequent IDers could also specify disagreements with a certain taxon, even if the community ID is already on a higher level