Copyright ©2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
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.
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.
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.
@@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#"
xmlns:ex="http://www.example.com/">
<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>
</rdf:Description>
</rdf:RDF>
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/>
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.
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:
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].
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.
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.
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.
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@@
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.
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:
skos:broader
and skos:narrower
enable the representation of hierarchical links, such as the relationship
between one genre and its more specific species, or the
one between one whole and its parts;skos:related
enables the representation of associative (non-hierarchical) links, such
as the relationship between one type of event and a category of
entities which typically participate in it. Another use for
skos:related is between two categories where neither is more
general or more specific.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.
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@@
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;
skos:definition
"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.
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@@
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@@
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.
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@@
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@@
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@@
@@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.
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
<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.
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.
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.
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 @@
@@TODO: remove the section, unless these features are explicitly (re)introduced in SKOS, as a resolution for ISSUE-76 @@
@@TODO: adapt from SKOS Core Guide, depending on the resolution on ISSUE-64@@
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... @@
@@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.@@
@@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...@@
@@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.
@@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...@@
The editors gratefully acknowledge contributions from:
@@ TODO @@
