Description of need:
Currently, it’s not possible for better-informed user to correct mistaken Annotations added by others. Instead, it’s only possible to add a “downvote” disagreeing with their annotation, or manually ask them to change/remove it (impossible for annotations made by users who no longer visit the site!).
This differs from the way Observation Fields are handled (most recent change overrules any previous one) and the broad rule for taxon ID (a single disagreeing ID changes the Community ID unless many previous agreements are present). The result is that a power user working through large volumes of observations simply can’t update with correct information as they go.
In my current project, the implication is that when I download datasets through the API, I would either need to write additional code to remove bad data on my end using the disagreement records (hypothetically–not sure this is possible since I haven’t tried), or manually change the records in my own dataset. Both approaches leave the bad data on iNat for future users to deal with, not showing up in the correct search filter results, etc.
Feature request details:
Change the way Annotations handle disagreement to match Observation Fields: the most recent edits by any user are the “official” ones used for search filtering and given in the API output. If desired, previous data could still be stored somehow, but it shouldn’t remain as the priority value.
I see sex annotated as “cannot be determined” all the time when it’s clearly a male or female. Sometimes I leave a comment, but I rarely get a reaction, so I increasingly don’t bother.
This system is also dissatisfactory from the other side. I use annotations a lot on my own observations. But I know I make mistakes at times. How do I find out when someone disagrees if I don’t get tagged? I assume that I can use URLs to search for such cases, but that’s a lot of homework.
I have once unintentionally selected a disagreeing choice of an annotation and it seemed to stick. I don’t know if that was only temporary, but I wouldn’t want to alter someone else’s selection purposefully. That feels inappropriate for the iNat concept.
I would prefer a vote count similar to that for taxon - if that is reasonably feasible.
Not all annotations are correctable since sometimes the correct value is no value. For example, a plant may exhibit evidence of flowering without being “budding”, “flowering”, or “fruiting”, in which case none of the values of Plant Phenology is correct.
However, every annotation is resettable, that is, you can always start from scratch. Performing a reset may be all that’s required in some cases.
I’m merely suggesting different terminology. A reset is the more basic operation. It solves all the problems identified in this thread. It is more easily understood and therefore has a better chance of being implemented.
Disagreeing with an annotation also knocks it out of the search results for things that don’t have a particular useful annotation yet but could use one. From a high-volume annotator perspective, that’s like the record is falling into a little black hole.
The rules should be probably be weaker than for IDs, though. A simple majority (like the DQA voting) would be sufficient (and probably much easier to implement). If there was a pressing need to reset an annotation, pinging a few knowledgeable users would overturn the vote quickly enough.
I’m simply advocating for Annotations to be treated the same way as Observation Fields–I don’t know that there’s a strong case that one deserves a higher bar of proof than the other? My perspective is somewhat skewed by my use goals, which involve annotating high volumes of observations at once; I don’t want to have to bother my collaborators every time I run into an error, etc. But I’m just putting forward my opinion; any change to the existing system that at least makes correction possible would be solve the major issue.
There is currently a really kludgy way to reset/delete annotations. If the record is switched over through an id disagreement to a taxon that cannot carry the old annotation(s), they will just be deleted. Quickly reverting the disagreement does not bring them back.
That applies to any/all mismatched annotations on the record, including the ones that were formerly correct, so it has the potential for abuse. If doing this workaround, it’s important to make a note of all current annotations so that they can be restored to the observer’s intention after reversion.
(All the times I’ve already annotated a Lepidoptera record and then accidentally selected Fabaceae in the pulldown instead of Papilionoidea when typing in “pap” to id farther, I’ve erased the work I’ve done and had to go back.)
Yes, being able to make corrections is the core functionality we need. But with that in place, I think the number of problem cases left over would be relatively small, so a simple majority voting requirement woudn’t result in a significant extra burden.
Should Annotations really be treated the same as Observation Fields? The latter are arbitrary, free-form metadata that don’t propagate to other parts of the main iNat interface, and users have control over who can add them to their own observations. By contrast, Annotations are much more strictly defined and have a much broader impact on the site as a whole, which would seem to imply that some form of community consensus is desirable in helping to maintain them.