The SKOS Core Vocabulary is an application of the Resource Description Framework (RDF), that can be used to express a concept scheme as an RDF graph. Using RDF allows data to be linked to and/or merged with other RDF data by semantic web applications.

This document is a guide using the SKOS Core Vocabulary, for readers who already have a basic understanding of RDF concepts.

@@TODO-PWD: N.B. This edition of the SKOS Core Guide [http://www.w3.org/2004/02/skos/core/guide/2005-02-15] is an Editor's Draft, and has no formal standing within W3C. It will be superseded shortly by a Public Working Draft (PWD) edition. Text that is relevant to this editor's draft only, and is therefore to be removed for publication as PWD, are marked with '@@TODO-PWD: remove me @@'. Text to be added for publication as PWD are marked '@@TODO+PWD: add me @@'.@@

@@TODO+PWD: This edition of the SKOS Core Guide [@@TODO] is a W3C Public Working Draft. It is the authoritative guide to recommended usage of the SKOS Core Vocabulary at the time of publication.@@

Status of this Document

This section describes the status of this document at the time of its publication.

This document is an Editor's Draft for review by the Semantic Web Best Practices and Deployment Working Group (hereafter 'the Working Group') and the participants of the public-esw-thes@w3.org mailing list and is subject to change without notice. This document has no formal standing within W3C. Please consult the Working Group's home page and the W3C technical reports index for information about the latest publications by this group. This document 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.

Introduction

SKOS stands for Simple Knowledge Organisation System. The name SKOS was chosen to emphasise the goal of providing a simple yet powerful framework for expressing knowledge organisation systems in a machine-understandable way.

SKOS Core provides a model for expressing the basic structure and content of concept schemes.

A 'concept scheme' is defined here as: a set of concepts, optionally including statements about semantic relationships between those concepts. Thesauri, classification schemes, subject heading lists, taxonomies, terminologies, glossaries and other types of controlled vocabulary are all examples of concept schemes.

The SKOS Core Vocabulary is a set of RDF properties and RDFS classes, that can be used to express the content and structure of a concept scheme as an RDF graph. For example, below is an extract from the UK Archival Thesaurus (UKAT) [UKAT]:

This extract, expressed as an RDF graph using the SKOS Core Vocabulary, looks like:

Each of the blue circles represents a concept from the UKAT.

If your controlled vocabulary (concept scheme) has a similar structure, you will be interested in reading this guide, because it will tell you how to express your concept scheme as an RDF graph using the SKOS Core Vocabulary. Using RDF will allow your data to be linked to and/or merged with other RDF data by semantic web applications.

This document is a guide to using the SKOS Core Vocabulary, for readers who already have a basic understanding of RDF concepts.

@@TODO+PWD: This edition of the SKOS Core Guide [@@TODO] is a W3C Public Working Draft. It has been reviewed and approved for publication by the Semantic Web Best Practices and Deployment Working Group. It is the authoritative guide to recommended usage of the SKOS Core Vocabulary at the time of publication.@@

Examples

Most of the examples in this guide are given as a visualisation of the RDF graph, e.g.

example

An RDF graph can be serialised (i.e. encoded as a series of characters) according to any of three currently defined RDF syntaxes: RDF/XML [RDF Syntax], N3/Turtle [Turtle][N3], N-Triple [N-Triple]. All examples in this guide use the RDF/XML syntax for consistency. Examples serialised as RDF/XML appear in boxes such as:

Inference Rules

Inference rules are part of SKOS Core. Inference rules are described in prose, and where appropriate are expressed using the Jena 2 rule syntax [Jena Inference], or as RDF statements using the OWL vocabulary [OWL]. Inference rules appear in boxes such as:

Labelling Properties

This section describes the SKOS Core labelling properties: skos:prefLabel, skos:altLabel, skos:hiddenLabel, skos:prefSymbol and skos:altSymbol. Here labelling means assigning some sort of token to a resource, where the token is intended to be used to denote (label) the resource in natural language discourse and/or in representations intended for human consumption.

Preferred and Alternative Lexical Labels

The skos:prefLabel and skos:altLabel properties allow you to assign preferred and alternative lexical labels to a resource. For example:

The labels in the above example, 'animals' 'creatures' and 'fauna', would under normal circumstances be considered synonyms of each other. However, when labelling resources of type skos:Concept, it is not necessary to restrict preferred and alternative lexical labels to precise synonyms. The following are all valid:

Abbreviations and acronyms may also be used to label concepts, and the choice of whether to use them as preferred or alternative terms is unconstrained. However, misspelled words are normally included among the hidden labels (see see hidden labels below).

Hidden Lexical Labels

A hidden lexical label is a lexical label for a resource, where you would like that character string to be accessible to applications performing text-based indexing and search operations, but you would not like that label to be visible otherwise. To assign a hidden lexical label to a resource, use the skos:hiddenLabel property.

The most common use of hidden labels is to include misspelt variants of other lexical labels. For example:

Multilingual Labelling

The value of the properties skos:prefLabel and skos:altLabel should be a plain literal. A plain literal is a character string with optional language tag, and the language tag may be used to restrict the scope of a lexical label to a particular language, for example:

When labelling a concept in more than one language, bear in mind that subtle differences in the common meaning of translated words or phrases between languages may result in differing interpretations of a concept by different language communities.

N.B. There is an open issue as to whether this hierarchy is appropriate, and whether in fact the assertion as to whether a note is public or private should be orthogonal to the assertion about the function of the note.

To clarify the difference between skos:definition and skos:scopeNote, a definition should be an attempt to completely explain the meaning of a concept, whereas a scope note may consist of partial information about what is or is not included within the meaning ('scope') of a concept.

To clarify the difference between a skos:historyNote and a skos:changeNote, a history note is a piece of information intended for users of the scheme, documenting significant changes to the meaning/form/state of a concept, whereas a change note is intended for documenting fine-grained changes to a concept for the purposes of administration and management.

There are three recommended usage patterns for the SKOS Core documentation properties:

Documentation as an RDF Literal

This is the simplest pattern for using the SKOS Core documentation properties, where the property value (i.e. the object of the triple) is an RDF literal.

An example of this pattern is below:

Example

<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:skos="http://www.w3.org/2004/02/skos/core#">
<skos:Concept rdf:about="http://www.example.org/concepts#bananarepublic">
<skos:prefLabel>banana republic</skos:prefLabel>
<skos:definition>A small country, especially in South and Central America, that is
poor and often badly and immorally ruled.</skos:definition>
</skos:Concept>
</rdf:RDF>

Note that an plain literal may include a language tag. Where a concept is labelled in more than one language, documentation may also be provided in multiple languages, for example:

The domain and range of the property skos:semanticRelation is the class skos:Concept, therefore the use of any of the SKOS Core semantic relation properties implies that both the subject and the object of the triple is a resource of type skos:Concept.

Broader/Narrower Relationships

To assert that one concept is broader in meaning (i.e. more general) than another, where the scope (meaning) of one falls completely within the scope of the other, use the skos:broader property. To assert the inverse, that one concept is narrower in meaning (i.e. more specific) than another, use the skos:narrower property. For example:

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, and therefore correctly modelling this kind of structure in RDF requires careful consideration.

SKOS Core has special vocabulary to handle collections, and this is described below. However, RDF has some generic vocabulary (rdf:Bag and rdf:Seq) to handle ordered/unordered groups of resources, and there has been extended discussion as to whether these should be used. The choice has been made provisionally not to use rdf:Bag and rdf:Seq for this purpose, for reasons outlined in [Collections and Arrays].

Labelled Collections

To define a meaningful collection of concepts, use the skos:Collection class and the skos:member property. To assign a lexical label to a collection, use the rdfs:label property. For example:

Note that in the example above the collection was defined as a blank node, i.e. no URI was allocated. URIs may be allocated to collections, but usually this is not necessary.

The most common use of a labelled collection such as the above is to enhance a hierarchical display. You can describe narrower and broader relationships between a concept and a collection, for example:

Collectable Properties

The class skos:CollectableProperty supports a generic mechanism by which collections can be involved in semantic relationships (and other sorts of statement). For this class the following rule applies:

Also ordered collections may be nested inside unordered collections, and vice versa.

Concept Schemes

Usually, concepts are defined in relation to other concepts, as part of an internally coherent concept scheme. As mentioned in the introduction, a 'concept scheme' is defined here as: a set of concepts, optionally including statements about semantic relationships between those concepts.

The skos:ConceptScheme class allows you to assert that a resource is a concept scheme. For example:

Concepts do not have to be a part of a concept scheme, concepts may be defined and declared as stand-alone resources. However, where you would like to assert that a concept is a part of a particular concept scheme, use the skos:inScheme property, for example:

For concept schemes where the concepts are arranged in a broader/narrower generalisation hierarchy, use the skos:hasTopConcept property to assert a link between the concept scheme and the concepts that are the top-level concepts in the generalisation hierarchy. For example:

The referenced document should conform to the requirements of a published subject indicator as defined by [PSI].

The skos:subjectIndicator property is an owl:InverseFunctionalProperty, which means that if any two nodes in an RDF graph have the same value for this property, then they are the same resource [OWL]. Therefore you can use the skos:subjectIndicator property to indirectly identify a concept by reference to the URI of the document that is the published subject indicator for that concept.

Below is an example of referring to a concept via the value of the skos:subjectIndicator property:

There is a subtle difference between SKOS Core and other RDF applications like FOAF [FOAF], in terms of what they allow you to model. SKOS Core allows you to model a set of concepts as an RDF graph. Other RDF applications, such as FOAF, allow you to model things like people, organisations, places etc. as an RDF graph. Technically, SKOS Core introduces a layer of indirection into the modelling.

To understand this indirection better, consider the following two graphs, both involving the dc:creator property:

The above graph describes a relationship between a concept, and the person who is the creator of that concept. This graph should be interpreted as saying, "the person named 'Alistair Miles' is the creator of the concept denoted by the URI http://www.example.com/concepts#henry8. This concept was modified on 2005-02-06." This graph should probably not be interpreted as saying, "the person named 'Alistair Miles' is the creator of King Henry VIII," or that, "King Henry VIII was modified on 2005-02-06".

Contrast this with the graph below:

This second graph should probably be interpreted as saying, "the persons named 'King Henry VII' and 'Elizabeth of York' are the creators of the person named 'King Henry VIII'."

So, for a resource of type skos:Concept, any properties of that resource (such as creator, date of modification, source etc.) should be interpreted as properties of a concept, and not as properties of some 'real world thing' that that resource may be a conceptualisation of.

This layer of indirection allows thesaurus-like data to be expressed as an RDF graph. The conceptual content of any thesaurus can of course be remodelled as an RDFS/OWL ontology. However, this remodelling work can be a major undertaking, particularly for large and/or informal thesauri. A SKOS Core representation of a thesaurus maps fairly directly onto the original data structures, and can therefore be created without expensive remodelling and analysis.

SKOS Core is intended to provide both a stable encoding of thesaurus-like data within the RDF graph formalism, as well as a migration path for exploring the costs and benefits of moving from thesaurus-like to RDFS/OWL-like modelling formalisms.

Concept Identity and Mapping

The property owl:sameAsshould not be used to express the fact that two conceptual resources (i.e. resources of type skos:Concept) share the same meaning. The property owl:sameAs implies that two resources are identical in every way (they are in fact the same resource). Although two conceptual resources may have the same meaning, they may have different owners, different labels, different documentation, different history, and of course a different future.

Any party may, however, assert a mapping relationship between any two conceptual resources. The SKOS Mapping vocabulary [SKOSMAP] contains a number of RDF properties for expressing mapping relationships between conceptual resources.

Concepts in Multiple Schemes

SKOS Core assumes that the meaning of a conceptual resource is not affected by any RDF or natural language statements made about it. The concept's owner determines the meaning of a concept, and statements about the concept serve only to explain the meaning of the concept to others. It is up to the concept's owner to provide an informative set of statements about the concept, to ensure that other people will correctly interpret the meaning, and so share the same understanding.

In practise, this means that a concept may be used in any context, and the meaning of the concept will remain unchanged. However, bear in mind that the set of semantic relationships that a concept is involved in are an important part of the explanation of the meaning of that concept, and will influence the interpretation made by other people. Where a concept has little documentation, people will rely heavily on the semantic context of the concept to form an idea of meaning. Therefore the extent to which the meaning a concept is effectively explained via labels and documentation will determine how usable that concept is outside of the originally anticipated context.

Concept Scheme Versioning

This section suggests how properties from the OWL [OWL] and DCMI Terms [DCMITERMS] vocabularies could be used to assert information about concept scheme versioning.

For example, if I allocated the URI http://www.example.com/conceptscheme to a concept scheme (in its current state), and then allocated the URIs http://www.example.com/conceptscheme/1
and http://www.example.com/conceptscheme/2 to specific versions of the scheme, I could declare that:

Consult the OWL [OWL] and Dublin Core [DCMITERMS] specifications for full usage guidelines with respect to properties in those vocabularies.

HTTP URIs for Concepts

Whether or not it is good practice to allocate HTTP URIs, or certain types of HTTP URIs, to conceptual resources remains an open question. This is an open issue for the W3C Technical Architecture Group (TAG), see [HTTP Range 14]. See also [VMTF Note].

Tom Baker, editor. Managing a Vocabulary for the Semantic Web -- Best Practice. Draft under development for W3C Semantic Web Best Practices and Deployment Working Group. (See http://esw.w3.org/topic/VocabManagementNote)