Using OWL and SKOS

May 2008

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.

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:

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.

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:

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.

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:

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:

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.)