W3C

Using OWL and SKOS

May 2008

Authors:
Sean Bechhofer, University of Manchester
Alistair Miles, STFC Rutherford Appleton Laboratory / University of Oxford

Abstract

This document tries to identify a number of patterns for working with SKOS and OWL.

The information contained here is not part of the normative SKOS recommendation. Rather, it is intended to provide an informative description of the possible ways in which SKOS vocabularies and OWL ontologies may interact.


Status of this Document

This document describes ways in which SKOS and OWL may be used together. The document is still under development and content may be subject to change.


Contents


Introduction

There are several possible situations in which we might want to use both SKOS and OWL.

For example, we might want to migrate from a semi-formal thesaurus-like structure to a formal ontology, to enable "richer" queries and new types of inference.

We might also want to do the opposite, and generate a semi-formal thesaurus-like structure from a formal ontology, perhaps for import into an application which has a simple browsing or navigation interface.

Alternatively, we might want to have a "hybrid" conceptualisation which is partly formal, partly semi-formal. This is actually a very common situation, which arises in any "faceted browsing" system. For example, the Semantic Web Environmental Directory (SWED) has a formal model describing organisations, projects and their respective properties such as their topic of interest, their geographical coverage etc., and semi-formal vocabularies describing e.g. actual topics of interest such as animal welfare, conservation etc.

Finally, we might want to add more human-readable information (labels and documentation) to an existing formal ontology.

This document discusses these four situations, and possible design patterns for their implementation.


Going from Less to More Formal (SKOS to OWL)

In this situation, we start off with a semi-formal conceptualisation, expressed using SKOS, and we want to create a formal conceptualisation, expressed using OWL.

This process necessarily requires some human input. However, what we are discussing here is not the process itself, but choices for expressing the result (output) of that process.

There are two basic patterns for expressing the result of this process.

To illustrate these patterns, let's start with the following semi-formal conceptualisation:

ex:mountains rdf:type skos:Concept;
  skos:prefLabel "Mountains"@en.

ex:himalayas rdf:type skos:Concept;
  skos:prefLabel "Himalayas"@en;
  skos:broader ex:mountains.

ex:everest rdf:type skos:Concept;
  skos:prefLabel "Everest"@en;
  skos:broader ex:himalayas.

Overlay SKOS with OWL

In this pattern, we use OWL to overlay additional semantics on the same vocabulary, e.g. by adding the following triples:

ex:mountains rdf:type owl:Class.

ex:himalayas rdf:type owl:Class;
  rdfs:subClassOf ex:mountains.

ex:everest rdf:type ex:himalayas.

If the two sets of triples are merged, then this pattern necessarily leads to an OWL Full representation, because an instance of skos:Concept might also be an instance of owl:Class.

Forgive me, but to use an analogy from the movie "Ghostbusters", I think of this pattern as "crossing the SKOS and OWL streams".

Allowing this design pattern has an impact on our choice for the semantics of skos:Concept. If this pattern is allowed, then skos:Concept cannot be disjoint with owl:Class or owl:ObjectProperty. (Note that owl:Class is equivalent to rdfs:Class and owl:ObjectProperty is equivalent to rdf:Property in OWL Full [OWL-REFERENCE].)

Transform SKOS to OWL

In this pattern, we view the process as a "transformation", and coin a new set of URIs to denote the classes, properties and individuals in the result (output) of the transformation.

For example, the result of the transformation might be:

ex2:MountainClass rdf:type owl:Class.

ex2:HimalayaClass rdf:type owl:Class;
  rdfs:subClassOf ex2:MountainClass.

ex2:EverestIndividual rdf:type ex2:HimalayaClass.

This pattern effectively treats SKOS and OWL universes as separate, and uses a completely separate vocabulary in each case. Because it does this, it is compatible with OWL DL.

To use the Ghostbusters analogy again, this pattern is very careful not to cross the SKOS and OWL streams.

Allowing this design pattern does not have any consequences for our choice of semantics for skos:Concept. I.e. we are free to have either a strict or a liberal semantics for skos:Concept.

As a point of interest, because there is a natural correspondance between the artefacts in our semi-formal conceptualisation, and the classes, properties and individuals in our formal conceptualisation, we might want some "bridging properties" to express this correspondance.

Some URIs have been suggested for this purpose -- skos:it and skos:as. For example:

ex:mountains skos:it ex2:MountainClass.
ex:himalayas skos:it ex2:HimalayaClass.
ex:everest skos:it ex2:EverestIndividual.

The precise semantics of such properties are not clear, but they might be useful even without clearly defined formal semantics.


Going from More to Less Formal (OWL to SKOS)

In this situation, we start with a formal conceptualisation expressed using OWL, and we want to create a semi-formal conceptualisation expressed using SKOS.

This process does not require any human input. As a point of interest, the process could be implemented as an inference process, or as a model-driven transformation. However, again, this discussion is not focused on the process itself, but on the patterns for representing the result of that process.

As with going in the other direction (from less to more formal), the same two basic patterns for expressing the result of the process are available: overlay and transformation.

To illustrate, let's start with the following formal ontology:

ex2:MountainClass rdf:type owl:Class.

ex2:HimalayaClass rdf:type owl:Class;
  rdfs:subClassOf ex2:MountainClass.

ex2:EverestIndividual rdf:type ex2:HimalayaClass.

Overlay OWL with SKOS

In this pattern, we use SKOS to overlay some additional triples, for example:


ex2:MountainClass rdf:type skos:Concept.

ex2:HimalayaClass rdf:type skos:Concept;
  skos:broader ex2:MountainClass.

ex2:EverestIndividual rdf:type skos:Concept;
  skos:broader ex2:HimalayaClass.

Again, this is necessarily OWL Full, if the two sets of triples are merged -- we are crossing the SKOS and OWL streams. Therefore, if we allow this pattern, we cannot have skos:Concept disjoint with owl:Class.

As a point of interest, the SKOS overlay triples could be inferred by RDFS-entailment, by stating that rdf:type, rdfs:subClassOf and rdfs:subPropertyOf are all sub-properties of skos:broader. If we were to allow that, then there would be consequences for the semantics of skos:broader, because we would at least have to optionally allow skos:broader to be interpreted as both reflexive and transitive.

Transform OWL to SKOS

In this pattern, we view the process as a "transformation", and coin a new set of URIs for the output. For example, we might generate the following triples:

ex:mountains rdf:type skos:Concept.

ex:himalayas rdf:type skos:Concept;
  skos:broader ex:mountains.

ex:everest rdf:type skos:Concept;
  skos:broader ex:himalayas.

As above, here we are being very careful not to "cross the SKOS and OWL streams". This pattern is compatible with OWL DL. Again, we would probably want some "bridging" properties to express a link between the artefacts in the input and output.

As a point of interest, this pattern is compatible with viewing the transformation process as a "model-driven" transformation from OWL to SKOS, where each class, property and individual in the OWL ontology is mapped to a new SKOS conceptual resource etc.


Formal / Semi-Formal Hybrids -- Part OWL, Part SKOS

In this situation, OWL and SKOS are used side-by-side to model different parts of the same conceptualisation.

For example (adapted from SWED), we might use OWL to define a class of Organisations, and its relevant properties:

ex:Organisation rdf:type owl:Class.

ex:topicOfInterest rdf:type owl:ObjectProperty;
  rdfs:domain ex:Organisation;
  rdfs:range ex:TopicOfInterestConcept.

ex:TopicOfInterestConcept rdf:type owl:Class;
  rdfs:subClassOf skos:Concept.

We might then use SKOS to define some topics of interest, e.g.:

ex:AnimalWelfare rdf:type ex:TopicOfInterestConcept;
  skos:prefLabel "Animal Welfare"@en.

ex:WelfareOfWildAnimals rdf:type ex:TopicOfInterestConcept;
  skos:prefLabel "Welfare of Wild Animals"@en;
  skos:broader ex:AnimalWelfare.

ex:WelfareOfDomesticAnimals rdf:type ex:TopicOfInterestConcept;
  skos:prefLabel "Welfare of Domestic Animals"@en;
  skos:broader ex:AnimalWelfare.

This pattern is perfectly compatible with OWL DL, and doesn't place any constraints on our choices for the semantics of skos:Concept. Although SKOS and OWL vocabularies are used in the same graph, the "SKOS and OWL streams" are effectively kept separate.


Adding Labels and Documentation (Notes) to a Formal Ontology

In this situation, we already have a formal ontology represented using OWL. To help people understand the ontology better, we want to add more human-readable information, as labels, notes etc. We use only the labelling and documentation (note) properties from SKOS to do this.

Because this situation doesn't involve the use of skos:Concept at all, allowing this pattern has no impact on our choice for the semantics of skos:Concept. Therefore, I won't go into any more detail about this pattern here. (It does, however, have an impact on our choice of semantics for the SKOS labelling and documentation properties, which I discuss in [LABEL-SEMANTICS].)


Summary

This document has illustrated four situations in which SKOS and OWL might be used together.

The first situation involves going from less to more formal knowledge representation (SKOS to OWL). There are two design patterns for representing the output of the process, here called "transformation" and "overlay".

The "transformation" pattern keeps the vocabularies of the input and output separate, and is "safe" in the sense that there are no complicated semantic consequences.

The "overlay" pattern is less "safe", in the sense that the result can lead to an OWL Full representation, and allowing the pattern has consequences for our choice of semantics for skos:Concept -- i.e. we would have to have a very liberal semantics for skos:Concept (which is not necessarily a bad thing).

The second situation involves going from more to less formal knowledge representation (OWL to SKOS), and the same two design patterns are available. Again, the "transformation" pattern is safe, but allowing the "overlay" pattern would force us to state a very liberal semantics for skos:Concept.

I.e. for moving between SKOS and OWL in either direction, we can allow the "transformation" pattern without any impact on our discussion of the semantics of skos:Concept. However, if we allow the "overlay" pattern, this would have a impact on our choice of semantics for skos:Concept, e.g. because we could not state that skos:Concept is disjoint with owl:Class (although we might not want to do this anyway).

The third situation involves a "hybrid", part formal, part semi-formal knowledge representation (part OWL, part SKOS). There is only one pattern here, which is quite safe, and should not impact our discussion of the semantics of skos:Concept.

The fourth situation involves using only SKOS labelling and documentation (note) properties to add more human-readable information into a formal ontology. This situation doesn't involve skos:Concept in any way, so has no impact on the current topic.

Recommendations

I think all of the above design patterns are important, and should be allowed. Therefore, I would recommend we choose a liberal semantics for skos:Concept which does not rule out any of the above patterns.

(We should also take the same consideration into account when choosing a semantics for other URIs in the SKOS vocabulary e.g. we should choose a semantics for skos:broader which does not rule out any of the above patterns.)


References

[SKOS-GUIDE]
http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102
[SKOS-SPEC]
http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20051102
[RDF-CONCEPTS]
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
[RDF-SEMANTICS]
http://www.w3.org/TR/2004/REC-rdf-mt-20040210/
[OWL-REFERENCE]
http://www.w3.org/TR/2004/REC-owl-ref-20040210/
[LABEL-SEMANTICS]
http://purl.org/net/skos/2007/10/f2f/labelling-properties.html

--- Change Log ---
$Log: master.html,v $
Revision 1.1  2008/06/09 14:55:19  sbechhof2
Initial document based largely on:

http://isegserv.itd.rl.ac.uk/public/skos/2007/10/f2f/skos-owl-patterns.html