• SkosDesign
• RdfsSemanticExtension

This document is an attempt to specify the semantics of SKOS as a semantic extension of RDFS.

Introduction

Following [RDF-SEMANTICS], the semantics of SKOS is given here as a list of semantic conditions on the interpretation of the SKOS Vocabulary and a set of axiomatic triples.

This document uses exactly the same definitions and notational conventions as laid out in [RDF-SEMANTICS]. However, rather than present all of the semantic conditions in a single table as is done in [RDF-SEMANTICS], each semantic condition is presented separately, so that the conditions may be understood and discussed independently.

Each condition is first introduced with an informal description of the intended semantics. The formal semantic condition is then given as a single row in a table. The logical consequences of the condition may then be illustrated by means of an example, and any further relevant discussion is given.

Some of the semantic conditions presented below should be intuitively obvious, and hence there should be little controversy as to their admission into the SKOS semantics. The problem for these conditions is to ensure that they have been specified correctly and as concisely as possible, and that their logical consequences are fully understood.

On the other hand, some of the semantic conditions presented below may be contentious, and there may be viable alternatives. Where a condition is potentially contentious, it is indicated as so, and possible alternatives are briefly mentioned.

This document builds on and extends earlier informal work on specifying integrity constraints for skos data, see [SKOS-INTEGRITY].

[ AlistairMiles: Reader beware! I have done my best to understand the principles of the RDF semantics, but I am at best an amateur logician. There may be serious errors in this document, and terminology may be used inappropriately. ]

Interpreting the SKOS Vocabulary

SKOS Interpretations

SKOS extends RDFS to include a larger vocabulary skosV with additional semantic constraints.

A skos-interpretation of a vocabulary V is an rdfs-interpretation I of (V union rdfV union rdfsV union skosV) which satisfies the following semantic conditions and all the triples in the subsequent table, called SKOS axiomatic triples.

Semantic Condition 1 (preferred lexical label cardinality)

Intuitively, it does not make sense for a resource to have more than one preferred lexical label (per language per written script). I.e. two things cannot both be "preferred".

If we accept that different language/script combinations can be specified by the language tag on a plain literal, then this condition can be restated informally as: for any resource, all values of the skos:prefLabel property must have a different language tag.

This condition makes it possible to write a contradictory statement in SKOS, by asserting two values of the skos:prefLabel property with the same language tag. For example

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

cannot be true in any skos-interpretation; it is skos-inconsistent.

Semantic Condition 2 (lexical label disjoint)

Intuitively, it does not make sense for any lexical label to be both "preferred" and "alternative", or both "preferred" and "hidden", or both "alternative" and "hidden", or all three. This can be restated informally as: for any resource, the sets of values of the properties skos:prefLabel skos:altLabel and skos:hiddenLabel must not overlap.

This condition makes it possible to write a contradictory statement in SKOS. For example

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

cannot be true in any skos-interpretation; it is skos-inconsistent.

Semantic Condition 3 (alternative lexical label isolation)

Intuitively, if some resource has an "alternative" lexical label in some language+script combination, then it must also have a "preferred" lexical label in the same language+script. I.e. you can't have an "alternative" without something else being "preferred".

This semantic condition licenses an inference rule, which may have no practical value.

Note that it is reasonable for a resource to have a "hidden" lexical label without having either "preferred" or "alternative" lexical labels.

Semantic Condition 4 (broader/narrower inverse)

Intuitively, the notions of "broader" and "narrower" are intended to be each other's inverse.

This semantic condition licenses some inference rules, with definite practical value.

For example

<ex:a> skos:broader <ex:b>.

entails

<ex:b> skos:narrower <ex:a>.

and vice versa.

Semantic Condition 5 (related symmetric)

Intuitively, the notion of "related" is symmetrical (although refinements of this notion may not be), i.e. if a is related to b then b is related to a and vice versa.

This semantic condition licenses an inference rule, for example

<ex:a> skos:related <ex:b>.

entails

<ex:b> skos:related <ex:a>.

and vice versa.

Semantic Condition 6 (broader/related disjoint)

The only concrete definition of the "associative relationship" (which skos:related is based on) in any of the thesaurus standards is "that which is not hierarchical". Therefore, it does not make sense for two things to be both "related" to each other and "broader" than each other. Note that this applies not just to immediate hierarchical relationships but also to indirect hierarchical relationships.

This semantic condition makes it possible to write a contradictory statement in SKOS, for example

<ex:a> skos:broader <ex:b>.
<ex:a> skos:related <ex:b>.

cannot be true in any skos-interpretation; it is skos-inconsistent. So too the graph below.

<ex:a> skos:broader <ex:b>.
<ex:b> skos:broader <ex:c>.
<ex:a> skos:related <ex:c>.

A Note on the Transitivity of skos:broader

[ AlistairMiles: This point is likely to be contentious. ]

Note that the semantic conditions on skos-interpretations given above do not constrain skos:broader to be a transitive property.

Semantic extensions of SKOS MAY place extra semantic conditions on the interpretation of skos:broader. For example, a semantic extension may specify the condition that IEXT(I(skos:broader)) defines a transitive relation.

The reason for this is simply to allow applications to make the choice as to whether or not to assume the transitivity of skos:broader and make inferences based on that assumption. For some applications this will be useful; other applications such as retrieval systems that perform graph-based reasoning (where the number of steps in a path is an important metric) will not want to treat skos:broader as transitive.

A Note on skos:Concept

[ AlistairMiles: This point is likely to be contentious. ]

Note that the semantic conditions on skos-interpretations given above do not include any conditions on the interpretation of skos:Concept other than those stated by the SKOS axiomatic triples.

This means that, for example, it is perfectly reasonable for a resource to have both skos:Concept and rdfs:Class as values for the rdf:type property; or for a resource to have both skos:Concept and rdf:Property as values for the rdf:type property.

Semantic extensions of SKOS MAY place extra semantic conditions on the interpretation of skos:Concept.

For example, a semantic extension of SKOS could specify the condition that ICEXCT(I(skos:Concept)) and ICEXT(I(rdfs:Class)) are disjoint (i.e. that a resource cannot have both skos:Concept and rdfs:Class as values for the rdf:type property).

[ AlistairMiles: The following paragraph may be both unnecessary and unhelpful - it is included only for discussion. ]

Although not necessary, it may be helpful to understand the semantics of SKOS in terms of a new semantic construct, a "concept", i.e. a resource which is an abstraction of something else in the universe. Concepts are defined to be things of type skos:Concept. The semantics of SKOS do not consider the possibility that a concept may have an "extension"; the semantics of SKOS are purely intensional. However, the semantics of SKOS do not preclude the possibility that a concept might also be a class, or a property, and therefore have an extension (the semantic conditions for the interpretation of which would then be given by [RDF-SEMANTICS]).

Semantic Condition 7 (broader circularity)

[ AlistairMiles: This point is likely to be contentious. ]

In RDFS, every class is defined to be a subclass of itself (i.e. the property rdfs:subClassOf is reflexive). It is also entirely reasonable to assert circular class subsumption hierarchies - this is equivalent to asserting that all classes in the circularity have the same extension (are "equivalent" classes).

This begs the question as to whether skos:broader should be reflexive or irreflexive, and whether circular assertions represent a contradiction.

It is arguably of no value to applications to assume that skos:broader be reflexive (i.e. that every concept is broader than itself).

It is also arguably of value to applications to assume that circular assertions involving skos:broader represent a contradiction, and to use this constraint as a means for "validating" SKOS data.

This semantics therefore takes the position that nothing can be broader than itself, and a circular assertion involving skos:broader represents a contradiction.

This semantic condition makes it possible to write a contradictory statement in SKOS, for example

<ex:a> skos:broader <ex:a>.

cannot be true in any skos-interpretation; it is skos-inconsistent. So too the graph below.

<ex:a> skos:broader <ex:b>.
<ex:b> skos:broader <ex:c>.
<ex:c> skos:broader <ex:a>.

SKOS axiomatic triples

skos:broader rdfs:domain skos:Concept.
skos:narrower rdfs:domain skos:Concept.
skos:related rdfs:domain skos:Concept.
skos:prefLabel rdfs:domain rdfs:Resource.
skos:altLabel rdfs:domain rdfs:Resource.
skos:hiddenLabel rdfs:domain rdfs:Resource.

skos:broader rdfs:range skos:Concept.
skos:narrower rdfs:range skos:Concept.
skos:related rdfs:range skos:Concept.
skos:prefLabel rdfs:range rdfs:Literal.
skos:altLabel rdfs:range rdfs:Literal.
skos:hiddenLabel rdfs:range rdfs:Literal.