SKOS Simple Knowledge Organization System
Reference

1. Introduction

1.1. Background and Motivation

@@TODO tighten up this section, maybe move some or all to Primer

The Simple Knowledge Organization System is an attempt to bridge several different fields of knowledge, technology and practice. As always with an attempt of this nature, it involves both opportunities and challenges.

In the library and information sciences, there is a long and distinguished heritage devoted to developing tools for organising large collections of objects such as books or museum artefacts. These tools are known generally as "knowledge organization systems" (KOS) or sometimes "controlled structured vocabularies", although no widely agreed definitions exist for these terms. The situation is complicated because a number of similar yet distinct traditions have emerged over time, each supported by a distinct community of practice and set of agreed standards. Different families of knowledge organization systems, including "thesauri", "classification schemes", "subject heading systems", and "taxonomies" are widely recognised and applied in both modern and traditional information systems. In practice it can be hard to draw an absolute distinction between "thesauri" and "classification schemes" or "taxonomies", although there are some defining properties which can be used to broadly characterise these different families (see e.g. [@@REF-BS8723-X]). The important thing for SKOS is that, in addition to their unique features, each of these families shares much in common, and can often be applied in similar ways.

In recent years, the W3C's Semantic Web Activity has stimulated a new field of integrative research and technology development, at the boundaries between database systems, formal logic and the World Wide Web. This work has led to the development of key foundational standards for the Semantic Web. The Resource Description Framework (RDF) provides a common data abstraction and syntax for the Web. The RDF Vocabulary Description Language (RDFS) and the Web Ontology Language (OWL) together provide a common data modeling (schema) language for data in the Web. The SPARQL Query Language and Protocol provide a standard means for interacting with data in the Web. @@TODO GRDDL & RDFa? These technologies are being applied across a diverse set of applications, because many applications require a common framework for publishing, sharing, exchanging and integrating ("joining up") data from different sources. It is this ability to "join up" data from different sources which, in particular, is proving a powerful motivation for many projects, as different communities seek to exploit the hidden value in data previously spread across isolated sources.

One facet of the Semantic Web vision is the hope that Semantic Web technology could be used to better organise the vast amounts of unstructured (i.e. human-readable) information in the Web, providing new, interesting and multi-dimensional routes to discovering and sharing that information. RDFS and OWL are rich and formally defined knowledge representation languages, and provide powerful ways of expressing meaning in a way that is amenable to computation, meaning which can complement and give structure to information already present in the Web. As such, they go a long way towards supporting that vision, but the story doesn't end there. To actually apply these technologies over large bodies of information requires the construction of detailed "maps" of particular domains of knowledge, in addition to the accurate description (i.e. annotation or cataloguing) of information resources on a large scale, much of which cannot be done automatically. The accumulated experience and best practices in the library and information sciences regarding the organization of information and knowledge is obviously complementary and applicable to this vision, as are the many existing knowledge organization systems already developed and in use, such as the Library of Congress Subject Headings or the United Nations Food and Agriculture Organization's Agrovoc Thesaurus.

The Simple Knowledge Organization System therefore aims to provide a bridge between different communities of practice within the library and information sciences involved in the design and application of knowledge organization systems. In addition, SKOS aims to provide a bridge between these communities and the Semantic Web, by transferring existing models of knowledge organization to the Semantic Web technology context, and by providing a low-cost migration path for porting existing knowledge organization systems to RDF.

Looking to the future, SKOS occupies a unique position in between the exploitation and analysis of unstructured information, the large and socially-mediated organization of information on an informal level, and the formal representation of knowledge. It is hoped that, by making the accumulated experience and wisdom of knowledge organization in the library and information sciences accessible, applicable within and transferrable to the technological context of the Semantic Web, in a way that is complementary to existing Semantic Web technology and in particular formal systems of knowledge representation such as OWL, SKOS may not only enable many new, interesting and valuable applications, but may also lead to new, integrative lines of research and development in both technology and practice.

1.2. What is SKOS?

The Simple Knowledge Organization System is a common data model for knowledge organization systems such as thesauri, classification schemes, subject heading systems and taxonomies. Using SKOS, a knowledge organization system can be expressed as data. It can then be exchanged between computer applications and published in a machine-readable format in the Web.

The SKOS data model is formally defined as an OWL Full ontology. I.e. SKOS is itself an OWL Full ontology. The "elements" of the SKOS data model are classes and properties, and the structure and integrity of the data model is defined by the logical characteristics of and interdependencies between those classes and properties. This is perhaps one of the most powerful and yet confusing aspects of SKOS, because SKOS can, in more advanced applications, also be used side-by-side with OWL to express and exchange knowledge about a domain. However, SKOS is not a formal knowledge representation language.

To understand this distinction, consider that the "knowledge" made explicit in a formal ontology is expressed as sets of axioms and facts. A thesaurus or classification scheme is of a completely different nature, and does not contain any axioms or facts. Rather, a thesaurus or classification scheme identifies and describes, through natural language and other informal means, a set of distinct "ideas" or "meanings", which are sometimes conveniently referred to as "concepts". These "concepts" may also be arranged and organised into various structures, most commonly hierarchies and association networks. These structures, however, do not have any formal semantics, and cannot be reliably interpreted as either formal axioms or facts about the world. Indeed they were never intended to be so, for they serve only to provide a convenient and intuitive "map" of some subject domain, which can then be used as an aid to organising and finding objects, such as documents, which are relevant to that domain.

To make the "knowledge" embedded in a thesaurus or classification scheme explicit in any formal sense requires that the thesaurus or classification scheme be re-engineered as a formal ontology. In other words, some person has to do the work of transforming the structure and intellectual content of a thesaurus or classification scheme into a set of formal axioms and facts. This work of transformation is both intellectually demanding and time consuming, and therefore costly. Much can be gained from using thesauri etc. "as-is", as informal, convenient structures for navigation within a subject domain. Using them "as-is" does not require any re-engineering, and is therefore much less costly.

Because OWL is a formal ontology language, it does not by itself provide a natural or suitable data model for expressing a thesaurus or classification scheme. I.e. it is appropriate (if one has the time, effort and need) to manually re-engineer a thesaurus or classification scheme as a formal OWL ontology, transforming the "concepts" of the thesaurus into the classes, properties and individuals of the ontology, and transforming the informal hierarchies and association networks of the thesaurus into axioms or facts of the ontology. However, it is not appropriate to express the "concepts" of a thesaurus or classification scheme directly as classes of an ontology, nor to express the informal (broader/narrower) hierarchy of a thesaurus directly as a set of class subsumption axioms. The reason for this is that, because a thesaurus or classification scheme has not been developed with formal semantics in mind, but rather as an informal or semi-formal aid to navigation and information retrieval, expressing a thesaurus hierarchy directly as a set of ontology classes with subsumption axioms typically leads to a number of innappropriate or nonsensical conclusions.

OWL does, however, provide a powerful data modeling language. We can, therefore, use OWL to construct a data model which is appropriate to the level of formality in a thesaurus or classification scheme. This is exactly what SKOS does. Taking this approach, the "concepts" of a thesaurus or classification scheme are modeled as individuals in the SKOS data model, and the informal descriptions about and links between those "concepts" as given by the thesaurus or classification scheme are modeled as facts about those individuals, never as class or property axioms. Note that these "facts" are facts about the thesaurus or classification scheme itself, such as "concept X has preferred label 'Y' and is part of thesaurus Z"; these are not facts about the way the world is arranged, as are typically expressed in a formal ontology.

SKOS data is then expressed as RDF triples. For example, the RDF graph below expresses some facts about a thesaurus.

<A> rdf:type skos:Concept ;
  skos:prefLabel "love"@en ;
  skos:prefLabel "adoration"@en ;
  skos:broader <B> ;
  skos:inScheme <C> .

<B> rdf:type skos:Concept ;
  skos:prefLabel "emotion"@en ;
  skos:altLabel "feeling"@en ;
  skos:inScheme <C> .

<C> rdf:type skos:ConceptScheme ;
  dc:title "My First Thesaurus" ;
  skos:hasTopConcept <B> .

This point is vital to understanding the formal definition of the SKOS data model, and how it may be implemented in software systems. This point is also vital to more advanced applications of SKOS, especially where SKOS and OWL are used in combination as part of a hybrid formal/semi-formal design.

From a users point of view, however, the distinction between a formal knowledge representation system and an informal or semi-formal knowledge organization system may naturally become blurred, and can often be ignored without any serious repercussions. In other words, it may not be relevant to a user that <A> and <B> in the graph below are individuals (of type skos:Concept), and <C> and <D> are classes.

<A> rdf:type skos:Concept ;
  skos:prefLabel "love"@en ;
  skos:broader <B> .

<B> rdf:type skos:Concept ;
  skos:prefLabel "emotion"@en .

<C> rdf:type owl:Class ;
  rdfs:label "mammals"@en ;
  rdfs:subClassOf <D> .

<D> rdf:type owl:Class ;
  rdfs:label "animals"@en .

An information system that has any awareness of the SKOS data model will, however, need to appreciate the distinction.

1.3. Consistency and Integrity

Under the RDF and OWL Full semantics, the formal meaning (interpretation) of an RDF graph is a truth value [@@REF-RDF-SEMANTICS] [@@REF-OWL-SEMANTICS]. I.e. an RDF graph is interpreted as either true or false.

In general, an RDF graph is said to be inconsistent if it cannot possibly be true. In other words, an RDF graph is inconsistent if it contains a contradiction.

Using the RDF and RDFS vocabularies alone, it is virtually impossible to make a contradictory statement. When the OWL vocabulary is used as well, there are many ways to state a contradiction. For example, consider the RDF graph below.

<Foo> rdf:type owl:Class .
<Bar> rdf:type owl:Class .
<Foo> owl:disjointWith <Bar> .
<foobar> rdf:type <Foo> , <Bar> .

The graph states that <Foo> and <Bar> are both classes, and that they are disjoint, i.e. that they do not have any members in common. This is contradicted by the statement that <foobar> has type both <Foo> and <Bar>. There is no OWL Full interpretation which can satisfy this graph, and therefore this graph is not OWL Full consistent.

When OWL Full is used as a knowledge representation language, the notion of inconsistency is useful because it reveals contradictions within the axioms and facts that are asserted in an ontology. By resolving these inconsistencies, we learn more about a domain of knowledge, and come to a better model of that domain from which interesting and valid inferences can be drawn.

When OWL Full is used as a data modeling (i.e. schema) language, the notion of inconsistency is again useful, but in a different way. Here we are not concerned with the logical consistency of human knowledge itself. We are simply interested in formally defining a data model, so that we can establish with certainty whether or not some given data conforms to or "fits" with the given data model. If the data is inconsistent with respect to the data model, then it does not "fit".

Here, we are not concerned with whether or not some given data has any correspondance with the "real world", i.e. whether it is true or false in any absolute sense. We are simply interested in whether or not the data fits the data model, because interoperability within a given class of applications depends on data conforming to a common data model.

Another way to express this view is via the notion of integrity. Integrity conditions are statements within the formal definition of a data model, which are used to establish whether or not given data is consistent with respect to the data model.

For example, the statement that <Foo> and <Bar> are disjoint classes can be viewed as an integrity condition on a data model. Given this condition, the data below is then not (OWL Full) consistent.

<foobar> rdf:type <Foo> , <Bar> .

The definition of the SKOS data model given in this document contains a limited number of integrity conditions. These integrity conditions are included to promote interoperability, by defining the circumstances under which data is not consistent with respect to the SKOS data model. Tools can then be implemented which "check" whether some or all of these integrity conditions are met for given data, and therefore whether the data "fits" the SKOS data model.

These integrity conditions are part of the formal definition of the SKOS data model, however they are presented separately from other parts of the formal definition because they serve a different purpose. Integrity conditions serve primarily to establish whether given data is consistent with the SKOS data model. All other statements within the definition of the SKOS data model serve only to support logical inferences (see also @@SECTION below).

Integrity conditions are defined for the SKOS data model in a way that is independent of strategies for their implementation, in so far as that is possible. This is because there are several different ways in which a procedure to find inconsistencies with the SKOS data model could be implemented. For example, inconsistencies could be found using an OWL reasoner. Alternatively, some inconsistencies could be found by searching for specific patterns within the data, or by a hybrid strategy (draw inferences using an RDFS or OWL reasoner, then search for patterns in the inferred graph).

The integrity conditions on the SKOS data model are fewer than might be expected, especially for those used to working within the "closed world" of database systems. See also the @@SECTION below, and the notes in @@SECTIONS below.

1.4. Inference, Dependency and the Open-World Assumption

This document defines the SKOS data model as an OWL Full ontology. There are other, alternative ways in which the SKOS data model could have been defined, for example as an entity-relationship model, or a UML class model. Although OWL Full as a data modeling language appears intuitively similar in many ways to these other modeling approaches, there is an important fundamental distinction.

RDF and OWL Full are designed for systems in which data may be widely distributed (e.g. the Web). As such a system becomes larger, it becomes both impractical and virtually impossible to "know" where all of the data in the system is located. Therefore, one cannot generally assume that data obtained from such a system is "complete". I.e. if some data appears to be "missing", one has to assume, in general, that the data might exist somewhere else in the system. This assumption, roughly speaking, is known as the "open world" assumption.

This means in practice that, for a data model defined as an OWL Full ontology, some definitions can have an unexpected meaning. No conclusions can be drawn from "missing" data, and removing something will never make data inconsistent.

For example, in the SKOS data model @@SECTION/DEFS, the property skos:semanticRelation is defined to have domain and range skos:Concept. These statements are not integrity conditions. I.e. the graph below is perfectly consistent with the SKOS data model, despite the fact that <A> and <B> have not been explicitly declared as having type skos:Concept.

<A> skos:semanticRelation <B> .

In fact, the domain and range definitions give license to inferences. In this case, the graph above (RDFS and OWL Full) entails the following graph. I.e. the following graph can be deduced or inferred.

<A> rdf:type skos:Concept .
<B> rdf:type skos:Concept .

In the SKOS data model, most statements of definition are not integrity conditions, but are statements of logical dependency between different elements of the data model, which under the open-world assumption give license to a number of simple inferences. For example, in @@SECTION skos:broader and skos:narrower are defined as inverse properties. This statement means that

<A> skos:narrower <B> .

entails

<B> skos:broader <A> .

Niether of these two graphs is inconsistent with the SKOS data model.

Knowledge organization systems such as thesauri and classification schemes are applied in a wide range of situations, and an individual knowledge organization system can be used in many different information systems. By defining the SKOS data model as an OWL Full ontology, the Semantic Web can then be used as a medium for publishing, exchanging, sharing and "joining up" data involving these knowledge organization systems. For this reason, for the expressiveness of OWL Full as a data modeling language, and for the possibility of then using thesauri, classification schemes etc. side-by-side with formal ontologies, OWL Full has been used to define the SKOS data model. The "open world" assumption is therefore a fundamental premise of the SKOS data model, and should be borne in mind when reading this document.

See also [@@REF-RDF-PRIMER] and [@@OWL-GUIDE].

1.5. How to Read this Document

This document formally defines the Simple Knowledge Organization System data model as an OWL Full ontology. The "elements" of the SKOS data model are OWL classes and properties, and a Uniform Resource Identifier (URI) is provided for each of these classes and properties so that they may be used unambiguously in the Web. This set of URIs comprises the SKOS vocabulary.

The complete SKOS vocabulary is given in section 2 below. Sections 3 to @@X then formally define the SKOS data model. The definition of the data model is broken down into a number of sections purely for convenience. Each of these sections 3 to @@X follows a common layout:

• Preamble -- the main ideas covered in the section are introduced informally.
• Vocabulary -- relevant URIs in the SKOS vocabulary are given.
• Class & Property Definitions -- the logical characteristics and interdependencies between the classes and properties denoted by those URIs are formally defined.
• Integrity Conditions -- if there are any integrity conditions on the vocabulary, those are given next.
• Examples -- some canonical examples are given, both of data which is consistent with the SKOS data model, and (where appropriate) of data which is not consistent with the SKOS data model.
• Notes -- any further notes and discussion are presented.

Most of the formal definitions and integrity conditions could be stated as RDF triples, using the RDF, RDFS and OWL vocabularies. However, a small number cannot, either because of limitations in the expressiveness of OWL Full or lack of standard URI for some class. To improve the overall readability of this document, rather than mix RDF triples and other notations, the formal definitions and integrity conditions are stated throughout using prose. The meaning of this prose will be obvious to a reader with a working knowledge of RDF and OWL. Some further explanation is provided below.

1.5.1. Types: Class, Object Property, Datatype Property

Each URI in the SKOS vocabulary is given an explicit type, which is stated in prose as either "Class", "Object Property" or "Datatype Property".

By "Class" we mean owl:Class, which is equivalent to rdfs:Class in the OWL Full semantics [@@REF].

By "Object Property" we mean owl:ObjectProperty, which is equivalent to rdf:Property in the OWL Full semantics [@@REF].

By "Datatype Property" we mean owl:DatatypeProperty, which is a sub-class of owl:ObjectProperty in the OWL Full semantics [@@REF].

1.5.2. Generalizations: Sub-Classes and Sub-Properties

Where applicable, generalizations are stated.

By "Sub-Class" we mean rdfs:subClassOf, and by "Sub-Property" we mean rdfs:subPropertyOf.

1.5.3. Domains and Ranges

Where applicable, domains and ranges are stated.

By "Domain" we mean rdfs:domain, and by "Range" we mean rdfs:range [@@REF].

1.5.4. Additional Property Characteristics

Where applicable, additional property characteristics are stated.

By "Functional Property", "Inverse Functional Property", "Symmetric Property" and "Inverse Properties" we mean owl:FunctionalProperty, owl:InverseFunctionalProperty, owl:SymmetricProperty and owl:inverseOf respectively [@@REF].

1.5.5. Conditions Not Expressable as RDF Triples

As mentioned above, some formal aspects of the SKOS data model cannot be stated as RDF triples using either RDF, RDFS or OWL vocabularies. These have been stated below in prose using standard terminology. It should be clear to the informed reader how these statements may be translated into formal conditions on the interpretation of an RDF vocabulary.

1.6. Conformance

This specification does not define a formal notion of conformance.

However, an RDF graph will be inconsistent with the SKOS data model if that graph and the SKOS data model (as defined formally below) together lead to a logical contradiction.

Appendix @@TODO gives some rules of thumb for avoiding inconsistency with the SKOS data model when constructing RDF graphs.

1.7. Examples

Examples of RDF graphs are given using the Terse RDF Triple Language (Turtle) [@@REF-TURTLE]. All examples assume that they are preceded by the following prefix and URI base directives:

@prefix rdf: <@@RDFNS> .
@prefix rdfs: <@@RDFSNS> .
@prefix owl: <@@OWLNS> .
@prefix skos: <@@SKOSNS> .
@base <http://example.org/ns/> .

Therefore, the example given below

is equivalent to the following Turtle document

@prefix rdf: <@@RDFNS> .
@prefix rdfs: <@@RDFSNS> .
@prefix owl: <@@OWLNS> .
@prefix skos: <@@SKOSNS> .
@base <http://example.org/ns/> .

<MyConcept> rdf:type skos:Concept .

which is equivalent to the following RDF/XML document [@@REF-RDF/XML]

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF 
  xmlns:rdf="@@RDFNS" 
  xmlns:rdfs="@@RDFNS" 
  xmlns:skos="@@SKOSNS"
  xmlns:owl="@@OWLNS"
  xml:base="http://example.org/ns/">

  <skos:Concept rdf:about="MyConcept"/>

</rdf:RDF>

which is equivalent to the following N-TRIPLES document [@@REF-N-TRIPLES]

<http://example.org/ns/MyConcept> <@@RDFNS#type> <@@SKOSNS#Concept> .

Note the use in Tertle of the ";" and "," characters to abbreviate multiple triples with the same subject or predicate.

2. SKOS Vocabulary

The SKOS vocabulary consists of a set of URIs, given in the table below.

See also the quick reference table in @@APPENDIX.

3. Conceptual Resources

3.1. Preamble

In the Simple Knowledge Organization System data model, Conceptual Resources are the fundamental units of Concept Schemes. A Conceptual Resource can be viewed as an idea or notion; a unit of thought. However, what constitutes a "unit of thought" is subjective, and this definition is meant to be suggestive, rather than restrictive.

The notion of a Conceptual Resource is useful when describing the conceptual or intellectual structure of a knowledge organization system, and when referring to specific ideas or meanings established within a KOS.

This section defines the formal vocabulary and semantics for the notion of a Conceptual Resource. Formally, the URI skos:Concept denotes the class of Conceptual Resources. Note however that, because SKOS is designed to be a vehicle for representing semi-formal KOS, such as thesauri and classification schemes, a certain amount of flexibility has been built in to the formal semantics of this class. See also the notes below.

See the SKOS Primer for more examples of identifying and describing Conceptual Resources.

3.2. Vocabulary

3.3. Class & Property Definitions

3.4. Examples

The graph below is consistent.

3.5. Notes

3.5.1. Conceptual Resources and OWL Classes

This specification does not make any statement about the formal relationship between the class of Conceptual Resources and the class of OWL Classes. The decision not to make any such statement has been made to allow applications the freedom to explore different design patterns for working with SKOS in combination with OWL.

For example, in the graph below, <MyConcept> has type skos:Concept and has type owl:Class.

This example is consistent with the SKOS data model. However, it is not compatible with OWL DL, because <MyConcept> has been used to denote both a class and an individual. To work within the OWL DL language, take care not to use the same URI to denote both an OWL Class and a Conceptual Resource.

3.5.2. Conceptual Resources and OWL Properties

In the graph below, <MyConcept> has type skos:Concept and has type owl:ObjectProperty.

This example is consistent with the SKOS data model. However, it is not compatible with OWL DL, because <MyConcept> has been used to denote both an object property and an individual.

For more information on recommended design patterns for working with SKOS in combination with OWL, see @@SECTION. See also @@APPENDIX for rules of thumb regarding assertions involving skos:Concept.

4. Concept Schemes

4.1. Preamble

A Concept Scheme can be viewed as an aggregation of one or more Conceptual Resources. Semantic Relationships (links) between those Conceptual Resources may also be viewed as part of a Concept Scheme. This definition is, however, meant to be suggestive rather than restrictive, and there is a certain amount of flexibility in the formal semantics stated below (see also the notes below).

The notion of a Concept Scheme is useful when dealing with data from an unknown source, and when dealing with data that describes two or more different knowledge organization systems.

This section defines the formal vocabulary and semantics for the notion of a Concept Scheme. Formally, the URI skos:ConceptScheme denotes the class of Concept Schemes. See also the notes below.

See the SKOS Primer for more examples of identifying and describing Concept Schemes.

4.2. Vocabulary

4.3. Class & Property Definitions

4.4. Integrity Conditions

4.5. Examples

The graph below is consistent.

4.6. Notes

4.6.1. Closed vs. Open Systems

The notion of an individual Concept Scheme corresponds roughly to the notion of an individual thesaurus, classification scheme, subject heading system or other knowledge organization system.

However, in most current information systems, a thesaurus or classification scheme is treated as a closed system - conceptual units defined within that system cannot take part in other systems (although they can be mapped to units in other systems).

Although SKOS does take a similar approach, there is no semantic constraint preventing a Conceptual Resource from taking part in zero, one, or more than one Concept Scheme.

So, for example, in the graph below the Conceptual Resource <MyConcept> takes part in two different Concept Schemes - this is consistent with the SKOS data model.

This flexibility is desirable because it allows, for example, new Concept Schemes to be described by linking two or more existing Concept Schemes together.

Also, note that there is no way to close the boundary of a Concept Scheme. So, while it is possible using skos:inScheme to say that Conceptual Resources X, Y and Z take part in Concept Scheme A, there is no way to say that only X, Y and Z take part in A.

Therefore, while SKOS can be used to describe a Concept Scheme, SKOS does not provide any mechanism to completely define a Concept Scheme.

4.6.2. Concept Schemes and OWL Ontologies

This specification does not make any statement about the formal relationship between the class of Concept Schemes and the class of OWL Ontologies. The decision not to make any such statement has been made to allow different design patterns to be explored for using SKOS in combination with OWL [@@REF-OWL].

For example, in the graph below, <MyScheme> denotes both a Concept Scheme and an OWL Ontology. This is consistent with the SKOS data model.

In the example below, owl:imports has been used to state that one Concept Scheme logically imports another Concept Scheme, according to the semantics and processing rules defined for importing OWL ontologies [@@REF]. Again, this is consistent with the SKOS data model.

For more information on recommended patterns for working with SKOS in combination with OWL, see @@SECTION. See also @@APPENDIX for rules of thumb regarding assertions involving skos:ConceptScheme.

4.6.3. Concept Schemes and Named RDF Graphs

This specification does not make any statement about the formal relationship between the class of Concept Schemes and the class of Named RDF Graphs. The decision not to make any such statement has been made to allow different design patterns to be explored for using SKOS with query languages such as SPARQL [@@REF].

For more information about recommended patterns for using SKOS with SPARQL, see @@SECTION.

5. Lexical Labels

5.1. Preamble

A Lexical Label is a string of UNICODE characters, such as "romantic love" or "れんあい", in a given natural language, such as English or Japanese Hiragana.

The Simple Knowledge Organization System provides some basic vocabulary for associating Lexical Labels with Resources. In particular, SKOS enables a distinction to be made between the "preferred", "alternative" and "hidden" Lexical Labels for any given Resource.

The "preferred" and "alternative" labels are useful when generating or creating human-readable representations of a knowledge organization system. These labels provide the strongest clues as to the meaning of a Conceptual Resource.

The "hidden" labels are useful when a user is interacting with a knowledge organization system via a text-based search function. The user may, for example, enter mis-spelled words when trying to find a relevant concept. If the mis-spelled query can be matched against a "hidden" label, the user will be able to find the relevant concept, but the "hidden" label won't otherwise be visible to the user (so further mistakes aren't encouraged).

Formally, a Lexical Label is an RDF Plain Literal [@@REF-RDF-CONCEPTS]. An RDF Plain Literal is composed of a lexical form, which is a string of UNICODE characters, and an optional language tag, which is a string of characters conforming to the syntax defined by [@@BCP47].

See the @@Primer for more examples of associating Lexical Labels with Conceptual Resources.

5.2. Vocabulary

5.3. Class & Property Definitions

5.4. Integrity Conditions

The conditions above assume that each distinct language tag allowed by [BCP 47] denotes a different "Language". E.g. "en", "en-GB" and "en-US" denote three different Languages (English, British English and US English respectively). E.g. "ja", "ja-Hani", "ja-Hira", "ja-Kana" and "ja-Latn" denote five different Languages (Japanese, Japanese Kanji, Japanese Hiragana, Japanese Katakana and Japanese Rōmaji respectively).

5.5. Examples

The following graph is consistent, and illustrates the provision of Lexical Labels in two different Languages (French and English).

The following graph is consistent, and illustrates the provision of Lexical Labels in four different Languages (Japanese Kanji, Japanese Hiragana, Japanese Katakana and Japanese Rōmaji).

The following graph is not consistent with the SKOS data model, because two different preferred Lexical Labels have been given for the same Language.

The following graph is not consistent with the SKOS data model, because there is a "clash" between the preferred and alternative Lexical Labels.

The following graph is not consistent with the SKOS data model, because there is a "clash" between alternative and hidden Lexical Labels.

The following graph is not consistent with the SKOS data model, because there is a "clash" between preferred and hidden Lexical Labels.

5.6. Notes

5.6.1. Domain of SKOS Lexical Labelling Properties

Note that no Domain is stated for skos:prefLabel, skos:altLabel and skos:hiddenLabel. Thus, the effective Domain of these properties is the class of all Resources (rdfs:Resource).

Therefore, using the properties skos:prefLabel, skos:altLabel and skos:hiddenLabel to label any type of resource is consistent with the SKOS data model.

For example, in the graph below, skos:prefLabel, skos:altLabel and skos:hiddenLabel have been used to label a resource of type owl:Class -- this is consistent with the SKOS data model.

This example is, however, incompatible with OWL DL, because a Datatype Property has been used to make assertions about a Class. To work within the OWL DL language, treat skos:prefLabel, skos:altLabel and skos:hiddenLabel as annotation properties.

For more information on recommended best practice for using SKOS in combination with OWL, see @@SECTION.

5.6.2. Range of SKOS Lexical Labelling Properties

Note that the Range of skos:prefLabel, skos:altLabel and skos:hiddenLabel is the class of RDF Plain Literals [@@REF-RDF-CONCEPTS].

However, there is nothing in the RDF or OWL Full semantics which prevents the use of a URI or a blank node to denote an RDF Plain Literal. Therefore, the graph below is consistent with the SKOS data model. See also @@APPENDIX for rules of thumb regarding the use of these properties.

5.6.3. Alternatives Without Preferred

In the graph below, a Resource has two alternative Lexical Labels, but no preferred Lexical Label. This is consistent with the SKOS data model, and there are no additional entailments which follow from the semantics. However, note that many applications will require a preferred Lexical Label in order to generate an optimum human-readable display.

5.6.4. Definition of a "Language"

Note the way in which the word "Language" has been defined for the semantic conditions above. Each different language tag permissable by [@@BCP 47] is taken to denote a different "Language". Therefore the graph below is consistent with the SKOS data model, because "en", "en-US" and "en-GB" are taken to denote different Languages.

In the graph below, there is no "clash" between the Lexical Labelling properties, again because "en" and "en-GB" are taken to denote different Languages, and therefore the graph is consistent.

6. Documentation (Notes)

6.1. Preamble

Notes are used to provide information relating to Resources. There is no restriction on the nature of this information. For example, it could be plain text, hypertext, or an image; it could be a definition, information about the scope of a Conceptual Resource, editorial information, or any other type of information.

There are 7 properties in SKOS for associating Notes with Resources, defined formally in this section. For more information on the recommended usage of each of the SKOS documentation properties, see the @@Primer.

These 7 properties are not intended to cover every situation, but rather to be useful in some of the most common situations, and to provide a set of extension points for defining more specific types of note. For more information on recommended best practice for extending SKOS, see @@SECTION.

Three different usage patterns are recommended in the @@Primer for the SKOS documentation properties -- "documentation as an RDF literal", "documentation as a related resource description" and "documentation as a document reference". The formal semantics stated in this section are intended to accommodate all three design patterns. See also the notes below.

6.2. Vocabulary

6.3. Class & Property Definitions

6.4. Examples

The graph below gives a consistent example of the "documentation as an RDF literal" pattern.

The graph below gives a consistent example of the "documentation as a related resource description" pattern.

The graph below gives a consistent example of the "documentation as a document reference" pattern.

6.5. Notes

6.5.1. Domain of the SKOS Documentation Properties

Note that no Domain is stated for the SKOS documentation properties. Thus, the effective domain for these properties is the class of all Resources (rdfs:Resource). Therefore, using the SKOS documentation properties to provide information on any type of Resource is consistent with the SKOS data model.

For example, in the graph below, skos:definition has been used to provide a plain text definition for a resource of type owl:Class -- this is consistent with the SKOS data model.

This example is, however, incompatible with OWL DL, because an object property has been used to make an assertion about a class. To use graphs like this and work within the OWL DL language, treat the SKOS documentation properties as annotation properties. For more on recommended best practice for using SKOS in combination with OWL, see @@SECTION.

6.5.2. Type & Range of the SKOS Documentation Properties

Note that the basis for the SKOS data model is the RDF-compatible model-theoretic semantics for OWL Full [@@REF-OWL-SEMANTICS]. Under the OWL Full semantics, the Class of Datatype Properties is a sub-class of the class of Object Properties [@@REF-OWL-REFERENCE]. Therefore, stating that the SKOS documentation properties are all Object Properties is the most general statement that can be made, and is consistent with all three usage patterns described in the @@Primer.

Note also that no Range is stated for the SKOS documentation properties, and thus the range of these properties is effectively the class of all Resources (rdfs:Resource). Under the RDF and OWL Full semantics, everything is a Resource, including RDF Plain Literals.

7. Semantic Relations

7.1. Preamble

Semantic Relations are links between Conceptual Resources, where the link is inherent in the meaning of the linked Conceptual Resources.

The Simple Knowledge Organization System distinguishes between two basic categories of Semantic Relations: Hierarchical and Associative. A Hierarchical link between two Conceptual Resources indicates that one is in some way more general ("broader") than the other ("narrower"). An Associative link between two Conceptual Resources indicates that the two are inherently "related", but that one is not in any way more general than the other.

Formally, the URI skos:broader denotes the Hierarchical Relation, and the URI skos:related denotes the Associative Relation. Note however that, because SKOS is designed to be a vehicle for representing semi-formal KOS, such as thesauri and classification schemes, a certain amount of flexibility has been built in to the formal definition of these features. See also the notes below.

For more examples of using the Hierarchical and Associative relations, see the @@Primer.

7.2. Vocabulary

7.3. Class & Property Definitions

7.4. Integrity Conditions

7.5. Examples

The graph below is consistent with the SKOS data model.

The graph below is not consistent with the SKOS data model, because there is a "clash" between skos:related and skos:broader.

The graph below is not consistent with the SKOS data model, because there is a "clash" between skos:related and the transitive closure of skos:broader.

The graph below is not consistent with the SKOS data model, again because there is a "clash" between skos:related and the transitive closure of skos:broader, which can be inferred from the semantic conditions stating that skos:broader and skos:narrower are Inverse Properties, and that skos:related is a Symmetric Property.

7.6. Notes

7.6.1. Domain and Range of SKOS Semantic Relation Properties

Note that the Domain and Range of skos:semanticRelation is skos:Concept. Because skos:broader, skos:narrower and skos:related are Sub-Properties of skos:semanticRelation, the graph in example @@X above entails that <A>, <B> and <C> each have type skos:Concept.

7.6.2. Symmetry of skos:related

skos:related is a symmetric property. The example below illustrates an entailment which follows from this condition.

Note that, although skos:related is a symmetric property, this condition does not place any restrictions on sub-properties of skos:related. I.e. sub-properties of skos:related could be symmetric, not symmetric or antisymmetric, and still be consistent with the SKOS data model.

To illustrate this point, in the example below, two new properties which are not symmetric are declared as sub-properties of skos:related. The example, which is consistent with the SKOS data model, also shows some of the entailments which follow.

See also @@SECTION for best practice recommendations on extending SKOS.

7.6.3. Transitivity of skos:related

Note that skos:related is not a transitive property. Therefore, the SKOS data model does not support an entailment as illustrated in the example below.

7.6.4. Reflexivity of skos:related

Note that skos:related is not a reflexive property, niether is it irreflexive.

Because skos:related is not irreflexive, the graph below is consistent with the SKOS data model.

See however @@APPENDIX for rules of thumb applying to skos:related.

7.6.5. Transitivity of skos:broader

Note that skos:broader is not a transitive property. Therefore, the SKOS data model does not support an entailment as illustrated in the example below.

This might seem counter-intuitive @@TODO explain why it is not transitive.

7.6.6. Reflexivity of skos:broader

Note that skos:broader is not a reflexive property, niether is it irreflexive.

Because skos:broader is not irreflexive, the graph below is consistent with the SKOS data model. See however @@APPENDIX for rules of thumb applying to skos:broader.

7.6.7. Cycles in the Hierarchical Relation

In the graph below, a cycle has been stated in the hierarchical relation. Note that this graph is consistent with the SKOS data model. I.e. there is no semantic condition requiring that the transitive closure of skos:broader be irreflexive.

See however @@APPENDIX for rules of thumb applying to skos:broader.

7.6.8. Alternative Paths in the Hierarchical Relation

In the graph below, there are two alternative paths from A to C in the hierarchical relation.

In the graph below, there are two alternative paths from A to D in the hierarchical relation.

This is a pattern which arises naturally in "polyhierarchical" knowledge organization systems.

Both of these graphs are consistent with the SKOS data model. I.e. there is no semantic condition requiring that there be only one path between any two nodes in the hierarchical relation.

See also @@APPENDIX for rules of thumb applying to skos:broader.

7.6.9. On the Semantics of the Hierarchical Relation

To developers and users of semi-formal knowledge organization systems, such as thesauri, classification schemes and subject heading systems, it might seem strange that the semantics of skos:broader have been defined such that the graphs given in examples @@X above are consistent -- intuitively, these graphs might seem to state a logical contradiction. However, @@TODO expand this point with reference to semantics of rdfs:subClassOf ...

8. Label Relations

8.1. Preamble

Label Relations are n-ary relations between Lexical Labels.

SKOS provides some general vocabulary for describing Label Relations. This vocabulary is intended primarily as an extension point for more specific vocabulary describing various sub-types of Label Relation, such as transliteration relations, acronym relations, abbreviation relations etc. Defining vocabulary for each of these sub-types of Label Relation is beyond the scope of SKOS. See also @@SECTION for best practice recommendations for extending SKOS.

8.2. Vocabulary

8.3. Class & Property Definitions

8.4. Integrity Conditions

8.5. Examples

The graph below is consistent with the SKOS data model.

8.6. Notes

8.6.1. Binary Label Relations

The SKOS Label Relations vocabulary provides a basis for defining Label Relations of any arity. However, most Label Relations are typically binary. In the graph below, a specific sub-type of binary Label Relation is defined by extending SKOS.

See also @@SECTION for best practice recommendations for extending SKOS.

8.6.2. Correspondance Between Lexical Labels and Label Relations

There are no integrity conditions on the SKOS Label Relations vocabulary. This means that there does not necessarily have to be any correspondance whatsoever between the Lexical Labels of a Resource, and the Labels involved in an associated Label Relation. The example below, which is consistent with the SKOS data model, illustrates this.

9. Collections (Grouping)

9.1. Preamble

Collections are labelled and/or ordered groups of Resources.

Collections are useful where a group of Conceptual Resources shares something in common, and it is convenient to group them under a common label, or where some Conceptual Resources can be placed in a meaningful order.

9.2. Vocabulary

9.3. Class & Property Definitions

9.4. Integrity Conditions

9.5. Examples

The graph below illustrates a Collection, and is consistent with the SKOS data model.

The graph below illustrates an Ordered Collection, and is consistent with the SKOS data model.

9.6. Notes

9.6.1. Inferring Collections from Ordered Collections

Definition @@X states the logical relationship between the skos:memberList and skos:member properties. This relationship means, in practice, that a Collection can be inferred from an Ordered Collection. This is illustrated in the example below.

There is no way to explicitly state that a Collection is not ordered.

9.6.2. skos:memberList Integrity

Note that skos:memberList is a functional property, i.e. it does not have more than one value. This is intended to capture within the SKOS data model that it doesn't make sense for an Ordered Collection to have more than one member list. Unfortunately, there is no way to use this condition as an integrity constraint without explicitly stating that two lists are different objects. In other words, although the graph below is consistent with the SKOS data model, it entails nonsense (a list with two first elements and a forked tail).

See also @@APPENDIX for rules of thumb applying to skos:memberList.

9.6.3. Nested Collections

In the example below, a Collection is nested within another Collection.

This example is consistent with the SKOS data model.

9.6.4. Concepts, Collections and Semantic Relations

In the SKOS data model, skos:Concept and skos:Collection are disjoint classes. The domain and range of the SKOS Semantic Relation properties is skos:Concept. Therefore, if any of the SKOS Semantic Relation properties (e.g. skos:narrower) are used to link to or from a Collection, the graph will not be consistent with the SKOS data model.

This is illustrated in the example below, which is not consistent with the SKOS data model.

Similarly, the graph below is not consistent with the SKOS data model.

Similarly, the graph below is not consistent with the SKOS data model.

However, the graph below is consistent with the SKOS data model.

10. Concept Mapping Relations

10.1. Preamble

Concept Mapping Relations are links between Conceptual Resources, typically in different Concept Schemes, where the links are inherent in the meaning of the linked Conceptual Resources.

Concept Mapping Relations mirror Semantic Relations, and the data model defined below is almost identical (with the exception of skos:exactMatch) to the data model defined in @@SECTION above. A distinct vocabulary is provided for Concept Mapping Relations, to provide a convenient way to differentiate links within a Concept Scheme from links between Concept Schemes. However, this pattern of usage is not a formal requirement of the SKOS data model, and relies on informal definitions of best practice. See also the @@PRIMER and the notes below.

10.2. Vocabulary

skos:mappingRelation denotes the union of all SKOS Mapping Relations, skos:exactMatch denotes the Exact Mapping Relation, skos:broadMatch denotes the Hierarchical Mapping Relation, and skos:relatedMatch denotes the Associative Mapping Relation.

10.3. Class & Property Definitions

10.4. Integrity Conditions

10.5. Examples

The graph below is consistent with the SKOS data model.

The graph below is not consistent with the SKOS data model, because there is a "clash" between skos:relatedMatch and skos:broadMatch.

The graph below is not consistent with the SKOS data model, again because there is a "clash" between skos:relatedMatch and skos:broadMatch, which can be inferred from the defining conditions stating that skos:broadMatch and skos:narrowMatch are Inverse Properties (@@X), and that skos:relatedMatch is a Symmetric Property (@@X).

10.6. Notes

10.6.1. Transitivity of skos:exactMatch, skos:broadMatch, skos:relatedMatch

None of the SKOS Concept Mapping properties are transitive. Therefore, entailments as illustrated in examples @@X-Y below are not supported by the SKOS data model.

10.6.2. Reflexivity of skos:exactMatch, skos:broadMatch, skos:relatedMatch

None of the SKOS Concept Mapping properties are reflexive, niether are they irreflexive.

Because skos:exactMatch, skos:broadMatch and skos:relatedMatch are not irreflexive, graph @@X below is consistent with the SKOS data model.

10.6.3. Disjointness of skos:exactMatch

The SKOS Concept Mapping property skos:exactMatch is not disjoint with any of the other SKOS Concept Mapping properties. Therefore the graph below is consistent with the SKOS data model.

10.6.4. Cycles and Alternative Paths in the Hierarchical Mapping Relation

There are no integrity conditions preventing either cycles or alternative paths in the Hierarchical Mapping Relation.

In the graph below there are two cycles involving skos:broadMatch. This graph is consistent with the SKOS data model.

In the graph below there are two alternative paths involving skos:broadMatch. This graph is consistent with the SKOS data model.

10.6.5. Links Between and Within Concept Schemes

Note that there are no integrity constraints preventing the SKOS Semantic Relation properties, skos:broader, skos:narrower and skos:related being used to link Conceptual Resources between different Concept Schemes.

Therefore the graph below is consistent with the SKOS data model.

Niether are there any integrity constraints preventing the SKOS Concept Mapping Relation properties being used to link Conceptual Resources within the same Concept Scheme.

Therefore, the graph below is consistent with the SKOS data model.

10.6.6. Interactions Between Semantic Relations and Mapping Relations

There are no integrity conditions on the interaction between the SKOS Semantic Relation properties and the SKOS Concept Mapping properties.

Therefore, the graph below is consistent with the SKOS data model.

There are no logical dependencies involving interactions between the Semantic Relation and Concept Mapping properties. Examples @@X-Y below illustrate entailments which do not hold for these properties.

12. Appendix A. SKOS Quick Reference

[show quick access panel]

13. Appendix B. SKOS Rules of Thumb

@@TODO

13.1. Don't Mess with the Vocabulary

@@TODO rule of thumb saying don't mess with the SKOS vocabulary, i.e. generally don't have triples where URI from SKOS vocabulary is in the subject position.

14. Appendix C. SKOS data model as RDF Triples

@@TODO