SKOS (Simple Knowledge Organisation System) Semantics

This section last edited on 2010-04-01 12:48:29 is part of the SKOS/Semantics wiki draft.

Introduction

@@TODO general introduction

Basis for the Semantics

In this document, semantic conditions on the interpretation of the SKOS Vocabulary may be given in one of two forms:

• Wherever possible, semantic conditions are stated as a set of "axiomatic" RDF triples, using the RDF, RDFS and OWL Vocabularies.

• Where this isn't possible, semantic conditions are stated using the mathematical definitions and conventions established in section 5 of [OWL Semantics], where I = < R_I, P_I, EXT_I, S_I, L_I, LV_I, > is an an interpretation of some vocabulary V with respect to a datatype map D.

This formulation of the SKOS semantics has been designed to allow applications to choose whether to view SKOS as a vocabulary extension of either RDF, RDFS or OWL Full.

Note that some aspects of the semantics of SKOS, which are deemed to be useful under certain circumstances, cannot be stated without violating the syntactic constraints imposed by the OWL DL language. This has been raised as an issue for the SWDWG, which has yet to be resolved.

As a temporary solution, this document marks a number of axiomatic triples as [OWL-Full]. Applications MAY then choose to view SKOS as a vocabulary extension of OWL DL, by ignoring any triples marked as such.

Guidance on how to use the SKOS Vocabulary within the constraints of the OWL DL language will be given in the SKOS/Primer.

URI Abbreviations

Throughout this document, URIs are presented in an abbreviated form, using the following table of abbreviations:

Structure of this Document

The main body of this document is divided into a number of different "modules". This is entirely for the convenience of the reader, and no formal meaning is intended by the word "module".

The structure of each module is decribed below.

First, URIs from the SKOS Vocabulary are given, to which subsequent statements within the module apply. These are given as a list of abbreviated URIs, using abbreviations set out in section @@TODO. For example:

Second, semantic conditions on the interpretation of these elements are stated. As described in section @@TODO above, semantic conditions are either stated as a set of RDF triples using the same syntax as is used in [RDF Semantics] (i.e. N-Triples with URI abbreviations allowed), for example:

or as formal statements following the conventions and definitions established in section 5 of [OWL Semantics], for example:

Third, informative examples may be given using the [Turtle] RDF syntax, which are consistent with the semantics, for example:

ex:a ex:foo "bar"@en.

Fourth, if applicable, informative examples may be given using the [Turtle] RDF syntax, which are not consistent with the semantics (i.e. give rise to a logical contradiction).

Fifth, any syntactic conditions which apply to the use of the vocabulary in RDF graphs are stated, using keywords MUST, SHOULD, MAY etc. as defined by [RFC 2199], for example:

Finally, any new entailment rules are stated, which follow from the semantic conditions given in the module. These rules are informative only, and are presented using the same conventions as used in section @@TODO of [RDF Semantics]. For example:

This section last edited on 2010-04-01 12:48:29 is part of the SKOS/Semantics wiki draft. The following open issues are directly associated with this module: ISSUE-31. The following open issues may have a bearing on this module: ISSUE-26, ISSUE-27.

Module: Labelling

This module defines a semantics for the basic labelling properties available in SKOS.

The triples below define semantic conditions on the interpretation of this vocabulary.

There are no further semantic conditions on the interpretation of this vocabulary.

Intuitively, it doesn't make sense for a resource to have more than one "preferred" label in any given language, or for a label to be both "preferred" and "alternative", or for a label to be both "alternative" and "hidden", or for a label to be both "preferred" and "hidden". Note however that these intuitions are not handled within the semantics, but are handled instead at a syntactic level (see the syntactic conditions given below), which is perhaps easier to implement and allows error-tolerant strategies to be defined.

This means that, under the semantics given above, the examples below are logically consistent, even though they are intuitively inconsistent.

ex:a skos:prefLabel "foo"@en.
ex:a skos:prefLabel "bar"@en.

ex:a skos:prefLabel "foo"@en.
ex:a skos:altLabel "foo"@en.

ex:a skos:altLabel "foo"@en.
ex:a skos:hiddenLabel "foo"@en.

ex:a skos:prefLabel "foo"@en.
ex:a skos:hiddenLabel "foo"@en.

Syntactic conditions on the use of this vocabulary are given below.

The first syntactic condition means that applications are only obliged to handle plain literals in the object position where these predicates are used. For example, an application MAY ignore the following triples:

ex:a skos:prefLabel ex:b.
ex:c skos:altLabel _:xxx.

The second syntactic condition specifies the recommended way for an application to handle more than one preferred label in any given language. For example, an application SHOULD ignore all but one of the following triples:

ex:a skos:prefLabel "foo"@en.
ex:a skos:prefLabel "bar"@en.
ex:a skos:prefLabel "baz"@en.

The third and fourth syntactic conditions specify the recommended way for an application to handle "clashes" between skos:prefLabel, skos:altLabel and skos:hiddenLabel. For example, an application SHOULD ignore the second triple in each of the three graphs below.

ex:a skos:prefLabel "foo"@en.
ex:a skos:altLabel "foo"@en.

ex:a skos:prefLabel "foo"@en.
ex:a skos:hiddenLabel "foo"@en.

ex:a skos:altLabel "foo"@en.
ex:a skos:hiddenLabel "foo"@en.

These syntactic conditions are intended to provide applications with an error-tolerant way of handling intuitively inconsistent data, which may easily arise where graphs are being merged from multiple sources. Nevertheless, producers of SKOS data are strongly advised to ensure that the graphs they produce do not contain any triples which trigger these syntactic conditions.

This section last edited on 2010-04-01 12:48:29 is part of the SKOS/Semantics wiki draft.

Module: Grouping Constructs

This module defines the grouping constructs available in SKOS, also known as "collections".

See also SKOS/Primer/Grouping.

The triples below define semantic conditions on the interpretation of this vocabulary.

There is also a logical relationship between the skos:memberList and skos:member properties, which is stated below (where "sequence" is defined as in section 5 of [OWL Semantics]).

I.e. informally, for ordered collections, every member given by the skos:memberList property can also be given by the skos:member property.

See SKOS/Primer/Grouping for examples of consistent and inconsistent usage of this vocabulary.

Note in particular that the use of a skos:Collection in either the subject or object position of a triple involving skos:broader, skos:narrower or skos:related as predicate will result in an inconsistency. This is because skos:Collection is disjoint with skos:Concept, and because skos:broader, skos:narrower and skos:related are sub-properties of skos:semanticRelation, which has both domain and range skos:Concept (see also SKOS/Semantics/ParadigmaticRelations).

See SKOS/Primer/Grouping for guidance on how to construct a systematic hierarchical display involving grouping constructs.

There are no syntactic conditions on the use of this vocabulary.

The following entailment rules follow from the logical relationship between the skos:memberList and skos:member properties stated above, where u v and x stand for any URI or blank node ID.