Synolib2

[nleanba]

Full architecture rework.

Breaking Changes all-around.

[nleanba]

This (and the other similar "# TODO #" lines are a hack to work around lindas not having all CoL-taxa for some reason?

Should be uncommented once all col-data are on lindas; this check prevents some weird edgecases like for example with "Quercus"

[nleanba]

In general, a problem is that this query wuth the UNIONs is much slower on lindas than on our server; however making them optional and FILTERing with

    OPTIONAL {
      ?col dwc:specificEpithet ?species .
      ?tn dwc:species ?tnspecies .
      OPTIONAL {
        ?col dwc:infraspecificEpithet ?infrasp .
        ?tn dwc:subspecies|dwc:variety ?tninfrasp .
      }
    }

    FILTER (COALESCE(?tnspecies, "N A") = COALESCE(?species, "N A"))
    FILTER (COALESCE(?tninfrasp, "N A") = COALESCE(?infrasp, "N A"))

does not work at all on our server, but is quite fast on lindas.

I am considering having both query-variants, and selecting depending on the endpoint which one to use. This should be SynoLib-user overridabe, but have hardcoded defaults for known servers (i.e. for those on the synospecies settings)

[nleanba]

Preview on https://plazi.github.io/synolib/

The example page uses query parameters for options:

• q=TAXON for the search term (Latin name, CoL-URI, taxon-name-URI or taxon-concept-URI)
• show_col= to include many more CoL taxa
• subtaxa= to include subtaxa of the search term
• server=URL to configure the sparql endpoint

e.g. https://plazi.github.io/synolib/?q=Sadayoshia%20miyakei&show_col=

[nleanba]

Open TODOs before releasing this:

• COL-taxa without authority
• [~] Check if the behaviour is the same on all supported endpoints (those listed on synospecies)
• Optional: Ability to have the deprecations link for COL-taxa (currently we have "is deprecated by" but not "deprecates"
• Ability to resolve one of the URIs to a Name:
  i.e. a way to await synoGroup.getExistingName(uri) which resolves with the respective Name (or authorizedName if applicable) if it is a synonym as soon as it is found or with some indication that this is not a synonym (await synoGroup.getExistingName(uri) does not do any requests!)
  This would allow the treatment details to show the actual names of the things, not just the uri.
• Optional: Add reason to justifications (is deprected by vs deprectates)
• Optional: Handle seeAlso: coluri triples in the treatmentdata linking col taxa to taxon-concepts
• Optional: Get the "tree" of a taxon, that is all higher taxa (for display purposes)
  This is currently not possible for COL-taxa on lindas, as there many are missing.

[nleanba]

Endpoint-Compatability:

• https://treatment.ld.plazi.org/sparql : works fast
• https://trifid-lindas.test.cluster.ldbar.ch/query : Fully broken, but also broken on Synospecies -- remove endpoint?
• https://lindas-cached.cluster.ldbar.ch/query / https://lindas.admin.ch/query : works, but comparatively slow, also is missing a bunch of CoL taxa

Compare e.g. for Tyrannosaurus rex:

• Plazi Endpoint: Found 42 names with 162 treatments. This took 28.069 seconds.
• Lindas: Found 42 names with 162 treatments. This took 173.008 seconds.

---

Update after 9663f68:

Times are now down to ~25s (plazi endpoint) vs ~31s (lindas) in my very unscientifc testing.

I think this is good enough for now.

The missing CoL taxa on lindas are still a problem. However, it should not be the case that current synolib/synospecies finds something but new synolib does not regardless of the CoL-taxa

[nleanba]

• Investigate duplication of results, e.g. for 'Mini' or 'Ficus'
  • Ficus seems to be because it is a homonym appering in multiple kingdoms, need to fix the missing kingdoms on lindas.
    1. add kingdom field to Name
    2. allow for missing kingdom and treat it as a separate one
    3. therefore, handle it similarly to species etc wrt existing & equal or bith non-exist
• Deduplicate Authorities/Collapse authorized names where appropriate:
  • i.e. check if a name is a subset of another (er al and firstnames), or a reordering
  • combine into one authorizedName with multiple uris

[nleanba]

• Investigate number or requests made, seems like a lot, maybe wait with requests where heuristically a request for the same Name is already in-flight
  • Consider not loading treatment details for cite-only treatments or hold off until user requests it (i.e. UI only shows "Cited by ## treatments" and an expand-button
  • Can we collapse the figure query into the other?
• Check or inconsistencies between getNameFrom_-queries