Tags

To SKOS or NOT to SKOS, part 1

Use case

In a project I'm working on a navigation structure is presented on a website to allow the user to navigate to relevant information.
This navigation structure has two levels: the first level describes major categories or domains.
The second level consists of concepts belonging to the respective domains.


navigation structure
Another website uses another navigation structure which is slightly different in structure and the terms used.

In the end the two structures need to be mapped to each other, so that a click on one node in the first environment finds related info from the second site.

SKOS: the solution?


SKOS stands for Simple Knowledge Organisation System for the Web and is a development to support the use of knowledge organisation systems (KOS) such as thesauri, classification schemes, subject heading systems and taxonomies within the framework of the Semantic Web. SKOS is formalised as an RDF vocabulary.

Using SKOS, concepts can be:
- identified using URIs,
- labeled with lexical strings in one or more natural languages,
- documented with various types of note,
- linked to other concepts and organized into informal hierarchies and association networks,
- aggregated into concept schemes,
- grouped into labeled and/or ordered collections,
- mapped to concepts in other schemes.

Our first impression is that SKOS fits our use case very well.
We have two informal hierarchies of which the concepts need to be mapped.

Encoding the navigation structure in SKOS

Scenario 1: all "narrower" relations

First we define a ConceptScheme for this peticular organisation system.
Then we define all the concepts.
Some concepts shown with their label are:
- Family and Youth (level 1)
- Education (level1)
- School holidays (level 2)
- Primary education (level2)
- Secundary education (level 2)
- Childcare (level2)

Then we define the toplevel concepts of the ConceptScheme and we indicate that the toplevel concepts have "narrower" second level terms.

This model looks in Topbraid Ensemble as follows:

narrower in Ensemble

For getting level 1 nodes, this SPARQL Query will do:
SELECT ?concept
WHERE {?scheme a skos:ConceptScheme.
?scheme skos:hasTopConcept ?concept}
For getting level 2 nodes

SELECT ?conceptl2
WHERE {
?concept rdfs:label "Education".
?concept skos:narrower ?conceptl2}
I have two problems with this approach however:
  1. the level 1 concepts are not always concepts, but a combination of concepts for classification reasons. E.g. Is "Traffic, vehicles and roads" a concept or rather a coordinated concept. And how do we threat such coordinated concepts best in SKOS?
  2. the relationships between the concepts are all indicated as "narrow", while this is not the case.
    Primary education is indeed education, hence narrower, but School holidays is not education; it is rather related. Hence ...

Scenario 2: indicating the relationships in a more semantic correct way.

This model looks in Topbraid Ensemble as follows:

semantic in Ensemble
The fact that now two different properties have been used doesn't complicate writing the query to get the subnodes from the toplevel node with label "Education".
We thank this to the fact that both the "narrower" and the "related" property are subproperties from "semanticRelation".

superproperty SematicRelation
Our query becomes

SELECT ?conceptl2
WHERE {?scheme a skos:ConceptScheme.
?scheme skos:hasTopConcept ?concept.
?concept rdfs:label "Education".
?concept skos:semanticRelation ?conceptl2}

This is surely better than the first approach of scenario 1.

Let's move on to the second issue in To SKOS or NOT, part 2.

Comments