You’re probably right, but it feels like the system is forcing identifiers to stop refining as close to species (I’d say ‘as far’ but I’m not a huge fan of subspecies 
) as possible… (And given that it’s a change, I’d even wonder how many such identifiers will fail to notice observations going to casual when they attempt to refine.)
we each have different workflows. But I do check, each time, that my ID and CID are where I expect them. If your new ID withdraws your previous active disagreement - that square peg has to be bashed into a round hole - which sometimes takes me a few attempts (and some of those times are because another identifier has accidentally withdrawn their intended disagreement). And I check why this obs is Casual, where is the unexpected glitch?
Prompted by this recent change I am working thru subspecies and variety for the Cape Peninsula.
I didn’t say that IDers should be doing this. I said that it happens and my experience suggests that it is not uncommon – and also that IDers may not consciously notice that their ID is not the same as the community ID, given that the community ID is not explicitly displayed anywhere on the observation page in cases where the community ID is different from the observation ID.
So whether or not IDers are felt to be behaving correctly, the problem created by this change – that is, observations are now in danger of being relegated to “casual” for no reason whatsoever – is not any less real.
It is definitely the case that it is very easy to overlook an observation becoming casual as a result of one’s actions, particularly if one is not expecting this to happen and if there is no logical reason why it should happen. These observations are not defective. If it is felt that observations should not be eligible for RG when the observation ID and community ID are not the same, then it should not be possible to use the DQA, or the DQA (if already entered) should no longer count and the observation should be returned to needs ID. Or I would be perfectly fine with observations that have been DQA’d to make them RG being displayed under the community ID, much the way (until now) observations with a single subspecies ID were displayed under the species. (I don’t see why this was felt to be a problem – those who think it is useful to refine them, can quite easily search for observations at species level; for those who do not find subspecies meaningful, the observations are no longer in needs ID.)
They should not become casual. Making them casual implies that there is something inherently problematic about the community ID and the observation ID not being the same, when in fact this is a perfectly normal part of the regular ID process (your comparison to a relay race with each IDer passing the baton to the next).
The fact that someone might click “ID cannot be improved” while simultaneously entering a refining ID has to do with different reasons why people use this DQA.
“ID cannot be improved” serves two functions. One is a claim about what exact level of ID is appropriate for the observation. The other is taking the observation out of “needs ID” when there is reason to believe that a species ID is not possible – regardless of the precise taxon assigned to the observation.
While these two goals largely overlap, they are not identical.
One of the situations I mentioned above is a good example of how the DQA is pragmatically fairly complex as a result of these different functions:
My point was that it makes no sense to have to click “yes” in such a situation to prevent the observation from becoming casual, which is what one has to do at present.
It is still the case that a species ID is not justifiable – the IDer wants the observation out of needs ID, to help manage IDing workflows and also so that unknowledgeable users will not be tempted to try to add a species ID. It is also the case that in the assessment of the IDer the observation ID cannot be improved, which is what the IDer sees at the top of the observation. They do not see the community ID displayed anywhere. It is highly illogical to click “yes, ID can be improved” for an observation that one does not believe can be improved beyond the ID that one just added. If the observation subsequently gets another subgenus ID, the IDer has to then see the notification, notice what the status of the observation is, and remove their “ID can be improved vote”, in order get the observation back to RG “ID cannot be improved” which is where it was in the first place.
It would also not be really accurate to suggest that the person who clicked “ID cannot be improved” at genus was doing so prematurely. They correctly recognized that a species ID was not realistic, but were not familiar enough with infrageneric groupings to go to subgenus. My experience is that determining what infrageneric categories to put something in is fairly specialized knowledge that is more about familiarity with the structure of the particular hierarchy used on iNat than with knowing how to identify the species (or how to determine when a species ID is not realistic). At least with the taxa I mostly work on, there are a variety of sublevels that are not used in all of the literature, or there are different systems followed by different authors, and they are subject to a certain amount of flux – say, if a new species group is created.
Sometimes it does happen that people use the DQA for observations that someone later determines actually can be ID’d to species and here it makes sense to countervote, but it feels rather nonsensical to do so when the observation still ultimately needs an “ID cannot be improved” vote to make it RG at a level above species.
Given this, it can make an effort to clean up a taxon even more difficult than it already is if one has to find two people who are skilled enough at interpreting iNat’s taxonomy to add the same infrageneric ID, rather than just two people who are willing to ID it and are familiar enough with what features are needed to ID a taxon that they can judge when it is appropriate to use the DQA. It is already the case that the DQA is not used as often as it probably should for many taxa, precisely because few IDers are confident making this call. This change only adds an additional factor discouraging IDers even more from using the DQA (because now they risk inadvertently causing observations to become casual, whether because of their own actions or because someone later withdraws an ID, deletes their account, etc.).
In most cases (with the exception perhaps of species complexes) what is going to be relevant for research purposes is whether a species ID was possible or not, rather than which infrageneric level the ID stopped at. To my knowledge, many of these infrageneric groups are not part of GBIF’s taxonomy, so observations that have been made RG at one of these levels will be interpreted by GBIF as though the ID were for the genus anyway. My Xylocopas may not be the best example because there are only a handful of species in Europe, but for all practical purposes, a “cannot be improved” genus Xylocopa ID is essentially the same as a “cannot be improved” subgenus Xylocopa ID, because in most of Europe unidentifiable Xylocopa observations are also going to be in subgenus Xylocopa in virtually all cases. But I imagine it is not all that different for something like, say, Taraxacum, where there are a dizzying number of infrageneric divisions and few who are willing or capable of navigating them.
(I’ll note here that when I have added a refining ID for an RG genus Xylocopa observation, it is not because I think it makes a tremendous difference from a data standpoint whether it is RG at genus or subgenus. I add a subgenus ID because if it can be refined, it makes sense to do so, but the reason I am looking at these observations in the first place because I am looking at all Xylocopa observations, RG or not, since at present the RG label has very little relationship with whether the observation is correctly ID’d or not. It is also the case that the community knowledge and skill has evolved and not everyone is working with the same understanding of whether individuals other than X. violacea males can be ID’d from photos, so what might have been a reasonable “ID cannot be improved” a couple of years ago may now be IDable in some cases.)
If one uses the DQA as a way of signalling “this should not be ID’d to species”, arguably there is little difference between clicking the DQA for an observation where there is a species ID plus a disagreeing subgenus ID and clicking the DQA for an observation where there is a genus ID plus a subgenus ID. If the point is that there should always be a consensus before an observation becomes RG, there is not really one in either case – the person who entered the species ID may not believe that the observation should be left at subgenus. And yet because of how the ID algorithm works, the former is treated as having a community consensus of the subgenus and the latter is not.
3 Likes
Correct, I made a mistake there. As for what the third identifier can do, they can vote “yes”, which will cancel out identifier 2’s “no” vote".
Just to be clear, I agree the casual thing is a problem and needs to be fixed, but I was also responding to the specific scenarios you mentioned and trying to go through in them in my mind as to what decisions a person might make there.
We just released a fix for this today (totally unrelated to this thread, someone on Github had decided to work on it a few weeks ago). So people will see the community taxon there now.
@loarie and I spent about an hour last night going through some observations on our test server to see how these votes are being used, and playing around with them, just to understand the scope of the problem better how to best mitigate it. For example, if someone votes on the community taxon at family and the community taxon gets moved to genus, that vote doesn’t really make any sense any longer and probably shouldn’t be applied. And yes, making that DQA not votable if the community taxon and obs taxon don’t agree is another potential improvement, although it does come with other consequences. It’s impossible to make a change that doesn’t tug on some other part of the spider web.
3 Likes
That’s exactly what I’ve been thinking…
1 Like
Correct
1 Like
Wait. So now if the observation has a subspecies ID and I ID it to that species (but not subspecies, because I don’t know that) it doesn’t go to RG at either rank??? (I hope I’ve misinterpreted this.)
9 Likes
It depends on whether the subspecies ID was first or subsequent ID. If the first ID, yes, a species ID effectively achieves nothing at all, so you’re wasting your time. If it was a later ID, a species ID will make the observation RG at species level (assuming no disagreements to mess things up).
I still don’t really understand why iNat treats subspecies differently from other taxonomic levels in that way, but that’s a different issue!
EDIT: @sedgequeen Apparently either I was wrong or it’s changed. I’ve just seen a case where genus ID + subspecies ID + species ID = Needs ID at subspecies level. So that’s worse than I thought. :-(
9 Likes
In the one case it wastes the species-level identifier time, whereas in the other case it’s the subspecies-level identifier who probably wasted their time refining to subspecies, if the next ID is at species level.
To help clear up what becomes of the CID, ObservationID, and the RG-Casual-NeedsID outcome in different situations… is there a synthetic view somewhere?
Something like this:
(observer) Species → CID at [rank], OID at [rank] → NeedsID at [rank]
(identifier #1) Subspecies agreement → CID at [rank], OID at [rank] → ??? at [rank]
(identifier #2) Species agreement → CID at [rank], OID at [rank] → ??? at [rank]
…for all combinations of rank and (dis)agreement
Except that as I’ve been saying, for a meaningful percentage of use cases, clicking “yes” is likely to feel completely absurd and counterproductive to what the IDer wants to accomplish. “Yes” puts the observation back in “Needs ID”. If the IDer is trying to determine which observations cannot be ID’d to species and which should therefore be taken out of “Needs ID”, this is moving in the wrong direction. The fact that they happen to be adding a refining ID may be completely incidental to this effort.
If the observation automatically returned to “Needs ID” as a result of the refining ID, one might not be thrilled about it, but it would be acceptable. But in the current situation the IDer has to actively click “yes” (to prevent the observation from becoming casual) which is exactly the opposite of what they want to do. If one is using a “no” vote on the DQA as a way of signalling “I don’t think this can reasonably be ID’d more specifically than the ID I just added” and “this observation doesn’t need to be looked at”, a “yes” vote implies that the IDer thinks more discussion is needed.
When infrageneric levels are likely to be more about familiarity with iNat’s taxonomy than about identification skill per se or distinctions that are meaningful for research uses, it seems to me that this disincentivizes IDers from adding refining IDs beyond what would result in a community consensus. So this seems to me to be a likely outcome:
If I want to sort observations in a taxon into those which can possibly be ID’d to species and those which cannot, it is now more in my interest to agree with a genus level ID than to refine that genus-level ID to subgenus, because agreeing with the genus allows me to take it out of “Needs ID” now, whereas refining it will consign the observation to being left at “Needs ID” indefinitely, with only a tiny gain in precision of the ID in return.
I can also imagine this happening now with cases where an IDer has to decide how to respond to an observation where the observation ID is at subspecies and they are not comfortable confirming the subspecies but do not disagree with it. They have the choice of adding an ID that reflects their level of comfort (species) but is useless because it won’t make the observation RG and several other people before them have already added one, or they can agree with a subspecies ID even though they can’t confirm it from their own knowledge, or they can refrain from IDing it at all (click “reviewed” and move on).
This seems to me to be an undesirable result – IDers should not feel that they have to modify their IDing behavior (providing IDs that are more specific or more general than they otherwise would, or not providing IDs at all) because of considerations about whether their ID will agree with the community ID or not.
Glad to see this has been implemented, but I honestly don’t think it substantially changes the underlying situation, because of the different ways that people use the DQA and their reasons for doing so. IDers may not be scrutinizing what taxon name is written next to the DQA. The observation ID is still far more prominent. And if IDers are using the DQA for some of the other purposes I discussed (managing collective IDer workflows, reducing the likelihood of random unknowledgeable species IDs), they may not be particularly focused on whether the community ID is exactly the same as the ID they just entered, because this may be of secondary importance.
I mean, yes, I agree, but there is also a big difference between refining from family to genus and refining from genus to subgenus (or some other infrageneric level above species/species complex). I don’t know how much the DQA gets used at family level – I suspect probably far less than at lower levels. And a species-level ID on an observation that has been DQA’d at some level above that should definitely return the observation to Needs ID.
But as I’ve been saying, infrageneric refinements are complex because there is more going on than simply questions of “what morphological characteristics are visible (or not) in this observation”. My suspicion is that most DQAs to make observations RG happen at the level of genus or infrageneric levels up to maybe tribe. If an observation is at family, IDers may be reluctant to use the DQA since it will make the observation casual, so I think most people try to refine it further if possible.
2 Likes
I agree, this is a very big change to not be publicly announced. I only saw this when checking for Bug Reports after noticing for days a problem with observations IDed at subspecies level remaining at Needs ID despite all of the non disagreeing species level IDs and being very confused when nothing I did fixed it.
I agree with all of the issues that @spiphany points out. Another big issue I see: I don’t usually ID to subspecies level (as I don’t know much about most subspecies and others I believe are most likely invalid); when an observer adds an initial ID at subspecies, I usually wait at least 6-12 hours before I add a non disagreeing species level ID. This is give some time for another user to potentially ID at subspecies level while ensuring that the observation becomes RG. Now it’s basically the same situation as observers opting out of CID (with their initial ID at subspecies): others adding non disagreeing species IDs will most likely not realize that the observation is still Needs ID (and I think I’ve already seen this happen). I believe this will increase the already large amount of Need IDs observations (especially since some users mass add subspecies IDs to RG observations at species level) and will probably encourage users to even more blindly agree with subspecies IDs.
when an observer adds an initial ID at subspecies, I usually wait at least 6-12 hours before I add a non disagreeing species level ID. This is give some time for another user to potentially ID at subspecies level while ensuring that the observation becomes RG.
I see no point in doing this now as the observation will no longer become RG. (I’m just glad this isn’t actively being applied retroactively.)
4 Likes
I had the same experience.
And since there is general agreement that there are never enough identifiers of any stripe, how can this be good? If there are too few of us identifying to species in most taxa, surely there are vastly fewer who can ID to ssp. So now observations will sit around in Needs ID until a second ssp specialist comes along? Sure, they may technically be at RG at species, but as long as they are in the Needs ID pile, they will continue to pass before the eyes of other IDers who can only ID to species, who may be baffled by an apparent inability to move the needle by doing so.
Gotta remember not to “fave” any old observations that might get thrown back into Needs ID!
Okay, my brain hurts. Now I need to go do something fun instead of trying to make sense of this. It’s a lovely fall day; instead of doing some identifying, or more forum-surfing, I really need to get out in the woods and do some observing…
7 Likes
After letting this change cook for a few days, I am absolutely not a fan of any of the changes that have been implemented. As someone who frequently tries to identify down to the most precise ID that I can, I will almost always apply a subspecies identification on taxa that I am knowledgeable enough about to make such a determination. For example, I like to identify while-tailed and mule deer specifically to subspecies (along with other ruminants, like moose, bison, elk, etc) because they are easily identified to subspecies.
However, since there are no official taxonomic sources that frequently use, or have a deep understanding of the subspecies of big game animals, very few recognized subspecies actually receive IDs to their taxa on a consistent basis (specifically thinking of Columbian black-tailed deer here that do consistently receive their appropriate subspecies IDs) so oftentimes I find myself being the only identifier contributing to a finer ID. In an observation like this one I was the first identifier, period. In this particular case, I was able to rule out every other subspecies of mule deer because of the tail, the only other option would have been Columbian black-tailed deer as they overlap ranges in certain areas within the Sierra Nevadas, and the general size and range rules out any potential vagrant Rocky Mountain or Inyo mule deer, of which either are highly unlikely to show up in the location that this was observed at, anyways. But because my identification being a subspecies identification on an observation that was originally identified at the genus level, but has three supporting species level IDs (four counting mine as well, because it has to be that species when refining even further to get to subspecies in the first place) this observation is still stuck at Needs ID. There is nothing I can do to make this observation appear as Research Graded without pulling my identification at the subspecies level and either resubmit it in a completely new identification, or withdraw and identify to species.
To further add to this, as discussed by many people at this point, interacting with the DQA can unjustly put observations into Casual Grade, and this is absolutely a problem with the current system that never happened in the old system, and this has got to go ASAP. The fact that this observation that I have linked does not show up in any filters that it is “Research Graded” and shows up in all filters that it’s “Needs ID” is completely inaccurate, and I think there are only two solutions to this, either we A: go back to the old system. While it was not perfect, it also wasn’t broken, and now we have broken a lot of things during the process of this change. However, if we still think that this new system has more potential, might I suggest a new system and way of viewing these observations. While I’m sure this will have flaws, and may not even work, I think it’s worth at least experimentation on the staff’s test sites. If you click on a species that has subspecies:
You can click on the dropdown menu to see what subspecies, and how many subspecies, a species has: Instead of incorporating the system we are currently employing, why don’t we allow it to be possible for an observation to be truly be Research Graded at the species level AND have it be Needs ID at the subspecies level, at the same time, by incorporating a dropdown menu that visually shows what the observation is at right beside the name of the organism: And have it show something like this in the dropdown menu:
That way, it actually shows what is being sent to GBIF and whoever else iNaturalist sends their data to so it can be used as useful data. To add onto this, this can apply for observations that are both originally identified to a subspecies, like my example, that have no supporting subspecies IDs, or subspecies ID being added to refine a species ID, this information can be displayed in this manner. Setting it up this way should remove any need to have these observations be stuck in Needs ID forever if originally identified to subspecies, because they will be filtered to Research Grade even if it might be displayed as “Needs ID”.
While I do think there might be some coding limitations to implement such a system, I think this could work, and may allow for the best solution that would make everyone happy because it should also assist in the discussed coarser ID Needs ID vs. Research Grade problems that other people have talked about being an issue here, because ultimately speaking I think this was a huge oversight to add “Community Taxon matches Observation Taxon”.
11 Likes
I’m quite confused by the Trillium example linked in Tony’s post, above. In that instance, there are (now) four IDs at least at species level with one at subspecies level, but the observation remains “Needs ID”? Is that because the Observation ID was at the coarse level of “Angiospermae”? If so, that would consign any and all observations entered with a coarse ID to never reach Research Grade. Or was it because the first lower ID was at subspecies and subsequent ID were not that fine? It makes no sense to leave the observation at “Needs ID” even as more species-level IDs accumulate. Surely instances like that deserve to be RG at species level.
What am I missing?
6 Likes
It makes sense (from a logical standpoint) to leave it as ‘needs ID’ since it is still possible to refine the identification further, as evidenced by the presence of several infrataxa, and at least one identifier going for var. level.
All we have to do is wait for more identifiers to chime in and contribute their ID - some may be as ‘plant’, others as genus, some as var, many as species. A consensus will emerge eventually about the precise identity of this plant: is it var. ovatum, and if not, what var. is it? No hurry, wait and see.
Either the ssp ID is valid - then it is Needs ID at ssp.
Or if it is RG at sp, then ‘you’ disagree with the ssp ID.
1 Like
One wrinkle: if you make a taxonomy change and do subspecies before species (intentionally or by “moving children”), observations will now revert to Needs ID.
2 Likes
If it causes people to realize that maybe the previous status quo wasn’t so bad, then maybe that’s the good that will eventually come of it. With some threads complaining that people actually use the CV, and others complaining that people upload things as unknown, it’s clear that there is no satisfying everyone. Maybe it’s time to say that the way it was being done before was good enough for iNat’s intended purposes.
2 Likes
Seems to have fixed a problem but created new problems with this “fix”.
6 Likes
This is kind of the point of my comment, the change completely ignores the dynamics of subspecies entirely. While I get there’s a lot of controversy around subspecies, and I know that a lot of people don’t believe in the concept of subspecies, some people do (myself included) believe they should be recognized, but the problem with this change is that it gives the implication that subspecies don’t matter, and it caters to those who either don’t believe in the use of subspecies, those who don’t identify to subspecies, or those who don’t know how to identify subspecies. That’s why I gave my proposal that I did because I think it would provide the best of both worlds, but definitely does have its flaws and would require further curation to get its best version, but I think that solution should only be implemented if we don’t revert back to the way things were before this change.
1 Like