This may be hopelessly complicated to implement, but I thought it would worth the ask based on several recent discussion threads (linked below), and since analogous basic functionality already exists for observations. (I think somebody once said “dream big”… )
Allow user-defined and -maintained fields and field values for taxa, analogous to current observation field functionality.
At least one such field already exists: taxon names.
Make taxa, observations, and IDs searchable/filterable by presence/absence of one or more taxon field or field value, at least via URL hacks.
Require all taxon fields to accommodate multiple defined values, to properly handle the results of taxon swaps and merges, and also for taxa that truly have multiple states for a particular category.
Consider requiring curator approval to define new fields or field values, to temper the proliferation of duplicate/overlapping fields currently plaguing observation fields.
Provide basic search capability sufficient to support detection and management of duplicates.
Allow fields to be applied at any taxonomic level (maybe only by curators above, say, Family level).
For search purposes, child taxa would inherit the current field value(s) of their immediate parent taxon, unless explicitly contradicted by adding different value(s) to the child taxon.
(here’s the craziest part…) Allow defined taxon fields and values to be applied directly to observations also, allowing observers and identifiers to label and search for observations (especially unknowns) in non-taxonomic categories such as “mangrove” or “lichen” or “tree” or “seaweed.”
This can be done with current observation field functionality, but would probably be better if tied to a more curated set of taxon categories instead.
I expect folks could find all kinds of other useful applications for the functionality that I haven’t thought of.
Consider later identifying the most useful taxon fields for conversion to taxon annotations analogous to current observation annotations, and have a path in place for migrating the former to the latter if and when decided by staff.
I like all these ideas. But, I’ve had a thought: will field names and values be translatable? Or will all fields/values have to have separate names/values in each language?
For example: the Insect Life Stage field autofills the Life Stage Annotation. Does it only do that on the English field name, or are there equivalent field names in other languages, or are the fields/values translated so they’re the same fields but in different languages? Etc.
Personally I think iNat should focus on observations and less on aggregating other non-observation based data, but that is probably based on knowing what a nightmare this information would be to amass, curate, and moderate, given my experience here with the taxonomy, atlases, vernacular names, and taxon page default photos. The similar crowd-sourced category system for taxa on Wikipedia is also full of inaccurate and incomplete information.
If implemented on iNat, it should:
be very narrow in scope, e.g. lichens or mangroves seem like they could be OK because they serve a specific ID-related purpose, but not “garden plants that grow well in zone 9b” or “taxa named by J.Carey in 1880” or “bite force quotient” lol
with very clear definitions with references,
requiring a source for every addition or change,
initially based on large imports of info from external sources, not initially crowd-sourced,
have tools in place to track changes, and
policies and repercussions for edit warring (it’s a tree! it’s a shrub! it’s a tree! it’s a shrub!), and would
definitely part of the translations, like annotations are
Anyway before brainstorming all the nitty gritties of a potential system, I would seriously consider whether iNat is the right place for these types of data, or whether something else like Wikidata would be better suited for it.
I like this idea (obviously as it incorporates one of my suggestions), but I also agree with the concerns @bouteloua raised.
Care needs to be taken in how to implement it and it should absolutely be narrow in scope.
Also responding to the concerns raised in that reply; if implemented responsibly it would absolutely be observation based, not an aggregate of non-observation data.
Taking lichens, for example, they are clearly something uniquely different from the rest of the fungal kingdom. Many different species of fungi and bacteria/algae have come together to make lichens and, even though it often takes experts to properly identify and classify, even very basically knowledgeable laypersons can easily determine if something is a lichen based on their observation.
I suspect that it would be necessary to initially scrape a database that includes all recognized lichens or all woody mangroves, or whatever, then to assign a name to that polyphyletic grouping. Determining what a reliable database to use would take a bit of work.
Sorry if my thinking is a bit fuzzy at the moment, we’ve been filming a documentary (3rd of the last month) from dark to dark and I’m a bit frayed around the edges.
I could see this potentially helping to make up for the deficiencies in the map functionality. For instance, how do I search for tropical Indo-Pacific reef fishes or subtropical Australian corals. These are both (relatively) easily defined groups, but presently impossible to search for on here.
Yeah, I was definitely trying to stay away from adding much to the curatorial workload, other than vetting new categories to make sure they aren’t duplications (and maybe to keep them ID-related, as you point out). Otherwise, as on Wikipedia, the data and usefulness would only be as good as interested users would have the time and energy to make it so – just as it currently is with observation fields. If there were a way to tie in to such taxon data via Wikipedia, then that would maybe be a viable alternative to this, though without the greater degree of control iNat users might want.
My thinking was that allowing multiple values would obviate most of that. There are plenty of taxa that are both trees and shrubs.
That’s definitely a weak point of using field functionality versus more development-heavy annotation functionality.
All this said, I’m not putting this idea on the table with much optimism that it would end up being workable enough to fly with the devs. Don’t get me wrong, I think it would be a useful thing if it could be implemented. But if not, at least the matter will have been settled.
I seem to recall there is a way to search comments on observations. I don’t remember how. Could we just try to leave comments with words like “mangrove” and “lichen”? We could ask the observer to add the word to their tags. Even if they don’t add the tag, just by asking you are adding the word to the comments.
I see somebody linked my thread The problem with mangroves. Mangroves present a bigger problem than lichens in this regard, because for lichens, at least the broadest category, “Fungi including lichens” mentions them. Mangroves are a defined ecological phenomenon, but so many times I have seen a mangrove get bumped back to “Dicots” even though the original observer knew it was a mangrove, because they did not know what kind of mangrove. Suggesting that someone leave a comment does not really help when the observer knows it’s a mangrove, IDs it as “Mangroves,” but may not realize that in iNat terms, that takes it to Rhizophoraceae.
)