As part of our ongoing work improving how iNaturalist restricts sensitive geographic information including processes for deciding when species are threatened by coordinate disclosure, we are revisiting the role of IUCN Red List statuses.
Almost 10 years ago, iNaturalist automatically imported global conservation statuses from the IUCN Red List. Complexity surrounding taxonomy and status vs. geoprivacy concerns have led us to not automatically update these statuses since then. This document describes a new plan for how we will automatically update/maintain these conservation statuses in light of these issues. Weâre piloting this process with reptiles and amphibians (IUCN Red List statuses for amphibians and reptiles have now been updated via the process described below) and plan to apply this process to update the entire IUCN Red List next month if the pilot goes well. The IUCN Red List generally releases updates biannually and we plan to use this process to update these statuses on that schedule.
Taxonomic concerns
In order to fetch conservation statuses from external authorities, the taxonâs valid scientific name on iNaturalist (internal) must match the name on the external authority. If there is an external name that doesnât match any internal name but uniquely matches an invalid scientific name, a one-to-one relationship can be used to fetch conservation statuses from external authorities.
Note that this process is naive to complex taxonomic mappings such as one-to-many (taxon broadened internally) and many-to-one (taxon narrowed internally) relationships. iNaturalist treats these as matches based on the name. This means that in the one-to-many case the applied conservation status may be too narrow. In the many-to-one case the applied conservation status may be too broad and there will be internal taxa that donât have statuses (e.g. Agalychnis taylori).
In the many-to-one scenario, if curators want to duplicate a status (e.g. for Agalychnis callidryas) for a taxon that doesnât have one (e.g. Agalychnis taylori) they are welcome to do so. But do not list âIUCN Red Listâ as the authority. Refer to some other authority if it exists (e.g. NatureServe G-ranks) or leave the authority field blank and describe in the conservation status description how it was manually derived. For example: âAgalychnis taylori was carved-off from Agalychnis callidryas sensu IUCN which has a Least Concern status so I manually applied that status here. See https://www.inaturalist.org/flags/XXXXâ where https://www.inaturalist.org/flags/XXXX is a resolved flag you created on the Agalychnis taylori taxon page to host any discussion about this status.
When automatically updating statuses, iNaturalist will use matching and one-to-one names to update the status for any existing global statuses with the IUCN Red List Authority and create any new ones. For newly created statuses, iNaturalist will set geoprivacy to open if the status is LC (Least Concern), NE (Not Evaluated), or DD (Data Deficient) and to obscured if the status is NT (Near Threatened), VU (Vulnerable), EN (Endangered), CR (Critically Endangered), EW (Extinct in the Wild), or EX (Extinct). See sections below for how iNaturalist treats taxon geoprivacy of existing statuses and other global statuses not in the IUCN RedList.
Status vs geoprivacy concerns
The status associated with conservation status is not always a good proxy for whether the species is threatened by coordinate disclosure. Species may be threatened by other factors such as habitat disturbance. Our default position on iNaturalist is that if the status is secure (LC, NE, or DD) then geoprivacy should be open and if the status is vulnerable (NT, VU, EN, CR, EW, or EX) then geoprivacy should be obscured.
However, there are exceptions where the community may choose to set taxon geoprivacy to open for a vulnerable species or vice versa. When this occurs, a resolved flag should be created and linked to from the conservation status description. The community should work to establish a record that this deviation was intentional any why it is warranted in the flag.
For examples, see Sclerophrys pantherina
and Melanophryniscus stelzneri
If an existing conservation status has a link to a flag in the description, iNaturalist will not automatically update the status to avoid undoing this work done by the community.
As part of this reptiles and amphibians pilot, weâve temporarily avoided updating geoprivacy on 933 global IUCN Red List conservation statuses where geoprivacy is not in the default position relative to status (e.g. open and threatened or obscured and secure) and there is no flag in the conservation decision explaining the deviation. We suspect that most of these are due to drift from updates on the IUCN Red List side and not community members intentionally deviating from the default position. But, if the latter is the case, please create a flag and include the flag link in the conservation status description by September 20th. After that date, we will update the geoprivacy for any of these that lack a flag. You can find the list of these defacto-deviations here.
Other global statuses
The automatic update process will delete any global statuses with the authority set to IUCN Red List on taxa no longer map to names in the IUCN Red List (e.g. in cases where a species was removed from the Red List in an update).
To avoid confusion, weâd like to have only one global conservation status on iNaturalist per taxon and for the IUCN Red List to be the primary source for these global statuses. Please limit adding other global authorities (e.g. Natureserve G-rankings) only to taxa that are not in IUCN. If a species is in IUCN, adding S or N rank Natureserve conservation statuses for each state or country is preferable. If you think another global authority suggests the IUCN default position geoprivacy is incorrect, rather than add a 2nd conflicting global status linked to this authority, please change the geoprivacy on the IUCN status and link to a flag in the description where you use this other authority to explain your reasoning (e.g. âwhile the IUCN Red List treats this species as secure, this other global authority thinks its threatened by location disclosure so Iâve set geoprivacy to obscured and included a link to this flag in the description so we can discuss this decisionâŚâ).
If a taxon is in the IUCN Red List and has another global conservation status on iNaturalist, the automatic process will merge those conservation statuses giving the IUCN Red List status and geoprivacy precedence. If the non-IUCN global conservation status has a flag in the description, iNaturalist will treat this as an intentional deviation and preserve this description and give the geoprivacy of the non-IUCN global conservation status precedence in the merge.
Conclusions
Thanks for helping us with this pilot. Weâve had many requests to update the IUCN conservation statuses over the years. What weâve outlined here is a bit clumsy, but we think it will allow us to maintain these statuses automatically while properly handling taxonomic concerns and status vs. geoprivacy concerns and without squashing intentional âdeviationsâ made by the iNat community.