Archive for the ‘skos’ Category
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 . 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 :
asteroid is a narrower term of
rotating body. In the SKOS version of this thesarus, we have two concepts,
http://www.ivoa.net/rdf/Vocabularies/IVOAT#asteroid with triples asserting the appropriate labels, the fact that these concepts occur in the IVOAT scheme and the narrower relationship.
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 , 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.
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: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…” . 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:hiddenLabel) allow the association of labels with concepts, with “terms used a descriptors in indexing systems … represented using [
skos:prefLabel]…” . 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.
- SKOS Home page http://www.w3.org/2004/02/skos/.
- A. Miles, S. Bechhofer (Eds.) SKOS Simple Knowledge Organization System Reference. W3C Recommendation. http://www.w3.org/TR/skos-reference/
- A. Isaac, E. Summers (Eds.) SKOS Simple Knowledge Organization System Primer. W3C Working Group Note http://www.w3.org/TR/skos-primer/