This is an archive of an inactive wiki and cannot be modified.


This page is about the SKOS RDF Schema

Current situation

A draft schema [1] is available. The schema is intended to provide a machine readable version of the referencee [2], encoding information in triples where possible. The draft makes a number of decisions w.r.t to namespaces, expressivity and deprecation of vocabulary


OWL Species

The schema is OWL full. This is due to a number of factors. Properties are defined as owl:ObjectProperty and then used with data values, which violates the OWL namespace separation. Properties are also defined as owl:ObjectProperty and then used to assert information about instances of owl:Class. Again, this is not allowed in OWL DL ontologies.

A number of people have expressed a desire to have the schema as an OWL DL ontology. A version of the schema could be produced without the offending triples (largely by removing the documentation from the schema). Usage of the SKOS schema could still easily result in OWL Full ontologies, however, if the documentation properties were to be used in particular ways.

If we do publish an OWL DL schema, how would this be done?

It is likely that the changes introduced in OWL 2 [3] will support the kinds of modelling used in the SKOS schema — in fact the SKOS WG may be able to use the schema as a use case and input for the OWL WG. In this event, an OWL 2 version of the schema could be published without impacting on the intended semantics.

Deprecated vocabulary

In [4] there are three alternative proposals for handling deprecated vocabulary

with C as the preferred option. The only explicit response to this was [5], which stated a strong preference for C. We discussed this at our 6 May 2008 face-to-face and resolved to choose C.

Namespace Change

A comment regarding the namespace change has been posted to the list [6]. A draft response is below.

Dear Bernard and Thomas,

Thank you for your comments regarding the SKOS Reference and

The Working Group spent some time discussing the question of the SKOS
namespace, and whether to adopt a new namespace for the SKOS
Recommendation. For example, see discussion threads:

SWD Telecon meeting minutes:

SKOS Issues:

For the sake of brevity, in the following discussion, I'll refer to
the namespace as the "2004 namespace"
and as the "2008 namespace".

The WG considered the following choices:

1/ Redefine the properties in the existing 2004 namespace


2/ Provide a new namespace

This was not a simple or easy choice -- there are tradeoffs that we
need to consider for both solutions. As you point out in your comment,
even though SKOS is not as yet, a Recommendation, there are already a
number of vocabularies and applications that are using the 2004
namespace. A change of namespace could then require change to those
vocabularies and applications.

A key issue here, however, was the fact that the proposed semantics
for the SKOS vocabulary (in particular the skos:broader and
skos:narrower properties) differ from the semantics in the 2004 SKOS
vocabulary as currently published at:

By continuing to use the 2004 namespace and changing the semantics, we
run the risk of inconsistent interpretations of existing vocabularies
that make assumptions based on the original specification.

The WG decided that there were sufficient changes in the vocabulary
(and semantics) to warrant the introduction of a new namespace. The
existing 2004 namespace can still be used, and the machine-readable
specification will also still be available.  

OWL Annotations

The following text is intended to represent our requirements for either property punning or rich annotations in OWL 2.

The SKOS vocabulary is intended for the representation of simple
knowledge organisation schemes such as thesauri, term lists and
controlled vocabularies. SKOS is designed to fit into existing
Semantic Web standards, and to achieve this, an RDF Schema which
defines the SKOS vocabulary has been produced.

The development of this schema has highlighted issues relating to OWL
species which are relevant to current work on OWL 2. In particular,
the current schema is in OWL Full. It would be desirable if the SKOS
vocabulary could be represented in OWL DL (or the equivalent of OWL DL
in the OWL 2 space).

Concepts in a SKOS vocabulary are defined as instances of the
owl:Class skos:Concept. They may be related to other skos:Concepts
using object properties such as skos:broader, skos:narrower and
skos:related -- known as SKOS semantic relations. SKOS also provides a
set of lexical labelling properties, such as skos:prefLabel and
skos:altLabel. These are datatype properties, with RDF plain literals
as values. Documentation properties including skos:note,
skos:changeNote, skos:definition are also provided, allowing the
decoration of concepts with additional information. In some
circumstances, the expected value of a documentation property is a
literal value (e.g. a simple textual note). In other circumstances,
the value may be an object, for example the value of skos:changeNote
may be a structured object containing information about a change along
with provenance or date information. Documentation properties are
defined as subproperties of skos:note.

An additional use case for SKOS is as an annotation vocabulary for OWL
ontologies. For example the SKOS vocabulary itself uses
skos:changeNote and skos:definition to attach provenance and
documentation information to the SKOS vocabulary terms. This then
pushes the ontology out of OWL DL as object properties are being
applied to classes. We envisage that SKOS properties will also be used
to attach lexical information to OWL ontologies (for example,
providing alternate names or labels for classes). Again, with the
current situation, this results in OWL Full ontologies.

One solution to this would be the provision of rich annotations. The
SKOS documentation properties are essentially annotations and would
ideally be represented as such, but with the addition of subproperty
relationships between the properties (i.e, skos:note as a
superproperty). The lexical labelling properties could also be
considered as annotation properties. SKOS is intended to be
extensible, however, so again allowing the possibility of providing
subproperties of the lexical labelling properties is desirable.

Support for punning, both in terms of class/instance and data/object
property would also provide solutions to some of these issues. Rich
annotations would, however, be our preference.