SKOS Simple Knowledge Organization System Primer

W3C Working Draft 21 February 2008

This version:
Latest version:
Antoine Isaac, Vrije Universiteit Amsterdam
Ed Summers, Library Of Congress


SKOS — Simple Knowledge Organisation System — provides a model for expressing the basic structure and content of concept schemes such as thesauri, classification schemes, subject heading lists, taxonomies, folksonomies, and other types of controlled vocabulary. As an application of the Resource Description Framework (RDF) SKOS allows concepts to be documented, linked and merged with other data, while still being composed, integrated and published on the World Wide Web.

This document is an implementors guide for those who would like to represent their concept scheme using SKOS.

In basic SKOS, conceptual resources (concepts) can be identified using URIs, labelled with strings in one or more natural languages, documented with various types of notes, semantically related to each other in informal hierarchies and association networks, and aggregated into distinct concept schemes.

In advanced SKOS, conceptual resources can be mapped to conceptual resources in other schemes and grouped into labelled or ordered collections. Concept labels can also be related to each other. Finally, the SKOS vocabulary itself can be extended to suit the needs of particular communities of practice.

This document is a companion to the SKOS Reference, which gives the normative reference on SKOS.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is a W3C First Public Working Draft published by the Semantic Web Deployment Working Group, part of the W3C Semantic Web Activity. This is a substantial update to and replacement for the previous SKOS Core Guide W3C Working Draft dated 2 November 2005. It is a companion document to the SKOS Simple Knowledge Organization System Reference W3C Working Draft dated 25 January 2008.

The Working Group solicits review and feedback on this document and the associated SKOS Reference Working Draft. All comments are welcome and may be sent to public-swd-wg@w3.org; please include the text "SKOS comment" in the subject line. All messages received at this address are viewable in a public archive. Certain open issues are indicated with Editors' notes to particularly draw the attention of readers; anything marked in the document with an "@@" indicates something still to be done or fixed. For example, "@@TODO" indicates an outstanding task.

The group does not expect this document to become a W3C Recommendation. The Working Group intends to advance the associated SKOS Reference to W3C Recommendation after further review and comment. The Working Group expects to revise this Primer while the SKOS Reference is undergoing review and eventually publish the Primer as a Working Group Note.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Table of Contents

1 Introduction

The Simple Knowledge Organization System (SKOS) is a RDF vocabulary for representing semi-formal knowledge organization systems (KOS), such as thesauri, taxonomies, classification schemes and subject heading systems. Because SKOS is based on the Resource Description Framework (RDF) [RDF-PRIMER] these representations are machine-readable, and can be exchanged between software applications and published on the World Wide Web.

SKOS has been designed to provide a low-cost migration path for porting existing organization systems to the Semantic Web. SKOS also provides a light weight, intuitive conceptual modeling language for developing and sharing new KOSs. It can be used on its own, or in combination with more formal languages like the Web Ontology Language (OWL) [OWL]. SKOS can also be seen as a bridging technology, providing the missing link between the rigorous logical formalism of ontology languages such as OWL and the chaotic, informal and weakly-structured world of social approaches to information management, as exemplified by social tagging applications.

1.1 About this Primer

This document is intended to help implementors who have a basic understanding of RDF to represent and publish their concept schemes as SKOS data. The Primer aims to provide introductory examples and guidance in the use of SKOS vocabulary features.

For an in-depth account on all SKOS vocabulary elements, including their reference formal semantics, the reader should consult the normative SKOS Reference [SKOS-REFERENCE]. This can be done, at the level of classes and properties, by clicking on their occurrences in the text (e.g. skos:Concept). For an overview of the use cases for SKOS and the elicited requirements that guided its design, the reader should consult [SKOS-UCR].

This Primer, together with the SKOS Reference document [SKOS-REFERENCE], replaces the earlier SKOS Core Guide [SWBP-SKOS-CORE-GUIDE] and the SKOS Core Vocabulary Specification [SWBP-SKOS-CORE-SPEC], which are now deprecated.

The essential features of the SKOS model are explained in Section 2. Here, the reader is presented with the set of vocabulary elements that are most commonly used for representing KOSs. In Section 3, the reader is shown how to add value to these representations, either by linking them together or by relating them to other kinds of Semantic Web resources. It is expected that many SKOS applications will employ some of the features presented in Section 3. Section 4 is focused on more advanced representation needs, which are likely to be required for a limited number of SKOS applications.

About examples in this primer

@@TODO: adapt, depending on final choice for syntax and/or graphs. A plausible option is to put graphs in the document and move Turtle examples in an annex @@

Most of the examples in this guide are given as a serialization of RDF graphs using the Turtle syntax for RDF [TURTLE]. Examples serialised as Turtle appear in code lines such as:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix ex: <http://www.example.com/>.

ex:aResource ex:aProperty ex:anotherResource;
  ex:anotherProperty "An RDF Literal"@en.

The above is equivalent to the following expression, in the RDF/XML reference syntax [RDF/XML-SYNTAX]:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
<rdf:Description rdf:about="http://www.example.com/aResource">
  <ex:aProperty rdf:resource="http://www.example.com/anotherResource"/>
  <ex:anotherProperty xml:lang="en">An RDF Literal</ex:anotherProperty>

For the sake of brievety a number of namespace declarations are omitted from the examples. This applies to standard namespaces (SKOS, RDF and RDFS [RDF-PRIMER], OWL [OWL] and Dublin Core [DC]) but also to the ones that are coined for the sake of examples. Generally, these namespaces could be declared as in the the following code:

@prefix skos: <http://www.w3.org/2004/02/skos/core#>
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
@prefix owl: <http://www.w3.org/2002/07/owl#>
@prefix dc: <http://purl.org/dc/elements/1.1/>
@prefix foaf: <http://xmlns.com/foaf/0.1/>
@prefix ex: <http://www.example.com/>
@prefix ex1: <http://www.example1.com/>
@prefix ex2: <http://www.example2.com/>

2 SKOS Essentials

This section introduces the core of the SKOS model, namely the features that are needed to represent most KOSs, as observed in the majority of use cases [SKOS-UCR].

In basic SKOS, conceptual resources (concepts) can be identified using URIs, labelled with lexical strings in one or more natural languages, documented with various types of notes, semantically related to each other in informal hierarchies and association networks, and aggregated into distinct concept schemes.

2.1 Concepts

The fundamental element of the SKOS vocabulary is the concept. Concepts denote ideas or meanings that are the units of thought [Willpower Glossary] which underly the KOSs used in a number of applications [SKOS-UCR]. As such, concepts exist in the mind as abstract entities which are independent of the terms used to label them.

SKOS introduces the skos:Concept RDFS class that allows implementors to assert that a given resource is a concept. This is done in two steps:

  1. create (or reuse) a Uniform Resource Identifier (URI [URI]) to uniquely identify the concept.
  2. assert in RDF that the resource identified by this URI is of type skos:Concept using the rdf:type property.

For example:

<http://www.example.com/animals> rdf:type skos:Concept.

Which can also be represented in Turtle more compactly using the ex namespace prefix defined above:

ex:animals rdf:type skos:Concept.

A key benefit of using SKOS to publish concept schemes is that it makes it easy to reference, distribute and integrate concepts into other resource descriptions on the Semantic Web. Implementors are encouraged to use HTTP URIs when minting concept URIs since they are resolvable and concept representations can be easily obtained using standard web technologies. For more information about URIs on the Semantic Web see Cool URIs for the Semantic Web [COOLURIS] and Best Practice Recipes for Publishing RDF Vocabularies [RECIPES].

2.2 Labels

The first characterization of concepts are the expressions that are used to refer to them in natural language—their labels. SKOS provides three properties to attach labels to conceptual resources: skos:prefLabel, skos:altLabel and skos:hiddenLabel. Each property implies a specific status for the label it introduces, ranging from a strong, univocal denotation relationship, to a string to aid in lookup. These properties are pairwise disjoint. A concept cannot have a same literal both as preferred label and alternative one at the same time, for instance.

As specified in Section 5 of the SKOS Reference, the properties skos:prefLabel, skos:altLabel and skos:hiddenLabel are considered as simple labelling means. As a result, they are all sub-properties of rdfs:label. Also, from a syntactic perspective, all these three properties have RDF plain literals as a range [RDF-CONCEPTS]. In other words they link a skos:Concept to a character string, not to another full-fledged RDF resource identified with a URI.

2.2.1 Preferred Lexical Labels

The skos:prefLabel property allows you to assign a preferred lexical label to a resource. Terms used as descriptors in indexing systems will for instance be represented using this property, as in the following example:

ex:animals rdf:type skos:Concept;
  skos:prefLabel "animals".

RDF plain literals are formally defined as character strings with optional language tags [RDF-CONCEPTS]. SKOS therefore enables a simple form of multilingual labelling. This is done by using the language tag of a lexical label to restrict its scope to a particular language. The following example illustrate how a concept is given one English preferred label and a French one at the same time:

ex:animals rdf:type skos:Concept;
  skos:prefLabel "animals"@en;
  skos:prefLabel "animaux"@fr.

Note that the notion of preferred label implies that a resource can only have one such label per language, as it is mentioned in Section 5 of the SKOS Reference [SKOS-REFERENCE].

Following common practice in KOS design, the preferred label of a concept may be also used to unambiguously represent this concept within one KOS and its applications. Although SKOS semantics do not formally enforce it, it is therefore recommended that no two concepts in the same KOS be given the same preferred lexical label in any given language.

2.2.2 Alternative Lexical Labels

The skos:altLabel property allows you to assign an alternative lexical label to a concept. This is especially helpful when assigning labels beyond the one that is preferred for the concept, for instance when synonyms need to be represented:

ex:animals rdf:type skos:Concept;
  skos:prefLabel "animals"@en;
  skos:altLabel "creatures"@en;
  skos:prefLabel "animaux"@fr;
  skos:altLabel "créatures"@fr.

Note that representation of synonyms for preferred labels is not the only use for skos:altLabel. Near-synonyms, abbreviations and acronyms can be represented the same way:

ex:fao rdf:type skos:Concept;
  skos:prefLabel "Food and Agriculture Organization"@en;
  skos:altLabel "FAO"@en.

It is also possible to use skos:altLabel to represent cases of upward posting [ISO-2788]. That is, when a concept aggregates more specialized notions that are not explicitly introduced as concepts in the considered KOS:

ex:rocks rdf:type skos:Concept;
  skos:prefLabel "rocks"@en;
  skos:altLabel "basalt"@en;
  skos:altLabel "granite"@en;
  skos:altLabel "slate"@en.

This last example, however, does not correspond to a recommended practice. A KOS more appropriate for this domain would introduce an instance of skos:Concept for each kind of rocks considered (basalt, granite and slate) and assert it as a narrower concept of ex:rock.

2.2.3 Hidden Lexical Labels

A hidden lexical label, represented by means of the skos:hiddenLabel property, is a lexical label for a resource, where a KOS designer would like that character string to be accessible to applications performing text-based indexing and search operations, but would not like that label to be visible otherwise. The most common use of hidden labels is to include misspelled variants of other lexical labels. For example:

ex:animals rdf:type skos:Concept;
  skos:prefLabel "animaux"@fr;
  skos:altLabel "bêtes"@fr;
  skos:hiddenLabel "betes"@fr.

@@TODO: add a paragraph when ISSUE-45 NaryLinksBetweenDescriptorsAndNonDescriptors is resolved@@

2.2.4 Use of Labels Outside of SKOS

While it is somewhat outside the scope of this Primer, it is possible to use SKOS labelling properties to label resources that are not of type skos:Concept. Consider these triples that describe Tim Berners-Lee:

<http://www.w3.org/People/Berners-Lee/card#i> rdf:type foaf:Person;
  foaf:name "Timothy Berners-Lee";
  rdfs:label "Tim Berners-Lee";
  skos:prefLabel "Tim Berners-Lee"@en.

An application that wishes to display a label for this resource is able to identify "Tim Berners-Lee" as the preferred label instead of having to choose between the equally compatible labels rdfs:label "Tim Berners-Lee" or the foaf:name "Timothy Berners-Lee". These labels are compatible because foaf:name is a sub-property of rdfs:label.

Another example are human-readable labels on classes, properties and individuals in OWL ontologies, which are normally expressed using rdfs:label alone. Consider the following triples that describe humans:

ex:Human rdf:type owl:Class;
  rdfs:label "human"@en;
  rdfs:label "man"@en.

An application would have difficulties to display the right label to the user as they both have the same weight. The semantics of skos:prefLabel allow implementors to explicitly define the label for a given resource. In general the ability to mix-in vocabulary elements from SKOS and other RDF vocabularies at will like this is what gives RDF much of its expressive power.

2.3 Semantic Relationships

In KOSs semantic relations play a crucial role for defining concepts. The meaning of a concept, beyond its expression in natural language via labels, also emerges from the links it maintains to other concepts in the vocabulary. SKOS proposes a general skos:semanticRelation property to express these "paradigmatic" links. Mirroring the fundamental categories of relations which are used in vocabularies such a thesauri [ISO2788], SKOS proposes three standard sub-properties for it:

2.3.1 Broader/Narrower Relationships

To assert that one concept is broader in meaning (i.e. more general) than another, the skos:broader property is used. The skos:narrower property is to be used to assert the inverse, i.e. when one concept is narrower in meaning (i.e. more specific) than another. For example:

ex:animals rdf:type skos:Concept;
  skos:prefLabel "animals"@en;
  skos:narrower ex:mammals.
ex:mammals rdf:type skos:Concept;
  skos:prefLabel "mammals"@en;
  skos:broader ex:animals.

The properties skos:broader and skos:narrower are each other's inverse. Whenever a concept X is broader than another concept Y, then Y is a narrower concept of X according to the SKOS semantics [SKOS-REFERENCE]. This can be of use for making SKOS representations more efficient by limiting the information they contain. In the above example, for instance, the statement ex:mammals skos:broader ex:animals can be left out if, before exploiting the concept scheme data, one uses an OWL reasoner to infer it from the ex:animals skos:narrower ex:mammals statement.

Note that in many cases, hierarchical relations in one concept scheme can be considered as transitive [OWL]. If ex:animals is broader than ex:mammals, which is itself broader than ex:cats, it makes sense to assert that ex:animals is broader than ex:cats. However, there are cases of "dirtier" hierarchies, where such a feature would not be judged appropriate. Consider for instance a case where ex2:vehicles is said to be broader than ex2:cars, which is itself asserted to be broader than ex2:wheels. It may be debatable to automatically infer from this that wheels is a narrower concept to vehicles. SKOS anticipates such problems by not defining skos:broader and skos:narrower as generally transitive properties. The reader interested in representing "transitive hierarchies" is encouraged to read Section 4.7, which presents a way to do this while retaining compatibility with the semantics of skos:broader defined in this section.

Finally, an aspect left untouched here is the way one can distinguish the situations that hierarchical relations cover. As said in the preamble for this section, these can range from instance-class relationhips to part-whole ones. The interested reader is referred to Section 4.8, which presents a way to create specializations of semantic relations so as to deal with this issue.

2.3.2 Associative Relationships

To assert an associative relationship between two concepts, skos:related can be used, as in the following example:

ex:birds rdf:type skos:Concept;
  skos:prefLabel "birds"@en;
  skos:related ex:ornithology.
ex:ornithology rdf:type skos:Concept;
  skos:prefLabel "ornithology"@en.

As mentioned in the SKOS semantics [SKOS-REFERENCE], the skos:related property is symmetric [OWL]. From the above RDF graph, for instance, it follows that ex:ornithology is the subject of a skos:related statement that has ex:birds as an object. The reader should finally be aware that in the SKOS semantics, skos:related is not defined as a generally transitive property. @@TODO: write an example@@

2.4 Documentary Notes

Semantic relationships are crucial to the definition of concepts, as many KOS guidelines emphasize it. However, next to these structured characterizations, concepts sometimes have to be further defined using human-readable, informal documentation, such as scope notes or definitions.

SKOS provides a skos:note property for general documentation purposes. Inspired by existing KOS guidelines, such as [ISO2788] or [BS8723-2], this property is further specialized into skos:scopeNote, skos:definition, skos:example, and skos:historyNote to fit more specific types of documentation.

skos:scopeNote supplies some, possibly partial, information about the intended meaning of a concept, especially as an indication of how the use a concept is limited in indexing practice. The following example is adapted from [ISO2788]:

ex:microwaveFrequencies skos:scopeNote 
    "Used for frequencies between 1GHz to 300Ghz"@en.

skos:definition supplies a complete explanation of the intended meaning of a concept. The following example is adapted from [ISO2788]:

ex:documentation skos:definition 
    "the process of storing and retrieving information in all fields of knowlegde"@en.

skos:example supplies an example of the use of a concept:

ex:organizationsOfScienceAndCulture skos:example 
    "academies of science, general museums, world fairs"@en.

skos:historyNote describes significant changes to the meaning or the form of a concept:

ex:childAbuse skos:historyNote 
    "estab. 1975; heading was: Cruelty to children [1952-1975]"@en.

In addition to these notes that are intended for users of a concept scheme, SKOS includes two specializations of skos:note that are useful for KOS managers or editors: skos:editorialNote and skos:changeNote.

skos:editorialNote supplies information that is an aid to administrative housekeeping, such as reminders of editorial work still to be done, or warnings in the event that future editorial changes might be made:

ex:doubleclick skos:editorialNote "Review this term after company merger complete"@en.
ex:folksonomy skos:editorialNote "Check spelling with Thomas Vander Wal"@en.

skos:changeNote documents fine-grained changes to a concept, for the purposes of administration and maintenance:

ex:tomato skos:changeNote 
  "Moved from under 'fruits' to under 'vegetables' by Horace Gray"@en.

It is important to notice that the hierarchical link between skos:note and its different specializations allows all the documentation associated to a concept to be retrieved in a straightforward way. Every skos:definition is a skos:note, every skos:scopeNote is a skos:note, and so on.

The above examples illustrate how SKOS documentation properties can be simply used with RDF plain literals. Section 4.3 will show that there are indeed other possible patterns, as the range of these properties is not be restricted to literals. One important feature of simple literals, however, is the ability to use language tags, as done for labelling properties. Documentation may thus be provided in multiple languages:

ex:pineapples rdf:type skos:Concept;
  skos:prefLabel "pineapples"@en;
  skos:prefLabel "ananas"@fr;
  skos:definition "The fruit of plants of the family Bromeliaceae"@en;
        "Le fruit de la plante herbacée de la famille des broméliacées"@fr.

Before concluding this section, it is important to note that other, non-SKOS properties could be used to document concepts. The source property from Dublin Core [DC] can for instance be used to point to a document from which a concept is derived:

ex:madagascarFishEagle dc:source "Internet bird collection, Apr. 6, 2005"@en.

2.5 Concept Schemes

Concepts can be created and used as stand-alone entities. However, especially in the indexing practice, concepts usually come in carefully compiled vocabularies, such as thesauri or classification schemes. SKOS offers the means to represent such KOSs using the skos:ConceptScheme class.

The following example shows how to define a concept scheme resource to represent a thesaurus, and create a general description of it, using the dc:title and dc:creator properties from Dublin Core [DC]:

ex:animalThesaurus rdf:type skos:ConceptScheme;
  dc:title "Simple animal thesaurus";
  dc:creator ex:antoineIsaac.

Once a concept scheme representation has been created, it is possible to link it to the concepts it contains, using the skos:inScheme property:

ex:mammals rdf:type skos:Concept;
  skos:inScheme ex:animalThesaurus.
ex:cows rdf:type skos:Concept;
  skos:broader ex:mammals;
  skos:inScheme ex:animalThesaurus.
ex:fish rdf:type skos:Concept;
  skos:inScheme ex:animalThesaurus.

Finally, for providing an efficient access to the entry points of broader/narrower concept hierarchies, SKOS coins a skos:hasTopConcept property. This property allows to link a concept scheme to the (possibly many) most general concepts it contains, as in the (continued) animal thesaurus example:

ex:animalThesaurus rdf:type skos:ConceptScheme;
  skos:hasTopConcept ex:mammals;
  skos:hasTopConcept ex:fish.

Concept schemes are designed to represent traditional vocabularies, and designers are encouraged to follow existing KOS guidelines (e.g., [ISO2788] or [BS8723-2]) when compiling a SKOS concept scheme. As mentioned in Section 2.2, it is for example recommended that no two concepts have the same preferred lexical label in a given language when they belong to a same concept scheme.

The reader should however be aware that there are some subtle differences between SKOS concept schemes and "traditional" KOSs, mainly due to the Semantic Web context for SKOS. Section 4.6 of the SKOS Reference [SKOS-REFERENCE] gives an account of these differences. One important feature of SKOS is that it is possible for a same concept to be linked to several concept schemes, using the skos:inScheme property. This will be discussed in the next section.

Finally, it is important to notice that the SKOS vocabulary only offers a limited support for containment of KOS information in a concept scheme. skos:inScheme and skos:hasTopConcept link concept schemes and concepts. Yet, there is no mechanism in SKOS to record that a specific statement concerning these concepts, e.g. a skos:broader assertion, pertains to a specific concept scheme, while it is usually acknowledged that a KOS consists of both its concepts and the links that define them. It is however possible to represent and access such containment information by making use of more general provenance mechanisms, like Named Graphs for RDF. For more detail, see the Annex E of the SKOS Reference [SKOS-REFERENCE].

@@TODO: add a paragraph when ISSUE-85 SemanticsOfSchemeContainmentProperties is resolved@@

3 Networking Knowledge Organization Schemes on the Semantic Web

Representing a KOS with SKOS not only serves as a publishing mechanism, but also allows a KOS to participate in a network of concept schemes. On the Semantic Web the true potential of data is unleashed when it is interlinked. As concepts from different concept schemes are connected together they begin to form a distributed, heterogeneous global concept scheme. A web of concept schemes can serve as the foundation for new applications that allow meaningful navigation between KOSs. This section introduces the simple SKOS features that enable the interlinking of concept schemes, and how to relate conceptual resources to other resources on the Semantic Web.

@@TODO: decide whether this ordering of sections make sense, or if it is better to group 3 and 4@@

3.1 Re-using and Extending Concept Schemes

Every SKOS concept is assigned a URI [COOLURIS], which makes it possible to unambiguously reference a concept in any SKOS application. The use of URIs on the Semantic Web allows resources to be shared and reused in a distributed fashion. As a result it is possible for a SKOS concept to participate in several concept schemes at the same time. For example, a SKOS publisher can choose to locally extend an existing concept scheme, and then publish the extension with the linkages intact. A new concept scheme can re-use existing concepts using the skos:inScheme property. Consider the example below, where a reference concept scheme for animals defines a concept for "platypus":

ex1:referenceAnimalScheme rdf:type skos:ConceptScheme;
   dc:title "Reference list of animals"@en. 
ex1:platypus rdf:type skos:Concept;
   skos:prefLabel "platypus"@en;
   skos:altLabel "ornithorhynchus anatinus"@la;
   skos:inScheme ex1:referenceAnimalScheme.

The creator of another concept scheme devoted to platypus descriptions can freely include the reference ex1:platypus concept in her scheme, and then reference it as follows:

ex2:thePlatypusScheme rdf:type skos:ConceptScheme;
   dc:title "Everything about platypus"@en. 
ex1:platypus skos:inScheme ex2:thePlatypusScheme.
ex2:nicePlatypus rdf:type skos:Concept;
   skos:broader ex1:platypus;
   skos:inScheme ex2:thePlatypusScheme.
ex2:badPlatypus rdf:type skos:Concept;
   skos:broader ex1:platypus;
   skos:inScheme ex2:thePlatypusScheme.

Note that the information source defining the new concept scheme does not re-assert the RDF statements for the ex1:platypus concept, e.g., its skos:prefLabel. Assuming ex1:platypus has been published, a Semantic Web application is able to retrieve the information for this concept by simply resolving the concept's URI (http://www.example1.com/platypus).

A special case of re-use/extension occurs when a concept scheme is "imported" as a whole using owl:imports. This is achieved by including the following statement in the source defining ex2:thePlatypusScheme:

ex2:thePlatypusScheme owl:imports ex1:referenceAnimalScheme.

If an application concerned with provenance information (see Section 4.5) reads this statement, it will infer that the triples present in the original concept scheme are also "stated" by the newly defined concept scheme. This does not however replace the skos:inScheme statements between the imported concepts and the importing scheme, as the SKOS Reference explains it in its Section 4.6.2 [SKOS-REFERENCE]. Using owl:imports indicates that all statements from ex1:referenceAnimalScheme are imported into ex2:thePlatypusScheme, but the original information source did not define its concepts as belonging to the new scheme. One has therefore to assert the ex1:platypus skos:inScheme ex2:thePlatypusScheme statement emphasized above.

3.2 Mapping Concept Schemes

Linking concepts by means of controlled concept scheme extension is not the only way to interlink concept schemes. Some applications, like information retrieval tools that use several KOSs at the same time, need to establish relations between pre-existing concepts. [BS8723-4]. Such conceptual mappings are expected to be a key advantage of making KOS available on the Semantic Web using SKOS.

SKOS provides a range of vocabulary elements that map concepts from different concept schemes. This can be done by asserting that two concepts have a same meaning, using the skos:exactMatch property. Two concepts from different concept schemes can also be mapped using properties that parallel the semantic relations introduced in Section 2.3: skos:broadMatch, skos:narrowMatch and skos:relatedMatch.

Consider the following example, where two concept schemes represent different views on animals:

ex1:referenceAnimalScheme rdf:type skos:ConceptScheme;
   dc:title "Extensive list of animals"@en. 
ex1:animal rdf:type skos:Concept;
   skos:prefLabel "animal"@en;
   skos:inScheme ex1:referenceAnimalScheme.
ex1:platypus rdf:type skos:Concept;
   skos:prefLabel "platypus"@en;
   skos:inScheme ex1:referenceAnimalScheme.

ex2:eggSellerScheme rdf:type skos:ConceptScheme;
   dc:title "Obsessed egg-seller's vocabulary"@en. 
ex2:eggLayingAnimals rdf:type skos:Concept;
   skos:prefLabel "animals that lay eggs"@en;
   skos:inScheme ex2:eggSellerScheme.
ex2:animals rdf:type skos:Concept;
   skos:prefLabel "animals"@en;
   skos:inScheme ex2:eggSellerScheme.
ex2:eggs rdf:type skos:Concept;
   skos:prefLabel "eggs"@en;
   skos:inScheme ex2:eggSellerScheme.

It is possible to map these two concept schemes using the mapping assertions below:

 ex1:platypus skos:broadMatch ex2:eggLayingAnimals.
 ex1:platypus skos:relatedMatch ex2:eggs.
 ex1:animal skos:exactMatch ex2:animals.

Note that SKOS provides skos:exactMatch to map concepts with equivalent meaning, and intentionally does not use owl:sameAs from the OWL ontology language [OWL]. When two resources are mapped with owl:sameAs they are considered to be the same resource, and triples involving these resources can be merged. This does not fit what is needed in usual SKOS applications. For example, if two concepts from different concept schemes were related with owl:sameAs, the preferred label of the first mapped concept would become the preferred label of the second, even if this one already had a (different) preferred label.

Note that it is also possible to create mapping links within a single concept scheme. This may happen for instance when a given application needs to enrich a concept scheme which lacks desired semantic structure. In the above example, ex2:eggLayingAnimals can be mapped to ex2:animals using skos:broadMatch, to compensate for the lack of skos:broader link between the two in the original concept scheme. Such an approach has the benefit of not requiring the creators of the original scheme to modify it, nor forcing its users to coin a new semantic definition of the considered concepts, which the assertion of a paradigmatic skos:broader relationship would practically amount to.

@@TODO: add a paragraph on mapping between coordinated concepts when a decision is made on ISSUE-40 and ISSUE-45@@

3.3 SKOS Concepts and OWL Classes

SKOS is an RDF/OWL vocabulary. The SKOS Reference defines skos:Concept as an OWL class [SKOS-REFERENCE]:

skos:Concept rdf:type owl:Class.

Thus, instances of skos:Concept (e.g. ex:Painting in a art vocabulary) are in OWL terms individuals.

ex:Painting rdf:type skos:Concept.

This raises the question whether a SKOS concept instance such as ex:Painting can be treated as a class in its own right. For example, can users define properties of ex:painting such as ex:title:

ex:title rdf:type owl:DatatypeProperty.
ex:title rdfs:domain ex:Painting.

One might ask the question: why would someone want to do this? Well, conceptually a class such as skos:Concept can be seen as a metaclass: its instances are the concepts occurring in a vocabulary. So, it is conceivable that SKOS users want to specify class-level characteristics of SKOS concepts, for example that paintings have titles or that cheese has a country of origin.

It should be pointed out that SKOS does not take a stance with respect to the flavor of OWL—OWL Full or OWL-DL [OWL-REFERENCE]—to be used together with SKOS. OWL Full users will be able to handle the situation above by treating instances of SKOS concepts explicitly as classes, e.g. by adding statements of the form:

ex:Painting rdf:type owl:Class.

This is possible because OWL Full does not require the sets of classes and individuals to be disjoint. People who wish to use the DL flavor of OWL cannot use this metamodeling mechanism, as the disjointness condition between classes and individuals must hold for any OWL-DL ontology. The OWL-DL users interested in linking OWL classes to SKOS concepts have to keep these formally distinct. They can nevertheless use dedicated annotation properties to bridge them, provided they can create and use their own extension for SKOS, as in:

ex:PaintingClass rdf:type owl:Class.
ex:PaintingConcept rdf:type skos:Concept.
ex:PaintingClass ex:correspondingConcept ex:PaintingConcept.

However, it should be pointed out that the (at the time of writing) recently started OWL 1.1 Working Group [OWL-WG] is chartered to handle (some forms of) metamodelling within a description-logic framework. This might allow OWL-DL users to opt for patterns that are easier to exploit.

Summarizing, the relationship between SKOS concepts and OWL classes/individuals is as follows:

@@TODO: check if there are problems related to SKOS indirection@@

3.4 Subject Indexing in SKOS

Though formally not belonging to the features defining a KOS, the link between a concept and the resources which are about this concept is fundamental in many KOS applications, like document indexing and document retrieval. This becomes even more important in a Semantic Web context, where there is a crucial need to annotate documents with conceptual units which define their subject.

While the SKOS vocabulary itself does not include a mechanism for associating an arbitrary resource with a skos:Concept it is recommended that implementors use dc:subject [DC]

ex1:platypus rdf:type skos:Concept;
   skos:prefLabel "platypus"@en.

<http://en.wikipedia.org/wiki/Platypus> rdf:type foaf:Document;
   dc:subject ex1:platypus.

Note that a same resource can have several subjects, and hence be involved in several dc:subject statements. These subjects can clearly come from different concept schemes, resulting for instance from a distributed annotation process.

@@TODO: Antoine had put skos:subject in this section, Ed replaced by dc:subject. This section shall be adapted to the final decision, as soon as a resolution is made on ISSUE-48@@

4 Advanced SKOS: when KOS are not simple anymore

@@TODO: isn't this section too long? Depending on reviewers' comment, shorten it or remove it and replace by a separate note.@@

Beyond the above mentioned features, SKOS proposes a number of vocabulary elements or guidelines that deal with more advanced representation needs, making SKOS compatible with a broad range of KOS modelling approaches. These are especially designed to meet requirements which were raised in the SKOS Use Cases and Requirements [SKOS-UCR], but which were also present in a smaller number of use cases:

This section concludes with a general note on the extensibility of the SKOS model, paving the way for even more specialized refinements of the vocabulary presented in this Primer.

4.1 Collections of Concepts

SKOS Core allow you to define meaningful groupings or "collections" of concepts. Such groupings are normally rendered in thesauri as in the following example:

  <milk by source animal>
    cow milk
    goat milk
    buffalo milk

In thesaurus terminology these collections are known as "arrays", and the term "milk by source animal" is a "node label" [Willpower Glossary]. There is consensus that a node label does not represent a label for a concept in its own right. Therefore, specific kinds of entities have to be introduced to represent them.

4.1.1 Labelled Collections

To correctly model such concept collection structures, SKOS introduces a skos:Collection class. Instances of this class group specific concepts by means of the skos:member property, as in the following example:

ex:milk rdf:type skos:Concept;
  skos:prefLabel "milk"@en.
ex:cowMilk rdf:type skos:Concept; 
  skos:prefLabel "cow milk"@en;
  skos:broader ex:milk.
ex:goatMilk rdf:type skos:Concept; 
  skos:prefLabel "goat milk"@en;
  skos:broader ex:milk.
ex:buffaloMilk rdf:type skos:Concept; 
  skos:prefLabel "buffalo milk"@en;
  skos:broader ex:milk.

_:b0 rdf:type skos:Collection;
   skos:prefLabel "milk by source animal"@en;
   skos:member ex:cowMilk;
   skos:member ex:goatMilk;
   skos:member ex:buffaloMilk.

Note that in the example above the collection was defined as a blank node, i.e. no defined URI was allocated. URIs may be allocated to collections, but usually this is not necessary. Also, skos:prefLabel has been used to assign a lexical label to the Collection, as this property (as other SKOS labelling properties) can be used with non-conceptual resources.

4.1.2 Ordered Collections

Sometimes it is important to capture the order of concepts in a collection: such as when concepts are listed in alphabetical or chronological order. To define an ordered collection of concepts the skos:OrderedCollection class is used, together with the skos:memberList property. This property links an instance of skos:OrderedCollection to a (possibly blank) node of type rdf:List, following the pattern that enables the definition of RDF collections [RDF-PRIMER]. For example:

ex:infants rdf:type skos:Concept; 
  skos:prefLabel "infants"@en.
ex:children rdf:type skos:Concept; 
  skos:prefLabel "children"@en.
ex:adults rdf:type skos:Concept; 
  skos:prefLabel "adults"@en.

_:b0 rdf:type skos:Collection;
   skos:prefLabel "people by age"@en;
   skos:memberList _:b1.
_:b1 rdf:first ex:infants;
   rdf:rest _:b2.
_:b2 rdf:first ex:children;
   rdf:rest _:b3.
_:b3 rdf:first ex:adults;
   rdf:rest rdf:nil.

4.1.3 SKOS Collections, Semantic Relations and Systematic Displays

Note that, according to SKOS semantics, collections are disjoint from concepts. It is therefore impossible to use SKOS semantic relations (see Section 2.3) to have a collection directly fit into a SKOS semantic network. In other words, grouping concepts into collections does not replace assertions about the concepts place in a concept scheme. For instance, in the above "milk" example, all source-defined milks must be explicitly attached to a more generic ex:milk using the skos:broader property:

ex:cowMilk skos:broader ex:milk.
ex:goatMilk skos:broader ex:milk.
ex:buffaloMilk skos:broader ex:milk.

A systematic (hierarchical) display can then be generated including the concept grouping "milk by source animal", as presented in the example introducing this sub-section. The skos:broader hierarchy and the collection membership information can be used for this, but the process still requires a dedicated algorithm, the implementation of which is left to specific applications.

@@TODO: adapt this paragraph, depending on a resolution for ISSUE-84 @@

4.2 Symbolic Labels

@@TODO: remove the section, unless these features are explicitly (re)introduced in SKOS, as a resolution for ISSUE-76 @@

4.3 Advanced Documentation Features

@@TODO: adapt from SKOS Core Guide, depending on the resolution on ISSUE-64@@

Documentation as a Related Resource Description

Documentation as a Document Reference

4.4 Relationships between Labels

Some applications require the creation of explicit links between the labels associated to concepts. For example, consider the relationship between a preferred label for a concept "Corporation" and its abbreviation coined as an alternative label "Corp.", or a translation link between two labels in different language: "Cow"@en and "Vache"@fr. The use of SKOS lexical labelling properties, e.g. skos:prefLabel, is restricted to RDF literals. Therefore these labels cannot be the subject of an RDF statement, and a direct relationship cannot be asserted between them.

To solve this representation issue, the SKOS model introduces a skos:LabelRelation class that treats relationships between labels as first-order RDF resources. Each instance of this class is linked to the labels it relates using the skos:labelRelated property. This relationship may later be connected to the concepts the labels are attached to, using the skos:seeLabelRelation property. Consider the example where the concept "Food and Agriculture Organization" is labelled by both the official name and the acronym of the institution. The relationship between the two labels can be represented in the following way:

ex:FAO rdf:type skos:Concept;
  skos:prefLabel "Food and Agriculture Organization"@en; 
  skos:altLabel "FAO"@en;
  skos:seeLabelRelation [
    skos:labelRelated "Food and Agriculture Organization"@en;
    skos:labelRelated "FAO"@en

Such a solution is however not optimal: an "acronym-sensitive" application would miss the actual information that the two labels are indeed in an acronymy relationship. Such an application would also miss the direction of the link. SKOS users are therefore encouraged to specialize the skos:LabelRelation and skos:labelRelated vocabulary elements so as to fit their application-specific requirements, as in the following:

ex:AcronymRelation rdfs:subClassOf skos:LabelRelation.
ex:fullForm rdfs:subPropertyOf skos:labelRelated.
ex:acronymForm rdfs:subPropertyOf skos:labelRelated.

ex:FAO rdf:type skos:Concept;
  skos:prefLabel "Food and Agriculture Organization"@en;
  skos:altLabel "FAO"@en;
  skos:seeLabelRelation [
    rdf:type ex:AcronymRelation;
    ex:fullForm "Food and Agriculture Organization"@en;
    ex:acronymForm "FAO"@en

@@TODO: Check whether further decisions on pattern and/or vocabulary proposals for ISSUE-26 do not interfere... @@

4.5 Provenance and Annotation of SKOS Statements

@@TODO: write this section, according to resolutions on ISSUE-27. Two aspects: (i) encapsulation of SKOS info in OWL ontologies and/or RDF information sources, (ii) pattern for annotation on labels.@@

4.6 Coordinating Concepts

@@TODO: write after a resolution has been made for ISSUE-40 and ISSUE-45. This section shall include stuff about pre-coordination/"strings", post-coordination...@@

4.7 Transitive Hierarchies

@@TODO: check this section, according to resolutions on ISSUE-82 on property names @@

As mentioned in Section 2.3.1, the properties used to represent KOS hierarchies, skos:broader and skos:narrower, are not defined as transitive. That is, their semantics do not support inferences of the type: if "animals" is broader than "mammals" and "mammals" is broader than "cats", then "animals" is broader than "cats". For the applications that require such semantics—for instance to perform query expansion—SKOS features two specific properties, skos:broaderTransitive and skos:narrowerTransitive.

These are defined as transitive super-properties of respectively skos:broader and skos:narrower [SKOS-REFERENCE]. This pattern enables, using a Semantic Web inference tool, to access the "transitive closure" of a hierarchy expressed with skos:broader and skos:narrower. Consider the example:

ex:animals skos:prefLabel "animals"@en.
ex:mammals skos:prefLabel "mammals"@en;
  ex:broader ex:animals.
ex:cats skos:prefLabel "cats"@en;
  ex:broader ex:mammals.

When reading the above triples, a reasoner makes use the definition of skos:broaderTransitive as a super-property of skos:broader to infer the following statements:

ex:cats skos:broaderTransitive ex:mammals.
ex:mammals skos:broaderTransitive ex:animals.

The transitivity of skos:broaderTransitive then leads to the inference of the desired statement:

ex:cats skos:broaderTransitive ex:animals.

The use of the skos:broaderTransitive super-property allows communities of practice to exploit transitive interpretations of hierarchical networks as they see fit, while not interfering with the general semantics skos:broader, which cannot enforce such transitivity.

4.8 On Specializing the SKOS Model

@@TODO: check this section, according to resolutions on ISSUE-56@@

SKOS is intended to serve as a common denominator between different modelling approaches. As such it is hoped that the current vocabulary specification will allow many existing KOS to be ported to the Semantic Web. However, the great variety of KOS models makes its impossible to capture every detail of these models while still retaining the "S" in SKOS.

Applications that require finer granularity will greatly benefit from SKOS being a Semantic Web vocabulary. SKOS can be seamlessly extended to suit the specific needs of a particular KOS community while retaining compatibility with applications that are based on the core SKOS features.

This can mostly be done by specializing existing SKOS constructs into more specific ones. Users can create their own properties and classes, and attach them to the standard SKOS vocabulary elements by using the rdfs:subPropertyOf and rdfs:subClassOf properties from the RDF Schema vocabulary [RDF-PRIMER].

The example in Section 4.4 illustrates how the standard skos:labelRelated can be specialized into a semantically richer property devoted to acronym link representation. Other uses are possible, such as creating different "flavors" of skos:broader and skos:narrower properties. Thesaurus standards indeed identify a small number of kinds of hierarchical relation, such as generic, part-whole, or instance-class [ISO2788]. SKOS perfectly allows to create new properties to capture this distinction, and to declare them as sub-properties of skos:broader:

ex:broaderGeneric rdfs:subPropertyOf skos:broader.
ex:broaderPartitive rdfs:subPropertyOf skos:broader.
ex:broaderInstantive rdfs:subPropertyOf skos:broader.

Every ex:broaderPartitive statement between two concepts, for instance, can be formally interpreted by a proper Semantic Web reasoning engine. This interpretation will lead to the assertion of a skos:broader statement between these concepts, a piece of information which may then be exploited by basic SKOS tools.

@@TODO: point at the "Rules of Thumb" appendix in the Reference, if it is kept as such and indeed not transferred in the Primer...@@


BS 8723-2:2005 Structured vocabularies for information retrieval. Guide. Thesauri, British Standards Institution, London, 2005.
BS 8723-4:2007 Structured vocabularies for information retrieval. Guide. Interoperability between vocabularies, British Standards Institution, London, 2007.
Cool URIs for the Semantic Web, Leo Sauermann, Richard Cyganiak. W3C Working Draft, 17 December 2007. Latest version available at http://www.w3.org/TR/cooluris/
Dublin Core Metadata Element Set, Version 1.1, 14 January 2008. Latest version available at http://dublincore.org/documents/dces/.
ISO 2788:1986 Documentation - Guidelines for the establishment and development of monolingual thesauri. Second edition. ISO TC 46/SC 9, 1986.
RDF/XML Syntax Specification (Revised), Dave Beckett, Editor. W3C Recommendation, 10 February 2004. Latest version available at http://www.w3.org/TR/rdf-syntax-grammar/.
Best Practice Recipes for Publishing RDF Vocabularies. Diego Berrueta, Jon Phipps. W3C Working Draft, 23 January 2008. Latest version available at http://www.w3.org/TR/swbp-vocab-pub/.
OWL Working Group, http://www.w3.org/2007/OWL/.
OWL Web Ontology Language Reference, Mike Dean, Guus Schreiber, Editors, W3C Recommendation, 10 February 2004. Latest version available at http://www.w3.org/TR/owl-ref/.
RDF Primer, Frank Manola, Eric Miller, Editors, W3C Recommendation, 10 February 2004. Latest version available at http://www.w3.org/TR/rdf-primer/.
Resource Description Framework (RDF): Concepts and Abstract Syntax , Graham Klyne, Jeremy Carroll, Editors, W3C Recommendation, 10 February 2004. Latest version available at http://www.w3.org/TR/rdf-concepts/.
SKOS Use Cases and Requirements, Antoine Isaac, Jon Phipps, Daniel Rubin, Editors, W3C Working Draft (work in progress), 16 May 2007. Latest version available at http://www.w3.org/TR/skos-ucr/.
SKOS Core Guide, Alistair Miles, Dan Brickley, Editors, W3C Working Draft, 2 November 2005. Latest version available at http://www.w3.org/TR/swbp-skos-core-guide/.
SKOS Reference, Alistair Miles, Sean Bechhofer, Editors, W3C Working Draft, 25 January 2008. Latest version available at http://www.w3.org/TR/skos-reference.
SKOS Core Vocabulary Specification, Alistair Miles, Dan Brickley, Editors, W3C Working Draft, 2 November 2005. Available at http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20051102/.
The Semantic Web Deployment Working Group, http://www.w3.org/2006/07/SWD/.
Turtle - Terse RDF Triple Language , David Beckett, Tim Berners-Lee. W3C Team Submission, 14 January 2008. Latest version available at http://www.w3.org/TeamSubmission/turtle/.
RFC 3986 - Uniform Resource Identifiers (URI): Generic Syntax, Tim Berners-Lee, Roy Fielding, Larry Masinter, IETF, January 2005. Available at http://tools.ietf.org/html/rfc3986
[Willpower Glossary]
Stella Dextre Clarke, Alan Gilchrist, Ron Davies and Leonard Will. Glossary of terms relating to thesauri and other forms of structured vocabulary for information retrieval. Willpower Information. See http://www.willpowerinfo.co.uk/glossary.htm.


The editors gratefully acknowledge contributions from:

@@ TODO @@

Valid XHTML 1.0! Valid CSS!