Browser links to multiple wrong external identifiers for taxon "Candidatus Endoriftia persephone"

[kbseah]

While familiarizing myself with the query browser, I found an unusual error when the taxon Candidatus Endoriftia persephone is used in a query (adding a screenshot in case this the problem is specific to my browser):
https://www.globalbioticinteractions.org/?interactionType=interactsWith&targetTaxon=Candidatus%20Endoriftia%20persephone

Under the taxon name, instead of a single link per external database as expected, there are multiple links. What they all have in common is that the names start with Candidatus. This is a designation used only in prokaryotic nomenclature for provisional names of taxa that are not yet in culture, because the prokaryotic code requires a type culture for valid publication (details).

Perhaps Candidatus names are being misinterpreted as Linnean trinomials by the name matcher?

Surprisingly there was no Wikidata item for Candidatus Endoriftia persephone, but I've just created one: https://www.wikidata.org/wiki/Q124846046

[jhpoelen]

@kbseah thanks for sharing your observations re: Candidatus names.

Perhaps Candidatus names are being misinterpreted as Linnean trinomials by the name matcher?

Yes, perhaps! I'd have to look into the taxon alignment code and make sure that the candidatus prefix is handled properly.

Meanwhile, perhaps @dimus or @mdoering may have some insights on how their parsers (gn parser https://github.com/gnames/gnames and gbif name parser https://github.com/gbif/name-parser resp.) handle the Candidatus names.

Surprisingly there was no Wikidata item for Candidatus Endoriftia persephone, but I've just created one: https://www.wikidata.org/wiki/Q124846046

Thanks for adding the wikidata item!

[dimus]

Hi @kbseah, from the point of GNparser: Candidatus Endoriftia persephone

https://parser.globalnames.org/?format=html&names=Candidatus+Endoriftia+persephone&with_details=on

[mdoering]

There is a special property for candidate names in the parsed result: http://api.checklistbank.org/parser/name?q=Candidatus%20Endoriftia%20persephone

The name in the label then is quoted entirely.

[jhpoelen]

@dimus Thanks for sharing your example of results of global names parser v1.9.1.

@mdoering Also, thanks for sharing your candidatus example. Which version of the GBIF parser are you using?

[mdoering]

checklistbank always uses the very latest release, 3.11.0 at this time: https://github.com/CatalogueOfLife/backend/blob/master/pom.xml#L83
The parser exposed at GBIF lacks a bit behind.

[jhpoelen]

Thanks for sharing the version of GBIF parser . Would it be an idea to include this in the result snippets?

[mdoering]

The version you mean? You can get that from the API which you can then use to find the corresponding parser and all other dependency versions:
https://api.checklistbank.org/version

Takes you to:
CatalogueOfLife/backend@81e1c72

https://github.com/CatalogueOfLife/backend/blob/81e1c72/pom.xml#L83

[jhpoelen]

I was imagining embedding the version of the parse method in the parse response.

currently,

curl https://api.checklistbank.org/parser/name?q=Candidatus%20Endoriftia%20persephone\
 | jq .

produces:

{
  "scientificName": "\"Candidatus Endoriftia persephone\"",
  "rank": "species",
  "genus": "Endoriftia",
  "specificEpithet": "persephone",
  "candidatus": true,
  "code": "bacterial",
  "type": "scientific",
  "label": "\"Candidatus Endoriftia persephone\"",
  "labelHtml": "\"Candidatus Endoriftia persephone\"",
  "parsed": true
}

suggest to add some provenance like:

{
  "scientificName": "\"Candidatus Endoriftia persephone\"",
  "rank": "species",
  "genus": "Endoriftia",
  "specificEpithet": "persephone",
  "candidatus": true,
  "code": "bacterial",
  "type": "scientific",
  "label": "\"Candidatus Endoriftia persephone\"",
  "labelHtml": "\"Candidatus Endoriftia persephone\"",
  "parsed": true,
  "generatedBy": "https://github.com/CatalogueOfLife/backend/commit/81e1c72"
}

[jhpoelen]

@kbseah Apologies for the delay in dealing with the Candidatus issue. Hoping to get to it sooner rather than later. Thanks for being patient.

[kbseah]

hi @jhpoelen , there's no need to apologise! Thanks for your continued work in maintaining this resource for everybody.