Enhance SKOS parsing and handling in BioPortal / AgroPortal

[jonquet]

En quoi cela consiste exactement ?

@msalvadores pointed us to where the SKOS parser code is: We just use the OWLAPI [1] and the SPARQL queries get configured for SKOS properties using language specific predicates for that format (see [2]).

[1] https://github.com/ncbo/owlapi_wrapper [2] https://github.com/ncbo/ontologies_linked_data/blob/master/lib/ontologies_linked_data/models/ontology_format.rb

C'est l'endroit qu'il faut regarder pour debugger.

[jonquet]

(switch to English to share this with NCBO)

Observed probems with SKOS in AgroPortal or BioPortal:

• [ ] BroaderTransitive relations are not parsed (Anne)
• [x] SKOS-XL is not parsed (Clement)
• [x] skos:topConcept is mandatory
• [x] skos:ConceptScheme are ignored => see #258 and #259
• [ ] Mixed skos/owl ontologies are not handled properly

[antool]

Dans le cas d'un fichier qui utilise à la fois OWL et SKOS, et si le fichier est chargé dans le portail au format OWL, les propriétés skos sont ignorées.

[jonquet]

Among the question is : how does BioPOrtal handles multiple skos:ConceptScheme ? How is this presented in the UI ?

[antool]

J'ai fait un test avec deux "conceptScheme" définis au sein du même vocabulaire. Dans l'UI, les "TopConcept" figurent au sommet de l'arborescence, quel que soit le "conceptScheme" auxquels ils appartiennent. C'est dans l'onglet "details" que l'on retrouve plus d'infos : pour chaque concept, la notion d'appartenance à un "conceptScheme" apparait dans la propriété "inSheme" (ou "is in Scheme" si on a fait un import skos dans le fichier). Et on a bien l'URI du conceptScheme correspondant.

[jonquet]

One new idea:

• [ ] Populate the notes for concept in BioPortal/AgroPortal using the information in skos:note properties.

[jonquet]

One old idea (not done yet!):

• [x] Parse the in file SKOS mappings to actually populate AgroPortal/BioPortal mappings.

[antool]

• [x] If the skos resource is only a skos:conceptScheme, then the metadata won't be extract. You also need to define the resource as a owl:Ontology.

[graybeal]

I'm not sure what behavior one should expect with a mixed "SKOS/OWL" ontology.

In OWL ontologies, the terms of interest are generally managed as classes. While I can imagine some use cases for mixing classes and individuals, I can't imagine them both having equal status as "first-class concepts" to be managed. In particular, vocabularies that try to mix the two would be very difficult to use semantically. (In general, combining SKOS and OWL via mappings is awkward for this reason; mapping classes to individuals is a bit messy.)

In SKOS ontologies, terms of interest are necessarily individuals. As Jennifer pointed out to me,

According to documentation on the W3C standards website, concepts in SKOS ontologies are declared with with the "skos:Concept" class, e.g: <http://www.example.com/animals> rdf:type skos:Concept.

So as I read this, if you declare your ontology is SKOS, you must declare the concepts within it as skos:Concept. The other OWL declarations are not relevant from a SKOS perspective.

BioPortal manages SKOS content by requiring that the content be identified as SKOS in the metadata, then (if I am not mistaken) treating the Concepts as classes (which makes them countable). You can't change the type of the resource to a non-SKOS ontology—if you do, then none of the Concepts are found.

(Thanks for the citation above from Manuel about the handling in https://github.com/ncbo/ontologies_linked_data/blob/master/lib/ontologies_linked_data/models/ontology_format.rb.)

[jonquet]

Yes you are right @graybeal on all these aspects related to SKOS. Indeed there no classes in SKOS.

A lot of développers mix the two into semantic resources called RTO (resource termino-ontologique) e.g. Transmat or Biorefinery in AgroPortal. But when they make it to the portal they are usually treated a OWL ontologies.

[jonquet]

Seems also that the Annotator semantic expansion with is-a hierarchy does not work with SKOS vocabularies. e.g., http://services.agroportal.lirmm.fr/annotator/?text=protozoa&ontologies=ANAEETHES&longest_only=false&exclude_numbers=false&whole_word_only=true&exclude_synonyms=false&expand_mappings=false&negation=false&temporality=false&lemmatize=false&expand_class_hierarchy=true&class_hierarchy_max_level=3&display_links=false&display_context=false&apikey=1de0a270-29c5-4dda-b043-7c3580628cd5

• [ ] Enable semantic expansion of annotation following the broader hierarchy

[graybeal]

Nor should it, semantically speaking? These are instances, so there should not be any is_a relation.

If you mean the more general hierarchy relation (broader/narrower in SKOS), conceivably that should be mapped for annotator purposes, but is not actually implemented. If you can verify this, please consider that a bug and file a corresponding ticket in the BioPortal project. Thanks!

[jonquet]

For memory, we need to aloso to fix agroportal/agroportal_web_ui#125 when fixing SKOS handling in AgroPortal.

[jonquet]

Co-assigning @syphax-bouazzouni as we are re-opening SKOS handling questions in AgroPortal.

[syphax-bouazzouni]

current state see: https://www.bioontology.org/wiki/SKOSSupport

[jonquet]

This is related to #258 and #259

[syphax-bouazzouni]

@jonquet I let you close this issue if you think it is done. Else extract relevant information in a new issue that references this one for clarity.

[jonquet]

Most of the aspect related to SKOS are handled in the AgroPortal 2.4 release.

I think we only need to capture the bug related to Annotator semantic expansion somewhere else (I will do), then we are good to close this. Done => https://github.com/ontoportal-lirmm/ncbo_annotator/issues/26