Terminology and Ontology Services: about the-fair-cookbook HOT 7 CLOSED

@FuqiX @tburdett @sgtp

This ticket is for writing a recipe for deploying and hosting a vocabulary service.

This is one of the capability and infrastructure service that has been identified and would meant an 'initial capability' for such services.

It would lead into other capabilities such as dealing with updates, serving specific versions of a given artefact. Which terminology service can do this?

It could cover means to access and querying (e.g. web-ui, rest-api, direct sparql (only for advanced users).

The idea here is to document how this can be done with, let's say open source tool, such as OLS.

This is for users who need to run private queries over terminologies of interest.

The recipe would be part of a set of recipes around terminology management.
I recall OLS was available as a docker container [https://github.com/MaastrichtUniversity/ols-docker]

more instructions from EBI: https://github.com/EBISPOT/OLS

I am looping in Tony and Andrea to have their opinion.

from the-fair-cookbook.

Captured from Squad 1 discussion 2020-02-19 :

Find an ontology service able to provide access to >1 public ontologies

Competency Qs:

recipe that provides guidance on available ontology services including commercial solutions, and domain specific; what are the pros and cons.

Links:

"e.g. https://www.ebi.ac.uk/ols/index ;
http://athena.ohdsi.org/search-terms/terms ; http://obofoundry.org/"

Details:

Cover OLS, Bioportal, Athena, Centree, OBO Foundry, (SciBite); skeleton structure on pros/cons (consideration of cost); skeleton section on domain type with recommendations on relevant ontologies; capabilities & versions; whether it can be brought in house; APIs & access;

Assumptions:

assumes that you already know which ontology/ontologies you are after

from the-fair-cookbook.

There are more ontology server available (e.g.: PoolParty). Even more so if we consider reference/MDM systems (at some low level of maturity, this may be what is available in some environments). Comparing systems is certainly useful, but the information will be obsolete in a couple of years.
It would be useful to have:

• A checklist for how to assess a terminology server
• Guidance on how to operate a terminology server (e.g.: roles and policies for updates, conflicts resolution)
• Guidance on how to select ontologies (perhaps out of scope in this task)
• A maturity model view

from the-fair-cookbook.

@sgtp 👍
the essential capabilities for term look up are:

• terminology artefact server
• serving different versions of the same artefacts (or the difference between versions) capability
• serving class metadata capability
• serving individuals for a given class capability
• web ui
• api (smart api )

Note: if capabilities broader than just artefact serving for the purpose of term selection are needed, terminology management services (broad sense) need to encompass:

• terminology artefact editing capability
  • term request & addition capability
  • term retirement service (obsoletion capability)
  • term merging capability
• mapping capability
• reasoning capability

from the-fair-cookbook.

is this recipe done? @FuqiX please comment

from the-fair-cookbook.

Related recipes:
Selection and exploitation of Ontology Lookup Service
Recipe 1.3: How to deploy a terminology service - an example with the EBI Ontology Lookup Service
Recipe 1.2 Technical & architectural selection criteria of ontology lookup services

from the-fair-cookbook.

Hi @FuqiX , I don't really agree that all of the raised comments are done; this is why I am attaching "done partially" and "backlog" label to this issue. In the future we will extract comments like the ones above into separate issues.

from the-fair-cookbook.