You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
2231 lines
112 KiB
2231 lines
112 KiB
<!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: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
|
|
@prefix ex: <http://www.example.com/>.
|
|
|
|
ex:aResource ex:aProperty ex:anotherResource;
|
|
ex:anotherProperty "An RDF Literal"@en.</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"><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
|
xmlns:ex="http://www.example.com/">
|
|
<rdf:Description rdf:about="http://www.example.com/aResource">
|
|
<ex:aProperty rdf:resource="http://www.example.com/anotherResource"/>
|
|
<ex:anotherProperty xml:lang="en">An RDF Literal</ex:anotherProperty>
|
|
</rdf:Description>
|
|
</rdf:RDF></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: <http://www.w3.org/2004/02/skos/core#> .
|
|
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
|
|
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
|
|
@prefix owl: <http://www.w3.org/2002/07/owl#> .
|
|
@prefix dct: <http://purl.org/dc/terms/> .
|
|
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
|
|
@prefix ex: <http://www.example.com/> .
|
|
@prefix ex1: <http://www.example.com/1/> .
|
|
@prefix ex2: <http://www.example.com/2/> .</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"><http://www.example.com/animals> 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.
|
|
|
|
<http://en.wikipedia.org/wiki/Platypus> 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
|
|
<milk by source animal>
|
|
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) & (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><http://www.w3.org/People/Berners-Lee/card#i> 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>
|