SKOS Cross-Scheme Management

Owned by Armando Stellato
Last updated: Apr 10, 2014

SKOS Cross-Scheme Management deals with the possibility of having concepts belonging to different schemes, instead of just having separate trees (bound to different schemes) of non-interlacing concepts.

We report here a series of checks which should be made when adding/removing concepts from schemes, or when adding/removing broader relationships between concepts, which could break branches of concept trees for various schemes.

Assumptions

OWLART provides a mechanism to end user applications for managing concept tree views over different concept schemes. Note that in SKOS, the skos:broader/narrower relationship, being realized through a simple triple, is not bound in any way to the notion of skos:conceptScheme. That is, a concept A is (or is not) skos:broader of a concept B independently of the schemes they belong, and it is not possible to assert a broader relationship which is local to a given scheme.

The kind of scheme-filtered view OWLART can provide is an API method which, by specifying a given scheme view, retrieves broader/narrower concepts filtering out those not belonging to the selected scheme (so, actually, not all borader/narrower concepts are returned).

Important: please notice that SKOS L2577 tells that:

<A> skos:narrower <B> .
<A> skos:inScheme <MyScheme> .
does not entail
<B> skos:inScheme <MyScheme> .

 

So, it is important that applications using OWLART (such as Semantic Turkey or VocBench) maintain that, for a given scheme, a tree based on a scheme view is never broken, that is, all of the concepts on its branches, belong to that scheme.

Legal Configurations and Integrity breaks

Note that some options may be desired. For instance, in the case of the sequence of concepts:

A skos:broader ..; skos:inScheme S .  (the rest of the tree, here we limit to consider these tree concepts)
B skos:broader A
C skos:broader B

if it is desired that scheme S shows only concept A, then it is admittable to have only A skos:inScheme S. The tree branch will be interrupted on A, but that's fine, because maybe, in the intention of the publisher, that branch should represent only some high-level concepts and be interrupted from showing further narrower concepts.

 

Also, a sequence like this is legal:

A skos:broader .. ; skos:inScheme S . 
B skos:broader A   
C skos:broader B ; skos:topConceptOf S

In the above case, A (following its broader concepts not reported here) will be shown. B will be left out, but B, though narrower of A, will be shown also as topConcept of that same scheme S (you may find it weird, but SKOS allows for that, not only because it is possible to write these triples, but this is a concrete possibility suggested in the specifications)

 

On the contrary, a sequence like this is not legal:

A skos:broader .. ; skos:inScheme S . 
B skos:broader A   
C skos:broader B ; skos:inScheme S .

In the above case, C is inScheme S, but has not broader concept in S, nor it is a topConceptOf S, thus there is no reachability for it (i.e. there is no path going from a topConcept of S to it which passes through all concepts which are bound through a skos:broader chain AND are all belonging to scheme S).

 

Checks

We will start reporting here a series of checks that are expected to be carried out by applications dealing with SKOS cross-scheme management. These checks should be applied when adding/removing concepts from a scheme, when asserting/retracting broader/narrower relationships and, in general, with all other operations which could cause a integrity break according to the above configurations.

Removing a concept from a scheme

When removing a concept C from a scheme TS, the operation should be allowed unless

1) C belongs only to TS (otherwise C itself would remaing dangling )
2) there is a chainbreak (CB) due to at least one of C narrowers remaining dangling in TS.
The check should be as defined below:
For each concept N narrower of C:.

  • If N doesn’t belong to scheme TS, then there it is not causing a CB.
  • If N is in scheme TS, but it is a top concepts of TS, then it is not a problem, because you won’t break any chain, as it is also topconcept of TS and thus visible even if its broader is removed from TS. You could ask: how is it possible that a concept is narrower of another concept which is in TS, and be also a topConcept of TS? Well, in SKOS this is possibile… (that’s the weird thing I told in the previous email when I joked about our innocence wrt to SKOS weirdness in the first days of development of ST  ). In that case, when vieweing scheme TS, you would see N both under C and as a topConcept.
  • One further check you could add is: if after the above checks, you have some N which seems to be causing a CB, you could check if N as some other broader (not C) which is in TS. In that case, N would be reachable in any case. Note: this check would just widen the possibilities. By not applying it, you are not causing any damage, you are just forbidding removal in a case where it could be admitted. My suggestion is that you do not carry it, and we will do everything server side in ST core SKOS services on VB2.2.