Forcing observations back to Needs ID at subspecies level

I’ve noticed some identifiers who really want observations to get to subspecies level are marking yes to community taxon can be improved on RG species level observations. This pulls the observations from GBIF and forces them back to the Needs ID pool. Is this a reasonable use of the can be improved checkbox? Is it ok for me to check the no box to put the observations back in GBIF, even if only at the species level? Future identifiers who also want subspecies level identifications can always find these observations by looking for things only identified to species level, and I suspect most observers would rather have their observations RG at species than Needs ID at subspecies.
A secondary issue is that the box often doesn’t get unchecked even when multiple identifiers have pushed it to subspecies, keeping the observations in Needs ID indefinitely (or at least until someone thinks to check the no box).

2 Likes

That’s a tricky one. I would say that if you are sufficiently knowledgeable about the taxon to the point where the features necessary for subspecies identification are not visible (in your opinion), then by all means mark “no”. If you don’t know the taxon well enough to make that call, I would err on the side of letting it be.

It potentially becomes a little thornier of a problem when the subspecies ID is based on range only - I’m personally not a fan of those type of IDs (as they are tautological and not based on the evidence), and in those cases I would always select “no” and potentially push the observation back to the species level.

1 Like

I assume it is clear they are trying to get it to ssp because they themselves have entered a subspecies ID ? Meaning they click yes the ID can be improved and put in a ssp identification ?

I really don’t feel this is an appropriate use. Far too often subspecies ID’s are being done based on range or assumption without the needed chararcteristics being visible and/or are being done where there is only one realistic option, in which case it adds no value in my mind. Lots of subspecies are poorly defined or accepted as well.

EDIT - did not mean to be repetitive, must have been typing at the same time as the above reply.

2 Likes

I agree subspecies ID’s are too common and often just based on range.
For the secondary issue @jwidness idenntified above though, maybe the system could just ignore any “yes the ID can be improved” flags once/if the community ID reaches the subspecies level. At that point, it’s essentially meaningless and ignoring it is appropriate (and would reduce the time of IDers, etc.).

1 Like

What if 3 people ID to subspecies, all in agreement, and I add an ID for a totally different species? I should be able to check yes it can be improved to put it back in Needs ID even though the CID is at subspecies.

2 Likes

To me that seems like a kind of “off brand” usage of the “yes the ID can be improved” box. The way that scenario plays out is essentially a double-weighted disagreement. That is “I’ve submitted my disagreeing ID but I’m also conveying the same information that I disagree in this box.” I guess I don’t know exactly how what the purpose of the box was intended to be, but my guess would be that that goes outside the purpose.
I would think a better method would be to recruit some other folks to offer IDs. Otherwise, the status of the ID risks devolving to a voting war in the “yes the ID can be improved” box as opposed to the IDs themselves. That’s not ideal for three reasons:

  1. The weighting there works differently than for IDs so it is less consistent
  2. Many non-power users don’t know about those boxes or how to interpret them as they are a little more hidden, so they may get confused or frustrated if an observation doesn’t seem to be conforming to the ID system for determining community ID and what needs ID.
    and
  3. People don’t get notifications about the “improvement” box being checked, so it makes it much harder to follow up on.
    And as someone mentioned already, a lot of times those boxes can get checked but not followed up on later.

So I guess I wouldn’t really want to encourage people to use the “yes the ID can be improved” box in that way.

1 Like

Sorry, I’m not sure which use you don’t really like – the one I described in the original post (to ask for further agreeing ssp IDs) or the one I described later (putting an obs back in Needs ID when your disagreeing ID alone isn’t enough).

As far as I understand, the second scenario is exactly the reason for the checkbox – to get more eyes on the observation from people who only look at the Needs ID pool.

2 Likes

The one putting an obs back in Needs ID when your disagreeing ID alone isn’t enough is the one I feel isn’t optimal. It just doesn’t seem like a great idea to have a two-tiered, less transparent ID system.

My inferred scenario for needing the check box would be when an observation is at a higher taxonomic level but one believes that it can still be at a finer level (ie, if something is RGed at genus or species but could still be ided to species or subspecies). The RG would take it out of the ID pools where most people would be seeing it.

The converse is the situation where an ider would tick the “No, it’s as good as can be” box: when one believes it can’t be given a finer ID.

1 Like

I think this is a really good point about the problematic two-tier system, but I think there are some cases where this approach is valid. I spend much of my iNat time looking for incorrect RG observations, and I think that can be a valid tool when a bunch of identifiers have piled on an incorrect ID and it needs multiple corrections to get it out of RG for the wrong taxon, much less into RG for the correct taxon. I mostly use it for older records when it’s unlikely that many of the identifiers are still active and would remove their incorrect ID. In those situations, the only other solution is to tag a bunch of other identifiers and try to bring it to their attention, but that’s not optimal for spamming folks’ notifications for dozens of observations.

4 Likes

I can see how power users might use the box productively in that way. Although I think if that usage case were to become common it would kind of break the current ID system. One potential thing that could make that better is having the box checks send a notification since then folks on the initial ID could react to it (or the OP would see it).

Out of curiosity, for older records is this really effective? They tend to be at the “bottom” of what gets seen anyways because of their date, so they get way fewer eyeballs on them in most peoples’ standard ID views. I’ve found that the tagging targeted users approach works reasonably well in these cases. While it does take a lot of users to get switch something to RG, it doesn’t take that many disagreeing IDs to just get it back to needs ID (ie even if an obs has 5 incorrect, concurring IDs, it only takes 2 more disagreeing IDs in addition to one’s own to get it back to needs ID). Usually I can pick 2-3 users to tag to check on it which doesn’t feel like spamming. And then, we’re however many closer IDs to getting the Community ID switched, which is the ultimate goal.

1 Like

In total agreement that that checkbox should spawn an automatic notification (although my dissenting ID does, so the observer is getting something).

It is effective for older records in that it effectively reduces the # of incorrect RG observations. That’s my primary goal, rather than increasing the # of correct RG observations. If the observer isn’t invested in their observations being correctly labeled and never follows up, I’m fine with letting it languish as Needs ID. If I use the tagging method, there is no simple way for me to follow up and ensure that it has been moved out of RG (e.g., if not enough of the people I tag chime in with a dissenting ID).

3 Likes

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