Add references to scientific name synonyms

Recently I have received several notifications about taxon swaps when changes are made to bring the iNat name in line with Plants of the World Online. These changes often seem to follow recently published research rather than existing (and even very newly published!) floras. At least to some extent iNat seems to include synonyms in the list of names as Scientific Names with strikethrough text. I think it might be helpful to more formally support adding synonyms, and include references to sources that use these names.

The existing Names section on the Taxon page looks like this (if this image gets included correctly):

A Names section with synonyms and references might look something like this:

Suggested%20Names

Personally I would love to see this approach adopted - it’s logical and informative and would damp down some of the indignant bewilderment experienced by many users when a familiar name is swapped for the one that the iNat authority deems valid. All your hypothetical examples reference other secondary sources (e.g. regional floras) and to limit the referencing to these, rather than primary sources, would keep it from becoming unwieldy.

1 Like

@twr61 In principle your suggestion makes a lot of sense. In practice I think the References would be hard to maintain.

Consider the situation where two taxa are merged, both of which have different pre-existing sets of synonyms with references. When they are merged, the old synonym references may or may not still be appropriate, because the newly accepted name may or may not have been accepted in some of the old synonym references – if that makes sense.

For some synonyms the correct reference may become the source reference for the new merge. A curator would need to review each prior synonym and decide which reference is appropriate for the newly merged taxon. This could greatly slow down taxonomic curation – which I realize might be a desirable outcome for some :wink: But the workload is so vast that I would really hate to see that happen :grimacing:

It’s possible that there could be an automated solution for this scenario – synonyms already associated with the newly accepted taxon would keep their existing references, and synonyms associated with incoming non-accepted taxa would automatically be give the source reference associated with the merge. But I have to imagine the potential scenarios are probably more complex than this, so any potential automation would really need to be thought through first.

@rfoster A preference for secondary references could be stated in the curator guidelines, but I think there would still need to be allowance for cases where only a primary reference is available or appropriate.

1 Like

@twr61 - my bad, I misread your proposal, I see now that the references you propose are for where the synonym has been used as an accepted taxon, not where previously synonymized.

That said, I think there could still be issues of differing taxonomic concepts. Say in your example above, the two different references for Aconogonon davisiae happened to use two different circumscriptions for that species. (Included different sets of synonyms.) POWO’s concept of Aconogonon davisiae might match any or none of those previous concepts. So that could still raise questions of whether references remain valid after a merge, split, or other curation event, that would need to be resolved through human inspection.

But is it not true, that if iNat were using this approach, changes would only be made after valid taxonomical revisions, so all the data would be in the revision, and iNat could simply follow that. Where that is not the case, curators should not be “making the call”.
So any different concepts would be “pro parte” if partial or “sensu x” if a totally different concept) in the monographs, and can be incorporated into iNat prudently.
For the observations themselves, just like the IDs need human or AI intervention, so would any updates.
In the case of a monographic or published revision, the same reference would apply to all the names added, changed or swapped, so the task would not be overly onerous…

@tonyrebelo In an ideal world yes. In our iNat world though there is still a lot of curatorial backlog just to get caught up with the current Taxonomic Frameworks we have in place for the various groups (either conforming with them or documenting deviations from them). I would not want to add much more to that workload, which I fear maintaining synonym references for everything would do. But maybe I’m missing something there…

1 Like

I agree. If we do it for “everything” it will take forever.
Lets be pragmatic and only do it when it is necessary (by whomsoever deems it to be so and is prepared to to the work). .

2 Likes

That works for me, if doing it piecemeal like that would still be deemed helpful.

I don’t think iNat is the place to store this type of info. Probably better left to sites like IPNI and Wikidata.

2 Likes

Wikidata is not a great solution for synonym management. Wikidata properties allow you to define a as a synonym of b, but oddly the inverse can not be done, nor is it automated (because there is no Wikidata property to populate). There is an active proposal to support it, but if it will be implemented is unclear. This proposal would add a ‘is a synonym of’ property to mirror the existing ‘has a synonym which is’ one.

But i agree the proposal is better handled outside inaturalist.

1 Like

Yeah, I was more referring to providing links to POWO/Jepson/eFloras/USDA PLANTS/etc for each name. I’m not aware of a website that tracks which name is “accepted” by which reference (vs. whether it is listed there, but as a synonym), but Wikidata seems like it could be a reasonable platform for that.

1 Like

Well the whole what site accepts this name can be done via references on Wikidata.

Here is an example i did today that defines a synonym for this accepted species and where. I can add as many of those as i want.

https://www.wikidata.org/wiki/Q17136037

But there is nothing that can be added on the synonym name.

1 Like

Closing, as we’re not going to move forward with this request.