Synolib2

[nleanba]

Full architecture rework.

Breaking Changes all-around.

Open TODOs:

• 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.
• Handle TN/TC with missing Kingdom
• Force use of (recent) cached entry if present (like stale-while-revalidate example from here: https://developer.mozilla.org/en-US/docs/Web/API/Request/cache#examples)
• Consider not using all the COALESCEs in the queries, instead sort out partial homonyms client-side -- possibly splitting queries in tow parts (TN/TC and CoL), as this might speed up the query times.
• When using the "subtaxa" option, results are missing if it doesnt find anything for the search term -- either consider everything lower-rank which has the search term as genus directly, or be more lenient in what taxon-names show up (currently many Genus w/o treatment dont show up, and so dont their subtaxa)
• See below:

[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)