In our GBIF published dataset, we have a large number of records that are currently determined as a species Lampsilis radiata luteola(Lamarck) which in the GBIF taxonomic backbone is considered a junior synonym of another species Lampsilis radiata(Gmelin).
Nomenclaturally, this is correct (as in, the name Unio luteolusLamarck is in fact a junior subjective synonym of Mya radiataGmelin based on the rules of nomenclature and examination of the type specimens in the literature).
However, I know that the people who identified the specimens in our collection as Lampsilis radiata luteola(Lamarck) were using a specific, incorrect concept of the name Lampsilis radiata luteola, and that that concept is synonymous with Lampsilis siliquoidea(Barnes), not Lampsilis radiata(Gmelin).
Our collection has a policy of reporting the taxonomic determination that is currently applied to a specimen, meaning we do not batch-update determinations without an expert examination of the specimens in question. We mainly track changes in taxonomy by means of the taxonomic tree relationships in our Specify 7 database, where each determination is linked to a taxon concept that is either currently accepted, or linked to anAcceptedName.
When uploading records to GBIF, we tried to force records to display the correct AcceptedNameby making Lampsilis radiata luteola a junior synonym of Lampsilis siliquoidea in our database’s taxonomic tree, thereby publishing all records to GBIF with Lampsilis siliquoidea in the AcceptedNameUsage field, andLampsilis radiata luteola as the ScientificName.
However, It seems that GBIF takes the reported ScientificName field and performs its own match against the GBIF taxonomic backbone to determine the AcceptedName that GBIF displays for the record, ignoring collections’ reported AcceptedNameterm.
What is the correct means of getting GBIF to recognize names used in error? Is it by usingNameAccordingTo?
In our case (Natural History Museum of L.A. County, marine invertebrates) we record a verbatimIdentification (pretty much a literal version of whatever we get from a label, etc.). We’ve adopted WoRMS (World Registry of Marine Species at https://marinespecies.org) as our standard taxonomy, so we then supply the scientificNameID for the matching taxon name in WoRMS, whether that’s accepted or unaccepted (e.g. urn:lsid:marinespecies.org:taxname:594970). Via WoRMS, that taxonID has both a scientific name and an accepted name. To GBIF, we report the accepted name as the scientificName (and use the accepted taxonID to fill in the higher classification and rank fields). Essentially we let WoRMS do the taxonomic update for us and report the most recent WoRMS opinion on the original taxon name.
As a side issue, we have the internal ability to override or supplement the WoRMS taxonomy if needed (species that aren’t in WoRMS, for example). In those cases, we omit the scientificNameID and just report out “our” scientificName and higher-level taxonomy (but that’s rare).
However, it’s important to note that this works well because we work in a field (marine invertebrates) that has largely converged on a single community nomenclator (WoRMS). Of course there are disagreements and necessary revisions, but we’re more oriented to sending those updates to WoRMS than recording them privately. Not every taxonomic community has as good a community agreement.
Hey @pentcheff , I think we do things in exactly the same way actually. We also use WoRMS (well, MolluscaBase, but they’re the same thing essentially).
The issue I describe above is different than what I think you are assuming. For example, we do exactly what you describe here in situations where there’s no match in WoRMS
Essentially, we are reporting the correct information and GBIF is making it incorrect, but incorrect in a way that would be hard for an end-user to interpret. The added problem is that we are the publisher of the vast majority of records of this taxon on GBIF, so the incorrect interpretation by GBIF of the valid name we are asserting is a problem that has broad implications.
The problem is how to indicate that a verbatimIdentification and scientificName is not the same thing as the WoRMS concept that is spelled exactly the same way? We don’t use the same AphiaID/LSID, but GBIF parses the current names and asserts the wrong concept, because WoRMS doesn’t include records for concepts, only names. Basically, the published misidentification of Lampsilis siliquoidea as Lampsilis radiata luteola in the book “The Freshwater Mussels of Ohio” is the concept that our collection used in the past.
Yes — got it. You’ve got a legitimate name that was used in a (known but incorrect) context. And yes, it would seem that using acceptedName should fix the problem. (We don’t fill in acceptedName, so don’t exactly replicate your situation). As you point out, it’s GBIF’s behavior of basing their taxonomic assignment on scientificName, ignoring your acceptedName.
I think, like you, I’d have expected acceptedName to override scientificName at GBIF, and be the basis for their taxonomic assignment. (In fact, had we thought of it, we might well have done just what you’re doing, and put our initial determination into scientificName and the WorMS-derived accepted name for that taxon into acceptedName — there’s even an acceptedNameUsageID available in DwC, parallel to scientificNameID. We were just simple-minded.)
So… What is the reasoning behind GBIF’s strategy? Or are the two of us just missing something obvious that makes it silly to think that acceptedName should override scientificName?
Cool, yes, you see the issue! I think it’s interesting that you don’t fill in acceptedName, I suppose the reason I do is an artifact of the way I constructed my database’s taxonomic tree (in that essentially I replicate the WoRMS taxonomic scheme locally but only for taxa that appear on labels in our collection, so we have an internal field that always displays the current accepted name.)
The only thing I could think of is that GBIF might have some rules that allow publishers to override the backbone’s name matching by using nameAccordingTo. See this thread by @mgrosjean explaining what GBIF considers the usage of the terms involved in our problem. In practice, I don’t know whether including nameAccordingTo will do what we need it to automatically, but I wanted to check here to find out before I potentially push an unecessary/experimental update to our GBIF dataset just to test what GBIF will do.
Could be. That’s a very helpful post from Marie, but doesn’t quite cover enough terms to take care of this case. Perhaps a test dataset is in order.
Side confession: We initially uploaded our original scientificName and scientificNameID, thinking for some reason that GBIF would act like WoRMS and somehow automatically divine the accepted name and ID and expose those. That was thoughtless. Hence now we swap in our (based on WoRMS) accepted name and accepted name ID when we upload. An alternative would be for us to build out a bit more explicitly into the other available DwC terms. But given the existence of WoRMS, it’s not clear that there’s a real value proposition to doing so.
We neither use dwc:nameAccordingTo nor taxonomic terms like dwc:acceptedNameUsage or dwc:originalNameUsage. These dwc:Taxon terms are all only interpreted when dealing with taxonomic checklist datasets, not occurrences.
The simplest solution would be to use the currently accepted name as the scientificName based on your / WoRMS knowledge and optionally put it’s WoRMS LSID into scientificNameID - so urn:lsid:marinespecies.org:taxname:857326 in your case to point to Lampsilis siliquoidea (Barnes, 1823).
If you want to preserve old identifications use the IdentificationHistory extension.
It will always be wrong in some ways to match from one taxonomy to another, especially if it is based on names only. With the advert of COL in GBIF we use the monthly updates from WoRMS and MolluscaBase, but they also treats Lampsilis radiata luteola (Lamarck, 1819) only as a synonym of Lampsilis radiata (Gmelin, 1791) and are not aware of any further misapplications in literature.
