From Athenawiki

Jump to: navigation, search


Main features

As a Semantic Web compliant format, SKOS is concept-oriented. This means that the fundamental element of a terminology designed in SKOS is the concept and not the term that expresses this concept. The SKOS data model consists of a basic structure that can be extended by specific classes for detailing lexical parts or semantic relations between the concepts of the terminology. The SKOS reference publication summarizes the main features of the SKOS model as follows:

“Using SKOS, can be identified using URIs, with lexical strings in one or more natural languages, assigned (lexical codes), with various types of note, and organized into informal hierarchies and association networks, aggregated into, grouped into, labeled and/or ordered , and to concepts in other schemes.”

SKOS data are expressed as RDF triples. This means that concepts may be subject or object and related via a SKOS property which would be the predicate. As RDF triples, SKOS concepts van be identified using URIs. These URIs can be defined according standard persistent identifier systems. The SKOS data model doesn’t require the use of persistent identifiers but in a Linked Open Data perspective, their use is highly recommended. Persistent identifiers will be described more precisely in the following sections.

The SKOS datamodel consists in three main components: classes, properties and relations. These three components always start with the prefix “skos:”. The distinction between a class and a property is done through the case: the element following the “skos:” prefix starts with an upper-case character when it is a class, e.g. skos:Concept and skos:ConceptScheme are classes; if the element following the “skos:” prefix starts with a lower case character, this means that the element is a property and not a class. For example skos:prefLabel is a property.


SKOS is a concept-oriented data model therefore the concept is the central element of the terminology. From a terminology point of view a concept can be defined as an idea, notion or unit of thought. A concept in SKOS is introduced as a class skos:Concept. Some bridges between the SKOS data model and the OWL one are available for a better interoperability. The skos:Concept class is an instance of owl:class which is a class from the OWL data model so that connections between the two data models are enabled. SKOS concepts can be brought together into two classes:

• SKOS concept scheme
• SKOS collections

Concept Schemes

A concept scheme is a way to bring together several concepts. A concept scheme is introduced by the class skos:ConceptScheme. An individual concept scheme roughly corresponds to the notion of an individual thesaurus, classification scheme or any other knowledge organization system. It is important to mention that a same concept can be part of more than one concept scheme.

Concept collections

A collection is a group of SKOS concepts. A collection is introduced by the main class skos:Collection. Although another class skos:OrderedCollection can also be used in the case where the order of the concepts within the collection has an importance. The notion of collection is different from the concept scheme. For the migration of a thesaurus for example, the whole could be considered as a concept scheme where several thematic groups of concepts could be designed as collections.


Each concept must be identified in a unique way in order to avoid any ambiguity. As it is the case in the RDF language and as a general principle of the Semantic Web and Linked data, it is recommended to use HTTP URIs in order to identify the concepts of terminology. The identifiers are introduced by a specific RDF property rdf:resource which is used each time that a new concept is introduced or semantic relations or mapping to other concepts are included in the description of the concept.


The SKOS model focuses on concepts therefore there is a distinction between the concept itself and the terms that may used to express this concept. Terms referring to a concept can be expressed via lexical labels according to the SKOS data model. A lexical label is a string of Unicode characters which allows you to have a term in any language with or without Latin characters. The SKOS data model defines 3 types of lexical label:

• Preferred label
• Alternative label
• Hidden label

The use of these different types of label enables the understanding of the concept and is useful for human-readable knowledge representation. The use of labels is not mandatory in the SKOS datamodel but is highly recommended especially for maintenance purposes.

Preferred label

The preferred label, introduced in the SKOS data model as the skos:prefLabel property, corresponds to the notion of descriptor from the standards for the elaboration of thesauri (ISO 2788 and ISO 5694). The SKOS data model does not allow there to be more than one preferred label in the same language.

Alternative label

Alternative labels, introduced as skos:altLabel property, are mainly used to give synonyms to the preferred label or other ways to refer to this preferred label, e.g. different spellings or acronyms. The SKOS model does not forbid the exclusive use of alternative labels instead of one preferred label and many alternative labels.

Hidden label

Hidden labels, introduced by the skos:hiddenLabel property, may be used for mentioning the misspellings of preferred or alternative labels but also for mentioning obsolete forms of a term. Alternative and hidden labels correspond roughly to the USE and UF (Used For) indicators defined in the ISO standards for thesauri. By definition, hidden labels are not visible but are very useful for the retrieval. Obviously the SKOS data model does not allow the use of the same string of characters as a preferred, alternative or hidden label in the same language. An extension to the SKOS model, SKOS-XL, is proposed for modeling more precisely the labels and including morphologic or syntactic information on labels.


Another property is available for expressing notations which are different from labels. Notations are symbols or codes that are not recognizable or understandable in any natural language.Notations are different from labels which usually are words or expressions understandable in any natural language. The skos:notation can then be used for example in the case of classifications where a code refers to a term referring itself to a concept. The notation can be more convenient than using an alternative label since it is considered as unambiguous and language independent.

Documentation properties

The SKOS model offers a variety of possibilities to provide information related to concepts. Different types of notes can be used to give the most accurate information. These notes can be of different natures (plain text, image, quotes …) and be used without any restriction.

The different types of notes that can be used to document a concept are:

  • Note (skos:note)
  • Change note (skos:changeNote)
  • Definition (skos:definition)
  • Editorial note (skos:editorialNote)
  • Example (skos:example)
  • History note (skos:historyNote)
  • Scope note (skos:scopeNote)

The skos:note can be used to provide general documentation on a concept. All the other types are specializations of this general property. The skos:changeNote and editorialNote are mainly useful for the purpose of administration and maintenance. The skos:definition, skos:example, skos:historyNote are useful for providing information on the concept for a better understanding of its meaning. As for labels, documentation properties can be provided in different languages by using language tags with the xml:lang attribute.

Semantic relations

The power of the SKOS model lies in the semantic relations that can be used to connect between different concepts. These semantic relations play a crucial role for defining concepts. There are two different categories of semantic relation: • Hierarchical
• Associative

Hierarchical relations

Hierarchical relations are introduced via two properties, skos:broader and skos:narrower. The skos:broader property is used to assert that a concept has more general meaning. skos:narrower is the inverse property used to assert that a concept has a more specific meaning. One concept can have more than one broader concept or more than one narrower concept.

It is important to note that these two properties only assert direct/immediate hierarchical link between two concepts. In order to enable non-immediate link between two concepts, the SKOS model provides two other properties that are transitive.

As for the skos:broader and skos:narrower, the properties skos:boaderTransitive and skos:narrowerTransitive are the inverse of each other.

Associative relations

The property skos:related is used to assert an associative link between two concepts. This property may be useful to make a link between a concept and another one which is neither an equivalent nor a broader/narrower concept. It is important to note that the skos:related property is symmetric.

skos:related is not a transitive property.

It is very important to keep in mind that, according to the guidelines provided in ISO 2788 and BS8723, mixing associative relations and hierarchical relations is not consistent with the SKOS data model. Therefore a special attention must be paid to the semantic relationships between concepts.


The SKOS data model provides several mapping properties for making alignment between concepts from different concept schemes. These properties are :

• skos:closeMatch
• skos:exactMatch
• skos:broadMatch
• skos:narrowMatch
• skos:relatedMatch

As for semantic relations between concepts, the mapping properties can be associative or hierarchical. The skos:broadMatch and skos:narrowMatch properties are used for a hierarchical mapping link between concepts whereas the skos:relatedMatch property is used for an associative one. Exactly as for semantic relations, skos:broadMatch is the inverse property of skos:narrowMatch.

The properties skos:closeMatch and skos:exactMatch are used to make a mapping link between concepts that are very similar or equal so they can be used interchangeably. The skos:exactMatch property is transitive and symmetric. Mapping properties are used rather than semantic relations in order to make mapping links between concepts from different concept schemes. In the case of a same concept scheme semantic relationships will be used instead of mapping properties.

As for semantic relations, there may be some conflicts in mixing hierarchical mapping properties with associative ones.

This page was last modified on 21 November 2010, at 14:39.This page has been accessed 17,612 times.