Humbly Report: Sean Bechhofer

Semantics 'n' stuff

Archive for the ‘skos’ Category

Gone Fishin’

leave a comment »

Roman Aquaduct, Segovia

A Fish

The project website is now online. is a collaboration between the University of Manchester School of Computer Science, the Freshwater Biological Association, King’s College London Centre for e-Research and Queen Mary, University of London River Communities Group funded under JISC’s Managing Research Data Programme. The project overview is as follows:

Motivated by the large quantity of diverse data in the freshwater biology community, FISH.Link will provide a demonstrator of the benefits of publishing data by illustrating how data can be combined, repurposed and reused with attribution and provenance information to promote data sharing. The project intends to support the sharing and integration of research data through the application of lightweight vocabularies and vocabulary mapping, facilitating integration of data sets, and moving towards the Web of Data that forms the current Linked Open Data vision.

A case study that addresses a real scientific question will be used to provide motivation, requirements and support evaluation. will produce tools that allow fresh water biologists to publish data in to the Linked Data Cloud. These tools will be integrated into the FISHnet platform that supports the data life cycle in fresh water science and will use SKOS for the representation of vocabularies.

The project will run for 12 months until July 2011.

Written by Sean Bechhofer

August 24, 2010 at 10:04 am

Posted in linked data, projects, skos

Tagged with ,

SKOS: Organisation

leave a comment »

Roman Aquaduct, Segovia

Roman Aquaduct, Segovia

Continuing the theme of reflecting on SKOS, the question of organisation is next. SKOS provides an RDF vocabulary for describing Knowledge Organisation Systems and there’s an assumption that SKOS is RDF from the ground up. The use of RDF brings advantages, but there are also limitations, in particular when we consider issues of containment. This is something that I wrestled with in the past when building the OWL-API libraries to support OWL [1]. In the RDF/XML serialisations of OWL, there was no explicit connection between the axioms stated in an ontology and the Ontology object itself. This can cause difficulties in the face of owl:imports as there was also no explicit link between the location where an RDF graph that represents and ontology is retrieved from and the URI of the Ontology itself. This was partly solved by the use of physical and logical URIs, but the question of containment is still there.

There is a similar, but perhaps more easily stated issue with SKOS. Consider, for example, the following fragment from the IVOAT thesaurus [2]:

rotating body

Thus asteroid is a narrower term of rotating body. In the SKOS version of this thesarus, we have two concepts, and with triples asserting the appropriate labels, the fact that these concepts occur in the IVOAT scheme and the narrower relationship.

<> rdf:type skos:ConceptScheme ;

:asteroid rdf:type skos:Concept ;
          skos:inScheme <> ;
          skos:prefLabel "asteroid"@en ;

:rotatingBody rdf:type skos:Concept ;
              skos:inScheme <> ;
              skos:prefLabel "rotating body"@en ;
              skos:narrower :asteroid.              

What we don’t have here, however, is the assertion that the narrower relationship occurs within the ConceptScheme. The same also holds of the labels — the labelling of the concept is not explicitly bound to the concept scheme.

Now, this isn’t really a failing of SKOS, but is rather a consequence of the use of RDF for the representation. Solutions to this could involve reification (bleuurgh) or the use of named graphs to identify the triples associated with a ConceptScheme. At the time of the SKOS Recommendation, however, no standard was available.

Does this really matter? Is it an issue? So far, a lot of SKOS publication seems to be organisations exposing their own vocabularies, with instances of skos:Concept appearing in a single skos:ConceptScheme with semantic relationships asserted “within” that scheme and thus under the control of the Scheme “owner”. That may not be too difficult to manage. Things will get more interesting once we have greater use of the SKOS mapping relationships [3], which are intended for use between Concepts in different ConceptSchemes. Such mappings are likely to present different and potentially conflicting points of view or opinions, and we will then require more details of the provenance of the assertions.


  1. OWL API
  2. IVOAT Thesaurus
  3. SKOS Mapping Properties,

Written by Sean Bechhofer

June 16, 2010 at 5:19 pm

Posted in rdf, skos, talks

SKOS: Too Simple?

with 2 comments

Stockport Viaduct

Bridging the Gap: Stockport Viaduct

I gave a keynote at the Extended Semantic Web Conference in Crete last week, speaking on the topic of SKOS, Simple Knowledge Organisation System [1,2]. Towards the end of the talk, I considered the question as to whether SKOS was actually too simple, had insufficient knowledge and a lack of organisation. Personally, I don’t think this is the case. We do still need further evidence and implementation experience, but the growing takeup and usage of SKOS suggests that there is sufficent for many purposes.

During the Q&A, Frank van Harmelen asked a question relating to this point. To paraphrase Frank, the question was essentially “without the additional semantics, what do you get from SKOS that you don’t get from XML?”. At the time, I didn’t give a particular good response to the point (I’m actually pretty terrible at thinking on my feet and answering questions in talks). However, with some reflection, I think that there is enough in there to make it useful and to support interoperation.

Simple put, SKOS essentially allows us to describe concept schemes, collections of concepts that can be used to index and retrieve collections of things. Those concepts can be labelled and can be organised using hierarchical/taxonomic and associative relations. The semantic relationships in SKOS (skos:broader, skos:narrower and skos:related) do not have a formal semantics in the way that OWL subclass hierarchies have a formal semantics. Rather, broader is used to “…to assert that one concept is broader in meaning (i.e. more general) than another…” [3]. A retrieval application using a SKOS vocabulary can then, for example, use the concept taxonomy to expand search terms to cover more potentially related topics. Similarly, the labelling properties (skos:prefLabel, skos:altLabel and skos:hiddenLabel) allow the association of labels with concepts, with “terms used a descriptors in indexing systems … represented using [skos:prefLabel]…” [3]. The presence of alternate labels allows for synonym replacement or again the broadening/narrowing a search processes.

Although these “semantics” (if one could even consider them as semantics) are not expressed in a machine processable form, I believe that the prose in the SKOS Recommendation documents [1,2] provide sufficient descriptions to facilitate interoperation between applications using SKOS vocabularies. If tighter interpretations are required, SKOS allows for extensions to the vocabulary (e.g. through subproperties).

So there is more here than just providing XML tags — we have a vocabulary with an associated description of how that vocabulary should be interpreted. Clearly we need to be careful what assumptions we make when consuming SKOS vocabularies, and it’s perhaps not much, but it’s hopefully enough.


  1. SKOS Home page
  2. A. Miles, S. Bechhofer (Eds.) SKOS Simple Knowledge Organization System Reference. W3C Recommendation.
  3. A. Isaac, E. Summers (Eds.) SKOS Simple Knowledge Organization System Primer. W3C Working Group Note

Written by Sean Bechhofer

June 8, 2010 at 12:56 pm

Posted in skos, talks


Get every new post delivered to your Inbox.