- From: Vladimir Alexiev <vladimir.alexiev@ontotext.com>
- Date: Thu, 19 Mar 2020 10:18:39 +0200
- To: "public-esw-thes@w3.org" <public-esw-thes@w3.org>
- Message-ID: <CAMv+wg49oCA5R9cC4YmR9cfMP+QT3Wq45mEHJcUnKObMMc2EtA@mail.gmail.com>
CHIN selected and deployed a TMS (PoolParty) about a year ago and the Nomenclature editors are using it actively. So it's not a question of selecting a new TMS but a quest for what would be the best API to provide for accessing the data. CHIN have collected some API requirements (calls that would be most useful) that have specifics: Especially regarding language and language fallbacks. Eg their website uses two flags "en vs fr" and "Canadian vs international". I've recommended passing these as one "RDF-like" param rather than two numeric flags. Eg "lang=en-CA" would mean "Give me prefLabels in English-Canadian if available, else in English" and correspond to this HTTP header: Accept-Language: en-CA, en # although this allows also other English "dialects", if such were in the data. Does any of the existing APIs implement lang filtering and fallback logic? It may well happen that because of such specifics, a custom API will be implemented. (A promising approach is grlc, which implements APIs as a collection of SPARQL queries). The feedback that we seek is what FORM of API the community thinks is most appropriate. BTW, in addition to the 3 modern standards I mentioned (LDP, Hydra and GraphQL), we are definitely considering OpenAPI (Swagger) that provides introspection and generation of API UIs. Even though the introspection is not RDF-based, OpenAPI is extremely popular. grlc implements OpenAPI. On Fri, Mar 13, 2020 at 6:27 PM Fabio Ricci <fabio.fr.ricci@gmail.com> wrote: > Is https://skosshuttle.ch/api/ maybe what you are searching for? > >
Received on Thursday, 19 March 2020 08:19:09 UTC