Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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

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

  • No labels