SKOS resources hierarchy defined with narrower (skos:narrower) properties are not parsed

[jonquet]

We know this SKOS limitation for a while. I finaly have an exmaple of SKOS thesuarus that is properly decalring its hiearchy with :

• topLevelConcepts
• narrower properties until the leaves
• broader properties in the leaves

https://agroportal.lirmm.fr/ontologies/SDNDEV

The hierarchy can't be displayed because its not declare in the source file with skos:broader properties. We can still reach the leaves and then the page will reload displaying them somewhere in the hierarchy bloc.

https://agroportal.lirmm.fr/ontologies/SDNDEV/?p=classes&conceptid=http%3A%2F%2Fvocab.nerc.ac.uk%2Fcollection%2FL05%2Fcurrent%2F69%2F

[syphax-bouazzouni]

The technical issue here is that: for getting a concept children we use skos:broader.

And to build the tree of an element we do skos:broader until getting to an element that is a root (no more parent)

Some docs about this: https://doc.jonquetlab.lirmm.fr/doc/how-concepts-tree-view-works-L8tf8MlZoa

Possible solutions

1. When parsing an ontology we materialize the inverse properties, if in the file we have A skos:broader Bwe materialize B skos:narrower A:

   • Advantage:
     • Will work with current code using only skos:broader
     • More performant requests (because we don't test which property is used in the hierarchy)
   • Cons:
     • Duplicate the data (number of skos:broader will be equal to skos:narrower)

2. In the get children request; we do the first try with skos:broader if noting found than try skos:narrower:

   • Advantage:
     • Simple to implement
   • Cons:
     • Duplicate the request for all the SKOS resources

3. Use a configuration property to tell which property to use (skos:broader or skos:narrower)

   • Advantage:
     • Simple to implement
   • Cons:
     • We need to be limited to skos:broader or skos:narrower for skos

[jonquet]

Thanks for the analysis and suggestion. I would go for solution 3 as we already have in the default OntoPortal metadata a property to store the hierachry property of the ontology (bpm:hierarchyProperty). Typically the fallback shall be skos:broader for SKOS resource and rdfs:subClassOf for others and in the case of a hierachry based on skos:narrower,, we will only have to manually edit this ontology metadata to fix the problem.