Prioritize scientific name over synonym and names in other languages in species search

[cthawley]

Currently, it seems that synonyms and scientific names have “equal weight” in terms of display order when a user enters species names into a search box. This can result in a situation where a species with a synonym which includes the scientific name of another species is displayed before it if it has more observations.

I’ll illustrate this with a situation I’m familiar with wherein the eastern fence lizard, Sceloporus undulatus, is deprioritized (displayed below) to the western fence lizard, Sceloporus occidentalis, because this species has “Sceloporus undulatus occidentalis” listed as a synonym.

You can see this behavior here:

This is undesirable because it:
a) Makes it a little more difficult to add correct identifications for S. undulatus and
b) Leads to confusion, whereby some users misidentify S. undulatus as S. occidentalis because S. occidentalis is suggested first. This despite the fact that the ranges of these two species do not overlap.

A little bit of background: As far as I can tell from Reptile Database (source of iNat’s reptile taxonomy framework), S. occidentalis has had priority over S. undulatus occidentalis since at least 1985, and that’s in the primary herp field guide for the Western US, which is where most observers (both professional and laypeople) are going to be getting their names from. The comparatively ancient synonym has been retained here, presumably to aid users who enter the old name.

One potential solution could be to remove the synonym from S. occidentalis. In this situation, that might be appropriate (since the synonym is so old), but this could also lead to confusion for users who prefer the old name. There are also likely other species with newer synonyms where this same situation arises and retaining the synonyms is quite useful.

A better solution, which I am proposing, would be to change the display order of taxa to prioritize displaying taxa for which a given text string matches their primary scientific name over those species which include the same string in their synonyms.

This is an issue that has come up on the forum before, but as far as I can tell there hasn’t been a feature request to change this. There have been two related bug reports (1, 2) which included ideas from @carnifex and @bouteloua about how reprioritizing ordering may be beneficial. In another general post, @chrisangell proposed some ordering criteria as well. (all tagged here in case they’d like to chime in!)

On a side note, this behavior also occurs even when the synonyms are not displayed (see example below from search bar on main page) which is also confusing.

[bouteloua]

I’ve run into similar frequent issues with common names in languages I don’t speak. Here was my suggestion on a different topic:

@bouteloua

I’m not sure what exactly the feature request would be, or how the current ranking is done, but ranking priorities like this would make sense to me:

1. accepted scientific name & common names that match my account settings
2. synonyms
3. common names that don’t match my account settings

plus some sort of weighting based on number of observations, but not at the expense of any queries exactly matching the accepted scientific name not appearing in the results.

[joe_fish]

strongly agree that this needs prompt fixing. in addition to synonymized names, common names in other languages can create a similar problem. for example, a search for the soft coral Cervera places it at #11 in the results, behind a bunch of non-English common names.

I would suggest the following priority.

1. accepted scientific name
2. synonymized scientific name
3. English common name
4. non-English common names

regarding #3, English is the de facto language of today’s science publishing, so it should take priority over non-English names.

[DianaStuder]

@bouteloua

common names in languages I don’t speak

Disconcerted that ‘Life’ is a common name for something in particular.

[aspidoscelis]

Regarding “3”: Presumably the best solution would be more consistent implementation of current stated policy over a broader range of contexts:

Why don’t I see my expected common name?

iNaturalist has a number of settings related to common names, and they are applied in a particular way. This is how iNat determines the common name displayed to you:

First, iNat looks for the default (top-ranked) name that is set to be used in your preferred name place. If you have no place priority set, or there is no name listed for that place, then iNat will use the top-ranked name in your Language/Locale setting. Only curators have access to the page that shows the name rankings and place associations, however anyone can use the API to view this information, e.g. https://www.inaturalist.org/taxon_names.json?taxon_id=55819. If there is no name listed for your Language, then iNat will use the top-ranked Global Name.

Since language-specific behavior already works very well in a variety of contexts, presumably addressing the few remaining gaps would be feasible.

I’m not sure that the “language of today’s science publishing” has any relevance in this context. The purpose of common names in iNaturalist is not science publishing, but making it easy for people to assign organisms to the right taxon. English is only the right choice if the user’s primary language is English. And, as a botanist—I know it differs in other contexts—scientific names are the standard in scientific publishing. English names are sometimes used, but if so the expectation is that the usage of that name will be established by reference to the scientific name.

[Averixus]

This issue comes up for me a lot with common names in languages I don’t speak being prioritised over the name I’m aiming for. Entering the first three letters each of genus and species starts bringing up results, but if I want to identify, say, Tradescantia virginiana, I can type all the way to “tra virgini” and the top result is still a different species matching a common name in a language I don’t use:

I started another feature request at first because I hadn’t found this post, so I’ll copy over my suggested solutions from there…

Basic feature: In species search fields, prioritise results where the query matches the scientific name and/or common names in the user’s locale or chosen lexicons. These results should appear at the top of the list, and results which match common names in other languages should be further down (but still included).

Bonus feature 1: When there are matches to multiple lexicons (e.g. some match scientific name, some match the user’s locale), pioritize the order within those matches based on the user’s account settings for scientific/common name display order and common name lexicon display order.

For example if the user has the setting Common Name (Scientific Name), and they have two common name locales in the order English → French: the results list would first show matches to English common names, then French common names, then scientific names, followed by matches in other languages.

Bonus feature 2: Add a setting in account details for users to choose their preferred lexicon search priority order manually, in the same way as choosing common name display order. This setting would let users order a list containing “scientific name”, “same as locale”, and any other common name lexicons they’ve added. The order of this list would then be used to prioritise results in species searches. For example, if a user puts “scientific name” at the top in the setting even if their name order is Common Name (Scientific Name), then when making a species search the top results would always be species whose scientific name match the query.

Here’s how I imagine the bonus feature could look, in between the Common Name Lexicon Display Order and Community Moderation Settings:

[DianaStuder]

traD vir …

[Averixus]

Yes, as in the other thread it is still possible to find workarounds, and I still find it frustrating that workarounds are necessary

[tiwane]

Added an issue for prioritizing active scientific names over synonyms: https://github.com/inaturalist/inaturalist/issues/3995 Doing something simlar for common names would be a lot more complex, so we’re going to focus on the synonym issue at this time.

[whitneybrook]

I realize the decision has been made to prioritize fixing this for scientific names first, but I have an example of a common name prioritization. I initially made a flag to remove the common name for it, but this isn’t against iNat guidelines that are broadly accepting diverse common names.

Prairie smoke is a widely accepted common name for Geum trifolium. A google search for prairie smoke will quickly reveal many hits for Geum trifolium. However, if you type prairie smoke into the iNat ID search when adding IDs, Pulsatilla nuttalliana comes up before Geum trifolium. This could result in ID errors and makes it harder to use common names for adding IDs. These plants both have wispy seedheads, which probably explains the temptation to use the same common name.

It would be good if there was a way to prioritize default common names for a region showing before addition common names in the search.

[cthawley]

This seems like a somewhat different issue with common names and search (doesn’t involve synonyms or other languages), so I think you would want to look into making a separate feature request. For what it’s worth, I believe the current system prioritizes the taxon matching the search string with the most observations (i.e., most commonly observed) which is often a good default. Commonly observed species often have more common names (so many of those names will not be the default - only one can be!). Less commonly observed species usually have fewer common names, making their names more likely to be the default. So if the prioritization is done by default common name only, there would likely be many situations where a rarer or less commonly observed taxon was prioritized in the search results for a shared common name which wouldn’t be optimal. In the example above, it seems like the taxon with the default common name which is the example target is second, which is pretty reasonable in my opinion. Observers/IDers will at least see it as an option.

[meteorquake]

There is a value for some people in looking up plants in a language not in their locale when they are doing research beyond their normal region.

One solution is to be able to prefix what you type. For example -

Prefix $ – searches latin names

Prefix # – searches your chosen vernacular language

Prefix * – searches all languages

No prefix – searches according to an option you set, default * all languages; someone might want to set it to e.g. $# to search in scientific name and their locale and then they would use prefix * when they want to search in all languages.

A consideration of different keyboard layouts might mean choosing the prefixes slightly differently or allowing the user to set them as a sequence of 3 characters. Many options could be provided using a free text ini-style box of properties with values and a help page of what can go in it.

[chase-prairie]

Please please please. There are two goldenrods that start with “rigid” plus multiple subspecies.
Because of synonyms, the first result is always Solidago rugosa.