Welcome curators! This guide describes some of the curatorial tools iNat provides as well as some of iNaturalist's policies toward how we curate our taxa. If you're not a site curator and would like to help curate our taxa, please contact us. We will generally allow anyone to be a curator if we know they have some expertise, or if they've demonstrated expertise by using the site. If you would like to be a curator but we don't know you and you have zero observations or identifications, we will probably ask you to use the site a bit more before approving your request. If you demonstrate by your behavior on the site or through your communication to us (the site admins) that you are unwilling to abide by our curatorial policies, abusive to us or members of our community, or otherwise unreasonable, we will revoke your curator status, or just not grant it in the first place. What constitutes abusive or unreasonable behavior is at the discretion of the site admins.
Being a site curator means you have the power to make new taxa, edit existing taxa, alter our taxonomic tree, delete taxon names, and generally maintain the state of iNat's taxonomy. The site admins do some of this in broad strokes from time to time, but we don't have the resources to keep everything current all of the time, or to vet everything we get from our data partners, so some hands-on curation is required.
Keep in mind that this document is both a how-to manual and a statement of our curatorial policies. If you cannot abide by our policies, we will start by warning you, but if you continue to reject our policies, we will remove your curator status.
Everyone on iNat can add new taxa to the system by searching external name providers using the taxon selector or by using the box at the bottom of the search page. Curators can make new taxa directly by going to http://www.inaturalist.org/taxa/new or by clicking the "Create a new taxon link" in the Curation box on their dashboard.
The taxon form looks like this:
Most of the fields include some explanatory text, but here are some extra explanations:
And of course there are caveats. For one thing, curators can't edit taxa above the order level. Changes toward the root of the tree create a ton of backend work that impacts site performance, so we stopped allowing it in July 2016. Also, these parts of the tree are pretty stable, so there's not much need to alter them. If you think these kinds of changes are needed, contact email@example.com.
iNaturalist obscures the locations of all taxa with an IUCN equivalent status of Near Threatened or 'worse'. However, if in rare situations these species are thought to be in VERY LITTLE DANGER from exploitation due to the public's knowledge of the location of these species, curators are advised to change the geoprivacy value associated with the conservation status from 'obscured' to 'open' on the taxon edit page.
Examples might be Coast Redwood which is listed as Vulnerable by IUCN because it is endangered by climate change but in very little danger of being collected or otherwise exploited by the public knowing the exact location of redwood observations. Likewise, polar bears are endangered from climate change but perhaps not from poaching.
Obviously, this is a gray area so if you feel compelled to un-obscure a threatened species be prepared to support why you are doing this. Why is the species not likely to be exploited by the public?, why is it of value to have the exact location accessible to the public?, etc.
Each taxon has one name (the scientific name), as well as multiple Taxon Name records. Taxon Name records are used to store all the names associated with a taxon, including current and outdated scientific names and vernacular names in multiple languages. Each name must be unique for a given taxon and lexicon.
On the left of the taxon page, you'll see a list of "All names." Any iNat user can add names using the "Add a name" link, but only curators can edit scientific names and delete names added by other people.
Currently the default common name for a taxon is the first English name that was added to iNat. In the future curators should be able to declare a default name more explicitly, but for now it's just based on order.
In general common names should be lowercase, except for animals, which should be capitalized. Capitalization is by "title case," meaning every distinct word in the name starts with a capital letter (examples: Eurasian Blackbird, Sulphur-crested Cockatoo). Proper nouns should always be capitalized wherever they appear.
Names, in general, should be as specific as possible, and common names are no exception. Most of us would agree that "mammal" would not be a good common name for the species Homo sapiens, so please don't add names like "snail" for some obscure gastropod with no real common name just because you think it will make it easier for novices to find. If anything, it will make it harder to find, since there are thousands and thousands of "snails." Instead, try to add names at the taxonomic level where they describe all members of that taxon and only members of that taxon. If a species has no common name in usage, please don't make one up.
For higher level taxa it can be hard to use a common name that describes all descendants. In these cases, we usually go with something like "Herons and Allies" or "heath family."
If you find names that don't meet these criteria, e.g. 10 taxa named "snail," please delete them without mercy.
Taxon Changes represent changes to our taxonomic classification where existing "input" taxa get replaced by new "output" taxa. They come in a few flavors:
You should create a Taxon Change any time you want to change the existing taxonomy, e.g. renaming a taxon or marking it as an outdated synonym of another taxon (Taxon Swaps). You can do this by clicking the "New taxon change" button on the upper right of http://www.inaturalist.org/taxon_changes, or just going directly to http://www.inaturalist.org/taxon_changes/new.
The single / multiple taxon boxes are a bit confusing. Every change has input and output taxa, so if you were replacing Hyla regilla with Pseudacris regilla, Hyla regilla would be the input and Pseudacris regilla would be the output. For Taxon Splits, there is one input and multiple output taxa, so the input goes in the "Single taxon" box on the left and the outputs go in "Multiple taxa" on the right. For Taxon Merges it's the other way around: multiple inputs, one output, so the output goes on the left and the inputs on the right.
iNaturalist taxa represent taxonomic concepts, meaning taxa can represent different things even if they have the same name. So they should have distinct taxon IDs and distinct taxon pages. For example, this taxonomic change split Rhipidura fuliginosa into Rhipidura albiscapa and Rhipidura fuliginosa, but the older, broader concept of Rhipidura fuliginosa has a different taxon id (8161) than the newer, narrower concept with the same name (244276). So when making a taxonomic split or merge, make sure you first make a new taxon if necessary. If the new taxon bears the same name as an existing taxon, you will need to mark the existing one as "inactive" before the system will let you create the new one.
When you save the Taxon Change it is in an "uncommitted" or "draft" state. You can review what observations will be affected by your change on the taxon change page (e.g. http://www.inaturalist.org/taxon_changes/31) and update your own content at the "commit for user page" (e.g. http://www.inaturalist.org/taxon_changes/31/commit_for_user). If you're unsure about your change, you can solicit feedback through comments on the taxon change.
Note that Taxon Changes represent changes within iNaturalist's taxonomy. While this should approximately mirror the direction of changes implied by the authorities we follow, they don't have to. For example, if Authority A says Vulpes vulpes is valid, but there's a new paper that says we should call the species Supervulpes vulpes and somehow Supervulpes vulpes got added to our taxonomy, it would be ok to make a swap from Supervulpes vulpes to Vulpes vulpes, because Authority A says that's the current name.
When you commit a taxon change, a bunch of things are going to happen:
All of the input taxa will be de-activated
All of the output taxa will be activated
All observers and identifiers who have used the input taxa will be receive a dashboard notification about this change
Associated records get updated (maybe)
This is where things get tricky. In theory, when a change only has one output, as with a swap or a merge, updating records is easy: replace uses of the input taxa with the output taxon. Except... some people want full control over their records and have opted out of these automatic changes. Plus we don't want to just change identifications in place b/c then we lose the history of what people really meant when they added an ID using an older taxon concept. And worst of all, splits have multiple output taxa, so we can't always choose what new taxon to assign to any given record.
So here's what happens:
Swaps: Identifications of the input taxon get marked as not current and new identifications of the output taxon are added, unless the identifier has opted out. Observations get updated because of these identification changes. Listed Taxa get changed in place to use the output taxon. Copies of the photos, conservation statuses, ranges, atlases, and names associated with the input get moved to the output. Children of the input get moved to the output, unless the input and output have the same rank and that rank is genus or lower. The latter case means the children need new names (e.g. if genus Foo gets replaced with genus Zoo, species Foo bar needs to become Zoo bar). In this case, instead of moving the children, new swaps are automatically created for the new names.
Merges: Just like swaps except conservation statuses, ranges, and atlases don't get moved to the output, since it's not always clear if those are still relevant to the new concept.
Splits: Most content just gets left with the input taxon. For identifications and listed taxa, records by people who have opted out get ignored, and for evertyhing else:
When all of the output taxa have atlases we can automatically choose the right output taxon for a record with a location, e.g. if Observation 1 is in Belgium and Output Taxon A occurs in Belgium but Output Taxon B does not, we can just add new identifications of Output Taxon A to Observation 1. However...
Where output atlases overlap, or if there's ambiguity due to output taxa without atlases, we fall back to adding identifications of the closest taxon that contains all of the output taxa, so if the input is Woofer and the outputs are Canus and Vulpes, all IDs of Woofer will be replaced with IDs of Canidae, b/c it contains all of the outputs and should be implied by all of the previous IDs. This is a little weird, we know, but it makes it easier for people to add new identifications to shift the community ID correctly.
If it's not already obvious, splits are the most disruptive kind of change. In the worst case scenario where some or all of the outputs are not atlased, observations of the input are going to get associated with some higher-level taxon and will need more IDs to become associated with one of the new outputs. This is probably going to be quite common, so if you split a taxon, please try and take responsibility for your change, review affected observations, and add new identifications where you can (there should be a banner on the taxon change page after you commit linking to a tool that will make this a bit easier).
Many of the consequences of taxon changes can be undone by site admins if you make a mistake (like the new identifications), not all (like the listed taxa). That's why it's really important to be careful when committing a taxon change, particularly for taxa that a lot of people have been using.
See the Policies below. We try to follow external authorities for certain groups in certain places. Please do not make changes that conflict with these authorities.
Name changes are really frustrating, so if you can, explain why this name was changed. For splits, help people out by explaining how to differentiate between the output taxa so people know how to update their content if it couldn't be updated automatically. These practices are good for record-keeping, but they can also reduce the frustration and help everyone learn.
While not required, we would like every change to be traced back to some publication or taxonomic authority. The ideal citation would be to the paper that introduced the change, along with a URL to that paper, but since that's often difficult / impossible to find without extensive library research, sourcing the change to a website or database is cool too. Since it's a pain to add a new Source record for every single page, it's often easier to set the Source as the website and include and specific URL to the page on that website that describes the change on the description. The goal is to ensure that anyone who wants to figure out why a particular change was made can trace it back. Keep in mind that the Encyclopedia of Life is not one of our taxonomic authorities! If you must cite them, perhaps because one of our authorities doesn't include an older synonym, please link directly to the relevant content, e.g. http://eol.org/pages/330496/names/synonyms.
@ mention others to review your changes for potential
errors and to discuss whether or not they're appropriate. This is especially
important if you're changing a taxon based on a regional authority and it
has observations outside that region. Curators have a lot of power to act
unilaterally because sometimes it's just hard or impossible to get others to
vet your work, but we (the site admins) would prefer a more collaborative
process whenever possible.
Most of our classifications come from our external name providers, but for some groups we try to adhere to different taxonomic authorities. Note that this means when we are tracking a secondary taxonomic authority like this, we explicitly do not track the taxonomy from the primary literature. We have a couple reasons for this:
Taxonomy is subjective and not every scientist agrees with every paper
While it may seem like the naming and classification of organisms is a formal process and all scientists agree on what names organisms should have, the truth is much messier. While there are standards for when and how an organism should be named, they do not apply to all taxa, and there are basically no universal standards for when two groups of organisms should be considered separate species. Biologists have never been able to agree on standards in these areas, so the result is much more akin to correct use of language than correct use of the periodic table: everyone has their own opinion, but most people tend to follow authorities (either individuals or groups) who they trust to make reasonable decisions about what names should be used. Thus, using names and classifications just because someone published a paper declaring that they should be used (even a peer-reviewed paper) is not a great idea, because it doesn't prove that the scientific community supports that paper's assertions.
iNaturalist is not a place to argue about taxonomy
Or at least we don't want it to be. Since taxonomy is subjective, people argue about it all the time, and since there is no absolute truth one can apply to settle such disputes, they can become rancorous, often to the point of absurdity. Following taxonomic authorities helps us avoid having these arguments on iNat. We can argue about which authorities to follow, but following authorities allows us to skip arguments about each and every paper.
Primary sources are often hidden, while secondary sources are usually open
iNat is largely a community of amateurs, and despite the advances made by open-access journals, the bulk of taxonomic literature is still prohibitively expensive for most amateurs to access. Avoiding the primary literature in favor of secondary taxonomic authorities, most of which are freely available on the Web, allows all our users to inspect the sources of taxonomic changes, not just the users with privileged access to the scientific literature.
Following established authorities makes it easier for us to share your data with researchers
"What taxonomy do you use?" is often one of the first questions we get from researchers interested in using our data, if we're even fortunate enough to have that discussion. More often people find our data through aggregators like GBIF, so if we're using synonymous names that researchers or GBIF doesn't know about, researchers searching GBIF won't find our data. Following authorities moderates the pace of taxonomic change in our data and increases the probability that people searching through it by name will find what they're looking for.
All that being said, there are also many situations in which we do not (or cannot) follow authorities. Sadly, many taxonomic authorities are incomplete and/or out of date, often because they are underfunded, understaffed, or suffer bizarre decisions borne out of financial or political issues that have nothing to do with taxonomy. Indeed, our own policy of following authorities has proven to be somewhat controversial, particularly for people who curate groups where there are either no authorities or the existing authorities suffer from some of these problems.
So, as a curator, what's to be done? Basically, we try match parts of our taxonomy to some taxonomic authorities, but for everything else we either accept the names and classifications we get from name providers like the Catalogue of Life and uBio, or we cite the primary literature. Here are the authorities we try to follow:
There are hardly any world authorities on any insect order, let alone all insects, so it's a tricky group. For most North American insects we try to follow BugGuide, but with deference to the following authorities:
Ground Beetles: Carabidae of the World
Dragonflies and Damselflies: A Checklist of North American Odonata
Bees (Andrenidae, Apidae, Colletidae, Halictidae, Megachilidae, Melittidae, Stenotritidae): ITIS World Bee Checklist
Plant taxonomy seems to have few centralized authorities that keep their data up-to-date. IPNI would be the ideal global source, but it seems difficult / impossible to retrieve forward synonymies, so The Plant List serves as a decent surrogate. The Kew World Checklist of Selected Plant Families is generally more up-to-date, but not comprehensive.
Regional floras tend to be more useful and up-to-date, so we try to follow a number of them, and resort to The Plant List to resolve conflicts (e.g. if Calflora thinks a dogwood is in Cornus and GoBotany thinks it's in Swida, we choose the placement favored by The Plant List). Our regional authorities are:
New Zealand: Ngā Tipu Aotearoa – New Zealand Plants
Site admins for NatureWatchNZ consider this the main authority for New Zealand plants. It's pretty current and has lots of info on synonymy.
Calflora uses an amalgamation of The Jepson Manual II, USDA PLANTS, and CNPS rare plant lists. We are a bit biased toward California here, but a large number of us are interested in California floristics, and we haven't run into many taxonomic conflicts with other systems, so it works for now.
New England: GoBotany
GoBotany follows Flora Nova Angliae (2011) by Haines, which is recent and has relatively few conflicts with Jepson.
North America: Bryophyte Flora of North America
Sadly this is another group where there really is no global consensus, and names are changing rapidly, so for fungi we should try to follow the peer-reviewed primary literature. Index Fungorum is a decent source of names, and Species Fungorum has some information on what names should be current, but neither are up-to-date enough to satisfy most mycologists. Please be wary of IF ePublications, though, which do not require any form of peer review or supporting evidence for name publication. Same goes for Mushroom Observer, which is a fantastic site but supports a number of unpublished and provisional names.
North American Lichens: Esslinger's North American Lichen Checklist
Esslinger's list seems to have the respect of North American lichenologists, and it gets updated yearly.
While our general tendency is toward lumping for the sake of simplicity, the heuristic we use is utility: if you feel some users on the site (including yourself) will benefit from having a subtribe in the system, perhaps because that's the lowest taxonomic level at which a particular insect can be identified based on a photograph, then go ahead and add it. If you're adding a subtribe just because someone somewhere decided they like taxonomic units with less than 20 species in them, don't add it, because that doesn't really help anyone on iNat.
Given their vague morphological delineation and taxonomic uncertainty, use of hybrid taxon concepts should be avoided whenever possible. Adding IDs of higher-level taxa is usually sufficient. In those rare cases when some external authority actually supports a named hybrid, we will tolerate it, but please abide by the following guidelines.
Hybrids between species should have scientific names (the name associated with the taxon) following the pattern GENUS SPECIES1 × SPECIES2, e.g. Picoides scalaris × nuttallii for a hybrid between Picoides scalaris and Picoides nuttallii. The rank for such hybrids should be set to "hybrid." Note that the cross character is "×" and not the Roman letter "x."
Hybrids between species in different genera usually receive a generic name that is a portmanteau of the two constituent genera and a novel specific epithet, so the name of a hybrid genus should follow the pattern "× NEW_GENUS," e.g. × Chitalpa, and should receive the rank "genushybrid." The hybrid species should follow the rules above, e.g. × Chitalpa tashkentensis, and its parent would be the genus hybrid, e.g. × Chitalpa.
Hybrids should only be made between taxa of the same rank. Hybrids like Canis lupus × canis lupus ssp. familiaris don't make sense. That's like saying you made a new kind of vehicle by combining the traits of a Honda Civic and a car.
Several of these External Authorities such as IUCN and NatureServe are explicit about the taxonomic concept that their names refer to, and in many cases these are different. For example, in IUCN Pseudacris regilla currently means something different (a frog whose range extends from the Pacific Northwest to Baja) than Pseudacris regilla means in Natureserve (a frog just in the Pacific Northwest). In iNat, we use Taxon Schemes to keep track of which iNaturalist taxon is the one different taxonomic authorities are referring to.
Places on iNaturalist represent physical places on Earth (no support for extraterrestrial places yet). When we started the site we pre-populated our places based on shapefiles from the US Census Bureau, the ESRI world political boundaries, and the California Protected Areas Database. We've run a few scripts since then to populate the database with some more places, but most of the rest come from user searches against the Yahoo GeoPlanet API. The remaining places were all manually created by users, and should show a "Place added" notice at the lower right of the place page showing who added it.
Anyone can add a place on iNat, but the only people who can edit it are the person who made it manually and the site curators. Here are some things to keep in mind when curating places:
iNat users can flag taxa that they think need curation. You can see the most recent flags in the "Curation" box on your Dashboard, and you can browse them all at http://www.inaturalist.org/taxa/curation. Try to deal with these issues if you can, and when you do, mark the flag as resolved so it doesn't show up in the queue.
We've defined inappropriate content in our FAQ (to the extent that such a definition is possible), and it will inevitably pop up from time to time. Curators can delete comments that seem inappropriate, but at present they don't have the ability to delete other kinds of records. We need a better system for dealing with this, but for now please send contact firstname.lastname@example.org if you find inappropriate content in observation descriptions, projects, journal posts, etc.
Please keep in mind that pictures of pets, humans, obvious test observations, and drawings that depict the organism observed are appropriate, unless someone repeatedly posts such content. These kinds of observations are educational opportunities, so inform the person that iNat is primarily for sharing observations of wild organisms from nature by leaving a polite comment or private message. If 25% or more of a user's observations are of pets, humans, abiotic phenomena, or other off-topic subjects, or if they persist in this kind of behavior despite being warned, that constitutes abuse and you should contact the site admins at email@example.com, who will give the user 24 hours to remove the off- topic content, after which they will simply remove it for them. All that being said, a few off-topic observations here and there are ok.
An additional note regarding drawings: drawings are ok because, like photos, they can show visual evidence of the individual organism observed. If you don't think the drawing was of the observed organism (e.g. it's just a drawing of the species, not of an individual), talk to the observer and ask them to clarify what their drawing depicts. If they admit the drawing is not of an individual organism they observed, please contact firstname.lastname@example.org and the admins will ask the user to remove the photo, and remove it for them if they don't comply. If you cannot identify the organism from the drawing, treat it like a blurry photo and vote that the community cannot improve the ID.
Curators can edit wiki pages like this one and the other help pages by
clicking the "Edit" link at the bottom right of the page. You can create
new pages by visiting the URL you want (e.g.
or by clicking to it from an existing page using the internal link syntax
somepage) and clicking the link.
Wiki pages support full HTML as well as Markdown formatting. The Formatting box on the edit form will show you what's available.