Leading subspecies IDs should change the obs taxon like leading IDs of other ranks

This is how the current system works


I’ve just had a run-in with this bug myself.

Why are we still displaying higher-order IDs rather than the leading ID of an infraspecies, or at least the parent species, if there is a problem with the way RG is coded? If I apply an ID for an infraspecies, I am also implicitly applying an ID of the species. In the case of the autonym, I am adding an ID for the species explicitly.

If the problem is with the way we handle RG, then we should be turning off RG until we find a way to solve this, not preventing identifications of infraspecies. I find the current concept of Research Grade a bit of a joke currently anyway. It is constantly gamed by a relatively high proportion of users blindly and instantly agreeing with external IDs.


Yes, but the displayed Species doesn’t change if a subspecies/var./etc. is suggested to an observation at genus or above. The platform just acts as though you didn’t add an ID at all. Shouldn’t it at least move it down to the species level until someone agrees with the subspecies?

1 Like

See the very second reply in this topic (quoted below). I think people, including iNat staff, generally agree that that would be ideal, it’s just an issue of implementing it. The ID system is pretty central to the way iNat works, and I suppose fiddling with it has the potential to mess things up pretty seriously.


Thanks, seems I misread what he was saying there.

1 Like

I see this complication stemming from the RG status only being able to be given at a level of species or below. Various coded rules have been added to handle this that don’t apply to other levels. Thus iNat behaves differently in these circumstances and appears like an error when it is noticed by users because no explanation is given on the observations’ pages.
Stripping out the RG level limit rule to remove this complexity would either fix this or extend the problem to all other observations and potentially make the site unusable.
An alternative is to add features and display information to deal with it. To avoid all observations becoming more complicated for every user perhaps this could be limited to the observations or taxa that need it.

Getting rid of RG altogether would solve this bug.

Regardless of whether it is acting so by design (since the alternative is worse), to me this is a functionality shortfall caused by the need to add extra gamification to the iNat experience.


Research grade can be granted at higher taxonomic levels than species.

Regardless of what you call it, how you calculate it, label it (or even if you put a label on it at all), you still need some criteria that determines that some level of consensus on the identity of a record has been reached and that it no longer shows in the default ‘needs to be identified’ sections of the site.

That function is probably the most important thing the Research Grade classification does (I’m assuming GBIF could get whatever dataset they wanted based on the fact they use a custom query to determine records to receive, so that query can simply be written to reflect what they wish to get)


Can you not do that while still presenting users with the ID at the rank it has reached, or even as species when there are leading infraspecies IDs? I was under the impression from the argument so far that it’s the hacks needed to present RG that cause observations to be presented to users ignoring infraspecific IDs.

This also leads to a data loss situation, and a mess come time to do splits: two subspecies are different taxa, and often get split eventually into different species. If I you encourage users to not use subspecies IDs because they don’t do what one expects them to do, then everything will have to be individually identified in the event that one of the infraspecies is upgraded to species.

I’m curious if you think this is a real deterrent for identifiers seeking to use subspecies IDs. In taxa that I ID, some people use subspecies and some people don’t, and from what I can tell, it has nothing to do with how the system handles it, and is mostly related to convictions about whether location alone should be used to ID to subspecies.

This is not true for most splits. The only time this is true is when no portion of the range can be unambiguously assigned (via atlases) to the output species.

(Note: further discussions about when and why people should use subspecies IDs are probably best had in another thread, e.g. this one or this one.)


Hard to say, but I think it would be when adding a subspecies or variety ID results in no change to the ID from genus. I think this is bad UX. Frustration can lead to ceasing a behaviour.

BTW I find it hard to think of infraspecies, especially varieties as geographic concepts. If they can’t be distinguished morphologically, they probably should not be used. Botanically there are many instances of co-occurring infraspecies that can’t be separated with an atlas.

For me it is. It even outweighs my annoyance that refining IDs are not considered agreeing for notification purposes–that is if I choose not to put the subspecies but the next person does, I’ll be notified.


How to see all observations with an infraspecies?

For example I have this observation that I have ID’d down to ‘var. hypoglauca’
Adiantum hispidulum (Rough Maidenhair Fern) from Talegalla Weir QLD 4650, Australia on April 11, 2020 at 04:41 PM by Scott W Gavins · iNaturalist Australia (ala.org.au)

but the species page says there are no observations of ‘var. hypoglauca’. I assume if it is not showing my observation that there may be more that are not shown. How do I find them?

Variety Adiantum hispidulum hypoglaucum · iNaturalist Australia (ala.org.au)

To find all observations with an ID of that particular variety, try the URL parameter ident_taxon_id=1002729

Or the IDs themselves:

As far as seeing all observations with an infraspecies ID, I think the only way is by using the API. @pisum has created a way to more easily view a list of IDs that meet a certain criteria here: https://jumear.github.io/stirfry/iNatAPIv1_identifications.html?hrank=subspecies (all IDs at rank subspecies, variety, form, or infrahybrid)

Thanks for the info.


I meant to clarify that I was referring to a particular infraspecies so the info you provided at the top of your comment covered that.

So I assume then that there is no iNat GUI to generate a url with something like ‘ident_taxon_id=1002729’ in it?

1 Like

Unfortunately no. One of many search queries not listed in the user interface: https://www.inaturalist.org/pages/search+urls#active-id

Shouldn’t this be RG as Junco hyemalis?

Observer has opted out of community id

1 Like

Oops, I didn’t notice.

In a recently closed redundant thread @fffffffff mentioned “impossible to find a workaround”. I just wanted to point out that there is one that works in typical situations, flow is

  1. first id is broad category (eg, Lepidoptera)
  2. second id is subspecies (eg, Limenitis arthemis ssp. astyanax)
  3. After this, record stays in the “Lepidoptera” pile, as far as normal identifiers can see.

An inconvenient workaround for 3), mentioned above, is for the first id to be withdrawn.

A more convenient workaround, if there is no one on hand right away to offer a second subspecies id in agreement:

  1. third id can be something narrower within the identifier’s capability although not to subspecies (eg, Papilionoidea or Limenitis or something in between those).
  2. Usually, the record will now bounce out to the ssp pile for identification at “Needs ID” level
  3. Subspecies-capable identifier is now more likely to see it, and comes by to confirm = Profit!
1 Like