Platform(s): all
URLs: n/a
Description of need:
A number of changes have been introduced in the past year or so in an attempt to resolve complexities and issues surrounding infraspecies / subspecies in relation to the data quality assessment, observation taxon behavior, and when and how things become research grade.
My impression is that these changes have been attempts to alleviate (but not necessarily solve) the underlying issues and complexities by means of small and minimally disruptive (from a software engineering standpoint) software changes. However, because these changes “double down” on a system which conflates two separate concerns, they’ve (in my opinion) failed to satisfy every perspective and use case. This failure is evidenced by yet another (and ongoing) discussion to make another such change – see https://www.inaturalist.org/blog/122781-proposed-change-to-subspecies-labels-try-the-demo-and-vote .
In my opinion, every (or more) perspectives and use cases will continue to fail to be well met until we separate the concerns of whether something needs further identification and whether something should be exported to GBIF – a separation that many have requested in various forms over the years. This feature request proposes and details a separation of those two concerns via a new concept called an “Export Taxon”.
Feature request details:
Observation Taxon: The logic to determine what the observation taxon is set to should be the same across all taxonomic ranks. Any previously implemented behavior within this logic which results in a different output when the existing or potential new observation taxon is at or below the rank of species should be removed.
I may be missing a few details here, but if I understand the current logic correctly, the new observation taxon determination logic should be something like as follows:
- Initial value of Observation Taxon, prior to any identifications, is Unknown.
- If active IDs from the observer are present and the observer has opted out of community ID, then the observation taxon is whatever the observer identified the observation as.
- If active IDs are present and the observer has not opted out of community ID, then the observation taxon is “led along” by an evaluation of community taxon consensus and leading identifications.
Community Taxon: I’m not aware of any behavior within the community taxon setting logic that changes when we’re dealing with a rank of species or below. To the extent my understanding aligns with reality, I don’t believe any changes to how community taxon is set are needed. It should continue to be set in line with the details provided here: https://help.inaturalist.org/en/support/solutions/articles/151000173076-what-are-the-community-taxon-and-the-observation-taxon- .
Export Taxon: Implement a new entity called the Export Taxon. The export taxon should be set to the lowest ranking taxon which both the observation taxon and the community taxon agree upon, but only once/while that agreement exists at a rank of (?) or below family. The export taxon should take the place of the observation taxon in terms of what gets sent to GBIF, and could be made visible on observations somehow.
JAN 20, 2026 EDIT: I originally intended, but neglected, to clarify that the community taxon should not just agree with the observation taxon at some rank, but the community taxon should itself have more than 2/3rds agreement before it is considered to “agree” with the observation taxon at any rank. I spoke to this oversight here – https://forum.inaturalist.org/t/add-new-export-taxon-to-solve-all-of-the-problems-with-research-grade/74888/5?u=regnierda – but I’m making an edit here too because this detail has a very material impact on when and how things get exported to GBIF.
Needs ID
The Needs ID status/indicator should be reworked to convey whether the community taxon can be further refined. The factors that should dictate this are as follows:
- Community Taxon
- is one present
- does the taxon lack any lower ranked taxa
- is there more than 2/3rds consensus
- DQA criterion: Based on the evidence, can the Community Taxon be improved?
One could argue to also add “has photos or sounds”, “evidence of organism”, and other DQA criteria to the above, if so desired. One could also argue that the number of “can’t be improved” votes should exceed the number of “can be improved” votes by 2 (or exceed a certain ratio) in order to kick something out of Needs ID. I say “one” could because I won’t here argue those points but do think they’d be worth exploring as a later, “Phase Two”, iteration upon this idea.
The Needs ID status/indicator should be separated from the Casual and Research Grade statuses/indicators. Either an observation Needs ID or it doesn’t. An observation being Casual or Research Grade doesn’t mean that the observation doesn’t Need(s) ID.
Research Grade & Casual
The Research Grade status/indicator should be reworked to separate it from the Needs ID status/indicator. The factors that should dictate whether an observation is Research Grade are as follows:
| Research Grade Qualification | ||
|---|---|---|
| Date specified | ||
| Location specified | ||
| Has Photos or Sounds | ||
| (REMOVE) Has ID supported by two or more | ||
| Date is accurate | ||
| Location is accurate | ||
| Organism is wild | ||
| Evidence of organism | ||
| Recent evidence of an organism | ||
| Evidence related to a single subject | ||
| Evidence accurately depicts organism or scene | ||
| (REMOVE) Community Taxon at species level or lower | ||
| (REMOVE) Community Taxon matches Observation Taxon | ||
| (REMOVE) Based on the evidence, can the Community Taxon be improved? | ||
| (NEW) Export taxon exists (could reword to be less abstract if so desired) |
Further Comment
It’d also be worth updating search filters to allow ones to easily surface observations based on observation taxon, community taxon, and export taxon. Minimal configuration could be done upfront so that things under this scheme are at least usable, and then additional configuration could be done later to really polish things up.
I understand that this idea involves reaching deep into the engine and making non-trivial changes to how things are working today, and would require work in several of the iNat repos. While this design proposal does involve a good amount of work and does add some overall conceptual complexity, it is ultimately cleaner in that it separates unrelated concerns and simplifies what certain concepts represent and how they behave.
Some more practical benefits of this design/proposal:
- Reduces contention surrounding and increases value of Community ID Opt-out observations by allowing them to go to GBIF under more circumstances while still keeping the observer in control of their own observations.
- Data goes to GBIF sooner instead of sitting limbo for as long as it does under the current system. If this proposal as worded would result in data going to GBIF too soon, I suspect there are ways that could be managed. The research grade qualifications could be tightened up a bit; or additional behavior could be added – for example, logic saying that Needs ID status excludes something from becoming Research Grade up until the observation has reached a certain age or something.
- Reduces some current incentive to abuse data quality assessment questions, provide guess IDs, etc. for the sake of getting something to research grade.
- Those that want to ID non-wild organisms can do so more easily (an often and long voiced need), while those that only want to ID wild organisms can still do so just as easily – and the needs of the two no longer conflict as much as they do today.
- Reduces some of the conflict between the needs and workflows of those who care about / believe in / use subspecies / infraspecies and the needs and workflows of those who don’t.