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.