SKOS Development

While not intended as a full SKOS guide, this page provides insights on aspect of SKOS development which are usually less known, best practices and also typical modeling issues and how they are dealt with in VocBench.

Concept Scheme Management and Multiple Schemes

A concept scheme identifies a single thesaurus or, more in general, a KOS (Knowledge Organization System). This is explained in different sections of the SKOS Primer guide. However, in SKOS, it is possible to use Concept Schemes in more advanced forms that, in general, imply the reuse of concepts across different schemes.

There can be different scenarios: for instance, there can be a thesaurus with completely disjoint schemes or, conversely, one scheme containing everything, and then some views over the full content. An example of a view is a concept scheme defining a subtree which is rooted on a concept which is not a topconcept of the main scheme. This is shown in the following code sample:

<S1> a skos:ConceptScheme .
<S2> a skos:ConceptScheme .
<C1> a skos:Concept .
<C2> a skos:Concept .

<C1> skos:topConceptOf  <S1> .
<C2> skos:inScheme      <S1> .
<C2> skos:broader       <C1> .


<C2> skos:topConceptOf  <S2> .

So, in S1, C1 is a topConcept, and C2 is a concept positioned "under" C1.
However, in the scheme S2, C2 is a top concept, and C1 is not present there.

It is possible even to have a mix of both situations, with some main disjoint schemes (i.e. no concepts in common) and some other schemes providing views over them, or even have partially overlapping schemes.

VocBench accounts for all of the above situations, and provide support in dealing with all of them.

ConceptScheme URI Naming Best Practices

There is no explicit rule nor consensus on how to name concept schemes. A quite common practice is to give the main scheme of a thesaurus (e.g. the scheme - if any - which usually holds all of its concepts), a URI equal to the thesaurus baseuri, minus the trailing slash.

E.g. in the case of Agrovoc, the baseuri is: http://aims.fao.org/aos/agrovoc/
and the URI of the mainscheme is: http://aims.fao.org/aos/agrovoc

For other schemes, usually they follow the same URI pattern of concepts, that is: baseuri + localname.

Cross-Scheme Management

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

Two important considerations hold:

Scope of broader/narrower relations: (see end of section 2.5 of the SKOS Primer): in SKOS, the broader/narrower relationship is not local to a scheme, so if you define a concept as broader/narrower of one another, this will happen everywhere

Visibility: for a concept C to be visible in a scheme S, it must not only belong to it, but there should be a clear path from a top concept of S to C, running through all concepts belonging to S (this trivially includes C being a topConceptOf S)

please notice in fact 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, 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 (that could seem to represent an integrity break) may be actually desired by the user, and should thus not be forbidden in toto. 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 three 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 as well:

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 C, though being 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 skos:inScheme S, but has not broader concept which is also skos:inScheme S, nor it is a skos: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 skos:inScheme S. The concept is thus not reachable from the tree and thus will never be visible on the concept panel when the view on scheme S is activated.

Checks

We report here a series of checks that are carried out by VocBench. These checks are 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:.