Ability to show isothes:ThesaurusArray in Hierarchy tab

[tfrancart]

I need to include ThesaurusArray in Hierarchy tab. This includes :

• handling ThesaurusArray at the first-level of the hierarchy
• properly linking the top-level ThesaurusArrays to theit ConceptSchemes if ConceptSchemes are used as first-level nodes in the tree
• displaying ThesaurusArray with a different color / font
• maybe opening these nodes automatically when their parent is opened

I will (maybe) work on this in the next few weeks/months.

[osma]

Ok, go ahead. Might be a little challenging since the code and the REST API isn't designed for this, but it's worth trying. Probably makes sense to break this up into smaller pieces and implement them one by one.

[tfrancart]

Before proceeding, I would like your opinion on the implementation approach. I am thinking about extending the query in GenericSparql::generateParentListQuery, so that it also returns the (optional) array (arrays ?) in which the child belong. Something like adding this, similar to what is done in generateConceptInfoQuery :

    private function generateParentListQuery($uri, $lang, $fallback, $props) {
        $fcl = $this->generateFromClause();
        $propertyClause = implode('|', $props);

        if ($arrayClass === null) {
            $selectArrays = $optionalArrays = "";
        } else {
            // add information that can be used to format narrower concepts by
            // the array they belong to ("milk by source animal" use case)
            $selectArrays = "\n ?childArray (SAMPLE(?childArrayLabels) as ?childArrayLabel)";
            $optionalArrays = <<<EOQ
        OPTIONAL {
                  ?childArray skos:member ?children .
                  ?childArray a <$arrayClass> .
                  FILTER NOT EXISTS {
                    ?childArray skos:member ?other .
                    FILTER NOT EXISTS { ?other skos:broader ?broad }
                  }

                  OPTIONAL {
                    ?childArray skos:prefLabel ?childArrayLabels .
                    FILTER (langMatches(lang(?childArrayLabels), "$lang"))
                  }
                  OPTIONAL {
                    ?childArray skos:prefLabel ?childArrayLabels .
                    FILTER (langMatches(lang(?childArrayLabels), "$fallback"))
                  }
                  OPTIONAL { # fallback - other language case
                    ?childArray skos:prefLabel ?childArrayLabels .
                  }
                  OPTIONAL {
                    ?childArray skos:notation ?childArrayNota .
                  }
         }
EOQ;
        }
// then in the query :
SELECT ?broad ?parent ?member ?children ?grandchildren
(SAMPLE(?lab) as ?label) (SAMPLE(?childlab) as ?childlabel) (SAMPLE(?topcs) AS ?top) (SAMPLE(?nota) as ?notation) (SAMPLE(?childnota) as ?childnotation) **$selectArrays** $fcl
WHERE {
...

This would be returned as additionnal information in the REST API (RestController:hierarchy), and then handled in hierarchy.js when building the tree.

Plus :

• No additionnal API

Minus :

• Makes the query slower if ThesaurusArrays are set in the configuration

Note that this does not cover the case where ThesaurusArray are used to organise top-level concepts.

The alternative approach would be to create a separate API to retrieve the array information of a list of concept, but this would necessitate one or more additionnal API calls from hierarchy.js.

Do you have any opinion/preference ? Thanks

[tfrancart]

Also, I am wondering whether the following clause is really necessary :

                  FILTER NOT EXISTS {
                    ?childArray skos:member ?other .
                    FILTER NOT EXISTS { ?other skos:broader ?broad }
                  }

Skosmos could simply "trust" the structure of the SKOS file, and defer necessary checks or alarms to in Skosify to warn the user about ThesaurusArrays not containing sibling concepts. Skosmos would gain in performance. I have noticed this clause is killing performance on Jena 2.4.x (to the point of generating a timeout of the query), but performs fine in Jena 3.

[tfrancart]

Something similar would be needed in GenericSparql::generateChildQuery, when retrieving the children of a concept. Which makes me think a separate API call could be better, since it could be used :

• after requesting the full parent hierarchy of a concept, for each level in the tree
• after requesting the top concepts
• after requesting the children of a concept when unfolding the tree

Something like :

• input : a list of sibling concept URIs
• output : a list of arrays (URIs + labels), and for each array the ordered list of sibling concepts belonging to that array (a sublist of the input list)