skos-primer 112 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  <title>SKOS Simple Knowledge Organization System Primer</title>
  <style type="text/css">
.note { margin-left: 4em }

.notecode { margin-left: 6em }

p.caption
{
  font-size: small;
  font-style: italic;
  color: #666;
  text-align: right;
  margin-bottom: 0;
}</style>
  <link rel="stylesheet" type="text/css"
  href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE">
</head>

<body>

<div class="head">
<a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home"
alt="W3C" height="48" width="72"></a>

<h1 id="title">SKOS Simple Knowledge Organization System Primer</h1>

<h2>W3C Working Group Note 18 August 2009</h2>
<dl>
  <dt>This version:</dt>
    <dd><a href="http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/"
       >http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/</a></dd>
  <dt>Latest version: </dt>
    <dd><a
      href="http://www.w3.org/TR/skos-primer">http://www.w3.org/TR/skos-primer</a></dd>
  <dt>Previous version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2009/WD-skos-primer-20090615/">http://www.w3.org/TR/2009/WD-skos-primer-20090615/</a></dd>
  <dt>Editors:</dt>
    <dd><a href="http://www.few.vu.nl/%7Eaisaac">Antoine Isaac</a>, Vrije
      Universiteit Amsterdam</dd>
    <dd><a href="http://www.loc.gov/">Ed Summers</a>, Library Of Congress</dd>
</dl>

<p>Please refer to the <a
href="http://www.w3.org/2006/07/SWD/SKOS/reference/20090811-errata"
><strong>errata</strong></a> for this
document, which may include some corrections.</p>

<p>See also <a
href="http://www.w3.org/2003/03/Translations/byTechnology?technology=skos-primer"><strong>translations</strong></a>.</p>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
©2009 <a href="http://www.w3.org/"><acronym
title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a
href="http://www.csail.mit.edu/"><acronym
title="Massachusetts Institute of Technology">MIT</acronym></a>, <a
href="http://www.ercim.org/"><acronym
title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> rules apply. </p>
<hr>
</div>

<h2 class="notoc"><a id="abstract" name="abstract">Abstract</a></h2>

<p>SKOS—Simple Knowledge Organization 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 similar types of controlled vocabulary. As an
application of the <a href="http://www.w3.org/RDF/">Resource Description
Framework (RDF)</a>, SKOS allows concepts to be composed and published on the
World Wide Web, linked with data on the Web and integrated into other concept
schemes.</p>

<p>This document is a user guide for those who would like to represent their
concept scheme using SKOS.</p>

<p>In basic SKOS, conceptual resources (concepts) are identified with URIs,
labeled with strings in one or more natural languages, documented with
various types of note, semantically related to each other in informal
hierarchies and association networks, and aggregated into concept schemes.</p>

<p>In advanced SKOS, conceptual resources can be mapped across concept
schemes and grouped into labeled or ordered collections. Relationships can be
specified between concept labels. Finally, the SKOS vocabulary itself can be
extended to suit the needs of particular communities of practice or combined
with other modeling vocabularies.</p>

<p>This document is a companion to the <a
href="http://www.w3.org/TR/skos-reference">SKOS Reference</a>, which provides
the normative reference on SKOS.</p>
<hr>

<h2 id="Status">Status of this Document</h2>

<p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a>
at http://www.w3.org/TR/.</em></p>

<p>This document is a Working Group Note published by the <a
href="http://www.w3.org/2006/07/SWD/">Semantic Web Deployment Working
Group</a>, part of the <a href="http://www.w3.org/2001/sw/Activity">W3C
Semantic Web Activity</a>. This version is an update to the <a
href="http://www.w3.org/TR/2009/WD-skos-primer-20090615/">previous
Working Draft of 15 June 2009</a>.  This version includes several minor
editorial changes as well as removing an example that suggested one
means to reference a system of notation (e.g. a symbolic notation)
in a label where the system of notation does not correspond to a
natural language. This suggestion was deemed inconsistent with
IETF <a href="http://www.rfc-editor.org/rfc/bcp/bcp47.txt"
>Best Current Practice 47</a> on the use of tags for identifying
languages.  Users should consider the <a
href="http://www.w3.org/TR/2009/REC-skos-reference-20090818/#xl"
>SKOS Extension vocabulary</a> for support of alternate systems of notation.</p>

<p>This is a companion document to the <a
href="http://www.w3.org/TR/2009/REC-skos-reference-20090818/">SKOS Simple
Knowledge Organization System Reference W3C Recommendation</a> dated
18 August 2009.</p>

<p>Comments on this document may be sent to <a
href="mailto:public-swd-wg@w3.org?Subject=SKOS%20comment">public-swd-wg@w3.org</a>;
please include the text "SKOS comment" in the subject line. All messages
received at this address are viewable in a <a
href="http://lists.w3.org/Archives/Public/public-swd-wg/">public
archive</a>.</p>

<p>This document was produced by a group operating under the <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004
W3C Patent Policy</a>. W3C maintains a <a rel="disclosure"
href="http://www.w3.org/2004/01/pp-impl/39408/status">public list of any
patent disclosures</a> 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
<a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
Claim(s)</a> must disclose the information in accordance with <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
6 of the W3C Patent Policy</a>.</p>

<p>Publication as a Working Group Note 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.</p>

<hr>

<h2 id="Contents">Table of Contents</h2>
<ul>
  <li><a href="#secintro">1 Introduction</a></li>
  <li><a href="#secsimple">2 SKOS Essentials</a>
    <ul class="contents2">
      <li><a href="#secconcept">2.1 Concepts</a></li>
      <li><a href="#seclabel">2.2 Labels</a>
        <ul>
          <li><a href="#secpref">2.2.1 Preferred Lexical Labels</a></li>
          <li><a href="#secalt">2.2.2 Alternative Lexical Labels</a></li>
          <li><a href="#sechidden">2.2.3 Hidden Lexical Labels</a></li>
        </ul>
      </li>
      <li><a href="#secrel">2.3 Semantic Relationships</a>
        <ul>
          <li><a href="#sechierarchy">2.3.1 Broader/Narrower
          Relationships</a></li>
          <li><a href="#secassociative">2.3.2 Associative
          Relationships</a></li>
        </ul>
      </li>
      <li><a href="#secdocumentation">2.4 Documentary Notes</a></li>
      <li><a href="#secscheme">2.5 Concept Schemes</a></li>
    </ul>
  </li>
  <li><a href="#secnetworking">3 Networking Knowledge Organization Systems on
    the Semantic Web</a>
    <ul class="contents2">
      <li><a href="#secmapping">3.1 Mapping Concept Schemes</a></li>
      <li><a href="#secextension">3.2 Re-using and Extending Concept
        Schemes</a></li>
      <li><a href="#secindexing">3.3 Subject Indexing and SKOS</a> </li>
    </ul>
  </li>
  <li><a href="#secadvanced">4 Advanced SKOS: When KOSs are not Simple
    Anymore</a>
    <ul class="contents2">
      <li><a href="#seccollections">4.1 Collections of Concepts</a></li>
      <li><a href="#secadvanceddocumentation">4.2 Advanced Documentation
        Features</a></li>
      <li><a href="#secrelationshipslabels">4.3 Relationships between
        Labels</a></li>
      <li><a href="#secconceptcoordination">4.4 Coordinating Concepts</a></li>
      <li><a href="#sectransitivebroader">4.5 Transitive Hierarchies</a></li>
      <li><a href="#secnotations">4.6 Notations</a></li>
      <li><a href="#secskosspecialization">4.7 On Specializing the SKOS
        Model</a></li>
    </ul>
  </li>
  <li><a href="#seccombining">5 Combining SKOS with other Modeling
    Approaches</a>
    <ul class="contents2">
      <li><a href="#seclabelsoutsideSKOS">5.1 Use of Labels Outside of
        SKOS</a></li>
      <li><a href="#secskosowl">5.2 SKOS Concepts and OWL Classes</a></li>
      <li><a href="#secskoscontainment">5.3 SKOS, RDF Datasets and
        Information Containment</a></li>
    </ul>
  </li>
  <li><a href="#secref">References</a></li>
  <li><a href="#secack">Acknowledgments</a></li>
  <li><a href="#seccorrespondencesISO">Appendix. Correspondences between
    ISO-2788/5964 and SKOS constructs</a></li>
</ul>
<hr>

<h2 id="secintro">1 Introduction</h2>

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

<p>SKOS has been designed to provide a low-cost migration path for porting
existing organization systems to the Semantic Web. SKOS also provides a
lightweight, intuitive conceptual modeling language for developing and
sharing new KOSs. It can be used on its own, or in combination with
more-formal languages such as the Web Ontology Language (OWL) [<cite><a
href="#OWL-REFERENCE">OWL</a></cite>]. 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 Web-based collaboration tools, as exemplified by
social tagging applications.</p>

<p>The aim of SKOS is not to replace original conceptual vocabularies in
their initial context of use, but to allow them to be ported to a shared
space, based on a simplified model, enabling wider re-use and better
interoperability.</p>

<h3 id="secabout">1.1 About this Primer</h3>

<p>This document is intended to help users 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 the SKOS
vocabulary. </p>

<p>For a systematic account of all SKOS vocabulary elements, including their
reference semantics, the reader should consult the normative <cite>SKOS
Reference</cite> [<cite><a href="#SKOS-REFERENCE">SKOS-REFERENCE</a></cite>].
This can be done, at the level of classes and properties, by clicking on
their occurrences in the text (e.g. <a
href="http://www.w3.org/TR/skos-reference#Concept">skos:Concept</a>). For an
overview of the use cases for SKOS and the elicited requirements that guided
its design, the reader should consult the <cite>SKOS Use Cases and
Requirements</cite> [<cite><a href="#SKOS-UCR">SKOS-UCR</a></cite>].</p>

<p>This Primer, together with the <cite>SKOS Reference</cite> [<cite><a
href="#SKOS-REFERENCE">SKOS-REFERENCE</a></cite>], replaces the earlier
<cite>SKOS Core Guide</cite> [<cite><a
href="#SWBP-SKOS-CORE-GUIDE">SWBP-SKOS-CORE-GUIDE</a></cite>] and the
<cite>SKOS Core Vocabulary Specification</cite> [<cite><a
href="#SWBP-SKOS-CORE-SPEC">SWBP-SKOS-CORE-SPEC</a></cite>], which are now
deprecated.</p>

<p>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. Section 5
discusses the use of SKOS in conjunction with other modeling approaches,
specifically OWL.</p>

<h4 id="secaboutexamples">About Examples in this Primer</h4>

<p>Most of the examples in this guide are given as a serialization of RDF
graphs using the Turtle syntax for RDF [<cite><a
href="#TURTLE">TURTLE</a></cite>]. Examples serialized as Turtle appear in
code lines such as: </p>
<pre class="code">@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
@prefix ex: &lt;http://www.example.com/&gt;.

ex:aResource ex:aProperty ex:anotherResource;
  ex:anotherProperty "An RDF Literal"@en.</pre>

<p>The above is equivalent to the following expression, in the RDF/XML
reference syntax [<cite><a
href="#RDF-XML-SYNTAX">RDF/XML-SYNTAX</a></cite>]:</p>
<pre class="code">&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://www.example.com/"&gt;
&lt;rdf:Description rdf:about="http://www.example.com/aResource"&gt;
  &lt;ex:aProperty rdf:resource="http://www.example.com/anotherResource"/&gt;
  &lt;ex:anotherProperty xml:lang="en"&gt;An RDF Literal&lt;/ex:anotherProperty&gt;
&lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;</pre>

<p>For the sake of brevity a number of namespace declarations are omitted
from the examples. This applies to standard namespaces (SKOS, RDF/RDFS
[<cite><a href="#RDF-PRIMER">RDF-PRIMER</a></cite>], OWL [<cite><a
href="#OWL-REFERENCE">OWL</a></cite>] and Dublin Core [<cite><a
href="#DC">DC</a></cite>]) but also to the ones that are coined for the
examples. Generally, these namespaces could be declared as in the following
code: </p>
<pre class="code">@prefix skos: &lt;http://www.w3.org/2004/02/skos/core#&gt; .
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt; .
@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt; .
@prefix owl: &lt;http://www.w3.org/2002/07/owl#&gt; .
@prefix dct: &lt;http://purl.org/dc/terms/&gt; .
@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt; .
@prefix ex: &lt;http://www.example.com/&gt; .
@prefix ex1: &lt;http://www.example.com/1/&gt; .
@prefix ex2: &lt;http://www.example.com/2/&gt; .</pre>
<hr>

<h2 id="secsimple">2 SKOS Essentials</h2>

<p>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 [<cite><a href="#SKOS-UCR">SKOS-UCR</a></cite>]. </p>

<p>In basic SKOS, <a href="#secconcept">conceptual resources</a> (concepts)
can be identified with URIs, <a href="#seclabel">labeled</a> with lexical
strings in one or more natural languages, <a
href="#secdocumentation">documented</a> with various types of note, <a
href="#secrel">semantically related</a> to each other in informal hierarchies
and association networks and aggregated into <a href="#secscheme">concept
schemes</a>.</p>
<hr>

<h3 id="secconcept">2.1 Concepts</h3>

<p>The fundamental element of the SKOS vocabulary is the <em>concept</em>.
Concepts are the <em>units of thought</em> [<cite><a
href="#WillpowerGlossary">WillpowerGlossary</a></cite>]—ideas, meanings, or
(categories of) objects and events—which underlie many knowledge
organization systems [<cite><a href="#SKOS-UCR">SKOS-UCR</a></cite>]. As
such, concepts exist in the mind as abstract entities which are independent
of the terms used to label them. </p>

<p>SKOS introduces the class <code><a
href="http://www.w3.org/TR/skos-reference#Concept">skos:Concept</a></code>,
which allows implementors to assert that a given resource is a concept. This
is done in two steps:</p>
<ol>
  <li>by creating (or reusing) a Uniform Resource Identifier (URI [<cite><a
    href="#URI">URI</a></cite>]) to uniquely identify the concept.</li>
  <li>by asserting in RDF, using the property <code><a
    href="http://www.w3.org/TR/rdf-schema/#ch_type">rdf:type</a></code>, that
    the resource identified by this URI is of type <code><a
    href="http://www.w3.org/TR/skos-reference#Concept">skos:Concept</a></code>.</li>
</ol>

<p>For example:</p>
<pre class="code">&lt;http://www.example.com/animals&gt; rdf:type skos:Concept.</pre>

<p>This can also be represented in Turtle more compactly using the namespace
prefix <code>ex</code> defined above:</p>
<pre class="code">ex:animals rdf:type skos:Concept.</pre>

<p>Using SKOS to publish concept schemes makes it easy to reference the
concepts in resource descriptions on the Semantic Web. Implementors are
encouraged to use HTTP URIs when minting concept URIs since they are
resolvable to representations that can be accessed using standard Web
technologies. For more information about URIs on the Semantic Web, see
<cite>Cool URIs for the Semantic Web</cite> [<cite><a
href="#COOLURIS">COOLURIS</a></cite>] and <cite>Best Practice Recipes for
Publishing RDF Vocabularies</cite> [<cite><a
href="#RECIPES">RECIPES</a></cite>].</p>
<hr>

<h3 id="seclabel">2.2 Labels</h3>

<p>The first characterizations of concepts are the expressions that are used
to refer to them in natural language: their <em>labels</em>. SKOS provides
three properties to attach labels to conceptual resources: <code><a
href="http://www.w3.org/TR/skos-reference#prefLabel">skos:prefLabel</a></code>,
<code><a
href="http://www.w3.org/TR/skos-reference#altLabel">skos:altLabel</a></code>
and <code><a
href="http://www.w3.org/TR/skos-reference#hiddenLabel">skos:hiddenLabel</a></code>.
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 formally defined as being pairwise disjoint.
This means, for example, that it is an error if a concept has a same literal
both as its preferred label and as an alternative label.</p>

<p>As specified in <a
href="http://www.w3.org/TR/skos-reference/#L2831">Section 5</a> of the
<cite>SKOS Reference</cite>, <code>skos:prefLabel</code>,
<code>skos:altLabel</code> and <code>skos:hiddenLabel</code> provide simple
labels. They are all sub-properties of <code><a
href="http://www.w3.org/TR/rdf-schema/#ch_label">rdfs:label</a></code>, and
are used to link a <code>skos:Concept</code> to an <a
href="http://www.w3.org/TR/rdf-concepts/#section-Literals">RDF plain
literal</a>, which is a character string (e.g. <code>"love"</code>) combined
with an optional language tag (e.g. <code>"en-US"</code>) [<cite><a
href="#RDF-CONCEPTS">RDF-CONCEPTS</a></cite>].</p>

<h4 id="secpref">2.2.1 Preferred Lexical Labels</h4>

<p>The <code><a
href="http://www.w3.org/TR/skos-reference#prefLabel">skos:prefLabel</a></code>
property makes it possible to assign a preferred lexical label to a resource.
Terms used as <em>descriptors</em> in indexing systems [<cite><a
href="#WillpowerGlossary">WillpowerGlossary</a></cite>] will for instance be
represented using this property, as in the following example:</p>
<pre class="code">ex:animals rdf:type skos:Concept;
  skos:prefLabel "animals".</pre>

<p>RDF plain literals are formally defined as character strings with optional
language tags. SKOS thereby enables a simple form of multilingual labeling.
This is done by using the language tag of a lexical label to restrict its
scope to a particular language. The following example illustrates how a
concept is given one preferred label in English and another in French:</p>
<pre class="code">ex:animals rdf:type skos:Concept;
  skos:prefLabel "animals"@en;
  skos:prefLabel "animaux"@fr.</pre>

<p>Note that the notion of <em>preferred</em> label implies that a resource
can only have one such label per language tag, as explained in <a
href="http://www.w3.org/TR/skos-reference#L2831">Section 5</a> of the
<cite>SKOS Reference</cite> [<cite><a
href="#SKOS-REFERENCE">SKOS-REFERENCE</a></cite>].</p>

<p>Following common practice in KOS design, the preferred label of a concept
may also be used to unambiguously represent this concept within a KOS and its
applications. So even though the SKOS data model does not formally enforce
it, it is recommended that no two concepts in the same KOS be given the same
preferred lexical label for any given language tag.</p>

<h4 id="secalt">2.2.2 Alternative Lexical Labels</h4>

<p>The <code><a
href="http://www.w3.org/TR/skos-reference#altLabel">skos:altLabel</a></code>
property makes it possible 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: </p>
<pre class="code">ex:animals rdf:type skos:Concept;
  skos:prefLabel "animals"@en;
  skos:altLabel "creatures"@en;
  skos:prefLabel "animaux"@fr;
  skos:altLabel "créatures"@fr.</pre>

<p>Note that representation of synonyms for preferred labels is not the only
use for <code>skos:altLabel</code>. <em>Near-synonyms</em>, abbreviations and
acronyms can be represented the same way:</p>
<pre><code>ex:fao rdf:type skos:Concept;
  skos:prefLabel "Food and Agriculture Organization"@en;
  skos:altLabel "FAO"@en.</code></pre>

<p class="note"><strong>Note on upward posting:</strong> It is also possible
to use <code>skos:altLabel</code> to represent cases of <em>upward
posting</em> [<cite><a href="#ISO2788">ISO-2788</a></cite>]. That is, when a
concept aggregates more-specialized notions that are not explicitly
introduced as concepts in the considered KOS:</p>
<pre class="notecode">ex:rocks rdf:type skos:Concept;
  skos:prefLabel "rocks"@en;
  skos:altLabel "basalt"@en;
  skos:altLabel "granite"@en;
  skos:altLabel "slate"@en.</pre>

<p class="note">However, even though SKOS is not intended to replace existing
guides for KOS design [<cite><a href="#ISO2788">ISO-2788</a></cite>, <cite><a
href="#BS8723-2">BS8723-2</a></cite>], the reader should be aware that upward
posting is not recommended. A more appropriate KOS for this domain would
introduce a <code>skos:Concept</code> for each kind of rock considered
(basalt, granite and slate) and assert it as a narrower concept of
<code>ex:rock</code>.</p>

<h4 id="sechidden">2.2.3 Hidden Lexical Labels</h4>

<p>A <em>hidden lexical label</em>, represented by means of the <code><a
href="http://www.w3.org/TR/skos-reference#hiddenLabel">skos:hiddenLabel</a></code>
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 <strong>not</strong> like that
label to be visible otherwise. Hidden labels may for instance be used to
include misspelled variants of other lexical labels. For example:</p>
<pre class="code">ex:animals rdf:type skos:Concept;
  skos:prefLabel "animaux"@fr;
  skos:altLabel "bêtes"@fr;
  skos:hiddenLabel "betes"@fr.</pre>
<hr>

<h3 id="secrel">2.3 Semantic Relationships</h3>

<p>In KOSs <em>semantic relations</em> play a crucial role for defining
concepts. The meaning of a concept is defined not just by the
natural-language words in its labels but also by its links to other concepts
in the vocabulary. Mirroring the fundamental categories of relations that are
used in vocabularies such as thesauri [<cite><a
href="#ISO2788">ISO2788</a></cite>], SKOS supplies three standard
properties:</p>
<ul>
  <li><code><a
    href="http://www.w3.org/TR/skos-reference#broader">skos:broader</a></code>
    and <code><a
    href="http://www.w3.org/TR/skos-reference#narrower">skos:narrower</a></code>
    enable the representation of hierarchical links, such as the relationship
    between one <em>genre</em> and its more specific <em>species</em>, or,
    depending on interpretations, the relationship between one <em>whole</em>
    and its <em>parts</em>;</li>
  <li><code><a
    href="http://www.w3.org/TR/skos-reference#related">skos:related</a></code>
    enables the representation of associative (non-hierarchical) links, such
    as the relationship between one type of <em>event</em> and a category of
    entities which typically <em>participate</em> in it. Another use for
    <code>skos:related</code> is between two categories where neither is more
    general or more specific. Note that <code>skos:related</code> enables the
    representation of associative (non-hierarchical) links, which can also be
    used to represent part-whole links that are not meant as hierarchical
    relationships.</li>
</ul>

<h4 id="sechierarchy">2.3.1 Broader/Narrower Relationships</h4>

<p>To assert that one concept is broader in meaning (i.e. more general) than
another, the <code><a
href="http://www.w3.org/TR/skos-reference#broader">skos:broader</a></code>
property is used. The <code><a
href="http://www.w3.org/TR/skos-reference#narrower">skos:narrower</a></code>
property is used to assert the inverse, namely when one concept is narrower
in meaning (i.e. more specific) than another. For example:</p>
<pre class="code">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.</pre>

<p>As is often the case in KOS, a SKOS concept can be attached to several
broader concepts at the same time. For example, a concept <code>ex:dog</code>
could have both <code>ex:mammals</code> and
<code>ex:domesticatedAnimals</code> as broader concepts.</p>

<p class="note"><strong>Note on <code>skos:broader</code> direction:</strong>
for historic reasons, the name of the <code>skos:broader</code> property (the
word "broader") does not provide an explicit indication of its direction. The
word "broader" should read here as "has broader concept"; the subject of a
<code>skos:broader</code> statement is the more specific concept involved in
the assertion and its object is the more generic one. </p>

<p class="note"><strong>Note on implicit
<code>skos:broader</code>/<code>skos:narrower</code> statements</strong>: the
properties <code>skos:broader</code> and <code>skos:narrower</code> 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 data model [<cite><a
href="#SKOS-REFERENCE">SKOS-REFERENCE</a></cite>]. This can be useful for
making SKOS representations more efficient by limiting the information they
contain. In the above example, for instance, the statement <code>ex:mammals
skos:broader ex:animals</code> can be left out if, before using the concept
scheme data, an OWL reasoner is used to infer it from the statement
<code>ex:animals skos:narrower ex:mammals</code>.</p>

<p>In many cases, hierarchical relations in a concept scheme can be
considered as <a
href="http://www.w3.org/TR/owl-ref/#TransitiveProperty-def">transitive</a>
[<cite><a href="#OWL-REFERENCE">OWL</a></cite>]. If <code>ex:animals</code>
is broader than <code>ex:mammals</code>, which is itself broader than
<code>ex:cats</code>, it makes sense to assert that <code>ex:animals</code>
is broader than <code>ex:cats</code>. However, there are "dirtier"
hierarchies, especially in KOSs different from standard well-designed
thesauri, where such a feature would not be judged appropriate. Consider for
instance a case where <code>ex2:vehicles</code> is said to be broader than
<code>ex2:cars</code>, which is itself asserted to be broader than
<code>ex2:wheels</code>. It may be problematic if "wheels" is automatically
inferred to be a narrower concept with respect to "vehicles". SKOS
anticipates such problems by <strong>not</strong> defining
<code>skos:broader</code> and <code>skos:narrower</code> as generally
transitive properties. The reader interested in representing "transitive
hierarchies" is encouraged to read <a href="#sectransitivebroader">Section
4.5</a>, which presents a way to do this while retaining compatibility with
the semantics of <code>skos:broader</code> defined in this section.</p>

<p class="note"><strong>Note on not transitive vs. intransitive</strong>: the
SKOS model does not state that <code>skos:broader</code> and
<code>skos:narrower</code> are transitive. Yet this does not imply that these
properties are <em>intransitive</em>. Consider a concept <code>cats</code>
which is narrower than a concept <code>mammals</code>, itself narrower than
<code>animals</code>: one can assert that <code>cats</code> is narrower than
<code>animals</code> as well, while staying compatible with the SKOS model.
Not specifying <code>skos:broader</code> as transitive implies that no new
<code>skos:broader</code> statement can be <em>inferred</em> between
<code>cats</code> and <code>animals</code> by applying SKOS axioms. This does
<strong>not</strong> prevent the publishers of a SKOS concept scheme from
<em>asserting</em> hierarchical statements that reflect a locally transitive
behaviour.</p>

<p>Similarly, SKOS does not assume that hierarchical relations are by default
irreflexive. In many thesaurus guidelines, it is prohibited to have a concept
broader than itself. However, in specific cases beyond classical thesauri,
some reflexive <code>skos:broader</code> statements may occur. Consider the
conversion of an existing RDFS/OWL ontology into a SKOS concept scheme. In
such a case, it is legitimate that every <code>rdfs:subClassOf</code>
statement will be re-interpreted as a <code>skos:broader</code> statement.
However, <code>rdfs:subClassOf</code> is a reflexive property, which means
that for every class <code>C</code>, the statement <code>C rdfs:subClassOf
C</code> is <a href="http://www.w3.org/TR/owl-ref/#subClassOf-def">true</a>
[<cite><a href="#OWL-REFERENCE">OWL</a></cite>]. In this case every concept
would therefore have itself among its broader concepts.</p>

<p>Not covered in basic SKOS is the distinction between types of hierarchical
relation: for example, instance-class and part-whole relationships. The
interested reader is referred to <a href="#secskosspecialization">Section
4.7</a>, which describes how to create specializations of semantic relations
to deal with this issue.</p>

<h4 id="secassociative">2.3.2 Associative Relationships</h4>

<p>To assert an associative relationship between two concepts, <code><a
href="http://www.w3.org/TR/skos-reference#related">skos:related</a></code>
can be used:</p>
<pre class="code">ex:birds rdf:type skos:Concept;
  skos:prefLabel "birds"@en;
  skos:related ex:ornithology.
ex:ornithology rdf:type skos:Concept;
  skos:prefLabel "ornithology"@en.</pre>

<p>As described in the <cite>SKOS Reference</cite> [<cite><a
href="#SKOS-REFERENCE">SKOS-REFERENCE</a></cite>], the
<code>skos:related</code> property is <a
href="http://www.w3.org/TR/owl-ref/#SymmetricProperty-def">symmetric</a>
[<cite><a href="#OWL-REFERENCE">OWL</a></cite>]. From the above RDF graph,
for instance, it follows that <code>ex:ornithology</code> is the subject of a
<code>skos:related</code> statement that has <code>ex:birds</code> as an
object. </p>

<p class="note"><strong>Note on (non-)transitivity of
<code>skos:related</code>:</strong> The reader should be aware that in the
SKOS data model <code>skos:related</code> is not defined as a transitive
property. A transitive <code>skos:related</code> could have unwanted
consequences, as in the following example:</p>
<pre class="notecode">ex:renaissance skos:related ex:humanism.
ex:humanism skos:related ex:philosophicalAnthropology.
ex:philosophicalAnthropology skos:related ex:philosophyOfMind.
ex:philosophyOfMind skos:related ex:cognitiveScience.</pre>

<p class="note">Should <code>skos:related</code> be transitive,
<code>ex:renaissance</code> would be then <em>directly</em> related to
<code>ex:cognitiveScence</code>. While every individual statement makes
sense, the inferred statement may not fit what the designer of the KOS
originally intended.</p>

<p class="note"><strong>Note on mixing hierarchy with association:</strong>
The transitive closure of <code>skos:broader</code> is disjoint from
<code>skos:related</code>. If resources A and B are related via
<code>skos:related</code>, there must not be a chain of
<code>skos:broader</code> relationships from A to B. The same holds of
<code>skos:narrower</code>.</p>
<hr>

<h3 id="secdocumentation">2.4 Documentary Notes</h3>

<p>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 <em>scope notes</em> or
<em>definitions</em>.</p>

<p>SKOS provides a <code><a
href="http://www.w3.org/TR/skos-reference#note">skos:note</a></code> property
for general documentation purposes. Inspired by existing KOS guidelines, such
as [<cite><a href="#ISO2788">ISO2788</a></cite>] or [<cite><a
href="#BS8723-2">BS8723-2</a></cite>], this property is further specialized
into <code>skos:scopeNote</code>, <code>skos:definition</code>,
<code>skos:example</code>, and <code>skos:historyNote</code> to fit
more-specific types of documentation.</p>

<p><code><a
href="http://www.w3.org/TR/skos-reference#scopeNote">skos:scopeNote</a></code>
supplies some, possibly partial, information about the intended meaning of a
concept, especially as an indication of how the use of a concept is limited
in indexing practice. The following example is adapted from [<cite><a
href="#ISO2788">ISO2788</a></cite>]:</p>
<pre class="code">ex:microwaveFrequencies skos:scopeNote
    "Used for frequencies between 1GHz to 300Ghz"@en.</pre>

<p><code><a
href="http://www.w3.org/TR/skos-reference#definition">skos:definition</a></code>
supplies a complete explanation of the intended meaning of a concept. The
following example is adapted from [<cite><a
href="#ISO2788">ISO2788</a></cite>]:</p>
<pre class="code">ex:documentation skos:definition
    "the process of storing and retrieving information
    in all fields of knowledge"@en.</pre>

<p><code><a
href="http://www.w3.org/TR/skos-reference#example">skos:example</a></code>
supplies an example of the use of a concept:</p>
<pre class="code">ex:organizationsOfScienceAndCulture skos:example
    "academies of science, general museums, world fairs"@en.</pre>

<p><code><a
href="http://www.w3.org/TR/skos-reference#historyNote">skos:historyNote</a></code>
describes significant changes to the meaning or the form of a concept:</p>
<pre class="code">ex:childAbuse skos:historyNote
    "estab. 1975; heading was: Cruelty to children [1952-1975]"@en.</pre>

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

<p><code><a
href="http://www.w3.org/TR/skos-reference#editorialNote">skos:editorialNote</a></code>
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:</p>
<pre><code>ex:doubleclick skos:editorialNote "Review this term after company merger
                                  complete"@en.
ex:folksonomy skos:editorialNote "Check spelling with Thomas Vander Wal"@en.</code></pre>

<p><code><a
href="http://www.w3.org/TR/skos-reference#changeNote">skos:changeNote</a></code>
documents fine-grained changes to a concept, for the purposes of
administration and maintenance:</p>
<pre><code>ex:tomato skos:changeNote
  "Moved from under 'fruits' to under 'vegetables' by Horace Gray"@en.</code></pre>

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

<p>As illustrated above, SKOS documentation properties can be simply used
with RDF plain literals. <a href="#secadvanceddocumentation">Section 4.2</a>
will show that there are 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 labeling
properties. Documentation may thus be provided in multiple languages:</p>
<pre class="code">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 d'une plante herbacée de la famille des broméliacées"@fr.</pre>

<p>Before concluding this section, it is important to note that other,
non-SKOS properties could be used to document concepts. The <a
href="http://purl.org/dc/terms/creator"><code>dct:creator</code></a> property
from Dublin Core [<cite><a href="#DC">DC</a></cite>] can for instance be used
to point to a person that created the concept:</p>
<pre class="code">ex:madagascarFishEagle dct:creator [ foaf:name "John Smith" ].</pre>
<hr>

<h3 id="secscheme">2.5 Concept Schemes</h3>

<p>Concepts can be created and used as stand-alone entities. However,
especially in indexing practice, concepts usually come in carefully compiled
vocabularies, such as thesauri or classification schemes. SKOS offers the
means of representing such KOSs using the <code><a
href="http://www.w3.org/TR/skos-reference#ConceptScheme">skos:ConceptScheme</a></code>
class. </p>

<p>The following example shows how to define a concept scheme resource
(representing a thesaurus) and to describe that resource using the <code><a
href="http://purl.org/dc/terms/title">dct:title</a></code> and <code><a
href="http://purl.org/dc/terms/creator">dct:creator</a></code> properties
from Dublin Core [<cite><a href="#DC">DC</a></cite>]:</p>
<pre class="code">ex:animalThesaurus rdf:type skos:ConceptScheme;
  dct:title "Simple animal thesaurus";
  dct:creator ex:antoineIsaac.</pre>

<p>Once the concept scheme resource has been created, it can be linked with
the concepts it contains using the <code><a
href="http://www.w3.org/TR/skos-reference#inScheme">skos:inScheme</a></code>
property:</p>
<pre class="code">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.</pre>

<p>In order to provide an efficient access to the entry points of
broader/narrower concept hierarchies, SKOS defines a <code><a
href="http://www.w3.org/TR/skos-reference#hasTopConcept">skos:hasTopConcept</a></code>
property. This property allows one to link a concept scheme to the (possibly
many) most general concepts it contains, as in the (continued) animal
thesaurus example:</p>
<pre class="code">ex:animalThesaurus rdf:type skos:ConceptScheme;
  skos:hasTopConcept ex:mammals;
  skos:hasTopConcept ex:fish.</pre>

<p>Concept schemes are designed to represent traditional vocabularies, and
designers are encouraged to follow existing KOS guidelines (e.g., [<cite><a
href="#ISO2788">ISO2788</a></cite>] or [<cite><a
href="#BS8723-2">BS8723-2</a></cite>]) when compiling a SKOS concept scheme.
For example, as described in <a href="#seclabel">Section 2.2</a>, it is
recommended that no two concepts have the same preferred lexical label in a
given language when they belong to the same concept scheme.</p>

<p>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. <a
href="http://www.w3.org/TR/skos-reference#L2497">Section 4.6</a> of the
<cite>SKOS Reference</cite> [<cite><a
href="#SKOS-REFERENCE">SKOS-REFERENCE</a></cite>] gives an account of these
differences. One important feature of SKOS is that it is possible for the
same concept to be linked to several concept schemes, using the
<code>skos:inScheme</code> property. This will be discussed in the next
section.</p>

<p>Finally, it is important to notice that the SKOS vocabulary only offers
limited support for containment of KOS information in a concept scheme.
<code>skos:inScheme</code> and <code>skos:hasTopConcept</code> link concept
schemes and concepts. Yet, there is no mechanism in SKOS to record that a
specific statement concerning these concepts, e.g. a
<code>skos:broader</code> assertion, pertains to a specific concept scheme,
whereas a KOS is usually seen as consisting of both its concepts and the
links that define them. The interested reader is referred to <a
href="#secskoscontainment">Section 5.3</a> for a discussion on this topic.</p>
<hr>

<h2 id="secnetworking">3 Networking Knowledge Organization Systems on the
Semantic Web</h2>

<p>Representing a KOS with SKOS not only serves as a publication mechanism,
but also allows it 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 SKOS features
that enable the interlinking of concept schemes and explains how to relate
conceptual resources to other resources on the Semantic Web. </p>
<hr>

<h3 id="secmapping">3.1 Mapping Concept Schemes</h3>

<p>Every SKOS concept is assigned a URI [<cite><a
href="#COOLURIS">COOLURIS</a></cite>], which makes it possible to
unambiguously reference a concept in any SKOS application. This can be
especially useful for establishing semantic relations between pre-existing
concepts. Such <em>mappings</em> are crucial for applications such as
information retrieval tools that use several KOSs at the same time, where
these KOSs have overlapping scopes and need to be semantically reconciled; <a
href="http://www.w3.org/TR/skos-ucr/#R-ConceptualMappingLinks">examples</a>
can be found in the <em>SKOS Use cases and Requirements</em> document
[<cite><a href="#SKOS-UCR">SKOS-UCR</a></cite>].</p>

<p>A crucial feature of mapping is the possibility to state that two concepts
from different schemes have comparable meanings, and to specify how these
meanings compare, even though they come from different contexts and possibly
follow different modeling principles [<cite><a
href="#BS8723-4">BS8723-4</a></cite>]. Conceptual mappings are expected to be
a key advantage of making KOSs available on the Semantic Web using SKOS. </p>

<p>SKOS provides several properties that map concepts between different
concept schemes. This can be done by asserting that two concepts have a
similar meaning, using the <code><a
href="http://www.w3.org/TR/skos-reference#exactMatch">skos:exactMatch</a></code>
and <a
href="http://www.w3.org/TR/skos-reference#exactMatch"><code>skos:closeMatch</code></a>
properties. Two concepts from different concept schemes can also be mapped
using properties that parallel the semantic relations introduced in <a
href="#secrel">Section 2.3</a>: <code><a
href="http://www.w3.org/TR/skos-reference#broadMatch">skos:broadMatch</a></code>,
<code><a
href="http://www.w3.org/TR/skos-reference#narrowMatch">skos:narrowMatch</a></code>
and <code><a
href="http://www.w3.org/TR/skos-reference#relatedMatch">skos:relatedMatch</a></code>.</p>

<p>Consider the following example, where two concept schemes represent
different views on animals:</p>
<pre class="code">ex1:referenceAnimalScheme rdf:type skos:ConceptScheme;
   dct: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;
   dct: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.</pre>

<p>It is possible to map the concepts in
<code>ex1:referenceAnimalScheme</code> to the concepts in
<code>ex2:eggSellerScheme</code> by using the mapping assertions below:</p>
<pre class="code"> ex1:platypus skos:broadMatch ex2:eggLayingAnimals.
 ex1:platypus skos:relatedMatch ex2:eggs.
 ex1:animal skos:exactMatch ex2:animals.</pre>

<p>A <code>skos:closeMatch</code> assertion indicates that two concepts are
sufficiently similar that they can be used interchangeably in applications
that consider the two concept schemes they belong to. However,
<code>skos:closeMatch</code> is not defined as transitive, which prevents
such similarity assessments to propagate beyond these two schemes. If a
concept <code>ex1:A</code> is a close match for another concept
<code>ex2:B</code> which is itself a close match for <code>ex3:C</code>, it
<strong>does not</strong> follow from the SKOS data model that
<code>ex1:A</code> is a close match for <code>ex3:C</code>.</p>

<p><code>skos:exactMatch</code> also indicates semantic similarity—it is a
sub-property of <code>skos:closeMatch</code>. However, it denotes an even
higher degree of closeness: the two concepts have equivalent meaning, and the
link can be exploited across a wider range of applications and schemes.
<code>skos:exactMatch</code> is indeed transitive: if a concept
<code>ex1:A</code> is an exact match for another concept <code>ex2:B</code>
which is itself an exact match for <code>ex3:C</code>, it
<strong>does</strong> follow from the SKOS data model that <code>ex1:A</code>
is an exact match for <code>ex3:C</code>.</p>

<p class="note"><strong>Note on <code>skos:exactMatch</code> vs.
<code>owl:sameAs</code>:</strong> SKOS provides <code>skos:exactMatch</code>
to map concepts with equivalent meaning, and intentionally does not use
<code><a
href="http://www.w3.org/TR/owl-ref/#sameAs-def">owl:sameAs</a></code> from
the OWL ontology language [<cite><a href="#OWL-REFERENCE">OWL</a></cite>].
When two resources are linked with <code>owl:sameAs</code> they are
considered to be the same resource, and triples involving these resources are
merged. This does not fit what is needed in most SKOS applications. In the
above example, <code>ex1:animal</code> is said to be equivalent to
<code>ex2:animals</code>. If this equivalence relation were represented using
<code>owl:sameAs</code>, the following statements would hold for
<code>ex:animal</code>:</p>
<pre class="notecode">ex1:animal rdf:type skos:Concept;
   skos:prefLabel "animal"@en;
   skos:inScheme ex1:referenceAnimalScheme.
   skos:prefLabel "animals"@en;
   skos:inScheme ex2:eggSellerScheme.</pre>

<p class="note">This would make <code>ex:animal</code> inconsistent, as a
concept cannot possess two different preferred labels in the same language.
Had the concepts been assigned other information, such as semantic
relationships to other concepts, or notes, these would be merged as well,
causing these concepts to acquire new meanings.</p>

<p>By convention, mapping properties are used to represent links that have
the same intended meaning as the "standard" semantic properties, but with a
different application scope. One might say that mapping relationships are
less <em>inherent</em> to the meaning of the concepts they involve. From the
point of view of the original designer of a mapped KOS, they might even
sometimes be wrong.</p>

<p>Mapping properties are expected to be useful in <em>specific</em>
applications that use multiple, conceptually overlapping KOSs. By convention,
mapping relationships are expected to be asserted between concepts that
belong to different concept schemes. </p>

<p>The reader should be aware that according to the SKOS data model, the
mapping properties that "mirror" a given semantic relation property are also
sub-properties of it in the RDFS sense. For instance,
<code>skos:broadMatch</code> is a sub-property of <code>skos:broader</code>.
Consequently, every assertion of <code>skos:broadMatch</code> between two
concepts leads by inference to asserting a <code>skos:broader</code> between
these concepts.</p>
<hr>

<h3 id="secextension">3.2 Re-using and Extending Concept Schemes</h3>

<p>Linking concepts by means of mappings is not the only way to interlink
concept schemes. 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 by declaring any new concepts that may be needed and simply
<em>linking</em> to concepts that have already been defined in the existing
scheme.</p>

<p>Extension of a KOS can be especially useful when its designers (or
third-party KOS publishers) want to achieve a better coverage of a domain or
sub-domain, while following the principles that guided the design of the
existing KOS—e.g., by re-using some of its concepts. Explicit KOS extension
and re-use can also be used as a modularization mechanism, when a family of
articulated KOSs (for instance microthesauri that belong to an overarching
vocabulary) is designed to cover several domains and its designers want to
allow specific applications to operate on given subsets of concepts.</p>

<p>A new concept scheme can re-use existing concepts using the <code><a
href="http://www.w3.org/TR/skos-reference#inScheme">skos:inScheme</a></code>
property. Consider the example below, where a first concept scheme for
animals defines a concept for "cats":</p>
<pre class="code">ex1:referenceAnimalScheme rdf:type skos:ConceptScheme;
   dct:title "Reference list of animals"@en.
ex1:cats rdf:type skos:Concept;
   skos:prefLabel "cats"@en;
   skos:inScheme ex1:referenceAnimalScheme.</pre>

<p>The creator of another concept scheme devoted to cat descriptions can
freely include the reference <code>ex1:cats</code> concept in her scheme, and
then reference it as follows:</p>
<pre class="code">ex2:catScheme rdf:type skos:ConceptScheme;
   dct:title "The Complete Cat Thesaurus"@en.

ex1:cats skos:inScheme ex2:catScheme.

ex2:abyssinian rdf:type skos:Concept;
   skos:prefLabel "Abyssinian Cats"@en;
   skos:broader ex1:cats;
   skos:inScheme ex2:catScheme.

ex2:siamese rdf:type skos:Concept;
   skos:prefLabel "Siamese Cats"@en;
   skos:broader ex1:cats;
   skos:inScheme ex2:catScheme.</pre>

<p>Note that the information source defining the new concept scheme does not
replicate information about the <code>ex1:cats</code> concept, such as its
preferred label. Assuming <code>ex1:cats</code> has been published, a
Semantic Web application is able to retrieve the information for this concept
by simply resolving the concept's URI
(<code>http://www.example.com/1/cats</code>).</p>

<p class="note"><strong>Note on <code>owl:imports</code> and re-using
KOSs</strong>: The <code><a
href="http://www.w3.org/TR/owl-ref/#imports-def">owl:imports</a></code>
property provides a mechanism for importing the assertions of one OWL
ontology into another. <code>owl:imports</code> may be used with SKOS
vocabularies to provide a special case of re-use/extension where a concept
scheme "imports" another concept scheme as a whole. To continue the example
above, this is achieved by including the following statement in the source
defining <code>ex2:catScheme</code>:</p>
<pre class="notecode">ex2:catScheme owl:imports ex1:referenceAnimalScheme.</pre>

<p class="note">Using <code>owl:imports</code> in this way has some
ramifications. First, the domain and range of <code>owl:imports</code> is
<code>owl:Ontology</code>, while <code>skos:ConceptScheme</code> is defined
as an <code>owl:Class</code>. Thus asserting that a concept scheme imports
another via <code>owl:imports</code> leads to the consequence that the
instances of <code>skos:conceptScheme</code> involved in the import are also
inferred to be instances of <code>owl:Ontology</code>. This in turn results
in an OWL Full ontology (due to the dual use of a URI as a class and
ontology, see <a
href="http://www.w3.org/TR/owl-semantics/mapping.html#4.2">Section 4.2</a> of
the <em>OWL Semantics</em> document [<cite><a
href="#OWL-SEMANTICS">OWL-SEMANTICS</a></cite>]).</p>

<p class="note">Second, under the OWL Full semantics (see <a
href="http://www.w3.org/TR/owl-semantics/rdfs.html#5.3">Section 5.3</a> of
the <em>OWL Semantics</em> [<cite><a
href="#OWL-SEMANTICS">OWL-SEMANTICS</a></cite>]), the intended interpretation
of <code>owl:imports</code> is that the RDF graph retrieved from the imported
URI is added to the importing graph. Users should be aware of this, and any
alternative interpretations should be avoided. In particular, there is no
logical dependency between <code>skos:inScheme</code> and
<code>owl:imports</code>: the use of <code>owl:imports</code> will not result
in the presence of any <code>skos:inScheme</code> statements other than the
ones already asserted in the imported graph. If we consider the example
above, <code>owl:imports</code> has been used to state that one concept
scheme logically imports another. But even though
<code>ex1:referenceAnimalScheme</code> contains the triple</p>
<pre class="notecode">ex1:Elephant skos:inScheme ex1:referenceAnimalsScheme.</pre>

<p class="note">the triple</p>
<pre class="notecode">ex1:Elephant skos:inScheme ex2:catScheme.</pre>

<p class="note">should <strong>not</strong> be inferred to be present in the
graph defining <code>ex2:catScheme</code>.</p>

<p class="note">If an application is concerned with practical provenance or
ownership information, additional steps may be required in order to maintain
the provenance or assert the authority of imported triples, as mentioned in
<a href="#secskoscontainment">Section 5.3</a>.</p>
<hr>

<h3 id="secindexing">3.3 Subject Indexing and SKOS</h3>

<p>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, such as 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.</p>

<p>While the SKOS vocabulary itself does not include a mechanism for
associating an arbitrary resource with a <code>skos:Concept</code>,
implementors can turn to other vocabularies. Dublin Core, for instance,
provides a <code><a
href="http://purl.org/dc/terms/subject">dct:subject</a></code> property
[<cite><a href="#DC">DC</a></cite>]:</p>
<pre class="code">ex1:platypus rdf:type skos:Concept;
   skos:prefLabel "platypus"@en.

&lt;http://en.wikipedia.org/wiki/Platypus&gt; rdf:type foaf:Document;
   dct:subject ex1:platypus.</pre>

<p>Note that a single resource can have several subjects, and hence be
involved in several <code>dct:subject</code> statements. These subjects can
clearly come from different concept schemes, resulting for instance from a
distributed annotation process.</p>
<hr>

<h2 id="secadvanced">4 Advanced SKOS: When KOSs are not Simple Anymore</h2>

<p>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 modeling approaches. These
are especially designed to meet requirements which were raised in the
<cite>SKOS Use Cases and Requirements</cite> [<cite><a
href="#SKOS-UCR">SKOS-UCR</a></cite>], but which were only present in a
smaller number of use cases:</p>
<ul>
  <li>Grouping of concepts based on specific criteria,</li>
  <li>Advanced documentation by means of complex resources,</li>
  <li>Establishing relationships between labels of concepts,</li>
  <li>Creation of complex concepts from simple ones (coordination),</li>
  <li>Accessing transitive hierarchical relationships,</li>
  <li>Representing notations for concepts.</li>
</ul>

<p>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.</p>
<hr>

<h3 id="seccollections">4.1 Collections of Concepts</h3>

<p>SKOS makes it possible to define meaningful groupings or "collections" of
concepts. Such groupings are normally rendered in thesauri as in the
following example:</p>
<pre>milk
  &lt;milk by source animal&gt;
    cow milk
    goat milk
    buffalo milk</pre>

<p>These collections can be used to represent "arrays" in thesaurus
terminology, in which the term "milk by source animal" is a "node label"
[<cite><a href="#WillpowerGlossary">WillpowerGlossary</a></cite>]. There is
consensus that a node label does <strong>not</strong> represent a label for a
concept in its own right. Therefore, specific entities have to be introduced
to represent them.</p>

<h4 id="seclabelledcollections">Labeled Collections</h4>

<p>To correctly model such concept collection structures, SKOS introduces a
<code><a
href="http://www.w3.org/TR/skos-reference#Collection">skos:Collection</a></code>
class. Instances of this class group specific concepts by means of the
<code><a
href="http://www.w3.org/TR/skos-reference#member">skos:member</a></code>
property, as in the following example:</p>
<pre class="code">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.</pre>

<p>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, <code>skos:prefLabel</code> has been
used to assign a lexical label to the Collection, as this property (as other
SKOS labeling properties) can be used with non-conceptual resources.</p>

<h4 id="secorderedcollections">Ordered Collections</h4>

<p>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 <code><a
href="http://www.w3.org/TR/skos-reference#OrderedCollection">skos:OrderedCollection</a></code>
class is used, together with the <code><a
href="http://www.w3.org/TR/skos-reference#memberList">skos:memberList</a></code>
property. This property links an instance of
<code>skos:OrderedCollection</code> to a (possibly blank) node of type
<code>rdf:List</code>, following the pattern that enables the definition of
<a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#collections">RDF
collections</a> [<cite><a href="#RDF-PRIMER">RDF-PRIMER</a></cite>]. For
example:</p>
<pre class="code">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:OrderedCollection;
   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.</pre>

<h4 id="seccollectionsanddisplay">SKOS Collections, Semantic Relations and
Systematic Displays</h4>

<p>Note that, according to the SKOS data model, collections are disjoint from
concepts. It is therefore impossible to use SKOS semantic relations (see <a
href="#secrel">Section 2.3</a>) 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 <code>ex:milk</code> using the
<code>skos:broader</code> property:</p>
<pre class="code">ex:cowMilk skos:broader ex:milk.
ex:goatMilk skos:broader ex:milk.
ex:buffaloMilk skos:broader ex:milk.</pre>

<p>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 <code>skos:broader</code> 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. </p>

<p>One may wonder whether using collections is desirable, as they add
complexity to the representations applications have to manipulate. In fact,
for some cases, e.g. when KOSs are mainly intended as navigation hierarchies,
it seems more intuitive to represent "node labels" or "guide terms" as
instances of <code>skos:Concept</code>, and to use normal semantic
relationships for linking them to other concepts. Take the following variant
of the "milk" example:</p>
<pre class="code">ex3:milkBySourceAnimal rdf:type skos:Concept;
   skos:prefLabel "milk by source animal"@en;
   skos:broader ex3:milk;
   skos:narrower ex3:cowMilk;
   skos:narrower ex3:goatMilk;
   skos:narrower ex3:buffaloMilk.</pre>

<p>The choice between the two representation options remains open, depending
on the application at hand. Readers should however be aware that not using
collections, even if that is more intuitive, may result in a harmful loss of
semantic accuracy. For many description applications, for instance, "node
labels" are entities of a really specific nature, and must not be used as
object indices alongside "normal" concepts. Representing them as mere
concepts is therefore clearly not a best practice.</p>
<hr>

<h3 id="secadvanceddocumentation">4.2 Advanced Documentation Features</h3>

<p>As shown in <a href="#secdocumentation">Section 2.4</a>, SKOS allows
concepts to be annotated by attaching various notes to them. It is worth
noticing that the <a href="http://www.w3.org/TR/skos-reference/#L1879">SKOS
Reference</a> does not restrict the range of resources that assertions can
use in the object position. This leads to different usage patterns, three of
which are explained—and recommended—in this document.</p>
<strong>Documentation as an RDF literal</strong>

<p>Here, documentation statements have simple RDF literals as objects, as
illustrated by <em>all</em> examples of <a href="#secdocumentation">Section
2.4</a>. This is the simplest way to document concepts, and it is expected to
fit most common applications. </p>
<strong>Documentation as a Related Resource Description </strong>

<p>In this second pattern, the object of a documentation statement consists
of a general non-literal RDF node—that is, a resource node (possibly blank)
that can be the subject of further RDF statements [<cite><a
href="#RDF-PRIMER">RDF-PRIMER</a></cite>]. This is especially useful to
represent with RDF more information about the documentation itself, such as
its creator or creation date. This is typically done using the RDF <a
href="http://www.w3.org/TR/rdf-primer/#rdfvalue">rdf:value</a> utility
property, as in the following example, which uses a blank node:</p>
<pre class="code">ex:tomato skos:changeNote [
  rdf:value "Moved from under 'fruits' to under 'vegetables'"@en;
  dct:creator ex:HoraceGray;
  dct:date "1999-01-23"
].
ex:HoraceGray rdf:type foaf:Person; foaf:name "Horace Gray".</pre>

<p><strong>Documentation as a Document Reference </strong></p>

<p>A third option consists of introducing, as the object of a documentation
statement, the URI of a <em>document</em>, for instance a Web page. Note that
this pattern, closely related to the previous one, also allows the definition
of further metadata for this document using RDF:</p>
<pre class="code">ex:zoology skos:definition ex:zoology.txt.
ex:zoology.txt dct:creator ex:JohnSmith.</pre>
<hr>

<h3 id="secrelationshipslabels">4.3 Relationships between Labels</h3>

<p>Some applications require the creation of explicit links between the
labels associated with concepts. For example, consider the relationship
between a preferred label for a concept "Corporation" and its abbreviation
"Corp." coined as an alternative label, or a translation link between two
labels in different languages: <code>"Cow"@en</code> and
<code>"Vache"@fr</code>. The use of SKOS lexical labeling properties, e.g.
<code>skos:prefLabel</code>, 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.</p>

<p>To solve this representation issue, the SKOS vocabulary has been augmented
with an optional extension for labels, <a
href="http://www.w3.org/TR/skos-reference#xl">SKOS-XL</a> [<cite><a
href="#SKOS-REFERENCE">SKOS-REFERENCE</a></cite>]. This extension introduces
a <code><a
href="http://www.w3.org/TR/skos-reference#xl-Label">skosxl:Label</a></code>
class that allows labels to be treated as first-order RDF resources. Each
instance of this class shall first be attached to a single RDF literal via
the <code>skosxl:literalForm</code> property. Consider the example where the
concept "Food and Agriculture Organization" is labeled by both the official
name and the acronym of the institution. The two labels can be represented in
the following way:</p>
<pre class="code">ex:FAOlabel1 rdf:type skosxl:Label;
  skosxl:literalForm "Food and Agriculture Organization"@en.
ex:FAOlabel2 rdf:type skosxl:Label;
  skosxl:literalForm "FAO"@en.</pre>

<p><code>skosxl:Label</code> instances can then be related to concepts using
properties (<code><a
href="http://www.w3.org/TR/skos-reference/#L5981">skosxl:prefLabel</a></code>,
<code><a
href="http://www.w3.org/TR/skos-reference/#L5981">skosxl:altLabel</a></code>,
<code><a
href="http://www.w3.org/TR/skos-reference/#L5981">skosxl:hiddenLabel</a></code>)
that mirror the standard <a href="#seclabel">literal-based labeling
constructs</a>. Finally, these instances can be linked together by <code><a
href="http://www.w3.org/TR/skos-reference/#L7196">skosxl:labelRelation</a></code>
statements:</p>
<pre class="code">ex:FAO rdf:type skos:Concept;
  skosxl:prefLabel ex:FAOlabel1;
  skosxl:altLabel ex:FAOlabel2.
ex:FAOlabel2 skosxl:labelRelation ex:FAOlabel1.</pre>

<p>Such a solution is however not complete: an "acronym-sensitive"
application would miss the actual information that the two labels are indeed
in an <em>acronymy</em> relationship. Such an application would also miss the
<em>direction</em> of the link. SKOS-XL users are therefore encouraged to
specialize <code>skosxl:labelRelation</code> so as to fit their
application-specific requirements, as in the following:</p>
<pre class="code">ex:isAcronymOf rdfs:subPropertyOf skosxl:labelRelation.
ex:FAOlabel2 ex:isAcronymOf ex:FAOlabel1.</pre>

<p>Note that the SKOS-XL data model ensures that using such a pattern remains
compatible with the standard SKOS labeling practice. If an instance of
<code>skosxl:Label</code> is attached to a concept by, say, a
<code>skosxl:altLabel</code> statement, it follows from the SKOS-XL data
model that the literal form of the <code>skosxl:Label</code> instance is
related to this concept by a standard <code>skos:altLabel</code> statement.
In the above example, <code>ex:FAO</code> therefore has
<code>"FAO"@en"</code> as alternative (literal) label.</p>
<hr>

<h3 id="secconceptcoordination">4.4 Coordinating Concepts </h3>

<p>Indexing practices involving thesauri and other KOSs often include the
notion of <em>coordination</em>. Coordination is an activity in which
concepts from a KOS are combined. In general there are two kinds of
coordination: <a
href="http://www.willpowerinfo.co.uk/glossary.htm#pre-coord">pre-coordination</a>
and <a
href="http://www.willpowerinfo.co.uk/glossary.htm#post-coord">post-coordination</a>
[<cite><a href="#WillpowerGlossary">WillpowerGlossary</a></cite>]. The key
distinction between the two hinges on when the actual coordination occurs in
relation to an information retrieval event.</p>

<p>Pre-coordination is done prior to information retrieval, by a KOS
maintainer, or by an indexer who is using a KOS—for example, if an indexer
takes two existing concepts from a concept scheme, such as "Bicycles" and
"Repairing", and explicitly combines them with a given syntax such as
"Bicycles--Repairing" to index a particular document.</p>

<p>Post-coordination on the other hand is performed as part of an information
retrieval task—for example, if a given document is indexed with two
distinct concepts "Bicycles" and "Repairing" and a user decides to perform a
search for all documents that are indexed with "Bicycles" and "Repairing".</p>

<p>Post-coordination as an information retrieval activity lends itself to
<em>indirect</em> representation as a SPARQL query to access RDF data
[<cite><a href="#SPARQL">SPARQL</a></cite>]. For example, given two distinct
concepts:</p>
<pre class="code">ex:bicycles skos:prefLabel "Bicycles"@en.
ex:repairing skos:prefLabel "Repairing"@en.</pre>

<p>one could construct a SPARQL query to return only the documents that are
indexed with both concepts</p>
<pre class="code">SELECT ?document
WHERE {
  ?document dct:subject ex:bicycles.
  ?document dct:subject ex:repairing.
}</pre>

<p>However the SKOS vocabulary itself does not provide any mechanism for
expressing that a given concept consists of a pre-coordination of other
concepts. Of course it is perfectly feasible to <a
href="#secskosspecialization">extend SKOS</a> to establish a pattern for
representing coordinated concepts. For example it has been <a
href="http://isegserv.itd.rl.ac.uk/public/skos/press/dc2006/coordination.html">suggested</a>
that a new property such as <code>ex:coordinationOf</code> could be
established:</p>
<pre class="code">ex:coordinationOf a rdf:Property;
  rdfs:domain skos:Concept;
  rdfs:range rdf:List.</pre>

<p>which could then be used in assertions such as:</p>
<pre class="code">ex:bicyclesRepairing a skos:Concept;
  ex:coordinationOf (ex:bicycles ex:repairing);
  skos:prefLabel "Bicycles--Repairing"@en.</pre>

<p>It has also been suggested that OWL itself could be used to coordinate
concepts:</p>
<pre class="code">ex:bicyclesRepairing a skos:Concept;
  owl:intersectionOf (ex:bicycles ex:repairing);
  skos:prefLabel "Bicycles--Repairing"@en.</pre>

<p>However, established patterns for pre-coordinations of this kind have not
yet emerged in the SKOS community. <code>ex:coordinationOf</code> (or some
equivalent extension), and the ramifications of <a href="#secskosowl">using
SKOS with OWL</a> have not been explored fully enough yet to warrant
inclusion in the SKOS vocabulary. Rather than commit to a design pattern that
has not been proven useful, the Semantic Web Deployment Group decided to
postpone the issue of <a
href="http://www.w3.org/2006/07/SWD/track/issues/40">coordination</a>, to
allow extension patterns to organically emerge as SKOS is deployed. The hope
is that as successful patterns are established, they can be published on the
Web as an <a href="#secskosspecialization">extension vocabulary to SKOS</a>
and documented as a W3C Note or some equivalent.</p>
<hr>

<h3 id="sectransitivebroader">4.5 Transitive Hierarchies</h3>

<p>As described in <a href="#sechierarchy">Section 2.3.1</a>, the properties
used to represent KOS hierarchies, <code>skos:broader</code> and
<code>skos:narrower</code>, are not defined as transitive. As shown in Fig.
4.5.1 (i) &amp; (ii), this means that their semantics do <strong>not</strong>
support inferences of the type: <em>if "animals" is broader than "mammals"
and "mammals" is broader than "cats", then "animals" is broader than
"cats"</em>. </p>

<p class="caption">Figure 4.5.1: <code>skos:broader</code> is not
transitive</p>

<p align="center"><img alt="skos:broader is not transitive"
src="./broaderNonTransitive.jpg" height="217" width="588"></p>

<p class="caption">Dotted arrows represent statements inferred from the SKOS
data model.<br>
Solid arrows represent asserted statements.</p>

<p>For the applications that require such semantics—for instance to perform
query expansion—SKOS features two specific properties, <code><a
href="http://www.w3.org/TR/skos-reference#broaderTransitive">skos:broaderTransitive</a></code>
and <code><a
href="http://www.w3.org/TR/skos-reference#narrowerTransitive">skos:narrowerTransitive</a></code>.
These are defined as transitive super-properties of <code>skos:broader</code>
and <code>skos:narrower</code> [<cite><a
href="#SKOS-REFERENCE">SKOS-REFERENCE</a></cite>]. This pattern enables,
using a Semantic Web inferencing tool, access to the "transitive closure" of
a hierarchy expressed with <code>skos:broader</code> and
<code>skos:narrower</code>.</p>

<p>Consider the example of Fig. 4.5.1 (i):</p>
<pre class="code">ex:animals skos:prefLabel "animals"@en.
ex:mammals skos:prefLabel "mammals"@en;
  skos:broader ex:animals.
ex:cats skos:prefLabel "cats"@en;
  skos:broader ex:mammals.</pre>

<p>When reading the above triples, a reasoner makes use the definition of
<code>skos:broaderTransitive</code> as a super-property of
<code>skos:broader</code> to infer the following statements:</p>
<pre class="code">ex:cats skos:broaderTransitive ex:mammals.
ex:mammals skos:broaderTransitive ex:animals.</pre>

<p>The transitivity of <code>skos:broaderTransitive</code> then causes the
desired statement to be inferred:</p>
<pre class="code">ex:cats skos:broaderTransitive ex:animals.</pre>

<p>These two steps are showed in the following figure:</p>

<p class="caption">Figure 4.5.2: inferring a transitive hierarchy from
asserted <code>skos:broader</code> statements</p>

<p align="center"><img
alt="Inferring a transitive hierarchy from asserted skos:broader statements"
src="./broaderTransitive.jpg" height="279" width="589"></p>

<p class="caption">Dotted arrows represent statements inferred from the SKOS
data model.<br>
Solid arrows represent asserted statements.</p>

<p>The use of the <code>skos:broaderTransitive</code> super-property allows
communities of practice to exploit transitive interpretations of hierarchical
networks as they see fit, while not interfering with the semantics of
<code>skos:broader</code>, which cannot enforce such transitivity.
Intuitively, one can interpret <code>skos:broader</code> statements as
explicitly asserted <em>direct parent</em> links, while
<code>skos:broaderTransitive</code> is used to reflect more-general (and
possibly indirect) <em>ancestor</em> relationships.</p>

<p class="note"><strong>Note on supposed "transitiveness
inheritance":</strong> the super-property link between
<code>skos:broader</code> and <code>skos:broaderTransitive</code> may look
counter-intuitive at first glance. Here, a non-transitive property is defined
as a child of a transitive one, while not inheriting its transitiveness. This
is however fully compliant with <a href="">RDFS/OWL semantics</a> for
<code>rdfs:subPropertyOf</code> [<cite><a
href="#OWL-REFERENCE">OWL</a></cite>]: a property P is a sub-property of Q if
and only if every time P holds between two resources, then Q also holds
between them. This does not enforce any transitiveness inheritance: on the
contrary, the set of all couples of resources related by P (its
<em>graph</em>), as a subset of Q's, is likely to miss some of the couples
that make Q transitive. </p>
<hr>

<h3 id="secnotations">4.6 Notations</h3>

<p>Some KOSs, for example classification systems such as the Universal
Decimal Classification [<cite><a href="#UDC">UDC</a></cite>], use
<em>notations</em> (or <em>captions</em>) as the primary means of access to
the concepts they contain. Notations are symbols which are not normally
recognizable as words or sequences of words in any natural language and are
thus usable independently of natural-language contexts. They are typically
composed of digits, complemented with punctuation signs and other characters,
as in the following UDC example:</p>
<pre class="code">512 Algebra
512.6 Special branches of algebra</pre>

<p>SKOS allows notations to be represented in two ways, depending on the
priorities of the concept scheme publisher. The first, preferred technique is
to use the <code><a
href="http://www.w3.org/TR/skos-reference#notation">skos:notation</a></code>
property. This property allows a concept to be attached to an <a
href="http://www.w3.org/TR/REC-rdf-syntax/#typedliterals">RDF typed
literal</a>—a literal with an explicit datatype [<cite><a
href="#RDF-PRIMER">RDF-PRIMER</a></cite>]. The datatype of the literal
specifies a syntax encoding scheme, which fits the usage of notations in the
concerned KOS. The value of the literal is the notation itself (in this case
the classification code itself):</p>
<pre class="code">ex:udc512 skos:prefLabel "Algebra"@en ;
  skos:notation "512"^^ex:UDCNotation .</pre>

<p><a href="http://www.w3.org/TR/skos-reference#L2613">Section 6.5.1</a> of
the <cite>SKOS Reference</cite> gives more detail on how to handle datatypes
[<cite><a href="#SKOS-REFERENCE">SKOS-REFERENCE</a></cite>]. This approach
can be especially useful if a KOS publisher wants to provide users with
processing rules that are specific to the KOS's notation scheme. For
instance, many classification systems have specific syntax rules which allow
complex notations to be decomposed, leading to the linking of the
corresponding concept to other, simpler concepts. Also, this pattern can help
creators of SKOS tools and KOS publishers who want to have notations
displayed in a dedicated way. </p>

<p>However, the management of such datatypes can be cumbersome. Further, the
previous pattern is not really needed when publishers consider the notations
themselves to be simple language-independent labels. In such cases, it is
possible to use one SKOS labeling property, for instance
<code>skos:prefLabel</code>, without any language tag, as in:</p>
<pre class="code">ex:udc512 skos:prefLabel "Algebra"@en ;
  skos:notation "512"^^ex:UDCNotation ;
  skos:prefLabel "512" .</pre>

<p>Note that it is unlikely that notations represented in such a manner will
benefit from notation-specific mechanisms (such as display procedures) in
SKOS tools. By default, users should expect these notations to be treated, in
accordance with the SKOS model, as mere labels.</p>
<hr>

<h3 id="secskosspecialization">4.7 On Specializing the SKOS Model</h3>

<p>SKOS is intended to serve as a common denominator between different
modeling approaches. As such, the current vocabulary specification will allow
many existing KOSs to be ported to the Semantic Web. However, the great
variety of KOS models makes it impossible to capture every detail of these
models while still retaining the first "S" ("simple") in "SKOS".</p>

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

<p>This can mostly be done by <em>specializing</em> 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
<code>rdfs:subPropertyOf</code> and <code>rdfs:subClassOf</code> properties
from the RDF Schema vocabulary [<cite><a
href="#RDF-PRIMER">RDF-PRIMER</a></cite>]. </p>

<p>The example in <a href="#secrelationshipslabels">Section 4.3</a>
illustrates how <code>skosxl:labelRelation</code> can be specialized into a
semantically richer property devoted to acronym link representation. Other
uses are possible, such as creating different "flavors" of the properties
<code>skos:broader</code> and <code>skos:narrower</code>. Thesaurus standards
indeed identify a small number of kinds of hierarchical relation, such as
generic, part-whole, or instance-class [<cite><a
href="#ISO2788">ISO2788</a></cite>]. The SKOS approach allows an application
designer to create new properties to capture this distinction, and to declare
them as sub-properties of <code>skos:broader</code>:</p>
<pre class="code">ex:broaderGeneric rdfs:subPropertyOf skos:broader.
ex:broaderPartitive rdfs:subPropertyOf skos:broader.
ex:broaderInstantive rdfs:subPropertyOf skos:broader.</pre>

<p>Every <code>ex:broaderPartitive</code> statement between two concepts, for
instance, can be formally interpreted by a proper Semantic Web reasoning
engine. This interpretation will yield the inference of a
<code>skos:broader</code> statement between these concepts—a piece of
information which may then be exploited by basic SKOS tools.</p>

<p class="note"><strong>Note on tampering with the SKOS vocabulary
itself:</strong> In general, it is best to avoid stating triples where a URI
from the SKOS vocabulary is in the <em>subject</em> position. By doing so,
one may alter the SKOS data model and introduce unwanted side effects. This
may then compromise the interoperability of vocabularies. If one wants to
adapt the behavior of the "built-in" vocabulary to specific cases, one should
first consider introducing one's own constructs as sub-classes or
sub-properties.</p>

<p>Of course the creators of extensions to SKOS are encouraged to publish
them, e.g., using the SKOS <a
href="http://lists.w3.org/Archives/Public/public-esw-thes">public mailing
list</a> (<a
href="mailto:public-esw-thes@w3.org">public-esw-thes@w3.org</a>). Such
extensions might correspond to shared concerns and thus be re-usable across
different applications. In turn, re-use is likely to bring community
feedback, helping to enhance the quality of published extensions.</p>
<hr>

<h2 id="seccombining">5 Combining SKOS with other Modeling Approaches</h2>

<p>As seen above, SKOS is an RDF/OWL vocabulary which can be seamlessly
extended to fit specific requirements. Likewise, SKOS features can also be
used on the Semantic Web as a complement to other modeling vocabularies. This
section gives examples of re-using SKOS labeling properties to describe
resources that are not necessarily SKOS concepts. It then deals with the
specific problem of articulating SKOS concepts with <em>classes</em> as
defined by the ontology language OWL.</p>

<p class="note"><strong>Note:</strong> this section deals with the issues
arising when an application requires SKOS features to be used in coordination
with other modeling approaches. Users not having such a requirement may skip
it.</p>

<h3 id="seclabelsoutsideSKOS">5.1 Use of Labels Outside of SKOS</h3>

<p>It is possible to use SKOS labeling properties to label resources that are
not of type <code>skos:Concept</code>. Consider these triples that describe
Tim Berners-Lee:</p>
<pre><code>&lt;http://www.w3.org/People/Berners-Lee/card#i&gt; rdf:type foaf:Person;
  foaf:name "Timothy Berners-Lee";
  rdfs:label "TBL";
  skos:prefLabel "Tim Berners-Lee"@en.</code></pre>

<p>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 <code><a
href="http://www.w3.org/TR/rdf-schema/#ch_label">rdfs:label</a></code> "TBL"
or the <code><a
href="http://xmlns.com/foaf/spec/#term_name">foaf:name</a></code> "Timothy
Berners-Lee"—these labels are compatible because <code>foaf:name</code> is
a sub-property of <code>rdfs:label</code>. </p>

<p>Another example is human-readable labels on classes, properties and
individuals in OWL ontologies, which are normally expressed using
<code>rdfs:label</code> alone. Consider the following triples that describe
humans:</p>
<pre class="code">ex:Human rdf:type owl:Class;
  rdfs:label "human"@en;
  rdfs:label "man"@en.</pre>

<p>An application would have difficulty determining the correct label to
display to the user since both labels have the same weight. The semantics of
<code>skos:prefLabel</code> allow implementors to explicitly define the
preferred label for a given resource. In general the ability to reuse
vocabulary elements from SKOS and other RDF vocabularies as needed is what
gives RDF much of its expressive power.</p>
<hr>

<h3 id="secskosowl">5.2 SKOS Concepts and OWL Classes</h3>

<p>The <a href="http://www.w3.org/TR/skos-reference/#L1289">SKOS
Reference</a> defines <code>skos:Concept</code> as an OWL class [<cite><a
href="#SKOS-REFERENCE">SKOS-REFERENCE</a></cite>]: </p>
<pre>skos:Concept rdf:type owl:Class.</pre>

<p>Thus, instances of <code>skos:Concept</code> (e.g.
<code>ex:Painting</code> in an art vocabulary) are in OWL terms
individuals.</p>
<pre class="code">ex:Painting rdf:type skos:Concept.</pre>

<p>This raises the question whether a SKOS concept instance such as
<code>ex:Painting</code> can be treated as a class in its own right. For
example, can users define properties of <code>ex:painting</code> such as
<code>ex:support</code>: </p>
<pre class="code">ex:support rdf:type owl:DatatypeProperty.
ex:support rdfs:domain ex:Painting.</pre>

<p>One might ask the question: why would someone want to do this? Well,
conceptually a class such as <code>skos:Concept</code> 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 supports or that cheese has a
country of origin.</p>

<p>It should be pointed out that SKOS does not take a stance with respect to
the flavor of OWL—OWL Full or OWL-DL [<cite><a
href="#OWL-REFERENCE">OWL-REFERENCE</a></cite>]—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: </p>
<pre class="code">ex:Painting rdf:type owl:Class.</pre>

<p>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 <em>OWL annotation
properties</em> to bridge them, provided they can create and use their own
extension for SKOS, as in: </p>
<pre class="code">ex:PaintingClass rdf:type owl:Class.
ex:PaintingConcept rdf:type skos:Concept.
ex:PaintingClass ex:correspondingConcept ex:PaintingConcept.</pre>

<p>Note that at the time of writing, the recently started <cite>OWL Working
Group</cite> [<cite><a href="#OWL-WG">OWL-WG</a></cite>] had been chartered
to handle (some forms of) metamodeling within a description-logic framework.
This might allow OWL-DL users to opt for patterns that are easier to
exploit.</p>

<p>Summarizing, the relationship between SKOS concepts and OWL
classes/individuals is as follows: </p>
<ul>
  <li>SKOS concepts are OWL individuals;</li>
  <li>SKOS does not take a stance on whether it must also be possible to
    treat SKOS concepts as OWL classes;</li>
  <li>The restrictions on OWL-DL prevent treating SKOS concepts as OWL
    classes;</li>
  <li>There is an expectation that an ongoing OWL revision will alleviate the
    latter problem by offering some form of metamodeling. </li>
</ul>
<hr>

<h3 id="secskoscontainment">5.3 SKOS, RDF Datasets and Information
Containment</h3>

<p>In a context of networked KOSs, some applications may require the
provenance or ownership of SKOS statements to be tracked, for instance for
trust purposes. A specific issue is how to establish explicit links between a
concept scheme and every piece of information that is stated in the original
KOS it represents, including for instance semantic relationships between
concepts. </p>

<p>Such functionality, albeit identified as a <a
href="http://www.w3.org/TR/skos-ucr/#R-ConceptSchemeContainment">candidate
requirement</a> [<cite><a href="#SKOS-UCR">SKOS-UCR</a></cite>], is currently
outside the scope of SKOS. In RDF, statements comes as context-free triples,
which makes it difficult to represent containment and provenance.</p>

<p>However, solutions for such problems have been proposed, such as named
graphs [<cite><a href="#NAMED-GRAPHS">NAMED-GRAPHS</a></cite>], and the use
of <a
href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#rdfDataset">RDF
Datasets</a> in SPARQL [<cite><a href="#SPARQL">SPARQL</a></cite>]. A SKOS
concept scheme can be related to an RDF Dataset, or even asserted to be such
a Dataset, which enables the creation of SPARQL queries dealing with some
form of provenance or containment. Continuing the example of <a
href="#secextension">Section 3.2</a>, and assuming that
<code>ex1:referenceAnimalScheme</code> and <code>ex2:catScheme</code> have
been managed as appropriate RDF Datasets (here, named graphs), the query</p>
<pre class="code">SELECT  ?x ?y
WHERE   {
  GRAPH ex2:catScheme { ?x skos:broader ?y }
}</pre>

<p>may return <code>(ex2:abyssinian, ex1:cat)</code> as a result, while this
tuple would not appear among the results of </p>
<pre class="code">SELECT  ?x ?
WHERE   {
   GRAPH ex1:referenceAnimalScheme { ?x skos:broader ?y }
}</pre>

<p>Readers should nevertheless be aware that these mechanisms have not been
widely used at the time of writing, and that different standard practices
could emerge in the future.</p>
<hr>

<h2 id="secref">References</h2>
<dl>
  <dt><a id="BS8723-2">[BS8723-2]</a></dt>
    <dd>BS 8723-2:2005 Structured vocabularies for information retrieval.
      Guide. Thesauri, British Standards Institution, London, 2005.</dd>
  <dt><a id="BS8723-4">[BS8723-4]</a></dt>
    <dd>BS 8723-4:2007 Structured vocabularies for information retrieval.
      Guide. Interoperability between vocabularies, British Standards
      Institution, London, 2007.</dd>
  <dt><a id="COOLURIS">[COOLURIS]</a></dt>
    <dd><cite><a
      href="http://www.w3.org/TR/2008/NOTE-cooluris-20081203/">Cool URIs for
      the Semantic Web</a></cite>, Leo Sauermann, Richard Cyganiak, Editors,
      W3C Interest Group Note, 3 December 2008. <a
      href="http://www.w3.org/TR/cooluris/">Latest version</a> available at
      http://www.w3.org/TR/cooluris/ .</dd>
  <dt><a id="DC">[DC]</a></dt>
    <dd><cite><a
      href="http://dublincore.org/documents/2008/01/14/dcmi-terms/">DCMI
      Metadata Terms</a></cite>, 14 January 2008. <a
      href="http://dublincore.org/documents/dcmi-terms/">Latest version</a>
      available at http://dublincore.org/documents/dcmi-terms/ . </dd>
  <dt><a name="ISO2788" id="ISO2788">[ISO2788]</a></dt>
    <dd><cite><a
      href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=7776">ISO
      2788:1986</a></cite> Documentation - Guidelines for the establishment
      and development of monolingual thesauri. Second edition. ISO TC 46/SC
      9, 1986.</dd>
  <dt><a name="ISO5964" id="ISO5964">[ISO5964]</a></dt>
    <dd><cite><a
      href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=12159">ISO
      5964:1985</a></cite> Documentation - Guidelines for the establishment
      and development of multilingual thesauri. First edition. ISO TC 46/SC
      9, 1985.</dd>
  <dt id="NAMED-GRAPHS">[NAMED-GRAPHS]</dt>
    <dd><cite>Named graphs, provenance and trust</cite>, Jeremy Carroll,
      Christian Bizer, Patrick Hayes, Patrick Stickler, WWW 2005.</dd>
  <dt id="RDF-XML-SYNTAX">[RDF/XML-SYNTAX]</dt>
    <dd><cite><a
      href="http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/">RDF/XML
      Syntax Specification (Revised)</a></cite>, Dave Beckett, Editor. W3C
      Recommendation, 10 February 2004. <a
      href="http://www.w3.org/TR/rdf-syntax-grammar/"
      title="Latest version of RDF/XML Syntax">Latest version</a> available
      at http://www.w3.org/TR/rdf-syntax-grammar/ .</dd>
  <dt id="RECIPES">[RECIPES]</dt>
    <dd><a
      href="http://www.w3.org/TR/2008/NOTE-swbp-vocab-pub-20080828/"><cite>Best
      Practice Recipes for Publishing RDF Vocabularies</cite></a>. Diego
      Berrueta, Jon Phipps. W3C Working Draft, 23 January 2008. <a
      href="http://www.w3.org/TR/swbp-vocab-pub/">Latest version</a>
      available at http://www.w3.org/TR/swbp-vocab-pub/ .</dd>
  <dt><a id="OWL-WG" name="OWL-WG">[OWL-WG]</a></dt>
    <dd><a href="http://www.w3.org/2007/OWL/"><cite>OWL Working
      Group</cite></a>, http://www.w3.org/2007/OWL/.</dd>
  <dt id="OWL-REFERENCE">[OWL]</dt>
    <dd><cite><a href="http://www.w3.org/TR/2004/REC-owl-ref-20040210/">OWL
      Web Ontology Language Reference</a></cite>, Mike Dean, Guus Schreiber,
      Editors, W3C Recommendation, 10 February 2004. <a
      href="http://www.w3.org/TR/owl-ref/"
      title="Latest version of OWL Reference">Latest version</a> available at
      http://www.w3.org/TR/owl-ref/ .</dd>
  <dt id="OWL-SEMANTICS">[OWL-SEMANTICS]</dt>
    <dd><cite><a
      href="http://www.w3.org/TR/2004/REC-owl-semantics-20040210/">OWL Web
      Ontology Language Semantics and Abstract Syntax</a></cite>, Peter F.
      Patel-Schneider, Patrick Hayes, Ian Horrocks, Editors, W3C
      Recommendation, 10 February 2004. <a
      href="http://www.w3.org/TR/owl-semantics/"
      title="Latest version of OWL Semantics">Latest version</a> available at
      http://www.w3.org/TR/owl-semantics/ .</dd>
  <dt id="RDF-PRIMER">[RDF-PRIMER]</dt>
    <dd><cite><a
      href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/">RDF
      Primer</a></cite>, Frank Manola, Eric Miller, Editors, W3C
      Recommendation, 10 February 2004. <a
      href="http://www.w3.org/TR/rdf-primer/"
      title="Latest version of RDF Primer">Latest version</a> available at
      http://www.w3.org/TR/rdf-primer/ .</dd>
  <dt id="RDF-CONCEPTS">[RDF-CONCEPTS]</dt>
    <dd><cite><a
      href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/">Resource
      Description Framework (RDF): Concepts and Abstract Syntax </a></cite>,
      Graham Klyne, Jeremy Carroll, Editors, W3C Recommendation, 10 February
      2004. <a href="http://www.w3.org/TR/rdf-concepts/"
      title="Latest version of RDF Concepts">Latest version</a> available at
      http://www.w3.org/TR/rdf-concepts/ .</dd>
  <dt><a id="RFC4646">[RFC4646]</a></dt>
    <dd><cite><a href="http://www.ietf.org/rfc/rfc4646.txt"
      class="reference-title">Tags for Identifying Languages</a></cite>, A.
      Phillips , M. Davis, Editors, September 2006. Available at
      http://www.ietf.org/rfc/rfc4646.txt .</dd>
  <dt><a id="SWBP-SKOS-CORE-GUIDE">[SWBP-SKOS-CORE-GUIDE]</a></dt>
    <dd><cite><a
      href="http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/">SKOS
      Core Guide</a></cite>, Alistair Miles, Dan Brickley, Editors, W3C
      Working Draft, 2 November 2005. <a
      href="http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/"
      title="Latest version of SKOS Core Guide">Latest version</a> available
      at http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/ .</dd>
  <dt><a id="SKOS-REFERENCE">[SKOS-REFERENCE]</a></dt>
    <dd><cite><a href="http://www.w3.org/TR/2009/REC-skos-reference-20090818/">SKOS
      Reference</a></cite>, Alistair Miles, Sean Bechhofer, Editors, W3C
      Recommendation, 18 August 2009. <a
      href="http://www.w3.org/TR/skos-reference"
      title="Latest version of SKOS Reference">Latest version</a> available
      at http://www.w3.org/TR/skos-reference .</dd>
  <dt><a id="SKOS-UCR">[SKOS-UCR]</a></dt>
    <dd><cite><a href="http://www.w3.org/TR/2009/NOTE-skos-ucr-20090818">SKOS Use Cases and
      Requirements</a></cite>, Antoine Isaac, Jon Phipps, Daniel Rubin,
      Editors, W3C Working Group Note, 18 August 2009. <a
      href="http://www.w3.org/TR/skos-ucr"
      title="Latest version of SKOS Use Cases and Requirements">Latest
      version</a> available at
      http://www.w3.org/TR/skos-ucr .</dd>
  <dt><a id="SPARQL">[SPARQL]</a></dt>
    <dd><cite><a
      href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/">SPARQL
      Query Language for RDF</a></cite>, Eric Prud'hommeaux, Andy Seaborne,
      Editors, W3C Working Draft, 15 January 2008. <a
      href="http://www.w3.org/TR/rdf-sparql-query/"
      title="Latest version of SPARQL Reference">Latest version</a> available
      at http://www.w3.org/TR/rdf-sparql-query/ .</dd>
  <dt><a id="SWBP-SKOS-CORE-SPEC">[SWBP-SKOS-CORE-SPEC]</a></dt>
    <dd><cite><a
      href="http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20051102/">SKOS
      Core Vocabulary Specification</a></cite>, 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/ .</dd>
  <dt><a id="SWD" name="SWD">[SWD]</a></dt>
    <dd><a href="http://www.w3.org/2006/07/SWD/"><cite>The Semantic Web
      Deployment Working Group</cite></a>, http://www.w3.org/2006/07/SWD/
    .</dd>
  <dt id="TURTLE">[TURTLE]</dt>
    <dd><a
      href="http://www.w3.org/TeamSubmission/2008/SUBM-turtle-20080114/"><cite>Turtle
      - Terse RDF Triple Language </cite></a>, David Beckett, Tim
      Berners-Lee. W3C Team Submission, 14 January 2008. <a
      href="http://www.w3.org/TeamSubmission/turtle/">Latest version</a>
      available at http://www.w3.org/TeamSubmission/turtle/ .</dd>
  <dt id="UDC">[UDC]</dt>
    <dd><cite><a href="http://www.udcc.org/">UDC - Universal Decimal
      Classification</a></cite>, UDC Consortium, http://www.udcc.org/ .</dd>
  <dt id="URI">[URI]</dt>
    <dd><cite><a href="http://tools.ietf.org/html/rfc3986">RFC 3986 - Uniform
      Resource Identifiers (URI): Generic Syntax</a></cite>, Tim Berners-Lee,
      Roy Fielding, Larry Masinter, IETF, January 2005. Available at
      http://tools.ietf.org/html/rfc3986 .</dd>
  <dt><a id="WillpowerGlossary">[WillpowerGlossary]</a></dt>
    <dd><cite><a href="http://www.willpowerinfo.co.uk/glossary.htm">Glossary
      of terms relating to thesauri and other forms of structured vocabulary
      for information retrieval</a></cite>, Stella Dextre Clarke, Alan
      Gilchrist, Ron Davies and Leonard Will,Willpower Information. Available
      at http://www.willpowerinfo.co.uk/glossary.htm .</dd>
</dl>
<hr>

<h2 id="secack">Acknowledgments</h2>

<p>The authors would like to thank Alistair Miles and Dan Brickley who edited
the SKOS Core Guide (which this Primer is largely based on); as well as Tom
Baker, Guus Schreiber and Sean Bechhofer who contributed significant portions
of this text. Semantic Web Deployment Group members Tom Baker, Margherita
Sini, Quentin Reul also provided extensive reviews during the publication
process.</p>

<p>This document is the result of extended discussions within the Semantic
Web Deployment Group as a whole. Working Group members not already mentioned
include (in alphabetical order): Ben Adida, Diego Berrueta, Jeremy Carroll,
Michael Hausenblas, Elisa Kendall, Vit Novacek, Jon Phipps, Clay Redding,
Daniel Rubin, Manu Sporny, and Ralph Swick.</p>

<p>Public comments (especially via the public-esw-thes@w3.org mailing list)
from the following individuals provided invaluable guidance, suggestions and
corrections: Mark van Assem, Stephen Bounds, Dan Brickley, Johan De Smedt,
Stella Dextre-Clarke, Alasdair Gray, Andrew Houghton, Simon Jupp, Carl
Mattocks, Emma McCulloch, Mikael Nilsson, Alan Ruttenberg, Aida Slavic, Simon
Spero, Doug Tudhope, Bernard Vatant, Jakob Voss, Leonard Will, Sue Ellen
Wright. </p>
<hr>

<h2 id="seccorrespondencesISO">Appendix. Correspondences between
ISO-2788/5964 and SKOS constructs</h2>

<p>SKOS owes much to decades of efforts in the KOS community, in the form of
applications, guidelines and standard formats. The compatibility between the
SKOS model and two such efforts, ISO 2788 specifications for monolingual
thesauri [<cite><a href="#ISO2788">ISO-2788</a></cite>] and ISO 5964
specifications for multilingual thesauri [<cite><a
href="#ISO5964">ISO-5964</a></cite>] was specifically raised as a candidate
requirement in the <cite>SKOS Use Case and Requirements</cite> [<cite><a
href="#SKOS-UCR">SKOS-UCR</a></cite>].</p>

<p>SKOS does not itself specify rules on how to create concept schemes;
however, its data model reflects some KOS construction principles. The design
of its vocabulary has also been especially influenced by standard thesaurus
guidelines, as these are among the most mature proposals in the KOS field. In
particular, there are many common points between SKOS and ISO 2788/5964. The
following table summarizes the parallels and highlights ways in which the
design of SKOS varies from ISO recommendations. It is hoped that this will
help future efforts to port thesauri that follow the ISO guidelines into
SKOS.</p>

<p>The reader should be aware that this comparison must not by any means be
interpreted as a limitation of the scope of SKOS to standard thesauri. As
already said in this document, SKOS can be used—possibly with appropriate
extensions—for other types of KOS, or thesauri that do not follow the ISO
guidelines.</p>

<table border="1">
  <caption></caption>
  <tbody>
    <tr valign="top">
      <td><strong>KOS design aspect</strong></td>
      <td><strong>ISO 2788/5964</strong></td>
      <td><strong>SKOS</strong></td>
    </tr>
    <tr valign="top">
      <td>concepts vs. terms</td>
      <td>In ISO standards, thesauri are indexing languages which consist of
        <em>terms.</em>

        <p>ISO 2788 discusses extensively the crafting of terms, focusing for
        instance on their form. For example, explicit qualifiers are used to
        distinguish homographs, e.g. <code>Crane (bird)</code> vs.
        <code>Crane (lifting equipment)</code>.</p>
      </td>
      <td><em>Concepts</em> are the central modeling primitive of SKOS. Terms
        in ISO standards correspond to <em>labels</em> of SKOS concepts.

        <p>SKOS, as a simple publishing vehicle, does not propose rules on
        label design. Further, since SKOS uses simple literals to represent
        labels, it is not possible to express term-forming mechanisms such as
        qualification formally and explicitly. For this, and for other cases
        of attaching information to labels and <strong>not</strong> to the
        concept they express, the SKOS-XL extension must be used (see <a
        href="#secrelationshipslabels">Section 4.3</a>).</p>
      </td>
    </tr>
    <tr valign="top">
      <td>intra-KOS semantic relationships — equivalence</td>
      <td>Terms can be semantically equivalent. They are then distinguished
        between <em>preferred</em> and <em>non-preferred</em>, using the
        <code>USE</code> and <code>UF</code> (used for) relations.

        <p>It is assumed that a non-preferred term can only point to one
        equivalent preferred term, the latter being the main entry point for
        the concept they both express.</p>
      </td>
      <td>Equivalent terms are represented as labels attached to a single
        concept. By default, there is no direct relationship between these
        labels. As in ISO 2788, <em>preferred</em> labels are distinct from
        non-preferred (<em>alternative</em>) ones. However, SKOS further
        allows to distinguish <em>hidden labels</em>.

        <p>A concept can have only one preferred label (per language). Inside
        a same concept scheme, different concepts can however share a
        preferred label, though this is not recommended.</p>
      </td>
    </tr>
    <tr valign="top">
      <td>intra-KOS semantic relationships — other links</td>
      <td>Beyond the equivalence relations <code>USE</code> and
        <code>UF</code>, three types of link are used to semantically relate
        terms. <code>BT</code> (broader term) and <code>NT</code> (narrower
        term) express that a term's meaning is more general than another's.
        <code>RT</code> (related term) is used when a (non-hierarchical)
        associative link holds between meanings, which can be useful for
        applications which exploit the thesaurus.

        <p>ISO 2788 separates three kinds of <code>BT</code>/<code>NT</code>
        by means of logical tests: generic (class-species), whole-part and
        class-instance. If necessary, the abbreviations <code>BTG</code>,
        <code>BTP</code> and <code>BTI</code> can be used to represent
        them.</p>

        <p>The validity of logical tests in well-formed thesauri leads to
        transitive interpretations of the hierarchy, for which a term can
        reasonably admit all its ancestors as superordinates.</p>
      </td>
      <td><code>skos:broader</code>, <code>skos:narrower</code> and
        <code>skos:related</code> mirror <code>BT</code>, <code>NT</code> and
        <code>RT</code> at the level of concepts.

        <p>However as SKOS has a wider scope in terms of KOS types, it does
        not make any recommendation as precise as in ISO 2788 on what is a
        valid hierarchy. It is mostly up to the KOS publishers to ensure that
        the links in their schemes will not conflict with what is observed in
        general KOS practice—of which thesauri are only part. SKOS instead
        focuses on separating explicitly asserted "parent-child" links
        (<code>skos:broader</code>) from more-general "ancestor-descendant"
        links which can be automatically inferred from them
        (<code>skos:broaderTransitive</code>) </p>

        <p>SKOS also allows for specializing semantic relationships (see <a
        href="#secskosspecialization">Section 4.7</a>). It does not, however,
        propose a standard set of such specializations. Rather, it is
        expected that these will come from other standards and guidelines,
        such as ISO 2788 itself.</p>
      </td>
    </tr>
    <tr valign="top">
      <td>syntactical composition of terms</td>
      <td>ISO 2788 features equivalence relations that link terms to
        combinations of other terms (<code>USE +</code>, <code>UF +</code>),
        as in <code>coal mining USE coal + mining</code>.</td>
      <td>By default, SKOS does not feature one-to-many concept-to-concept or
        concept-to-label links. Extensions might be however devised to
        address this shortcoming, e.g. by specializing
        <code>skos:Concept</code> or <code>skosxl:Label</code>.</td>
    </tr>
    <tr valign="top">
      <td>node labels</td>
      <td>Thesaurus <em>arrays</em> play an important role regarding the
        rendering of term hierarchy in a <em>systematic</em> display. They
        are for example the main vehicle for faceted organization of
      thesauri.</td>
      <td>SKOS allows the representation of groupings of concepts. But it
        focuses on the conceptual level, and no construct is given that
        biases towards a specific display strategy. As a result, collections
        in SKOS are not explicitly related to one "parent" concept. This link
        must be (re-)created via a specific display algorithm, or by using an
        ad-hoc extension.</td>
    </tr>
    <tr valign="top">
      <td>documentation notes</td>
      <td>ISO 2788 proposes to attach scope notes and definitions to terms
        using the <code>SN</code> abbreviation.</td>
      <td>SKOS has more types of note for concepts: scope notes, definition,
        history note, etc. These properties can be further extended to match
        specific requirements.</td>
    </tr>
    <tr valign="top">
      <td>notations</td>
      <td>ISO guidelines target standard thesauri. As a result, they do not
        address the issue of notations as used in other types of KOS.</td>
      <td>There are two ways to attach represent notations: either via the
        <code>skos:notation</code> property, or by using simple labeling
        properties (see <a href="#secnotations">Section 4.6</a>).</td>
    </tr>
    <tr valign="top">
      <td>concept schemes</td>
      <td>In ISO 2788, there is no explicit rendering of thesauri themselves,
        as terms are only considered in the context of one indexing
        vocabulary.</td>
      <td>SKOS is influenced by the possibility of having several KOSs
        co-exist. A <code>ConceptScheme</code> class is proposed to represent
        them explicitly and to attach descriptive metadata to them, even
        though SKOS itself does not feature specific constructs for this. The
        link between a KOS and its concepts is explicit, and a same concept
        can belong to several KOSs.</td>
    </tr>
    <tr valign="top">
      <td>top concepts</td>
      <td>In a thesaurus display, the <code>TT</code> abbreviation can be
        used to refer to the topmost term of the hierarchy to which displayed
        terms belong.</td>
      <td><code>skos:hasTopConcept</code> is used to relate a concept scheme
        to the concepts that constitute entry points in its hierarchy.</td>
    </tr>
    <tr valign="top">
      <td>language management</td>
      <td>In ISO 2788 terms should come from a same language.

        <p>ISO 5964 proposes to have several languages co-exist in a same
        thesaurus. The terms from each language form however quite
        independent parts of the thesaurus, only related to each other by
        <em>translation</em> links.</p>
      </td>
      <td>From a model perspective, concepts are language-independent : a
        concept can have labels in different languages. Labels can indeed be
        declared as language-specific, using RDF literal language tags.
        Several languages may therefore be tightly integrated in a same
        concept scheme.</td>
    </tr>
    <tr valign="top">
      <td>inter-KOS mapping relationships</td>
      <td>Semantic mapping relations are only considered by ISO 5964 in the
        context of multilingual thesauri, as a further characterization for
        the translation. The types discussed are:
        <ul>
          <li>exact equivalence,</li>
          <li>inexact equivalence—terms express a same general idea but
            their meaning is not fully identical,</li>
          <li>partial equivalence—the meaning of one term is broader than
            another's,</li>
          <li>single-to-multiple—a concept expressed by one term in the
            source language is expressed by a combination of terms in the
            target language.</li>
        </ul>

        <p>Note that ISO 5964 addresses many issues that are outside the
        scope of SKOS, such as transferring hierarchical and associative
        relations from one language to the other, or coining new terms in a
        language when a semantic equivalent cannot be found for terms in
        other languages.</p>
      </td>
      <td>SKOS mapping relations mirror relatively well ISO 5964 types. For
        example, <code>skos:exactMatch</code> and
        <code>skos:closeMatch</code> separate cases where equivalence is
        perfectly valid from a semantic perspective from other cases where
        semantic equivalence is not exact but can be accepted for a given
        application.

        <p>For an individual multilingual KOS, however, equivalence links in
        ISO 5964 may be represented in SKOS by attaching equivalent terms as
        labels of a same concept. This fits the approach of ISO 5964, which
        only makes it necessary to link preferred terms: such links can be
        transferred at the level of the concepts these terms express. Yet ISO
        5964 also allows to relate non-preferred terms (e.g.,
        <code>"DNA"@en</code> and <code>"ADN"@fr</code>). In SKOS, such links
        can be represented only using the SKOS-XL extension.</p>

        <p>Single-to-multiple translations cannot be represented in SKOS. As
        for syntactic combination of terms within one thesaurus, extensions
        to the standard model are required.</p>

        <p>Note finally that ISO 5964 discusses extensively the display of
        multilingual thesauri. SKOS does not address this. But as for simple
        thesauri, ISO 5964 displays can be implemented on top of SKOS
        data—except in the case of the single-to-multiple mappings
        mentioned above.</p>
      </td>
    </tr>
  </tbody>
</table>
<hr>

<p><a href="http://validator.w3.org/check?uri=referer"><img
src="http://www.w3.org/Icons/valid-xhtml10" alt="Valid XHTML 1.0!"
height="31" width="88"></a> <a
href="http://jigsaw.w3.org/css-validator/"><img
style="border: 0pt none ; width: 88px; height: 31px;"
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a></p>
</body>
</html>