Another abandoned server code base... this is kind of an ancestor of taskrambler.
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.
 
 
 
 
 
 

6375 lines
222 KiB

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<title>SKOS Simple Knowledge Organization System Reference</title>
<meta name="generator" content="Amaya 9.54, see http://www.w3.org/Amaya/" />
<link href="extras.css" rel="stylesheet" type="text/css" />
<link href="http://www.w3.org/StyleSheets/TR/W3C-REC" rel="stylesheet"
type="text/css" />
<script type="text/javascript" src="extras.js">
</script>
</head>
<body>
<div id="holdall">
<div id="div-hd" class="head">
<a href="http://www.w3.org/"><img height="48" width="72" alt="W3C" src="http://www.w3.org/Icons/w3c_home"/></a>
<h1>SKOS Simple Knowledge Organization System <br />
Reference</h1>
<h2><a id="w3c-doctype">W3C Recommendation 18 August 2009</a></h2>
<dl>
<dt>This version: </dt>
<dd><a
href="http://www.w3.org/TR/2009/REC-skos-reference-20090818/">http://www.w3.org/TR/2009/REC-skos-reference-20090818/</a><br
/></dd>
<dt>Latest version:</dt>
<dd><a
href="http://www.w3.org/TR/skos-reference">http://www.w3.org/TR/skos-reference</a></dd>
<dt>Previous versions:</dt>
<dd>
<a
href="http://www.w3.org/TR/2009/PR-skos-reference-20090615/">http://www.w3.org/TR/2009/PR-skos-reference-20090615/</a></dd>
<dt>Editors:</dt>
<dd><span><a href="http://purl.org/net/aliman"><span>Alistair</span> <span>Miles</span></a></span>, STFC
Rutherford Appleton Laboratory / University of Oxford<br />
<span><a href="http://www.cs.man.ac.uk/~seanb/#me"><span>Sean</span> <span>Bechhofer</span></a></span>,
University of Manchester<br />
</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 normative corrections.</p>
<p>See also <a
href="http://www.w3.org/2003/03/Translations/byTechnology?technology=skos-reference"><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>
<div id="div-abstract">
<h2><a id="abstract">Abstract</a></h2>
<p>This document defines the Simple Knowledge Organization System (SKOS), a
common data model for sharing and linking knowledge organization systems via
the Web.</p>
<p>Many knowledge organization systems, such as thesauri, taxonomies,
classification schemes and subject heading systems, share a similar
structure, and are used in similar applications. SKOS captures much of this
similarity and makes it explicit, to enable data and technology sharing
across diverse applications.</p>
<p>The SKOS data model provides a standard, low-cost migration path for
porting existing knowledge organization systems to the Semantic Web. SKOS
also provides a lightweight, intuitive language for developing and sharing
new knowledge organization systems. It may be used on its own, or in
combination with formal knowledge representation languages such as the Web
Ontology language (OWL).</p>
<p>This document is the normative specification of the Simple Knowledge
Organization System. It is intended for readers who are involved in the
design and implementation of information systems, and who already have a good
understanding of Semantic Web technology, especially RDF and OWL.</p>
<p>For an informative guide to using SKOS, see the [<a class="citation" rel="citation" href="#ref-SKOS-PRIMER">SKOS-PRIMER</a>].</p>
</div>
<div id="div-synopsis">
<h3>Synopsis</h3>
<p>Using SKOS, <strong><a href="#concepts">concepts</a></strong> can be
identified using URIs, <strong><a href="#labels">labeled</a></strong> with
lexical strings in one or more natural languages, assigned <strong><a
href="#notations">notations</a></strong> (lexical codes), <strong><a
href="#notes">documented</a></strong> with various types of note, <strong><a
href="#semantic-relations">linked to other concepts</a></strong> and
organized into informal hierarchies and association networks, aggregated into
<strong><a href="#schemes">concept schemes</a></strong>, grouped into labeled
and/or ordered <strong><a href="#collections">collections</a></strong>, and
<strong><a href="#mapping">mapped</a></strong> to concepts in other schemes.
</p>
<p>[<a class="action" onclick="showQuickAccess()"
onkeypress="showQuickAccess()">show quick access panel</a>]</p>
<hr />
</div>
<div id="div-sotd">
<h2 id="status">Status of This Document</h2>
<!-- Start Status-Of-This-Document Text -->
<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 W3C Recommendation developed 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 document reflects an editorial change arising during
the Proposed Recommendation review: a non-normative example and
preceding text was removed 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="#xl">SKOS Extension vocabulary</a>
for support of alternate systems of notation.
An <a
href="http://www.w3.org/2006/07/SWD/SKOS/reference/20090315/implementation.html"
>implementation report</a> documents known uses of SKOS
during the Candidate Recommendation review period. An updated
<a href="http://www.w3.org/TR/skos-primer">SKOS Primer</a> is being
published concurrently with this Recommendation.</p>
<p id='changes'>Changes Since <a
href="http://www.w3.org/TR/2009/PR-skos-reference-20090615/"
>15 June 2009 Proposed Recommendation</a>:</p>
<ul>
<li>Removed final paragraph and example from section 6.5.4
on use of private use language sub-tags.</li>
<li>Editorial changes to references section and citation of
SKOS Primer.</li>
</ul>
<p>Comments on this document may be sent to
<a href="mailto:public-swd-wg@w3.org">public-swd-wg@w3.org</a>
with
<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>This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.</p>
</div>
<div id="div-quick-access" class="invisible">
<p>Quick Access Panel [<a class="action" onclick="hideQuickAccess()"
onkeypress="hideQuickAccess()">hide</a>]</p>
<p><a href="#toc">Full Table of Contents</a></p>
<p><strong>Classes</strong></p>
<ul>
<li><a href="#Collection">skos:Collection</a></li>
<li><a href="#Concept">skos:Concept</a></li>
<li><a href="#ConceptScheme">skos:ConceptScheme</a></li>
<li><a href="#OrderedCollection">skos:OrderedCollection</a></li>
</ul>
<p><strong>Properties</strong></p>
<ul>
<li><a href="#altLabel">skos:altLabel</a></li>
<li><a href="#broadMatch">skos:broadMatch</a></li>
<li><a href="#broader">skos:broader</a></li>
<li><a href="#broaderTransitive">skos:broaderTransitive</a></li>
<li><a href="#changeNote">skos:changeNote</a></li>
<li><a href="#closeMatch">skos:closeMatch</a></li>
<li><a href="#definition">skos:definition</a></li>
<li><a href="#editorialNote">skos:editorialNote</a></li>
<li><a href="#exactMatch">skos:exactMatch</a></li>
<li><a href="#example">skos:example</a></li>
<li><a href="#hasTopConcept">skos:hasTopConcept</a></li>
<li><a href="#hiddenLabel">skos:hiddenLabel</a></li>
<li><a href="#historyNote">skos:historyNote</a></li>
<li><a href="#inScheme">skos:inScheme</a></li>
<li><a href="#mappingRelation">skos:mappingRelation</a></li>
<li><a href="#member">skos:member</a></li>
<li><a href="#memberList">skos:memberList</a></li>
<li><a href="#narrowMatch">skos:narrowMatch</a></li>
<li><a href="#narrower">skos:narrower</a></li>
<li><a href="#narrowerTransitive">skos:narrowerTransitive</a></li>
<li><a href="#notation">skos:notation</a></li>
<li><a href="#note">skos:note</a></li>
<li><a href="#prefLabel">skos:prefLabel</a></li>
<li><a href="#related">skos:related</a></li>
<li><a href="#relatedMatch">skos:relatedMatch</a></li>
<li><a href="#scopeNote">skos:scopeNote</a></li>
<li><a href="#semanticRelation">skos:semanticRelation</a></li>
<li><a href="#topConceptOf">skos:topConceptOf</a></li>
</ul>
<p><strong>Sections</strong></p>
<ul>
<li><a href="#intro">1. Introduction</a></li>
<li><a href="#vocab">2. Namespace and Vocabulary</a></li>
<li><a href="#concepts">3. The skos:Concept Class</a></li>
<li><a href="#schemes">4. Concept Schemes</a></li>
<li><a href="#labels">5. Lexical Labels</a></li>
<li><a href="#notations">6. Notations</a></li>
<li><a href="#notes">7. Documentation Properties</a></li>
<li><a href="#semantic-relations">8. Semantic Relations</a></li>
<li><a href="#collections">9. Concept Collections</a></li>
<li><a href="#mapping">10. Mapping Properties</a></li>
<li><a href="#references">11. References</a></li>
</ul>
<p><strong>Appendices</strong></p>
<ul>
<li><a href="#overview">A. SKOS Properties and Classes</a></li>
<li><a href="#xl">B. SKOS eXtension for Labels (SKOS-XL)</a></li>
<li><a href="#namespace-documents">C. SKOS and SKOS-XL Namespace Documents</a></li>
<li><a href="#namespace">D. SKOS Namespace</a></li>
</ul>
</div>
<div id="div-toc">
<a id="toc"></a>
<h2>Table of Contents</h2>
<p>[<a class="action" onclick="showQuickAccess()"
onkeypress="showQuickAccess()">show quick access panel</a>]</p>
<div class="toc">
<ul>
<li><a href="#intro"><strong>1. Introduction</strong></a>
<ul>
<li><a href="#L879">1.1. Background and Motivation</a></li>
<li><a href="#L895">1.2. SKOS Overview</a></li>
<li><a href="#L1045">1.3. SKOS, RDF and OWL</a></li>
<li><a href="#L831">1.4. Consistency and Integrity </a></li>
<li><a href="#L881">1.5. Inference, Dependency and the Open-World
Assumption</a></li>
<li><a href="#rationale">1.6. Design Rationale</a></li>
<li><a href="#L649">1.7. How to Read this Document</a>
<ul>
<li><a href="#L1291">1.7.1. Formal Definitions</a></li>
<li><a href="#L1368">1.7.2. URI Abbreviations</a></li>
<li><a href="#L1501">1.7.3. Examples</a></li>
</ul>
</li>
<li><a href="#L434">1.8. Conformance</a></li>
</ul>
</li>
<li><a href="#vocab"><strong>2. SKOS Namespace and Vocabulary</strong></a></li>
<li><a href="#concepts"><strong>3. The skos:Concept Class</strong></a>
<ul>
<li><a href="#L1437">3.1. Preamble</a></li>
<li><a href="#L2039">3.2. Vocabulary</a></li>
<li><a href="#L842">3.3. Class &amp; Property Definitions</a></li>
<li><a href="#L2118">3.4. Examples</a></li>
<li><a href="#L2145">3.5. Notes</a>
<ul>
<li><a href="#L896">3.5.1. SKOS Concepts, OWL Classes and OWL
Properties</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#schemes"><strong>4. Concept Schemes</strong></a>
<ul>
<li><a href="#L1638">4.1. Preamble</a></li>
<li><a href="#L2457">4.2. Vocabulary</a></li>
<li><a href="#L8421">4.3. Class &amp; Property Definitions</a></li>
<li><a href="#L1228">4.4. Integrity Conditions</a></li>
<li><a href="#L21181">4.5. Examples</a></li>
<li><a href="#L2497">4.6. Notes</a>
<ul>
<li><a href="#L1101">4.6.1. Closed vs. Open Systems</a></li>
<li><a href="#L1170">4.6.2. SKOS Concept Schemes and OWL
Ontologies</a></li>
<li><a href="#L2446">4.6.3. Top Concepts and Semantic
Relations</a></li>
<li><a href="#L2577">4.6.4. Scheme Containment and Semantic
Relations</a></li>
<li><a href="#L2805">4.6.5. Domain of skos:inScheme</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#labels"><strong>5. Lexical Labels</strong></a>
<ul>
<li><a href="#L2007">5.1. Preamble</a></li>
<li><a href="#L1304">5.2. Vocabulary</a></li>
<li><a href="#L1329">5.3. Class &amp; Property Definitions</a></li>
<li><a href="#L1567">5.4. Integrity Conditions</a></li>
<li><a href="#L1409">5.5. Examples</a></li>
<li><a href="#L1539">5.6. Notes</a>
<ul>
<li><a href="#L1541">5.6.1. Domain of SKOS Lexical Labeling
Properties</a></li>
<li><a href="#L1581">5.6.2. Range of SKOS Lexical Labeling
Properties</a></li>
<li><a href="#L3260">5.6.3. Defining Label Relations</a></li>
<li><a href="#L1606">5.6.4. Alternates Without Preferred</a></li>
<li><a href="#L1629">5.6.5. Labeling and Language Tags</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#notations"><strong>6. Notations</strong></a>
<ul>
<li><a href="#L2531">6.1. Preamble</a></li>
<li><a href="#L2542">6.2. Vocabulary</a></li>
<li><a href="#L2557">6.3. Class &amp; Property Definitions</a></li>
<li><a href="#L2584">6.4. Examples</a></li>
<li><a href="#L2611">6.5. Notes</a>
<ul>
<li><a href="#L2613">6.5.1. Notations, Typed Literals and
Datatypes</a></li>
<li><a href="#L2637">6.5.2. Multiple Notations</a></li>
<li><a href="#L2646">6.5.3. Unique Notations in Concept
Schemes</a></li>
<li><a href="#L2655">6.5.4. Notations and Preferred Labels</a></li>
<li><a href="#notations-note-domain">6.5.5. Domain of skos:notation</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#notes"><strong>7. Documentation Properties (Note Properties)</strong></a>
<ul>
<li><a href="#L2543">7.1. Preamble</a></li>
<li><a href="#L1693">7.2. Vocabulary</a></li>
<li><a href="#L1738">7.3. Class &amp; Property Definitions</a></li>
<li><a href="#L1812">7.4. Examples</a></li>
<li><a href="#L1877">7.5. Notes</a>
<ul>
<li><a href="#L1879">7.5.1. Domain of the SKOS Documentation
Properties</a></li>
<li><a href="#L1917">7.5.2. Range of the SKOS
Documentation Properties</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#semantic-relations"><strong>8. Semantic Relations</strong></a>
<ul>
<li><a href="#L2810">8.1. Preamble</a></li>
<li><a href="#L2010">8.2. Vocabulary</a></li>
<li><a href="#L2055">8.3. Class &amp; Property Definitions</a></li>
<li><a href="#L2422">8.4. Integrity Conditions</a></li>
<li><a href="#L2157">8.5. Examples</a></li>
<li><a href="#L2249">8.6. Notes</a>
<ul>
<li><a href="#L3732">8.6.1. Sub-Property Relationships</a></li>
<li><a href="#L2251">8.6.2. Domain and Range of SKOS Semantic
Relation Properties</a></li>
<li><a href="#L2255">8.6.3. Symmetry of skos:related</a></li>
<li><a href="#L2344">8.6.4. skos:related and Transitivity</a></li>
<li><a href="#L2376">8.6.5. skos:related and Reflexivity</a></li>
<li><a href="#L2413">8.6.6. skos:broader and Transitivity</a></li>
<li><a href="#L2449">8.6.7. skos:broader and Reflexivity</a></li>
<li><a href="#L2484">8.6.8. Cycles in the Hierarchical Relation
(skos:broaderTransitive and Reflexivity)</a></li>
<li><a href="#L2518">8.6.9. Alternate Paths in the Hierarchical
Relation</a></li>
<li><a href="#L4261">8.6.10. Disjointness of skos:related and
skos:broaderTransitive</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#collections"><strong>9. Concept Collections</strong></a>
<ul>
<li><a href="#L3806">9.1. Preamble</a></li>
<li><a href="#L3282">9.2. Vocabulary</a></li>
<li><a href="#L3312">9.3. Class &amp; Property Definitions</a></li>
<li><a href="#L3424">9.4. Integrity Conditions</a></li>
<li><a href="#L3460">9.5. Examples</a></li>
<li><a href="#L3512">9.6. Notes</a>
<ul>
<li><a href="#L3514">9.6.1. Inferring Collections from Ordered
Collections</a></li>
<li><a href="#L3551">9.6.2. skos:memberList Integrity</a></li>
<li><a href="#L3588">9.6.3. Nested Collections</a></li>
<li><a href="#L3625">9.6.4. SKOS Concepts, Concept Collections and
Semantic Relations</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#mapping"><strong>10. Mapping Properties</strong></a>
<ul>
<li><a href="#L4307">10.1. Preamble</a></li>
<li><a href="#L4138">10.2. Vocabulary</a></li>
<li><a href="#L4186">10.3. Class &amp; Property Definitions</a></li>
<li><a href="#L5429">10.4. Integrity Conditions</a></li>
<li><a href="#L4316">10.5. Examples</a></li>
<li><a href="#L4412">10.6. Notes</a>
<ul>
<li><a href="#L4160">10.6.1. Mapping Properties, Semantic Relation
Properties and Concept Schemes</a></li>
<li><a href="#L4394">10.6.2. Clashes Between Hierarchical and
Associative Links</a></li>
<li><a href="#L4414">10.6.3. Mapping Properties and
Transitivity</a></li>
<li><a href="#L4499">10.6.4. Mapping Properties and
Reflexivity</a></li>
<li><a href="#L4564">10.6.5. Cycles and Alternate Paths Involving
skos:broadMatch</a></li>
<li><a href="#mapping-cycles-exactMatch">10.6.6. Cycles Involving skos:exactMatch and
skos:closeMatch</a></li>
<li><a href="#L5675">10.6.7. Sub-Property Chains Involving
skos:exactMatch</a></li>
<li><a href="#L4858">10.6.8. skos:closeMatch, skos:exactMatch,
owl:sameAs, owl:equivalentClass, owl:equivalentProperty</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#references"><strong>11. References</strong></a></li>
<li><a href="#ack"><strong>12. Acknowledgments</strong></a></li>
<li><a href="#overview"><strong>Appendix A. SKOS Properties and Classes</strong></a>
<ul>
<li><a href="#L7130">A.1. Classes in the SKOS Data Model</a></li>
<li><a href="#L7307">A.2. Properties in the SKOS Data Model</a></li>
</ul>
</li>
<li><a href="#xl"><strong>Appendix B. SKOS eXtension for Labels (SKOS-XL)</strong></a>
<ul>
<li><a href="#L5212">B.1. SKOS-XL Namespace and Vocabulary</a></li>
<li><a href="#L5444">B.2. The skosxl:Label Class</a>
<ul>
<li><a href="#L375">B.2.1. Preamble</a></li>
<li><a href="#L5518">B.2.2. Class and Property
Definitions</a></li>
<li><a href="#L5525">B.2.3. Examples</a></li>
<li><a href="#L5716">B.2.4. Notes</a>
<ul>
<li><a href="#L5739">B.2.4.1. Identity and
Entailment</a></li>
<li><a href="#L648">B.2.4.2. Membership of Concept
Schemes</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#L5981">B.3. Preferred, Alternate and Hidden
skosxl:Labels</a>
<ul>
<li><a href="#L661">B.3.1. Preamble</a></li>
<li><a href="#L677">B.3.2. Class and Property
Definitions</a></li>
<li><a href="#L724">B.3.3. Examples</a></li>
<li><a href="#L778">B.3.4. Notes</a>
<ul>
<li><a href="#L780">B.3.4.1. Dumbing-Down to SKOS
Lexical Labels</a></li>
<li><a href="#L899">B.3.4.2. SKOS-XL Labeling
Integrity</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#L7196">B.4. Links Between skosxl:Labels</a>
<ul>
<li><a href="#L1120">B.4.1. Preamble</a></li>
<li><a href="#L1129">B.4.2. Class and Property
Definitions</a></li>
<li><a href="#L1160">B.4.3. Examples</a></li>
<li><a href="#L1193">B.4.4. Notes</a>
<ul>
<li><a href="#L1195">B.4.4.1. Refinements of this
Pattern</a></li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li><a href="#namespace-documents"><strong>Appendix C. SKOS and SKOS-XL Namespace Documents</strong></a></li>
<li><a href="#namespace"><strong>Appendix D. SKOS Namespace: a historical note</strong></a></li>
</ul>
</div>
<hr />
</div>
<div id="div-content">
<div id="div-intro">
<a id="intro"></a>
<h2 id="L155">1. Introduction</h2>
<h3 id="L879">1.1. Background and Motivation</h3>
<p>The Simple Knowledge Organization System is a data-sharing standard,
bridging several different fields of knowledge, technology and practice. </p>
<p>In the library and information sciences, a long and distinguished heritage
is devoted to developing tools for organizing large collections of objects
such as books or museum artifacts. These tools are known generally as
"knowledge organization systems" (KOS) or sometimes as "controlled structured
vocabularies". Several similar yet distinct traditions have emerged over
time, each supported by a community of practice and set of agreed standards.
Different families of knowledge organization systems, including thesauri,
classification schemes, subject heading systems, and taxonomies are
widely recognized and applied in both modern and traditional information
systems. In practice it can be hard to draw an absolute distinction between
thesauri and classification schemes or taxonomies, although some
properties can be used to broadly characterize these different families (see
e.g., [<a class="citation" rel="citation" href="#ref-BS8723-3">BS8723-3</a>]).
The important point for SKOS is that, in addition to their unique features,
each of these families shares much in common, and can often be used in
similar ways [<a class="citation" rel="citation" href="#ref-SKOS-UCR">SKOS-UCR</a>].
However, there is currently no widely deployed standard for
representing these knowledge organization systems as data and exchanging them
between computer systems.</p>
<p>The W3C's Semantic Web Activity [<a class="citation"
href="#ref-SW">SW</a>] has stimulated a new field of integrative research and
technology development, at the boundaries between database systems, formal
logic and the World Wide Web. This work has led to the development of
foundational standards for the Semantic Web. The Resource Description
Framework (RDF) provides a common data abstraction and syntax for the Web [<a
class="citation" rel="citation" href="#ref-RDF-PRIMER">RDF-PRIMER</a>]. The
RDF Vocabulary Description language (RDFS) and the Web Ontology language
(OWL) together provide a common data modeling (schema) language for data in
the Web [<a class="citation" rel="citation" href="#ref-RDFS">RDFS</a>] [<a
class="citation" rel="citation" href="#ref-OWL-GUIDE">OWL-GUIDE</a>]. The
SPARQL Query Language and Protocol provide a standard means for interacting
with data in the Web [<a class="citation" rel="citation"
href="#ref-SPARQL">SPARQL</a>]. </p>
<p>These technologies are being applied across diverse applications, because
many applications require a common framework for publishing, sharing,
exchanging and integrating ("joining up") data from different sources. The
ability to link data from different sources is motivating many projects,
as different communities seek to exploit the hidden value in data
previously spread across isolated sources.</p>
<p>One facet of the Semantic Web vision is the hope of better organizing the
vast amounts of unstructured (i.e., human-readable) information in the Web,
providing new routes to discovering and sharing that information. RDFS and
OWL are formally defined knowledge representation languages, providing ways
of expressing meaning that are amenable to computation, meaning that
complements and gives structure to information already present in the Web [<a
class="citation" rel="citation" href="#ref-RDF-PRIMER">RDF-PRIMER</a>] [<a
class="citation" rel="citation" href="#ref-OWL-GUIDE">OWL-GUIDE</a>]. However, to actually apply these technologies over large bodies of information
requires the construction of detailed maps of particular domains of
knowledge, in addition to the accurate description (i.e., annotation or
cataloging) of information resources on a large scale, much of which cannot
be done automatically. The accumulated experience and best practices in the
library and information sciences regarding the organization of information
and knowledge are obviously complementary and applicable to this vision, as
are the many existing knowledge organization systems already developed and in
use, such as the Library of Congress Subject Headings [<a class="citation"
rel="citation" href="#ref-LCSH">LCSH</a>] or the United Nations Food and
Agriculture Organization's AGROVOC Thesaurus [<a class="citation"
rel="citation" href="#ref-AGROVOC">AGROVOC</a>].</p>
<p>The Simple Knowledge Organization System therefore aims to provide a
bridge between different communities of practice within the library and
information sciences involved in the design and application of knowledge
organization systems. In addition, SKOS aims to provide a bridge between
these communities and the Semantic Web, by transferring existing models of
knowledge organization to the Semantic Web technology context, and by
providing a low-cost migration path for porting existing knowledge
organization systems to RDF.</p>
<p>Looking to the future, SKOS occupies a position between the exploitation
and analysis of unstructured information, the informal and socially-mediated
organization of information on a large scale, and the formal representation
of knowledge. By making the accumulated experience and
wisdom of knowledge organization in the library and information sciences
accessible, applicable and transferable to the technological context
of the Semantic Web, in a way that is complementary to existing Semantic Web
technology (and in particular formal systems of knowledge representation such
as OWL), it is hoped that SKOS will enable many new and valuable applications, and will also
lead to new integrative lines of research and development in both technology
and practice. </p>
<h3 id="L895">1.2. SKOS Overview</h3>
<p>The Simple Knowledge Organization System is a common data model for
knowledge organization systems such as thesauri, classification schemes,
subject heading systems and taxonomies. Using SKOS, a knowledge organization
system can be expressed <strong>as machine-readable data</strong>. It can
then be exchanged between computer applications and published in a
machine-readable format in the Web.</p>
<p>The SKOS data model is formally defined in this specification as an OWL
Full ontology [<a class="citation" rel="citation"
href="#ref-OWL-SEMANTICS">OWL-SEMANTICS</a>]. SKOS data are expressed as RDF
triples [<a class="citation" rel="citation"
href="#ref-RDF-CONCEPTS">RDF-CONCEPTS</a>], and may be encoded using any
concrete RDF syntax (such as RDF/XML [<a class="citation" rel="citation"
href="#ref-RDF-XML">RDF-XML</a>] or Turtle [<a class="citation"
rel="citation" href="#ref-TURTLE">TURTLE</a>]). For more on the relationships
between SKOS, RDF and OWL, see the next sub-section below.</p>
<p>The SKOS data model views a knowledge organization system as a
<strong>concept scheme</strong> comprising a set of
<strong>concepts</strong>. These SKOS concept schemes and SKOS concepts are
identified by URIs, enabling anyone to refer to them unambiguously from any
context, and making them a part of the World Wide Web. See <a
href="#concepts">Section 3. The skos:Concept Class</a> for more on
identifying and describing SKOS concepts, and <a href="#schemes">Section 4.
Concept Schemes</a> for more on concept schemes.</p>
<p>SKOS concepts can be <strong>labeled</strong> with any number of lexical
(UNICODE) strings, such as "romantic love" or "れんあい", in any given
natural language, such as English or Japanese (written here in hiragana). One of these labels
in any given language can be indicated as the preferred label for that
language, and the others as alternative labels. Labels may also be "hidden",
which is useful where a knowledge organization system is being queried
via a text index. See <a href="#labels">Section 5. Lexical Labels</a> for
more on the SKOS lexical labeling properties.</p>
<p>SKOS concepts can be assigned one or more <strong>notations</strong>,
which are lexical codes used to uniquely identify the concept within the
scope of a given concept scheme. While URIs are the preferred means of
identifying SKOS concepts within computer systems, notations provide a bridge
to other systems of identification already in use such as classification
codes used in library catalogs. See <a href="#notations">Section 6.
Notations</a> for more on notations.</p>
<p>SKOS concepts can be <strong>documented</strong> with notes of various
types. The SKOS data model provides a basic set of documentation properties,
supporting scope notes, definitions and editorial notes, among others. This
set is not meant to be exhaustive, but rather to provide a framework that can
be extended by third parties to provide support for more specific types of
note. See <a href="#notes">Section 7. Documentation Properties</a> for more
on notes.</p>
<p>SKOS concepts can be <strong>linked</strong> to other SKOS concepts via
semantic relation properties. The SKOS data model provides support for
hierarchical and associative links between SKOS concepts. Again, as with any
part of the SKOS data model, these can be extended by third parties to
provide support for more specific needs. See <a
href="#semantic-relations">Section 8. Semantic Relations</a> for more on
linking SKOS concepts.</p>
<p>SKOS concepts can be grouped into <strong>collections</strong>, which can
be labeled and/or ordered. This feature of the SKOS data model is intended to
provide support for node labels within thesauri, and for situations where the
ordering of a set of concepts is meaningful or provides some useful
information. See <a href="#collections">Section 9. Concept Collections</a>
for more on collections.</p>
<p>SKOS concepts can be <strong>mapped</strong> to other SKOS concepts in
different concept schemes. The SKOS data model provides support for four
basic types of mapping link: hierarchical, associative, close equivalent and
exact equivalent. See <a href="#mapping">Section 10. Mapping Properties</a>
for more on mapping.</p>
<p>Finally, an optional extension to SKOS is defined in <a
href="#xl">Appendix B. SKOS eXtension for Labels (SKOS-XL)</a>. SKOS-XL provides more
support for identifying, describing and linking lexical entities. </p>
<h3 id="L1045">1.3. SKOS, RDF and OWL</h3>
<p>The elements of the SKOS data model are classes and properties, and the
structure and integrity of the data model is defined by the logical
characteristics of, and interdependencies between, those classes and
properties. This is perhaps one of the most powerful and yet potentially
confusing aspects of SKOS, because SKOS can, in more advanced applications,
also be used side-by-side with OWL to express and exchange knowledge about a
domain. However, SKOS is <strong>not</strong> a formal knowledge
representation language. </p>
<p>To understand this distinction, consider that the "knowledge" made
explicit in a formal ontology is expressed as sets of axioms and facts. A
thesaurus or classification scheme is of a completely different nature, and
does not assert any axioms or facts. Rather, a thesaurus or classification
scheme identifies and describes, through natural language and other informal
means, a set of distinct ideas or meanings, which are sometimes
conveniently referred to as "concepts". These "concepts" may also be arranged
and organized into various structures, most commonly hierarchies and
association networks. These structures, however, do not have any formal
semantics, and cannot be reliably interpreted as either formal axioms or
facts about the world. Indeed they were never intended to be so, for they
serve only to provide a convenient and intuitive map of some subject
domain, which can then be used as an aid to organizing and finding objects,
such as documents, which are relevant to that domain. </p>
<p>To make the "knowledge" embedded in a thesaurus or classification scheme
explicit in any formal sense requires that the thesaurus or classification
scheme be <em>re-engineered</em> as a formal ontology. In other words, some
person has to do the work of transforming the structure and intellectual
content of a thesaurus or classification scheme into a set of formal axioms
and facts. This work of transformation is both intellectually demanding and
time consuming, and therefore costly. Much can be gained from using thesauri,
etc., as-is, as informal, convenient structures for navigation within a
subject domain. Using them as-is does not require any re-engineering and
is therefore much less costly. In addition, some KOS are, by design, not
intended to represent a logical view of their domain. Converting such KOS to a
formal logic-based representation may, in practice, involve changes which result
in a representation that no longer meets the originally intended purpose. </p>
<p>OWL does, however, provide a powerful data modeling language. We can,
therefore, use OWL to construct a data model for representing thesauri or
classification schemes as-is. This is exactly what SKOS does. Taking this
approach, the "concepts" of a thesaurus or classification scheme are modeled
as individuals in the SKOS data model, and the informal descriptions about
and links between those "concepts" as given by the thesaurus or
classification scheme are modeled as facts about those individuals, never as
class or property axioms. Note that these are facts <em>about</em>
the thesaurus or classification scheme <em>itself</em>, such as "concept X
has preferred label 'Y' and is part of thesaurus Z"; these are
<strong>not</strong> facts about the way the world is arranged within a
particular subject domain, as might be expressed in a formal ontology. </p>
<p>SKOS data are then expressed as RDF triples. The RDF graph
below (in [<a class="citation" rel="citation" href="#ref-TURTLE">TURTLE</a>]
as discussed in <a href="#L1501">Section 1.7.3</a>) expresses some facts
about a thesaurus.</p>
<pre>&lt;A&gt; rdf:type skos:Concept ;
skos:prefLabel "love"@en ;
skos:altLabel "adoration"@en ;
skos:broader &lt;B&gt; ;
skos:inScheme &lt;S&gt; .
&lt;B&gt; rdf:type skos:Concept ;
skos:prefLabel "emotion"@en ;
skos:altLabel "feeling"@en ;
skos:topConceptOf &lt;S&gt; .
&lt;S&gt; rdf:type skos:ConceptScheme ;
dct:title "My First Thesaurus" ;
skos:hasTopConcept &lt;B&gt; .</pre>
<p>This point is vital to understanding the formal definition of the SKOS
data model and how it may be implemented in software systems. This point is
also vital to more advanced applications of SKOS, especially where SKOS and
OWL are used in combination as part of a hybrid formal/semi-formal design.
</p>
<p>From a user's point of view, however, the distinction between a formal
knowledge representation system and an informal or semi-formal knowledge
organization system may naturally become blurred. In other words, it may not
be relevant to a user that <code>&lt;A&gt;</code> and <code>&lt;B&gt;</code>
in the graph below are individuals (instances of <code>skos:Concept</code>),
and <code>&lt;C&gt;</code> and <code>&lt;D&gt;</code> are classes (instances
of <code>owl:Class</code>) .</p>
<p></p>
<pre>&lt;A&gt; rdf:type skos:Concept ;
skos:prefLabel "love"@en ;
skos:broader &lt;B&gt; .
&lt;B&gt; rdf:type skos:Concept ;
skos:prefLabel "emotion"@en .
&lt;C&gt; rdf:type owl:Class ;
rdfs:label "mammals"@en ;
rdfs:subClassOf &lt;D&gt; .
&lt;D&gt; rdf:type owl:Class ;
rdfs:label "animals"@en .</pre>
<p>An information system that has any awareness of the SKOS data model will,
however, need to appreciate the distinction.</p>
<p>RDF schemas for SKOS and the SKOS eXtension for Labels (SKOS-XL) are described
in <a href="#namespace-documents">Appendix C. SKOS and SKOS-XL Namespace Documents</a>. Note
that, as there are constraints that cannot be completely captured in the
schema, the RDF/XML document provides a normative subset of this
specification. </p>
</div>
<div id="div-intro2">
<h3 id="L831">1.4. Consistency and Integrity </h3>
<p>Under the RDF and OWL Full semantics, the formal meaning
(<em>interpretation</em>) of an RDF graph is a truth value [<a
class="citation" rel="citation" href="#ref-RDF-SEMANTICS">RDF-SEMANTICS</a>]
[<a class="citation" rel="citation"
href="#ref-OWL-SEMANTICS">OWL-SEMANTICS</a>], i.e., an RDF graph is
interpreted as either true or false.</p>
<p>In general, an RDF graph is said to be <em>inconsistent</em> if it cannot
possibly be true. In other words, an RDF graph is inconsistent if it contains
a contradiction. </p>
<p>Using the RDF and RDFS vocabularies alone, it is virtually impossible to
make a contradictory statement. When the OWL vocabulary is used as well,
there are many ways to state a contradiction, e.g., consider the RDF
graph below.</p>
<pre>&lt;Dog&gt; rdf:type owl:Class .
&lt;Cat&gt; rdf:type owl:Class .
&lt;Dog&gt; owl:disjointWith &lt;Cat&gt; .
&lt;dogcat&gt; rdf:type &lt;Dog&gt; , &lt;Cat&gt; .</pre>
<p>The graph states that <code>&lt;Dog&gt;</code> and
<code>&lt;Cat&gt;</code> are both classes, and that they are disjoint, i.e.,
that they do not have any members in common. This is contradicted by the
statement that <code>&lt;dogcat&gt;</code> has type both
<code>&lt;Dog&gt;</code> and <code>&lt;Cat&gt;</code>. There is no OWL Full
interpretation which can satisfy this graph, and therefore this graph is
<strong>not</strong> OWL Full consistent.</p>
<p>When OWL Full is used as a knowledge representation language, the notion
of inconsistency is useful because it reveals contradictions within the
axioms and facts that are asserted in an ontology. By resolving these
inconsistencies we learn more about a domain of knowledge, and come to a
better model of that domain from which interesting and valid inferences can
be drawn. </p>
<p>When OWL Full is used as a data modeling (i.e., schema) language, the
notion of inconsistency is again useful, but in a different way. Here we are
not concerned with the logical consistency of human knowledge itself. We are
simply interested in formally defining a data model, so that we can establish
with certainty whether or not some given data fit with (i.e., conform to) the
given data model. If the data are inconsistent with respect to the data
model, then the data does not fit.</p>
<p>Here, we are not concerned with whether or not some given data have any
correspondence with the real world, i.e., whether they are true or false in any
absolute sense. We are simply interested in whether or not the data fit the
data model, because interoperability within a given class of applications
depends on data conforming to a common data model.</p>
<p>Another way to express this view is via the notion of <em>integrity</em>.
Integrity conditions are statements within the formal definition of a data
model, which are used to establish whether or not given data are consistent
with respect to the data model, e.g., the statement that <code>&lt;Dog&gt;</code> and
<code>&lt;Cat&gt;</code> are disjoint classes can be viewed as an integrity
condition on a data model. Given this condition, the data below are then not consistent.</p>
<pre>&lt;dogcat&gt; rdf:type &lt;Dog&gt; , &lt;Cat&gt; .</pre>
<p>The definition of the SKOS data model given in this document contains a
limited number of statements that are intended as integrity conditions. These
integrity conditions are included to promote interoperability, by defining
the circumstances under which data are <strong>not consistent</strong> with
respect to the SKOS data model. Tools can then be implemented which check
whether some or all of these integrity conditions are met for given data, and
therefore whether the data are consistent with the SKOS data model.</p>
<p>These integrity conditions are part of the formal definition of the
classes and properties of the SKOS data model. However, they are presented
separately from other parts of the formal definition because they serve a
different purpose. Integrity conditions serve primarily to establish whether
given data are consistent with the SKOS data model. All other statements
within the definition of the SKOS data model serve <strong>only</strong> to
support logical inferences. (See also the next sub-section.) </p>
<p>Integrity conditions are defined for the SKOS data model in a way that is
independent of strategies for their implementation, in so far as that is
possible. This is because there are several different ways in which a
procedure to find inconsistencies with the SKOS data model could be
implemented. Inconsistencies could be found using an OWL
reasoner. Alternatively, some inconsistencies could be found by searching for
specific patterns within the data, or by a hybrid strategy (e.g., drawing inferences
using an RDFS or OWL reasoner, then searching for patterns in the inferred
graph). </p>
<p>The integrity conditions on the SKOS data model are fewer than might be
expected, especially for those used to working within the closed world of
database systems. See also the next sub-section, and the notes in sections
3-10 below.</p>
<h3 id="L881">1.5. Inference, Dependency and the Open World Assumption</h3>
<p>This document defines the SKOS data model as an OWL Full ontology. There
are other ways in which the SKOS data model could have been
defined, for example as an entity-relationship model, or a UML class model.
Although OWL Full as a data modeling language appears intuitively similar in
many ways to these other modeling approaches, there is an important
fundamental distinction. </p>
<p>RDF and OWL Full are designed for systems in which data may be widely
distributed (e.g., the Web). As such a system becomes larger, it becomes both
impractical and virtually impossible to know where all of the data in the
system are located. Therefore, one cannot generally assume that data obtained
from such a system are complete. If some data appear to be missing,
one has to assume, in general, that the data <em>might</em> exist somewhere
else in the system. This assumption, roughly speaking, is known as the
<strong>open world assumption</strong> [<a class="citation" rel="citation"
href="#ref-OWL-GUIDE">OWL-GUIDE</a>]. </p>
<p>This means in practice that, for a data model defined as an OWL Full
ontology, some definitions can have a counter-intuitive meaning. No
conclusions can be drawn from missing data, and removing something will
never make the remaining data inconsistent. This is illustrated, for example, by the definition of <code>skos:semanticRelation</code> in <a href="#semantic-relations">Section 8</a> below. The
property <code>skos:semanticRelation</code> is defined to have domain and
range <code>skos:Concept</code>. These domain and range definitions give
license to <strong>inferences</strong>. Consider the graph below.</p>
<pre>&lt;A&gt; skos:semanticRelation &lt;B&gt;.</pre>
<p>In this case, the graph above entails the following
graph.</p>
<pre>&lt;A&gt; rdf:type skos:Concept .
&lt;B&gt; rdf:type skos:Concept .</pre>
<p>Thus, we do not need to <em>explicitly</em> state here that
<code>&lt;A&gt;</code> and <code>&lt;B&gt;</code> are instances of
<code>skos:Concept</code>, because such statements are entailed by the definition of <code>skos:semanticRelation</code>.</p>
<p>In the SKOS data model, most statements of definition are
<strong>not</strong> integrity conditions, but are statements of logical
dependency between different elements of the data model, which (under the
open world assumption) give license to a number of simple inferences. This is illustrated, for
example, by the statement in <a href="#semantic-relations">Section 7</a> below that
<code>skos:broader</code> and <code>skos:narrower</code> are
inverse properties. This statement means that</p>
<pre>&lt;A&gt; skos:narrower &lt;B&gt; .</pre>
<p>entails</p>
<pre>&lt;B&gt; skos:broader &lt;A&gt; .</pre>
<p>Both of these two graphs are, by themselves, consistent with the SKOS data
model.</p>
<p>Knowledge organization systems such as thesauri and classification schemes
are applied in a wide range of situations, and an individual knowledge
organization system can be used in many different information systems. By
defining the SKOS data model as an OWL Full ontology, the Semantic Web can
then be used as a medium for publishing, exchanging, sharing and linking
data involving these knowledge organization systems. For this reason, for the
expressiveness of OWL Full as a data modeling language, and for the
possibility of using thesauri, classification schemes, etc., side-by-side with
formal ontologies, OWL Full has been used to define the SKOS data model. The
open world assumption is therefore a fundamental premise of the SKOS data
model, and should be borne in mind when reading this document.</p>
<p>See also [<a class="citation" rel="citation"
href="#ref-RDF-PRIMER">RDF-PRIMER</a>] and [<a class="citation"
rel="citation" href="#ref-OWL-GUIDE">OWL-GUIDE</a>].</p>
</div>
<h3 id="rationale">1.6. Design Rationale</h3>
As discussed above, the notion of a Knowledge Organization System encompasses
a wide range of artifacts. There is thus a danger of overcommitment in the
SKOS schema, which could preclude the use of SKOS in some
applications. In order to alleviate this, in situations where there is doubt
about the inclusion of a formal constraint (for example, see the discussion about
<code>skos:hasTopConcept</code>), the constraint has not been stated
formally. In some cases, although no formal constraint is stated, usage conventions
are recommended. Applications that require more constrained behaviour may define
extensions to the SKOS vocabulary. See also the [<a class="citation" rel="citation" href="#ref-SKOS-PRIMER">SKOS-PRIMER</a>].
<div id="div-intro1">
<h3 id="L649">1.7. How to Read this Document</h3>
<p>This document formally defines the Simple Knowledge Organization System
data model as an OWL Full ontology. The elements of the SKOS data model are
OWL classes and properties, and a Uniform Resource Identifier (URI) is
provided for each of these classes and properties so that they may be used
unambiguously in the Web. This set of URIs is the SKOS vocabulary.</p>
<p>The complete SKOS vocabulary is given in section 2 below. Sections 3 to 10
then formally define the SKOS data model. The definition of the data model is
broken down into a number of sections purely for convenience. Each of these
sections 3 to 10 follows a common layout:</p>
<ul>
<li><strong>Preamble</strong> — the main ideas covered in the section are
introduced informally.</li>
<li><strong>Vocabulary</strong> — URIs from the SKOS vocabulary which are
defined in the section are given. </li>
<li><strong>Class &amp; Property Definitions</strong> — the logical
characteristics and interdependencies between the classes and properties
denoted by those URIs are formally defined.</li>
<li><strong>Integrity Conditions</strong> — if there are any integrity
conditions, those are given.</li>
<li><strong>Examples</strong> — some canonical examples are given, both
of data which <strong>are</strong> consistent with the SKOS data model,
and (where appropriate) of data which are <strong>not</strong> consistent
with the SKOS data model.</li>
<li><strong>Notes</strong> — any further notes and discussion are
presented.</li>
</ul>
<h4 id="L1291">1.7.1. Formal Definitions</h4>
<p>Most of the class and property definitions and integrity conditions stated
in this document could be stated as RDF triples, using the RDF, RDFS and OWL
vocabularies. However, a small number cannot, either because of limitations
in the expressiveness of OWL Full or lack of a standard URI for some class. To
improve the overall readability of this document, rather than mix RDF triples
and other notations, the formal definitions and integrity conditions are
stated throughout using prose. </p>
<p>The style of this prose generally follows the style used in [<a
class="citation" rel="citation" href="#ref-RDFS">RDFS</a>], and should be
clear to a reader with a working knowledge of RDF and OWL. </p>
<p>So, for example, "<code>ex:Person</code> is an instance of
<code>owl:Class</code>" means</p>
<pre>ex:Person rdf:type owl:Class .</pre>
<p>"<code>ex:hasParent</code> and <code>ex:hasMother</code> are each
instances of <code>owl:ObjectProperty</code>" means:</p>
<pre>ex:hasParent rdf:type owl:ObjectProperty .
ex:hasMother rdf:type owl:ObjectProperty .</pre>
<p>"<code>ex:hasMother</code> is a sub-property of <code>ex:hasParent</code>"
means</p>
<pre>ex:hasMother rdfs:subPropertyOf ex:hasParent .</pre>
<p>"the <code>rdfs:range</code> of <code>ex:hasParent</code> is the class
<code>ex:Person</code>" means:</p>
<pre>ex:hasParent rdfs:range ex:Person .</pre>
<p>Where some formal aspects of the SKOS data model cannot be stated as RDF
triples using either RDF, RDFS or OWL vocabularies, it should be clear to a
reader with a basic understanding of the RDF and OWL semantics how these
statements might be translated into formal conditions on the interpretation
of an RDF vocabulary (e.g., from <a href="#labels">Section 5</a>, "A resource has no more
than one value of <code>skos:prefLabel</code> per language tag" means for any
resource x, no two members of the set { y | &lt;x,y&gt; is in
IEXT(I(<code>skos:prefLabel</code>)) } share the same language tag, where I
and IEXT are functions as defined in [<a class="citation" rel="citation"
href="#ref-RDF-SEMANTICS">RDF-SEMANTICS</a>]).</p>
<h4 id="L1368">1.7.2. URI Abbreviations</h4>
<p>Full URIs are cited in the text of this document in monospace font,
enclosed by angle brackets, e.g.,
<code>&lt;http://example.org/ns/example&gt;</code>. Relative URIs are cited
in the same way, and are relative to the base URI
<code>&lt;http://example.org/ns/&gt;</code>, e.g.,
<code>&lt;example&gt;</code> and
<code>&lt;http://example.org/ns/example&gt;</code> are the same URI.</p>
<p>URIs are also cited in the text of this document in an abbreviated form.
Abbreviated URIs are cited in monospace font without angle brackets, and
should be expanded using the table of abbreviations below.</p>
<table border="0" class="vocab">
<caption>Table 1. URI Abbreviations</caption>
<tbody>
<tr>
<th>URI</th>
<th>Abbreviation</th>
</tr>
<tr>
<td><strong>http://www.w3.org/2004/02/skos/core#</strong></td>
<td><strong>skos:</strong></td>
</tr>
<tr>
<td>http://www.w3.org/1999/02/22-rdf-syntax-ns#</td>
<td>rdf:</td>
</tr>
<tr>
<td>http://www.w3.org/2000/01/rdf-schema#</td>
<td>rdfs:</td>
</tr>
<tr>
<td>http://www.w3.org/2002/07/owl#</td>
<td>owl:</td>
</tr>
</tbody>
</table>
<p>So, for example, <code>skos:Concept</code> is an abbreviation of
<code>&lt;http://www.w3.org/2004/02/skos/core#Concept&gt;</code>.</p>
<h4 id="L1501">1.7.3. Examples</h4>
<p>Examples of RDF graphs are given using the Terse RDF Triple language
(Turtle) [<a class="citation" rel="citation" href="#ref-TURTLE">TURTLE</a>].
All examples assume that they are preceded by the following prefix and URI
base directives:</p>
<pre>@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt; .
@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt; .
@prefix owl: &lt;http://www.w3.org/2002/07/owl#&gt; .<br />@prefix skos: &lt;http://www.w3.org/2004/02/skos/core#&gt; .<br />@base &lt;http://example.org/ns/&gt; .<br /></pre>
<p>Therefore, the example given below</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-1">Example 1</th>
</tr>
<tr>
<td>
<div>
&lt;MyConcept&gt; rdf:type skos:Concept .</div>
</td>
</tr>
</tbody>
</table>
<p>is equivalent to the following Turtle document</p>
<pre>@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt; .
@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt; .
@prefix owl: &lt;http://www.w3.org/2002/07/owl#&gt; .<br />@prefix skos: &lt;http://www.w3.org/2004/02/skos/core#&gt; .<br />@base &lt;http://example.org/ns/&gt; .
&lt;MyConcept&gt; rdf:type skos:Concept .</pre>
<p>which is equivalent to the following RDF/XML document [<a class="citation"
rel="citation" href="#ref-RDF-XML">RDF-XML</a>]</p>
<pre>&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;rdf:RDF <br />   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" <br /> xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" <br /> xmlns:skos="http://www.w3.org/2004/02/skos/core#"<br /> xmlns:owl="http://www.w3.org/2002/07/owl#"<br /> xml:base="http://example.org/ns/"&gt;
&lt;skos:Concept rdf:about="MyConcept"/&gt;
&lt;/rdf:RDF&gt;</pre>
<p>which is equivalent to the following N-TRIPLES document [<a
class="citation" rel="citation" href="#ref-NTRIPLES">NTRIPLES</a>]</p>
<pre>&lt;http://example.org/ns/MyConcept&gt; &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#type&gt; &lt;http://www.w3.org/2004/02/skos/core#Concept&gt; .</pre>
<p>Note the use in Turtle of the ";" and "," characters to abbreviate
multiple triples with the same subject or predicate. Some examples also make
use of the Turtle syntax "(...)", representing an RDF Collection.</p>
<p id="L8810"><a id="conformance"></a></p>
<h3 id="L434">1.8. Conformance</h3>
<p>This specification does not define a formal notion of conformance.</p>
<p>However, an RDF graph will be <strong>inconsistent</strong> with the SKOS
data model if that graph and the SKOS data model (as defined formally below)
taken together lead to a logical contradiction.</p>
<p>Where URIs are used to identify resources of type
<code>skos:Concept</code>, <code>skos:ConceptScheme</code>,
<code>skos:Collection</code> or <code>skosxl:Label</code>, this specification
<strong>does not</strong> require specific behavior when dereferencing those
URIs via the Web [<a class="citation" rel="citation"
href="#ref-WEBARCH">WEBARCH</a>]. It is, however, strongly recommended that
publishers of SKOS data follow the guidelines given in [<a class="citation"
rel="citation" href="#ref-COOLURIS">COOLURIS</a>] and [<a class="citation"
rel="citation" href="#ref-RECIPES">RECIPES</a>].</p>
<hr />
</div>
<div id="div-vocab">
<a id="vocab"></a>
<h2 id="L1302">2. SKOS Namespace and Vocabulary</h2>
<p>The SKOS namespace URI is:</p>
<ul>
<li><strong>http://www.w3.org/2004/02/skos/core#</strong></li>
</ul>
<p>The SKOS vocabulary is a set of URIs, given in the left-hand column in the
table below.</p>
<table border="0" class="vocab">
<caption>Table 1. SKOS Vocabulary</caption>
<tbody>
<tr>
<th>URI</th>
<th>Definition</th>
</tr>
<tr>
<td>skos:Concept</td>
<td><a href="#concepts">Section 3. The skos:Concept Class</a></td>
</tr>
<tr>
<td>skos:ConceptScheme</td>
<td><a href="#schemes">Section 4. Concept Schemes</a></td>
</tr>
<tr>
<td>skos:inScheme</td>
<td><a href="#schemes">Section 4. Concept Schemes</a></td>
</tr>
<tr>
<td>skos:hasTopConcept</td>
<td><a href="#schemes">Section 4. Concept Schemes</a></td>
</tr>
<tr>
<td>skos:topConceptOf</td>
<td><a href="#schemes">Section 4. Concept Schemes</a></td>
</tr>
<tr>
<td>skos:altLabel</td>
<td><a href="#labels">Section 5. Lexical Labels</a></td>
</tr>
<tr>
<td>skos:hiddenLabel</td>
<td><a href="#labels">Section 5. Lexical Labels</a></td>
</tr>
<tr>
<td>skos:prefLabel</td>
<td><a href="#labels">Section 5. Lexical Labels</a></td>
</tr>
<tr>
<td>skos:notation</td>
<td><a href="#notations">Section 6. Notations</a></td>
</tr>
<tr>
<td>skos:changeNote</td>
<td><a href="#notes">Section 7. Documentation Properties</a></td>
</tr>
<tr>
<td>skos:definition</td>
<td><a href="#notes">Section 7. Documentation Properties</a></td>
</tr>
<tr>
<td>skos:editorialNote</td>
<td><a href="#notes">Section 7. Documentation Properties</a></td>
</tr>
<tr>
<td>skos:example</td>
<td><a href="#notes">Section 7. Documentation Properties</a></td>
</tr>
<tr>
<td>skos:historyNote</td>
<td><a href="#notes">Section 7. Documentation Properties</a></td>
</tr>
<tr>
<td>skos:note</td>
<td><a href="#notes">Section 7. Documentation Properties</a></td>
</tr>
<tr>
<td>skos:scopeNote</td>
<td><a href="#notes">Section 7. Documentation Properties</a></td>
</tr>
<tr>
<td>skos:broader</td>
<td><a href="#semantic-relations">Section 8. Semantic Relations</a></td>
</tr>
<tr>
<td>skos:broaderTransitive</td>
<td><a href="#semantic-relations">Section 8. Semantic Relations</a></td>
</tr>
<tr>
<td>skos:narrower</td>
<td><a href="#semantic-relations">Section 8. Semantic Relations</a></td>
</tr>
<tr>
<td>skos:narrowerTransitive</td>
<td><a href="#semantic-relations">Section 8. Semantic Relations</a></td>
</tr>
<tr>
<td>skos:related</td>
<td><a href="#semantic-relations">Section 8. Semantic Relations</a></td>
</tr>
<tr>
<td>skos:semanticRelation</td>
<td><a href="#semantic-relations">Section 8. Semantic Relations</a></td>
</tr>
<tr>
<td>skos:Collection</td>
<td><a href="#collections">Section 9. Concept Collections</a></td>
</tr>
<tr>
<td>skos:OrderedCollection</td>
<td><a href="#collections">Section 9. Concept Collections</a></td>
</tr>
<tr>
<td>skos:member</td>
<td><a href="#collections">Section 9. Concept Collections</a></td>
</tr>
<tr>
<td>skos:memberList</td>
<td><a href="#collections">Section 9. Concept Collections</a></td>
</tr>
<tr>
<td>skos:broadMatch</td>
<td><a href="#mapping">Section 10. Mapping Properties</a></td>
</tr>
<tr>
<td>skos:closeMatch</td>
<td><a href="#mapping">Section 10. Mapping Properties</a></td>
</tr>
<tr>
<td>skos:exactMatch</td>
<td><a href="#mapping">Section 10. Mapping Properties</a></td>
</tr>
<tr>
<td>skos:mappingRelation</td>
<td><a href="#mapping">Section 10. Mapping Properties</a></td>
</tr>
<tr>
<td>skos:narrowMatch</td>
<td><a href="#mapping">Section 10. Mapping Properties</a></td>
</tr>
<tr>
<td>skos:relatedMatch</td>
<td><a href="#mapping">Section 10. Mapping Properties</a></td>
</tr>
</tbody>
</table>
<p>All URIs in the SKOS vocabulary are constructed by appending a local name
(e.g., "prefLabel") to the SKOS namespace URI. </p>
<p>See also the SKOS overview in <a href="#overview">Appendix B</a> and the
<a class="action" onclick="showQuickAccess()"
onkeypress="showQuickAccess()">quick access panel</a>.</p>
<hr />
</div>
<div id="div-conceptual-resources">
<a id="concepts"></a>
<h2 id="L1289">3. The skos:Concept Class</h2>
<h3 id="L1437">3.1. Preamble</h3>
<p>The class <code>skos:Concept</code> is the class of SKOS concepts.</p>
<p>A SKOS concept can be viewed as an idea or notion; a unit of thought.
However, what constitutes a unit of thought is subjective, and this
definition is meant to be suggestive, rather than restrictive. </p>
<p>The notion of a SKOS concept is useful when describing the conceptual or
intellectual structure of a knowledge organization system, and when referring
to specific ideas or meanings established within a KOS.</p>
<p>Note that, because SKOS is designed to be a vehicle for representing
semi-formal KOS, such as thesauri and classification schemes, a certain
amount of flexibility has been built in to the formal definition of this
class.</p>
<p>See the [<a class="citation" rel="citation" href="#ref-SKOS-PRIMER">SKOS-PRIMER</a>] for
more examples of identifying and describing SKOS concepts.</p>
<h3 id="L2039">3.2. Vocabulary</h3>
<table border="0" class="vocab">
<caption></caption>
<tbody>
<tr>
<td><code>skos:Concept</code></td>
</tr>
</tbody>
</table>
<h3 id="L842">3.3. Class &amp; Property Definitions</h3>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S1">S1</td>
<td><code>skos:Concept</code> is an instance of
<code>owl:Class</code>.</td>
</tr>
</tbody>
</table>
<h3 id="L2118">3.4. Examples</h3>
<p>The graph below states that <code>&lt;MyConcept&gt;</code> is a SKOS
concept (i.e., an instance of <code>skos:Concept</code>).</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-2">Example 2 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;MyConcept&gt; rdf:type skos:Concept .</div>
</td>
</tr>
</tbody>
</table>
<h3 id="L2145">3.5. Notes</h3>
<h4 id="L896">3.5.1. SKOS Concepts, OWL Classes and OWL Properties</h4>
<p>Other than the assertion that <code>skos:Concept</code> is an instance of
<code>owl:Class</code>, this specification does <strong>not</strong> make any
additional statement about the formal relationship between the class of SKOS
concepts and the class of OWL classes. The decision <strong>not</strong> to
make any such statement has been made to allow applications the freedom to
explore different design patterns for working with SKOS in combination with
OWL.</p>
<p>In the example graph below, <code>&lt;MyConcept&gt;</code> is an
instance of <code>skos:Concept</code> <strong>and</strong> an instance of
<code>owl:Class</code>.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-3">Example 3 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;MyConcept&gt; rdf:type skos:Concept , owl:Class .</div>
</td>
</tr>
</tbody>
</table>
<p>This example is <strong>consistent</strong> with the SKOS data
model.</p>
<p>Similarly, this specification does <strong>not</strong> make any
statement about the formal relationship between the class of SKOS
concepts and the class of OWL properties. </p>
<p>In the example graph below, <code>&lt;MyConcept&gt;</code> is
an instance of <code>skos:Concept</code> <strong>and</strong> an
instance of
<code>owl:ObjectProperty</code>.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-4">Example 4 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;MyConcept&gt; rdf:type skos:Concept , owl:ObjectProperty .</div>
</td>
</tr>
</tbody>
</table>
<p>This example is <strong>consistent</strong> with the SKOS data
model.</p>
<hr />
</div>
<div id="div-concept-schemes">
<a id="schemes"></a>
<h2 id="L2430">4. Concept Schemes</h2>
<h3 id="L1638">4.1. Preamble</h3>
<p>A SKOS concept scheme can be viewed as an aggregation of one or more SKOS
concepts. Semantic relationships (links) between those concepts may also be
viewed as part of a concept scheme. This definition is, however, meant to be
suggestive rather than restrictive, and there is some flexibility in the
formal data model stated below.</p>
<p>The notion of a concept scheme is useful when dealing with data from an
unknown source, and when dealing with data that describes two or more
different knowledge organization systems. </p>
<p>See the [<a class="citation" rel="citation" href="#ref-SKOS-PRIMER">SKOS-PRIMER</a>] for
more examples of identifying and describing concept schemes.</p>
<h3 id="L2457">4.2. Vocabulary</h3>
<table border="0" class="vocab">
<caption></caption>
<tbody>
<tr>
<td><code>skos:ConceptScheme</code></td>
</tr>
<tr>
<td><code>skos:inScheme</code></td>
</tr>
<tr>
<td><code>skos:hasTopConcept</code></td>
</tr>
<tr>
<td><code>skos:topConceptOf</code></td>
</tr>
</tbody>
</table>
<h3 id="L8421">4.3. Class &amp; Property Definitions</h3>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S2">S2</td>
<td><code>skos:ConceptScheme</code> is an instance of
<code>owl:Class</code>.</td>
</tr>
<tr>
<td id="S3">S3</td>
<td><code>skos:inScheme</code>, <code>skos:hasTopConcept</code> and
<code>skos:topConceptOf</code> are each instances of
<code>owl:ObjectProperty</code>.</td>
</tr>
<tr>
<td id="S4">S4</td>
<td>The <code>rdfs:range</code> of <code>skos:inScheme</code> is the
class <code>skos:ConceptScheme</code>.</td>
</tr>
<tr>
<td id="S5">S5</td>
<td>The <code>rdfs:domain</code> of <code>skos:hasTopConcept</code> is
the class <code>skos:ConceptScheme</code>.</td>
</tr>
<tr>
<td id="S6">S6</td>
<td>The <code>rdfs:range</code> of <code>skos:hasTopConcept</code> is
the class <code>skos:Concept</code>.</td>
</tr>
<tr>
<td id="S7">S7</td>
<td><code>skos:topConceptOf</code> is a sub-property of
<code>skos:inScheme</code>.</td>
</tr>
<tr>
<td id="S8">S8</td>
<td><code>skos:topConceptOf</code> is <code>owl:inverseOf</code>
the property <code>skos:hasTopConcept</code>.</td>
</tr>
</tbody>
</table>
<h3 id="L1228">4.4. Integrity Conditions</h3>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S9">S9</td>
<td><code>skos:ConceptScheme</code> is disjoint with
<code>skos:Concept</code>.</td>
</tr>
</tbody>
</table>
<h3 id="L21181">4.5. Examples</h3>
<p>The graph below describes a concept scheme with two SKOS concepts, one of
which is a top-level concept in that scheme.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-5">Example 5 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;MyScheme&gt; rdf:type skos:ConceptScheme ; <br />
  skos:hasTopConcept &lt;MyConcept&gt; . <br />
<br />
&lt;MyConcept&gt; skos:topConceptOf &lt;MyScheme&gt; . <br />
<br />
&lt;AnotherConcept&gt; skos:inScheme &lt;MyScheme&gt; .</div>
</td>
</tr>
</tbody>
</table>
<h3 id="L2497">4.6. Notes</h3>
<h4 id="L1101">4.6.1. Closed vs. Open Systems</h4>
<p>The notion of an individual SKOS concept scheme corresponds
<strong>roughly</strong> to the notion of an individual thesaurus,
classification scheme, subject heading system or other knowledge organization
system. </p>
<p>However, in most current information systems, a thesaurus or
classification scheme is treated as a <strong>closed system</strong>
conceptual units defined within that system cannot take part in other systems
(although they can be <em>mapped</em> to units in other systems).</p>
<p>Although SKOS does take a similar approach, there are <strong>no</strong>
conditions preventing a SKOS concept from taking part in zero, one, or more
than one concept scheme. </p>
<p>So, for example, in the graph below the SKOS concept
<code>&lt;MyConcept&gt;</code> takes part in two different concept schemes
— this is <strong>consistent</strong> with the SKOS data model.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-6">Example 6 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;MyScheme&gt; rdf:type skos:ConceptScheme . <br />
<br />
&lt;AnotherScheme&gt; rdf:type skos:ConceptScheme ; <br />
  owl:differentFrom &lt;MyScheme&gt; . <br />
<br />
&lt;MyConcept&gt; skos:inScheme &lt;MyScheme&gt; ,
&lt;AnotherScheme&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>This flexibility is desirable because it allows, for example, new concept
schemes to be described by linking two or more existing concept schemes
together. </p>
<p>Also, note that there is no way to close the boundary of a concept scheme.
So, while it is possible using <code>skos:inScheme</code> to say that SKOS
concepts X, Y and Z take part in concept scheme A, there is no way to say
that <strong>only</strong> X, Y and Z take part in A. </p>
<p>Therefore, while SKOS can be used to <strong>describe</strong> a concept
scheme, SKOS does not provide any mechanism to completely
<strong>define</strong> a concept scheme.</p>
<h4 id="L1170">4.6.2. SKOS Concept Schemes and OWL Ontologies</h4>
<p>This specification does <strong>not</strong> make any statement about the
formal relationship between the class of SKOS concept schemes and the class
of OWL ontologies. The decision <strong>not</strong> to make any such
statement has been made to allow different design patterns to be explored for
using SKOS in combination with OWL [<a class="citation" rel="citation"
href="#ref-OWL-GUIDE">OWL-GUIDE</a>].</p>
<p>In the example graph below, <code>&lt;MyScheme&gt;</code> is
both a SKOS concept scheme and an OWL ontology. This
is <strong>consistent</strong> with the SKOS data model.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-7">Example 7 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;MyScheme&gt; rdf:type skos:ConceptScheme , owl:Ontology . <br />
<br />
&lt;MyConcept&gt; skos:inScheme &lt;MyScheme&gt; .</div>
</td>
</tr>
</tbody>
</table>
<h4 id="L2446">4.6.3. Top Concepts and Semantic Relations</h4>
<p>The property <code>skos:hasTopConcept</code> is, by convention, used to
link a concept scheme to the SKOS concept(s) which are topmost in the
hierarchical relations for that scheme. However, there are no integrity
conditions enforcing this convention. Therefore, the graph below, whilst not
strictly adhering to the usage convention for
<code>skos:hasTopConcept</code>, is nevertheless <strong>consistent</strong>
with the SKOS data model. </p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-8">Example 8 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;MyScheme&gt; skos:hasTopConcept &lt;MyConcept&gt; .<br />
&lt;MyConcept&gt; skos:broader &lt;AnotherConcept&gt; .<br />
&lt;AnotherConcept&gt; skos:inScheme &lt;MyScheme&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>An application may reject such data but is not required to.</p>
<h4 id="L2577">4.6.4. Scheme Containment and Semantic Relations</h4>
<p>A link between two SKOS concepts <strong>does not</strong> entail
containment within the same concept scheme. This is illustrated in the
example below.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-9">Example 9 (non-entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:narrower &lt;B&gt; .<br />
&lt;A&gt; skos:inScheme &lt;MyScheme&gt; .</div>
<p><em>does not entail</em></p>
<div>
&lt;B&gt; skos:inScheme &lt;MyScheme&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>See also <a href="#semantic-relations">Section 8</a> below.</p>
<h4 id="L2805">4.6.5. Domain of skos:inScheme</h4>
<p>Note that <strong>no domain is stated</strong> for the property
<code>skos:inScheme</code>, i.e., the domain is effectively the class of all
resources (<code>rdfs:Resource</code>). The decision not to state any domain
has been made to provide some flexibility, enabling extensions to SKOS to
define new classes of resource but still use <code>skos:inScheme</code> to
link them to a <code>skos:ConceptScheme</code>. See also <a
href="#example-82">example 82</a> below.</p>
<hr />
</div>
<div id="div-lexical-labels">
<a id="labels"></a>
<h2 id="L2831">5. Lexical Labels</h2>
<h3 id="L2007">5.1. Preamble</h3>
<p>A lexical label is a string of UNICODE characters, such as "romantic love"
or "れんあい", in a given natural language, such as English or Japanese (written here in hiragana). </p>
<p>The Simple Knowledge Organization System provides some basic vocabulary
for associating lexical labels with resources of any type. In particular,
SKOS enables a distinction to be made between the preferred, alternative
and "hidden" lexical labels for any given resource. </p>
<p>The preferred and alternative labels are useful when generating or
creating human-readable representations of a knowledge organization system.
These labels provide the strongest clues as to the meaning of a SKOS
concept.</p>
<p>The hidden labels are useful when a user is interacting with a knowledge
organization system via a text-based search function. The user may, for
example, enter mis-spelled words when trying to find a relevant concept. If
the mis-spelled query can be matched against a hidden label, the user will
be able to find the relevant concept, but the hidden label won't otherwise
be visible to the user (so further mistakes aren't encouraged).</p>
<p>Formally, a lexical label is an RDF plain literal [<a class="citation"
rel="citation" href="#ref-RDF-CONCEPTS">RDF-CONCEPTS</a>]. An RDF plain
literal is composed of a lexical form, which is a string of UNICODE
characters, and an optional language tag, which is a string of characters
conforming to the syntax defined by [<a class="citation" rel="citation"
href="#ref-BCP47">BCP47</a>].</p>
<p>See the [<a class="citation" rel="citation" href="#ref-SKOS-PRIMER">SKOS-PRIMER</a>] for
more examples of labeling SKOS concepts. Note especially that the examples below
serve only to illustrate general features of the SKOS data model, and <strong>do not</strong> necessarily indicate best practice for the provision of labels with
different language tags. The SKOS Reference aims to establish a data model
that is applicable across a range of situations, which may then be refined and/or
constrained by usage conventions for more specific situations. Application- and
language-specific usage conventions with respect to labels and language tags
are out of scope for the SKOS Reference.</p>
<h3 id="L1304">5.2. Vocabulary</h3>
<table border="0" class="vocab">
<caption></caption>
<tbody>
<tr>
<td><code>skos:prefLabel</code></td>
</tr>
<tr>
<td><code>skos:altLabel</code></td>
</tr>
<tr>
<td><code>skos:hiddenLabel</code></td>
</tr>
</tbody>
</table>
<h3 id="L1329">5.3. Class &amp; Property Definitions</h3>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S10">S10</td>
<td><code></code><code>skos:prefLabel</code>,
<code>skos:altLabel</code> and <code>skos:hiddenLabel</code> are each
instances of <code>owl:AnnotationProperty</code>.</td>
</tr>
<tr>
<td id="S11">S11</td>
<td><code></code><code>skos:prefLabel</code>,
<code>skos:altLabel</code> and <code>skos:hiddenLabel</code> are each
sub-properties of <code>rdfs:label</code>.</td>
</tr>
<tr>
<td id="S12">S12</td>
<td>The <code>rdfs:range</code> of each of <code>skos:prefLabel</code>,
<code>skos:altLabel</code> and <code>skos:hiddenLabel</code> is the
class of RDF plain literals.</td>
</tr>
</tbody>
</table>
<h3 id="L1567">5.4. Integrity Conditions</h3>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S13">S13</td>
<td><code>skos:prefLabel</code>, <code>skos:altLabel</code> and
<code>skos:hiddenLabel</code> are pairwise disjoint properties.</td>
</tr>
<tr>
<td id="S14">S14</td>
<td><code></code>A resource has no more than one value of
<code>skos:prefLabel</code> per language tag.</td>
</tr>
</tbody>
</table>
<h3 id="L1409">5.5. Examples</h3>
<p>The following graph is <strong>consistent</strong>, and illustrates the
provision of lexical labels in two different languages (French and
English).</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-10">Example 10 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;MyResource&gt; <br />
  skos:prefLabel "animals"@en ; <br />
  skos:altLabel "fauna"@en ; <br />
  skos:hiddenLabel "aminals"@en ; <br />
  skos:prefLabel "animaux"@fr ; <br />
  skos:altLabel "faune"@fr .</div>
</td>
</tr>
</tbody>
</table>
<p>The following graph is <strong>consistent</strong> and illustrates the provision of lexical labels in four different variations (Japanese written with
kanji, the hiragana script, the katakana script or with latin characters (rōmaji)).</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-11">Example 11 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;AnotherResource&gt; <br />
  skos:prefLabel "東"@ja-Hani ; <br />
  skos:prefLabel "ひがし"@ja-Hira ; <br />
  skos:altLabel "あずま"@ja-Hira ; <br />
  skos:prefLabel "ヒガシ"@ja-Kana ; <br />
  skos:altLabel "アズマ"@ja-Kana ; <br />
  skos:prefLabel "higashi"@ja-Latn ; <br />
  skos:altLabel "azuma"@ja-Latn .</div>
</td>
</tr>
</tbody>
</table>
<p>The following graph is <strong>not consistent</strong> with the SKOS data
model, because two different preferred lexical labels have been given with the
same language tag.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-12">Example 12 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;Love&gt; skos:prefLabel "love"@en ; skos:prefLabel "adoration"@en
.</div>
</td>
</tr>
</tbody>
</table>
<p>The following graph is <strong>not consistent</strong> with the SKOS data
model, because there is a clash between the preferred and alternative lexical
labels.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-13">Example 13 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;Love&gt; skos:prefLabel "love"@en ; skos:altLabel "love"@en
.</div>
</td>
</tr>
</tbody>
</table>
<p>The following graph is <strong>not consistent</strong> with the SKOS data
model, because there is a clash between alternative and hidden lexical
labels.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-14">Example 14 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;Love&gt; skos:altLabel "love"@en ; skos:hiddenLabel "love"@en
.</div>
</td>
</tr>
</tbody>
</table>
<p>The following graph is <strong>not consistent</strong> with the SKOS data
model, because there is a clash between preferred and hidden lexical
labels.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-15">Example 15 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;Love&gt; skos:prefLabel "love"@en ; skos:hiddenLabel "love"@en
.</div>
</td>
</tr>
</tbody>
</table>
<h3 id="L1539">5.6. Notes</h3>
<h4 id="L1541">5.6.1. Domain of SKOS Lexical Labeling Properties</h4>
<p>Note that <strong>no domain is stated</strong> for
<code>skos:prefLabel</code>, <code>skos:altLabel</code> and
<code>skos:hiddenLabel</code>. Thus, the effective domain of these properties
is the class of all resources (<code>rdfs:Resource</code>). </p>
<p>Therefore, using the properties <code>skos:prefLabel</code>,
<code>skos:altLabel</code> and <code>skos:hiddenLabel</code> to <strong>label
any type of resource</strong> is <strong>consistent</strong> with the SKOS
data model.</p>
<p>In the example graph below, <code>skos:prefLabel</code>,
<code>skos:altLabel</code> and <code>skos:hiddenLabel</code> have been used
to label a resource of type <code>owl:Class</code> — this is
<strong>consistent</strong> with the SKOS data model.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-16">Example 16 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;MyClass&gt; rdf:type owl:Class ; <br />
  skos:prefLabel "animals"@en ; <br />
  skos:altLabel "fauna"@en ; <br />
  skos:hiddenLabel "aminals"@en ; <br />
  skos:prefLabel "animaux"@fr ; <br />
  skos:altLabel "faune"@fr .</div>
</td>
</tr>
</tbody>
</table>
<h4 id="L1581">5.6.2. Range of SKOS Lexical Labeling Properties</h4>
<p>Note that the range of <code>skos:prefLabel</code>,
<code>skos:altLabel</code> and <code>skos:hiddenLabel</code> is the class of
RDF plain literals [<a class="citation" rel="citation"
href="#ref-RDF-CONCEPTS">RDF-CONCEPTS</a>]. </p>
<p>By convention, RDF plain literals are always used in the object position
of a triple, where the predicate is one of <code>skos:prefLabel</code>,
<code>skos:altLabel</code> or <code>skos:hiddenLabel</code>. If a
graph <strong>does not</strong> follow this usage convention an
application may reject such data but is not required to. See also the
note below.</p>
<h4 id="L3260">5.6.3. Defining Label Relations</h4>
<p>Some applications require additional functionality relating to labels, for
example allowing the description of those labels or the definition of
additional relations between the labels (such as acronyms). This can be
achieved through the identification of labels using URIs. The SKOS eXtension
for Labels defined in <a href="#xl">Appendix A</a> provides support for
this.</p>
<h4 id="L1606">5.6.4. Alternates Without Preferred</h4>
<p>In the graph below, a resource has two alternative lexical labels, but no
preferred lexical label. This is <strong>consistent</strong> with the SKOS
data model, and there are no additional entailments which follow from the
data model. However, note that many applications will require a preferred
lexical label in order to generate an optimum human-readable display.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-17">Example 17 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;Love&gt; skos:altLabel "adoration"@en , "desire"@en .</div>
</td>
</tr>
</tbody>
</table>
<h4 id="L1629">5.6.5. Labeling and Language Tags</h4>
<p>[<a class="citation" rel="citation" href="#ref-BCP47">BCP47</a>]
defines tags for identifying languages. Note that "en", "en-GB", "en-US" are
three different language
tags, used with English, British English and US English respectively.
Similarly "ja", "ja-Hani", "ja-Hira", "ja-Kana" and "ja-Latn" are five
different language tags used with Japanese, Japanese written with
kanji, the hiragana script, the katakana script or with latin characters (rōmaji) respectively.</p>
<p>The graph below is <strong>consistent</strong> with the SKOS data
model, because "en", "en-US" and "en-GB" are different language tags.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-18">Example 18 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;Colour&gt; skos:prefLabel "color"@en , "color"@en-US ,
"colour"@en-GB .</div>
</td>
</tr>
</tbody>
</table>
<p>In the graph below, there is no clash between the lexical labeling
properties, again because "en" and "en-GB" are different language tags, and
therefore the graph is <strong>consistent</strong> with the SKOS data model. </p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-19">Example 19 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;Love&gt; skos:prefLabel "love"@en ; skos:altLabel "love"@en-GB
.</div>
</td>
</tr>
</tbody>
</table>
<p>Note however that, as stated above in section 5.1, these examples serve only to illustrate general features of the SKOS data model, and <strong>do not</strong> necessarily indicate best practice for the provision of labels with different language tags. Application- and language-specific usage conventions with respect to labels and language tags are out of scope for the SKOS Reference.</p>
<p>It is suggested that applications match requests for labels in a
given language to labels with related language tags that are provided by a SKOS concept scheme, e.g., by implementing the "lookup" algorithm defined by [<a href="#ref-BCP47">BCP
47</a>]. Applications that perform matching in this way do not require labels to be provided in all possible language variations (of which there could be many), and are compatible with SKOS concept schemes that
provide only those labels whose lexical forms are distinct for a given
language or collection of languages.</p>
<hr />
</div>
<div id="div-notations">
<a id="notations"></a>
<h2 id="L2064">6. Notations</h2>
<h3 id="L2531">6.1. Preamble</h3>
<p>A notation is a string of characters such as "T58.5" or "303.4833" used to
uniquely identify a concept within the scope of a given concept scheme. </p>
<p>A notation is different from a lexical label in that a notation is not
normally recognizable as a word or sequence of words in any natural
language.</p>
<p>This section defines the <code>skos:notation</code> property. This
property is used to assign a notation as a typed literal
[<a class="citation" rel="citation"
href="#ref-RDF-CONCEPTS">RDF-CONCEPTS</a>].
</p>
<h3 id="L2542">6.2. Vocabulary</h3>
<table border="0" class="vocab">
<caption></caption>
<tbody>
<tr>
<td><code>skos:notation</code></td>
</tr>
</tbody>
</table>
<h3 id="L2557">6.3. Class &amp; Property Definitions</h3>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S15">S15</td>
<td><code></code><code>skos:notation</code> is an instance of
<code>owl:DatatypeProperty</code>.</td>
</tr>
</tbody>
</table>
<h3 id="L2584">6.4. Examples</h3>
<p>The example below illustrates a resource
<code>&lt;http://example.com/ns/MyConcept&gt;</code> with a notation whose
lexical form is the UNICODE string "303.4833" and whose datatype is denoted
by the URI <code>&lt;http://example.com/ns/MyNotationDatatype&gt;</code>.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-20">Example 20 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;MyConcept&gt; skos:notation
"303.4833"^^&lt;MyNotationDatatype&gt; .</div>
</td>
</tr>
</tbody>
</table>
<h3 id="L2611">6.5. Notes</h3>
<h4 id="L2613">6.5.1. Notations, Typed Literals and Datatypes</h4>
<p>A typed literal is a UNICODE string combined with a datatype URI [<a
class="citation" rel="citation" href="#ref-RDF-CONCEPTS">RDF-CONCEPTS</a>].
</p>
<p>Typed literals are commonly used to denote values such as integers,
floating point numbers and dates, and there are a number of datatypes
pre-defined by the XML Schema specification [<a class="citation"
rel="citation" href="#ref-XML-SCHEMA">XML-SCHEMA</a>] such as
<code>xs:integer</code>, <code>xs:float</code> and <code>xs:date</code>.</p>
<p>For other situations, new datatypes can be defined, and these are
commonly called "user-defined datatypes" [<a class="citation"
rel="citation" href="#ref-SWBP-DATATYPES">SWBP-DATATYPES</a>]. </p>
<p>By convention, the property <code>skos:notation</code> is only used with a
typed literal in the object position of the triple, where the datatype URI
denotes a user-defined datatype corresponding to a particular system of
notations or classification codes. </p>
<p>For many situations it may be sufficient to simply coin a datatype URI for
a particular notation system, and define the datatype informally via a
document that describes how the notations are constructed and/or which
lexical forms are allowed. Note, however, that it is also possible to define
at least the lexical space of a datatype more formally via the XML Schema
language, see [<a class="citation" rel="citation"
href="#ref-SWBP-DATATYPES">SWBP-DATATYPES</a>] section 2. Users
should be aware that tools may vary in their support of
datatypes. However, as discussed in [<a class="citation"
rel="citation" href="#ref-OWL-REFERENCE">OWL-REFERENCE</a>] section
6.3, tools should at least treat lexically identical literals as
equal.</p>
<h4 id="L2637">6.5.2. Multiple Notations</h4>
<p>There are no constraints on the cardinality of the
<code>skos:notation</code> property. A concept may have zero, 1 or more
notations. </p>
<p>Where a concept has more than 1 notation, these may be from the same or
different notation systems. In the case where notations are from different
systems, different datatypes may be used to indicate this. It is not
common practice to assign more than one notation from the same notation
system (i.e., with the same datatype URI). </p>
<h4 id="L2646">6.5.3. Unique Notations in Concept Schemes</h4>
<p>By convention, no two concepts in the same concept scheme are given the
same notation. If they were, it would not be possible to use the notation to
uniquely refer to a concept (i.e., the notation would become ambiguous). </p>
<h4 id="L2655">6.5.4. Notations and Preferred Labels</h4>
<p>There are no constraints on the combined use of <code>skos:notation</code>
and <code>skos:prefLabel</code>. In the example below, the same string is
given both as the lexical form of a notation and as a the lexical form of a
preferred label.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-21">Example 21 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;Potassium&gt; <br />
  skos:prefLabel "K"@en ;<br />
  skos:notation "K"^^&lt;ChemicalSymbolNotation&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>Typed literals consist of a string of characters and a datatype
URI. By convention, <code>skos:notation</code> is only used
with <strong>typed literals</strong> in the object position of the
triple.</p>
<p>Plain literals consist of a string of characters and a language tag. By
convention, <code>skos:prefLabel</code> (and <code>skos:altLabel</code> and
<code>skos:hiddenLabel</code>) are only used with <strong>plain
literals</strong> in the object position of the triple.</p>
<p>There is no such thing as an RDF literal with both a language tag and a
datatype URI, i.e., a typed literal does not have a language tag, and a plain
literal does not have a datatype URI.</p>
<h4 id="notations-note-domain">6.5.5. Domain of skos:notation</h4>
<p>Note that <strong>no domain is stated</strong> for <code>skos:notation</code>. Thus, the
effective domain is the class of all resources (<code>rdfs:Resource</code>).
Therefore, using <code>skos:notation</code> with any type of resource is
consistent with the SKOS data model.</p>
<hr />
</div>
<div id="div-notes">
<a id="notes"></a>
<h2 id="L2860">7. Documentation Properties (Note Properties)</h2>
<h3 id="L2543">7.1. Preamble</h3>
<p>Notes are used to provide information relating to SKOS concepts. There is
no restriction on the nature of this information, e.g., it could be
plain text, hypertext, or an image; it could be a definition, information
about the scope of a concept, editorial information, or any other type of
information. </p>
<p>There are seven properties in SKOS for associating notes with concepts,
defined formally in this section. For more information on the recommended
usage of each of the SKOS documentation properties, see the [<a class="citation" rel="citation" href="#ref-SKOS-PRIMER">SKOS-PRIMER</a>].</p>
<p>These seven properties are not intended to cover every situation, but
rather to be useful in some of the most common situations, and to provide a
set of extension points for defining more specific types of note. For more
information on recommended best practice for extending SKOS, see the [<a class="citation" rel="citation" href="#ref-SKOS-PRIMER">SKOS-PRIMER</a>].</p>
<p>Three different usage patterns are recommended in the [<a class="citation" rel="citation" href="#ref-SKOS-PRIMER">SKOS-PRIMER</a>] for the SKOS
documentation properties — "documentation as an RDF literal",
"documentation as a related resource description" and "documentation as a
document reference". The data model defined in this section is intended
to accommodate all three design patterns.</p>
<h3 id="L1693">7.2. Vocabulary</h3>
<table border="0" class="vocab">
<caption></caption>
<tbody>
<tr>
<td><code>skos:note</code></td>
</tr>
<tr>
<td><code>skos:changeNote</code></td>
</tr>
<tr>
<td><code>skos:definition</code></td>
</tr>
<tr>
<td><code>skos:editorialNote</code></td>
</tr>
<tr>
<td><code>skos:example</code></td>
</tr>
<tr>
<td><code>skos:historyNote</code></td>
</tr>
<tr>
<td><code>skos:scopeNote</code></td>
</tr>
</tbody>
</table>
<h3 id="L1738">7.3. Class &amp; Property Definitions</h3>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S16">S16</td>
<td><code></code><code>skos:note</code>, <code>skos:changeNote</code>,
<code>skos:definition</code>, <code>skos:editorialNote</code>,
<code>skos:example</code>, <code>skos:historyNote</code> and
<code>skos:scopeNote</code> are each instances of
<code>owl:AnnotationProperty</code>.</td>
</tr>
<tr>
<td id="S17">S17</td>
<td><code>skos:changeNote</code>, <code>skos:definition</code>,
<code>skos:editorialNote</code>, <code>skos:example</code>,
<code>skos:historyNote</code> and <code>skos:scopeNote</code> are
each sub-properties of <code>skos:note</code>.</td>
</tr>
</tbody>
</table>
<h3 id="L1812">7.4. Examples</h3>
<p>The graph below gives an example of the "documentation as an RDF literal"
pattern.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-22">Example 22 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;MyResource&gt; skos:note "this is a note"@en .</div>
</td>
</tr>
</tbody>
</table>
<p>The graph below gives an example of the "documentation as a document
reference" pattern.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-23">Example 23 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;MyResource&gt; skos:note &lt;MyNote&gt; .</div>
</td>
</tr>
</tbody>
</table>
<h3 id="L1877">7.5. Notes</h3>
<h4 id="L1879">7.5.1. Domain of the SKOS Documentation Properties</h4>
<p>Note that <strong>no domain is stated</strong> for the SKOS documentation
properties. Thus, the effective domain for these properties is the class of
all resources (<code>rdfs:Resource</code>). Therefore, using the SKOS
documentation properties to provide information on <strong>any type of
resource</strong> is consistent with the SKOS data model.</p>
<p>In the example graph below, <code>skos:definition</code> has been
used to provide a plain text definition for a resource of type
<code>owl:Class</code> — this is consistent with the SKOS data model.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-24">Example 24 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;Protein&gt; rdf:type owl:Class ;<br />
  skos:definition """A physical entity consisting of a sequence of
amino-acids; a protein monomer; a single polypeptide chain. An
example is the EGFR protein."""@en .</div>
</td>
</tr>
</tbody>
</table>
<h4 id="L1917">7.5.2. Range of the SKOS Documentation
Properties</h4>
<p>Note that no range is stated for the SKOS documentation properties,
and thus the range of these properties is effectively the class of all
resources (<code>rdfs:Resource</code>). Under the RDF and OWL Full semantics,
everything is a resource, including RDF plain literals.</p>
<hr />
</div>
<div id="div-semantic-relations">
<a id="semantic-relations"></a>
<h2 id="L1930">8. Semantic Relations</h2>
<h3 id="L2810">8.1. Preamble</h3>
<p>SKOS semantic relations are links between SKOS concepts, where the link is
inherent in the meaning of the linked concepts. </p>
<p>The Simple Knowledge Organization System distinguishes between two basic
categories of semantic relation: <strong>hierarchical</strong> and
<strong>associative</strong>. A hierarchical link between two concepts
indicates that one is in some way more general ("broader") than the other
("narrower"). An associative link between two concepts indicates that the two
are inherently "related", but that one is <strong>not</strong> in any way
more general than the other.</p>
<p>The properties <code>skos:broader</code> and <code>skos:narrower</code>
are used to assert a direct hierarchical link between two SKOS concepts. A
triple <code>&lt;A&gt; skos:broader &lt;B&gt;</code> asserts that
<code>&lt;B&gt;</code>, the object of the triple, is a broader concept than
<code>&lt;A&gt;</code>, the subject of the triple. Similarly, a triple
<code>&lt;C&gt; skos:narrower &lt;D&gt;</code> asserts that
<code>&lt;D&gt;</code>, the object of the triple, is a narrower concept than
<code>&lt;C&gt;</code>, the subject of the triple. </p>
<p>By convention, <code>skos:broader</code> and <code>skos:narrower</code>
are <strong>only</strong> used to assert a <strong>direct</strong> (i.e.,
immediate) hierarchical link between two SKOS concepts. This provides
applications with a convenient and reliable way to access the direct broader
and narrower links for any given concept. Note that, to support this usage
convention, the properties <code>skos:broader</code> and
<code>skos:narrower</code> are <strong>not</strong> declared as transitive
properties. </p>
<p>Some applications need to make use of <strong>both direct and
indirect</strong> hierarchical links between concepts, for instance to
improve search recall through query expansion. For this purpose, the
properties <code>skos:broaderTransitive</code> and
<code>skos:narrowerTransitive</code> are provided. A triple
<code>&lt;A&gt;</code> <code>skos:broaderTransitive</code>
<code>&lt;B&gt;</code> represents a direct or indirect hierarchical link,
where <code>&lt;B&gt;</code> is a broader "ancestor" of
<code>&lt;A&gt;</code>. Similarly a triple <code>&lt;C&gt;
skos:narrowerTransitive &lt;D&gt;</code> represents a direct or indirect
hierarchical link, where <code>&lt;D&gt;</code> is a narrower "descendant" of
<code>&lt;C&gt;</code>. </p>
<p>By convention, the properties <code>skos:broaderTransitive</code> and
<code>skos:narrowerTransitive</code> are <strong>not</strong> used to make
assertions. Rather, these properties are used to infer the transitive closure
of the hierarchical links, which can then be used to access direct or
indirect hierarchical links between concepts. </p>
<p>The property <code>skos:related</code> is used to assert an associative
link between two SKOS concepts.</p>
<p>For more examples of stating hierarchical and associative links, see the
[<a class="citation" rel="citation" href="#ref-SKOS-PRIMER">SKOS-PRIMER</a>].</p>
<h3 id="L2010">8.2. Vocabulary</h3>
<table border="0" class="vocab">
<caption></caption>
<tbody>
<tr>
<td><code>skos:semanticRelation</code></td>
</tr>
<tr>
<td><code>skos:broader</code></td>
</tr>
<tr>
<td><code>skos:narrower</code></td>
</tr>
<tr>
<td><code>skos:related</code></td>
</tr>
<tr>
<td><code>skos:broaderTransitive</code></td>
</tr>
<tr>
<td><code>skos:narrowerTransitive</code></td>
</tr>
</tbody>
</table>
<h3 id="L2055">8.3. Class &amp; Property Definitions</h3>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S18">S18</td>
<td><code></code><code>skos:semanticRelation</code>,
<code>skos:broader</code>, <code>skos:narrower</code>,
<code>skos:related</code>, <code>skos:broaderTransitive</code> and
<code>skos:narrowerTransitive</code> are each instances of
<code>owl:ObjectProperty</code>.</td>
</tr>
<tr>
<td id="S19">S19</td>
<td>The <code>rdfs:domain</code> of <code>skos:semanticRelation</code>
is the class <code>skos:Concept</code>.</td>
</tr>
<tr>
<td id="S20">S20</td>
<td>The <code>rdfs:range</code> of <code>skos:semanticRelation</code>
is the class <code>skos:Concept</code>.</td>
</tr>
<tr>
<td id="S21">S21</td>
<td><code>skos:broaderTransitive</code>,
<code>skos:narrowerTransitive</code> and <code>skos:related</code>
are each sub-properties of <code>skos:semanticRelation</code>.</td>
</tr>
<tr>
<td id="S22">S22</td>
<td><code>skos:broader</code> is a sub-property of
<code>skos:broaderTransitive</code>, and <code>skos:narrower</code>
is a sub-property of <code>skos:narrowerTransitive</code>.</td>
</tr>
<tr>
<td id="S23">S23</td>
<td><code>skos:related</code> is an instance of
<code>owl:SymmetricProperty</code>.</td>
</tr>
<tr>
<td id="S24">S24</td>
<td><code>skos:broaderTransitive</code> and
<code>skos:narrowerTransitive</code> are each instances of
<code>owl:TransitiveProperty</code>.</td>
</tr>
<tr>
<td id="S25">S25</td>
<td><code>skos:narrower</code> is <code>owl:inverseOf</code> the
property <code>skos:broader</code>.</td>
</tr>
<tr>
<td id="S26">S26</td>
<td><code>skos:narrowerTransitive</code> is
<code>owl:inverseOf</code> the property
<code>skos:broaderTransitive</code>. </td>
</tr>
</tbody>
</table>
<h3 id="L2422">8.4. Integrity Conditions</h3>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S27">S27</td>
<td><code>skos:related</code> is disjoint with the property
<code>skos:broaderTransitive</code>.</td>
</tr>
</tbody>
</table>
<p>Note that because <code>skos:related</code> is a symmetric property, and
<code>skos:broaderTransitive</code> and <code>skos:narrowerTransitive</code>
are inverses, <code>skos:related</code> is therefore also disjoint with
<code>skos:narrowerTransitive</code>.</p>
<h3 id="L2157">8.5. Examples</h3>
<p>The graph below asserts a direct hierarchical link between
<code>&lt;A&gt;</code> and <code>&lt;B&gt;</code> (where
<code>&lt;B&gt;</code> is broader than <code>&lt;A&gt;</code>), and an
associative link between <code>&lt;A&gt;</code> and <code>&lt;C&gt;</code>,
and is <strong>consistent</strong> with the SKOS data model.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-25">Example 25 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broader &lt;B&gt; ; skos:related &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>The graph below is <strong>not consistent</strong> with the SKOS data
model, because there is a clash between associative links and hierarchical
links.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-26">Example 26 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broader &lt;B&gt; ; skos:related &lt;B&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>The graph below is <strong>not consistent</strong> with the SKOS data
model, again because there is a clash between associative links and
hierarchical links. </p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-27">Example 27 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broader &lt;B&gt; ; skos:related &lt;C&gt; .<br />
&lt;B&gt; skos:broader &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>In the example above, the clash is not immediately obvious. The clash
becomes apparent when inferences are drawn, based on the class and property
definitions above, giving the following graph.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-28">Example 28 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broaderTransitive &lt;C&gt; ; skos:related &lt;C&gt;
.<br />
</div>
</td>
</tr>
</tbody>
</table>
<p>The graph below is <strong>not consistent</strong> with the SKOS data
model, again because there is a clash between associative links and
hierarchical links, which can be inferred from the class and property
definitions given above.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-29">Example 29 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:narrower &lt;B&gt; ; skos:related &lt;C&gt; .<br />
&lt;B&gt; skos:narrower &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<h3 id="L2249">8.6. Notes</h3>
<h4 id="L3732">8.6.1. Sub-Property Relationships</h4>
<p>The diagram below illustrates informally the sub-property relationships
between the SKOS semantic relation properties.</p>
<pre>skos:semanticRelation
|
+— skos:related
|
+— skos:broaderTransitive
| |
| +— skos:broader
|
+— skos:narrowerTransitive
|
+— skos:narrower</pre>
<h4 id="L2251">8.6.2. Domain and Range of SKOS Semantic Relation
Properties</h4>
<p>Note that the domain and range of <code>skos:semanticRelation</code> is
the class <code>skos:Concept</code>. Because <code>skos:broader</code>,
<code>skos:narrower</code> and <code>skos:related</code> are each
sub-properties of <code>skos:semanticRelation</code>, the graph in <a href="#example-26">example 26</a>
above entails that <code>&lt;A&gt;</code>, <code>&lt;B&gt;</code> and
<code>&lt;C&gt;</code> are each instances of <code>skos:Concept</code>.</p>
<h4 id="L2255">8.6.3. Symmetry of skos:related</h4>
<p><code>skos:related</code> is a symmetric property. The example below
illustrates an entailment which follows from this condition.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-30">Example 30 (entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:related &lt;B&gt; .</div>
<p><em>entails</em></p>
<div>
&lt;B&gt; skos:related &lt;A&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>Note that, although <code>skos:related</code> is a symmetric property,
this condition does <strong>not</strong> place any restrictions on
sub-properties of <code>skos:related</code> (i.e., sub-properties of
<code>skos:related</code> could be symmetric, not symmetric or antisymmetric,
and still be consistent with the SKOS data model). </p>
<p>To illustrate this point, in the example below, two new properties which
are <strong>not</strong> symmetric are declared as sub-properties of
<code>skos:related</code>. The example, which is <strong>consistent</strong>
with the SKOS data model, also shows some of the entailments which follow.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-31">Example 31 (entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;cause&gt; rdf:type owl:ObjectProperty ;<br />
  rdfs:subPropertyOf skos:related .<br />
<br />
&lt;effect&gt; rdf:type owl:ObjectProperty ;<br />
 rdfs:subPropertyOf skos:related ;<br />
  owl:inverseOf &lt;cause&gt; .<br />
<br />
&lt;A&gt; &lt;cause&gt; &lt;B&gt; .</div>
<p><em>entails</em></p>
<div>
&lt;A&gt; skos:related &lt;B&gt; .<br />
<br />
&lt;B&gt; &lt;effect&gt; &lt;A&gt; ; skos:related &lt;A&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>See also the [<a class="citation" rel="citation" href="#ref-SKOS-PRIMER">SKOS-PRIMER</a>]
for best practice recommendations on extending SKOS.</p>
<h4 id="L2344">8.6.4. skos:related and Transitivity</h4>
<p>Note that <code>skos:related</code> is <strong>not</strong> a transitive
property. Therefore, the SKOS data model does <strong>not</strong> support an
entailment as illustrated in the example below.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-32">Example 32 (non-entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:related &lt;B&gt; .<br />
&lt;B&gt; skos:related &lt;C&gt; .</div>
<p><em>does not entail</em></p>
<div>
&lt;A&gt; skos:related &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<h4 id="L2376">8.6.5. skos:related and Reflexivity</h4>
<p>Note that this specification does not state that <code>skos:related</code>
is a <strong></strong>reflexive property, <strong>neither</strong> does it
state that <code>skos:related</code> is an irreflexive property.</p>
<p>Because <code>skos:related</code> is <strong>not</strong> defined as an
irreflexive property, the graph below is <strong>consistent</strong> with the
SKOS data model. </p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-33">Example 33 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:related &lt;A&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>However, for many applications that use knowledge organization systems,
statements of the form X <code>skos:related</code> X are a potential problem.
Where this is the case, an application may wish to search for such statements
prior to processing SKOS data, although how an application should handle such
statements is not defined in this specification and may vary between
applications.</p>
<h4 id="L2413">8.6.6. skos:broader and Transitivity</h4>
<p>Note that <code>skos:broader</code> is <strong>not</strong> a transitive
property. Similarly, <code>skos:narrower</code> is <strong>not</strong> a
transitive property. Therefore, the SKOS data model does <strong>not</strong>
support an entailment as illustrated in the example below.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-34">Example 34 (non-entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broader &lt;B&gt; .<br />
&lt;B&gt; skos:broader &lt;C&gt; .</div>
<p><em>does not entail</em></p>
<div>
&lt;A&gt; skos:broader &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>However, <code>skos:broader</code> is a sub-property of
<code>skos:broaderTransitive</code>, which <strong>is</strong> a transitive
property. Similarly, <code>skos:narrower</code> is a sub-property of
<code>skos:narrowerTransitive</code>, which <strong>is</strong> a transitive
property. Therefore the SKOS data model <strong>does</strong> support the
entailments illustrated below.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-35">Example 35 (entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broader &lt;B&gt; .<br />
&lt;B&gt; skos:broader &lt;C&gt; .</div>
<p><em>entails</em></p>
<div>
&lt;A&gt; skos:broaderTransitive &lt;B&gt; .<br />
&lt;B&gt; skos:broaderTransitive &lt;C&gt; .<br />
&lt;A&gt; skos:broaderTransitive &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>Note especially that, by convention, <code>skos:broader</code> and
<code>skos:narrower</code> are <strong>only</strong> used to assert immediate
(i.e., direct) hierarchical links between two SKOS concepts. By convention,
<code>skos:broaderTransitive</code> and <code>skos:narrowerTransitive</code>
are <strong>not</strong> used to make assertions, but are instead used only
to draw inferences. </p>
<p>This pattern allows the information about direct (i.e., immediate)
hierarchical links to be preserved, which is necessary for many tasks (e.g.,
building various types of visual representation of a knowledge organization
system), whilst also providing a mechanism for conveniently querying the
transitive closure of those hierarchical links (which will include both
direct and indirect links), which is useful in other situations (e.g., query
expansion algorithms).</p>
<p>Note also that a sub-property of a transitive property is
<strong>not</strong> necessarily transitive.</p>
<p>See also the note on alternative paths below.</p>
<h4 id="L2449">8.6.7. skos:broader and Reflexivity</h4>
<p>Note that this specification makes no statements regarding the reflexive
characteristics of the <code>skos:broader</code> relationship. It does not
state that <code>skos:broader</code> is a <strong></strong>reflexive
property, <strong>neither</strong> does it state that
<code>skos:broader</code> is an irreflexive property. Thus for any graph and
resource <code>&lt;A&gt;</code>, the triple:</p>
<table class="example-good" border="0">
<caption></caption>
<tbody>
<tr>
<th id="example-36">Example 36 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broader &lt;A&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>may or may not be present. This conservative position allows SKOS to be
used to model both KOS where the interpretation of <code>skos:broader</code>
is reflexive (e.g., a direct translation of an inferred OWL sub-class
hierarchy), or KOS where <code>skos:broader</code> could be considered
irreflexive (as would be appropriate for most thesauri or classification
schemes). </p>
<p>Similarly, there are no assertions made as to the reflexivity or
irreflexivity of <code>skos:narrower</code>.</p>
<p>However, for many applications that use knowledge organization systems,
statements of the form X <code>skos:broader</code> X or Y
<code>skos:narrower</code> Y represent a potential problem. Where this is the
case, an application may wish to search for such statements prior to
processing SKOS data, although how an application should handle such
statements is not defined in this specification and may vary between
applications.</p>
<h4 id="L2484">8.6.8. Cycles in the Hierarchical Relation
(skos:broaderTransitive and Reflexivity)</h4>
<p>In the graph below, a cycle has been stated in the hierarchical relation.
Note that this graph is <strong>consistent</strong> with the SKOS data model,
i.e., there is <strong>no</strong> condition requiring that
<code>skos:broaderTransitive</code> be irreflexive. </p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-37">Example 37 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broader &lt;B&gt; .<br />
&lt;B&gt; skos:broader &lt;A&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>However, for many applications where knowledge organization systems are
used, a cycle in the hierarchical relation represents a potential problem.
For these applications, computing the transitive closure of
<code>skos:broaderTransitive</code> then looking for statements of the form
<code></code>X <code>skos:broaderTransitive</code> X<code></code> is a
convenient strategy for finding cycles in the hierarchical relation. How an
application should handle such statements is not defined in this
specification and may vary between applications.</p>
<h4 id="L2518">8.6.9. Alternate Paths in the Hierarchical Relation</h4>
<p>In the graph below, there are two alternative paths from A to C in the
hierarchical relation.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-38">Example 38 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broader &lt;B&gt; , &lt;C&gt; .<br />
&lt;B&gt; skos:broader &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>In the graph below, there are two alternative paths from A to D in the
hierarchical relation.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-39">Example 39 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broader &lt;B&gt; , &lt;C&gt; .<br />
&lt;B&gt; skos:broader &lt;D&gt; .<br />
&lt;C&gt; skos:broader &lt;D&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>This is a pattern which arises naturally in poly-hierarchical knowledge
organization systems.</p>
<p>Both of these graphs are <strong>consistent</strong> with the SKOS data
model, i.e., there is <strong>no</strong> condition requiring that there be
only one path between any two nodes in the hierarchical relation. </p>
<h4 id="L4261">8.6.10. Disjointness of skos:related and
skos:broaderTransitive</h4>
<p>This specification treats the hierarchical and associative relations as
fundamentally distinct in nature. Therefore a clash between hierarchical
and associative links is <strong>not</strong> consistent with the SKOS data
model. The examples above illustrate some situations in which a clash is
seen to arise.</p>
<p>This position follows the usual definitions given to hierarchical and
associative relations in thesaurus standards [<a class="citation"
rel="citation" href="#ref-ISO2788">ISO2788</a>] [<a class="citation"
rel="citation" href="#ref-BS8723-2">BS8723-2</a>], and supports common
practice in many existing knowledge organization systems.</p>
<p>Note that this specification takes the stronger position that, not only
are the immediate (i.e., direct) hierarchical and associative links disjoint,
but associative links are also disjoint with <em>indirect</em> hierarchical
links. This is captured formally in the integrity condition asserting that
<code>skos:related</code> and <code>skos:broaderTransitive</code> are
disjoint properties.</p>
<hr />
</div>
<div id="div-collections">
<a id="collections"></a>
<h2 id="L2942">9. Concept Collections</h2>
<h3 id="L3806">9.1. Preamble</h3>
<p>SKOS concept collections are labeled and/or ordered groups of SKOS
concepts.</p>
<p>Collections are useful where a group of concepts shares something in
common, and it is convenient to group them under a common label, or where
some concepts can be placed in a meaningful order.</p>
<h3 id="L3282">9.2. Vocabulary</h3>
<table border="0" class="vocab">
<caption></caption>
<tbody>
<tr>
<td><code>skos:Collection</code></td>
</tr>
<tr>
<td><code>skos:OrderedCollection</code></td>
</tr>
<tr>
<td><code>skos:member</code></td>
</tr>
<tr>
<td><code>skos:memberList</code></td>
</tr>
</tbody>
</table>
<h3 id="L3312">9.3. Class &amp; Property Definitions</h3>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S28">S28</td>
<td><code>skos:Collection</code> and
<code>skos:OrderedCollection</code> are each instances of
<code>owl:Class</code>.</td>
</tr>
<tr>
<td id="S29">S29</td>
<td><code>skos:OrderedCollection</code> is a sub-class of
<code>skos:Collection</code>.</td>
</tr>
<tr>
<td id="S30">S30</td>
<td><code>skos:member</code> and <code>skos:memberList</code> are each
instances of <code>owl:ObjectProperty</code>.</td>
</tr>
<tr>
<td id="S31">S31</td>
<td>The <code>rdfs:domain</code> of <code>skos:member</code> is the
class <code>skos:Collection</code>.</td>
</tr>
<tr>
<td id="S32">S32</td>
<td>The <code>rdfs:range</code> of <code>skos:member</code> is the
union of classes <code>skos:Concept</code> and <code>skos:Collection</code>.</td>
</tr>
<tr>
<td id="S33">S33</td>
<td>The <code>rdfs:domain</code> of <code>skos:memberList</code> is the
class <code>skos:OrderedCollection</code>.</td>
</tr>
<tr>
<td id="S34">S34</td>
<td>The <code>rdfs:range</code> of <code>skos:memberList</code> is the
class <code>rdf:List</code>.</td>
</tr>
<tr>
<td id="S35">S35</td>
<td><code>skos:memberList</code> is an instance of
<code>owl:FunctionalProperty</code>.</td>
</tr>
<tr>
<td id="S36">S36</td>
<td>For any resource, every item in the list given as the value of the
<code>skos:memberList</code> property is also a value of the
<code>skos:member</code> property.</td>
</tr>
</tbody>
</table>
<h3 id="L3424">9.4. Integrity Conditions</h3>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S37">S37</td>
<td><code>skos:Collection</code> is disjoint with each of
<code>skos:Concept</code> and <code>skos:ConceptScheme</code>.</td>
</tr>
</tbody>
</table>
<h3 id="L3460">9.5. Examples</h3>
<p>The graph below illustrates a SKOS collection with 3 members.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-40">Example 40 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;MyCollection&gt; rdf:type skos:Collection ; <br />
  skos:member &lt;X&gt; , &lt;Y&gt; , &lt;Z&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>The graph below illustrates an ordered SKOS collection with 3 members.
Note the use of the Turtle syntax <code>(...)</code>, representing an RDF
Collection (list).</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-41">Example 41 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;MyOrderedCollection&gt; rdf:type skos:OrderedCollection ; <br />
  skos:memberList ( &lt;X&gt; &lt;Y&gt; &lt;Z&gt; ) .</div>
</td>
</tr>
</tbody>
</table>
<h3 id="L3512">9.6. Notes</h3>
<h4 id="L3514">9.6.1. Inferring Collections from Ordered Collections</h4>
<p>Statement <a href="#S36">S36</a> states the logical relationship between the
<code>skos:memberList</code> and <code>skos:member</code> properties. This
relationship means that a collection can be inferred from an ordered
collection. This is illustrated in the example below.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-42">Example 42 (entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;MyOrderedCollection&gt; rdf:type skos:OrderedCollection ; <br />
  skos:memberList ( &lt;X&gt; &lt;Y&gt; &lt;Z&gt; ) .</div>
<p><em>entails</em></p>
<div>
&lt;MyOrderedCollection&gt; rdf:type skos:Collection ;<br />
  skos:member &lt;X&gt; , &lt;Y&gt; , &lt;Z&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>Note that SKOS does not provide any way to explicitly state that a
collection is <strong>not</strong> ordered.</p>
<h4 id="L3551">9.6.2. skos:memberList Integrity</h4>
<p>Note that <code>skos:memberList</code> is a functional property, i.e., it
does not have more than one value. This is intended to capture within the
SKOS data model that it doesn't make sense for an ordered collection to have
more than one member list. Unfortunately, there is no way to use this
condition as an integrity condition without explicitly stating that two lists
are different objects. In other words, although the graph below is
<strong>consistent</strong> with the SKOS data model, it entails nonsense (a
list with two first elements and a forked tail). </p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-43">Example 43 (entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;OrderedCollectionResource&gt; <br />
  skos:memberList ( &lt;A&gt; &lt;B&gt; ) , ( &lt;X&gt; &lt;Y&gt; )
. </div>
<p><em>entails</em></p>
<div>
&lt;OrderedCollectionResource&gt; <br />
  skos:memberList [ rdf:first &lt;A&gt; , &lt;X&gt; ; rdf:rest [
rdf:first &lt;B&gt; ; rdf:rest rdf:nil ] , [ rdf:first &lt;Y&gt; ;
rdf:rest rdf:nil ] ] .</div>
</td>
</tr>
</tbody>
</table>
<p>However, as stated in [<a class="citation" rel="citation"
href="#ref-RDF-SEMANTICS">RDF-SEMANTICS</a>] section 3.3.3, semantic
extensions to RDF may place extra syntactic well-formedness
restrictions on the use of the RDF collection vocabulary
(<code>rdf:first</code>, <code>rdf:rest</code>, <code>rdf:nil</code>)
in order to rule out such graphs.</p>
<h4 id="L3588">9.6.3. Nested Collections</h4>
<p>In the example below, a collection is nested within another collection.
</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-44">Example 44 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;MyCollection&gt; rdf:type skos:Collection ; <br />
  skos:member &lt;A&gt; , &lt;B&gt; , &lt;MyNestedCollection&gt;
.<br />
<br />
&lt;MyNestedCollection&gt; rdf:type skos:Collection ;<br />
  skos:member &lt;X&gt; , &lt;Y&gt; , &lt;Z&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>This example is <strong>consistent</strong> with the SKOS data
model, because the range of <code>skos:member</code> is the
union of <code>skos:Concept</code>
and <code>skos:Collection</code>.</p>
<h4 id="L3625">9.6.4. SKOS Concepts, Concept Collections and Semantic
Relations</h4>
<p>In the SKOS data model, <code>skos:Concept</code> and
<code>skos:Collection</code> are disjoint classes. The domain and range of
the SKOS semantic relation properties is <code>skos:Concept</code>.
Therefore, if any of the SKOS semantic relation properties (e.g.,
<code>skos:narrower</code>) are used to link to or from a collection, the
graph will <strong>not</strong> be consistent with the SKOS data model.</p>
<p>This is illustrated in the example below, which is <strong>not</strong>
consistent with the SKOS data model.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-45">Example 45 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:narrower &lt;B&gt; .<br />
&lt;B&gt; rdf:type skos:Collection .</div>
</td>
</tr>
</tbody>
</table>
<p>Similarly, the graph below is <strong>not</strong> consistent with the
SKOS data model.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-46">Example 46 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broader &lt;B&gt; .<br />
&lt;B&gt; rdf:type skos:Collection .</div>
</td>
</tr>
</tbody>
</table>
<p>Similarly, the graph below is <strong>not</strong> consistent with the
SKOS data model.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-47">Example 47 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:related &lt;B&gt; .<br />
&lt;B&gt; rdf:type skos:Collection .</div>
</td>
</tr>
</tbody>
</table>
<p>However, the graph below is consistent with the SKOS data model.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-48">Example 48 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:narrower &lt;B&gt; , &lt;C&gt; , &lt;D&gt; .<br />
<br />
&lt;ResourceCollection&gt; rdfs:label "Resource Collection"@en ; <br
/>
  skos:member &lt;B&gt; , &lt;C&gt; , &lt;D&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>This means that, for thesauri and other knowledge organization systems
where node labels are used within the systematic display for that
thesaurus, the appropriate SKOS representation requires careful
consideration. Furthermore, where node labels are used in the systematic
display, it may not always be possible to fully reconstruct the systematic
display from a SKOS representation alone. Fully representing all of the
information represented in a systematic display of a thesaurus or other
knowledge organization system, including details of layout and presentation,
is beyond the scope of SKOS. </p>
<hr />
</div>
<div id="div-mapping">
<a id="mapping"></a>
<h2 id="L1309">10. Mapping Properties</h2>
<h3 id="L4307">10.1. Preamble</h3>
<p>The SKOS mapping properties are <code>skos:closeMatch</code>,
<code>skos:exactMatch</code>, <code>skos:broadMatch</code>,
<code>skos:narrowMatch</code> and <code>skos:relatedMatch</code>. These
properties are used to state mapping (alignment) links between SKOS concepts
in different concept schemes, where the links are inherent in the meaning of
the linked concepts. </p>
<p>The properties <code>skos:broadMatch</code> and
<code>skos:narrowMatch</code> are used to state a hierarchical mapping link
between two concepts.</p>
<p>The property <code>skos:relatedMatch</code> is used to state an
associative mapping link between two concepts.</p>
<p>The property <code>skos:closeMatch</code> is used to link two concepts
that are sufficiently similar that they can be used interchangeably in
<strong>some</strong> information retrieval applications. In order to avoid
the possibility of "compound errors" when combining mappings across more than
two concept schemes, <code>skos:closeMatch</code> is <strong>not</strong>
declared to be a transitive property. </p>
<p>The property <code>skos:exactMatch</code> is used to link two concepts,
indicating a high degree of confidence that the concepts can be used
interchangeably across a wide range of information retrieval applications.
<code>skos:exactMatch</code> is a transitive property, and is a sub-property
of <code>skos:closeMatch</code>.</p>
<h3 id="L4138">10.2. Vocabulary</h3>
<table border="0" class="vocab">
<caption></caption>
<tbody>
<tr>
<td><code>skos:mappingRelation</code></td>
</tr>
<tr>
<td><code>skos:closeMatch</code></td>
</tr>
<tr>
<td><code>skos:exactMatch</code></td>
</tr>
<tr>
<td><code>skos:broadMatch</code></td>
</tr>
<tr>
<td><code>skos:narrowMatch</code></td>
</tr>
<tr>
<td><code>skos:relatedMatch</code></td>
</tr>
</tbody>
</table>
<h3 id="L4186">10.3. Class &amp; Property Definitions</h3>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S38">S38</td>
<td><code>skos:mappingRelation</code>, <code>skos:closeMatch</code>,
<code>skos:exactMatch</code>, <code>skos:broadMatch</code>,
<code>skos:narrowMatch</code> and <code>skos:relatedMatch</code> are
each instances of <code>owl:ObjectProperty</code>.</td>
</tr>
<tr>
<td id="S39">S39</td>
<td><code>skos:mappingRelation</code> is a sub-property of
<code>skos:semanticRelation</code>.</td>
</tr>
<tr>
<td id="S40">S40</td>
<td><code>skos:closeMatch</code>, <code>skos:broadMatch</code>,
<code>skos:narrowMatch</code> and <code>skos:relatedMatch</code> are
each sub-properties of <code>skos:mappingRelation</code>. </td>
</tr>
<tr>
<td id="S41">S41</td>
<td><code>skos:broadMatch</code> is a sub-property of
<code>skos:broader</code>, <code>skos:narrowMatch</code> is a
sub-property of <code>skos:narrower</code>, and
<code>skos:relatedMatch</code> is a sub-property of
<code>skos:related</code>.</td>
</tr>
<tr>
<td id="S42">S42</td>
<td><code>skos:exactMatch</code> is a sub-property of
<code>skos:closeMatch</code>.</td>
</tr>
<tr>
<td id="S43">S43</td>
<td><code>skos:narrowMatch</code> is <code>owl:inverseOf</code> the
property <code>skos:broadMatch</code>.</td>
</tr>
<tr>
<td id="S44">S44</td>
<td><code>skos:relatedMatch</code>, <code>skos:closeMatch</code> and
<code>skos:exactMatch</code> are each instances of
<code>owl:SymmetricProperty</code>.</td>
</tr>
<tr>
<td id="S45">S45</td>
<td><code>skos:exactMatch</code> is an instance of
<code>owl:TransitiveProperty</code>.</td>
</tr>
</tbody>
</table>
<h3 id="L5429">10.4. Integrity Conditions</h3>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S46">S46</td>
<td><code>skos:exactMatch</code> is disjoint with each of the
properties <code>skos:broadMatch</code> and
<code>skos:relatedMatch</code>.</td>
</tr>
</tbody>
</table>
<p>Note that because <code>skos:exactMatch</code> is a symmetric property, and
<code>skos:broadMatch</code> and <code>skos:narrowMatch</code> are inverses,
<code>skos:exactMatch</code> is therefore also disjoint with
<code>skos:narrowMatch</code>.</p>
<h3 id="L4316">10.5. Examples</h3>
<p>The graph below asserts an exact equivalence mapping link between
<code>&lt;A&gt;</code> and <code>&lt;B&gt;</code>.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-49">Example 49 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:exactMatch &lt;B&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>The graph below asserts a close equivalence mapping link between
<code>&lt;A&gt;</code> and <code>&lt;B&gt;</code>.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-50">Example 50 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:closeMatch &lt;B&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>The graph below asserts a hierarchical mapping link between
<code>&lt;A&gt;</code> and <code>&lt;B&gt;</code> (where
<code>&lt;B&gt;</code> is broader than <code>&lt;A&gt;</code>), and an
associative mapping link between <code>&lt;A&gt;</code> and
<code>&lt;C&gt;</code>.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-51">Example 51 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broadMatch &lt;B&gt; ; skos:relatedMatch &lt;C&gt;
.</div>
</td>
</tr>
</tbody>
</table>
<p>The graph below is <strong>not consistent</strong> with the SKOS data
model, because there is a clash between exact and hierarchical mapping
links.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-52">Example 52 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:exactMatch &lt;B&gt; ; skos:broadMatch &lt;B&gt; .<br
/>
</div>
</td>
</tr>
</tbody>
</table>
<p>The graph below is <strong>not consistent</strong> with the SKOS data
model, because there is a clash between exact and associative mapping
links.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-53">Example 53 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:exactMatch &lt;B&gt; ; skos:relatedMatch &lt;B&gt;
.<br />
</div>
</td>
</tr>
</tbody>
</table>
<h3 id="L4412">10.6. Notes</h3>
<h4 id="L4160">10.6.1. Mapping Properties, Semantic Relation Properties and
Concept Schemes</h4>
<p>By convention, the SKOS mapping properties are only used to link concepts
in <strong>different</strong> concept schemes. However, note that using the
SKOS semantic relation properties (<code>skos:broader</code>,
<code>skos:narrower</code>, <code>skos:related</code>) to link concepts in
<strong>different</strong> concept schemes is also
<strong>consistent</strong> with the SKOS data model (see <a
href="#semantic-relations">Section 8</a>). </p>
<p>The mapping properties <code>skos:broadMatch</code>,
<code>skos:narrowMatch</code> and <code>skos:relatedMatch</code> are provided
as a convenience, for situations where the provenance of data is known, and
it is useful to be able to tell at a glance the difference between internal
links within a concept scheme and mapping links between concept schemes. </p>
<p>However, using the SKOS mapping properties is <strong>no
substitute</strong> for the careful management of RDF graphs or the use of
provenance mechanisms. </p>
<p>The rationale behind this design is that it is hard to draw an absolute
distinction between internal links within a concept scheme and mapping links
between concept schemes. This is especially true in an open environment where
different people might re-organize concepts into concept schemes in different
ways. What one person views as two concept schemes with mapping links
between, another might view as one single concept scheme with internal links
only. This specification allows both points of view to co-exist, which (it is
hoped) will promote flexibility and innovation in the re-use of SKOS data in
the Web. </p>
<p>There is therefore an intimate connection between the SKOS semantic
relation properties and the SKOS mapping properties. The property
<code>skos:broadMatch</code> is a sub-property of <code>skos:broader</code>,
<code>skos:narrowMatch</code> is a sub-property of
<code>skos:narrower</code>, and <code>skos:relatedMatch</code> is a
sub-property of <code>skos:related</code>. The full set of sub-property
relationships is illustrated below.</p>
<pre>skos:semanticRelation
|
+- skos:related
| |
| +- skos:relatedMatch
|
+- skos:broaderTransitive
| |
| +- skos:broader
| |
| +- skos:broadMatch
|
+- skos:narrowerTransitive
| |
| +- skos:narrower
| |
| +- skos:narrowMatch
|
+- skos:mappingRelation
|
+- skos:closeMatch
| |
| +- skos:exactMatch
|
+- skos:relatedMatch
|
+- skos:broadMatch
|
+- skos:narrowMatch </pre>
<p>Examples below illustrate some entailments which follow from this
sub-property tree, and from the domain and range of <code>skos:semanticRelation</code>.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-54">Example 54 (entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broadMatch &lt;B&gt; .</div>
<p><em>entails</em></p>
<div>
&lt;A&gt; skos:mappingRelation &lt;B&gt; .<br/>
&lt;A&gt; skos:broader &lt;B&gt; .<br />
&lt;A&gt; skos:broaderTransitive &lt;B&gt; .<br />
&lt;A&gt; skos:semanticRelation &lt;B&gt; .<br />
&lt;A&gt; rdf:type skos:Concept .<br/>
&lt;B&gt; rdf:type skos:Concept .</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-55">Example 55 (entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:narrowMatch &lt;B&gt; .</div>
<p><em>entails</em></p>
<div>
&lt;A&gt; skos:mappingRelation &lt;B&gt; .<br/>
&lt;A&gt; skos:narrower &lt;B&gt; .<br />
&lt;A&gt; skos:narrowerTransitive &lt;B&gt; .<br />
&lt;A&gt; skos:semanticRelation &lt;B&gt; .<br />
&lt;A&gt; rdf:type skos:Concept .<br/>
&lt;B&gt; rdf:type skos:Concept .</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-56">Example 56 (entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:relatedMatch &lt;B&gt; .</div>
<p><em>entails</em></p>
<div>
&lt;A&gt; skos:mappingRelation &lt;B&gt; .<br/>
&lt;A&gt; skos:related &lt;B&gt; .<br />
&lt;A&gt; skos:semanticRelation &lt;B&gt; .<br />
&lt;A&gt; rdf:type skos:Concept .<br/>
&lt;B&gt; rdf:type skos:Concept .</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-57">Example 57 (entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:exactMatch &lt;B&gt; .</div>
<p><em>entails</em></p>
<div>
&lt;A&gt; skos:closeMatch &lt;B&gt; .<br />
&lt;A&gt; skos:mappingRelation &lt;B&gt; .<br/>
&lt;A&gt; skos:semanticRelation &lt;B&gt; .<br/>
&lt;A&gt; rdf:type skos:Concept .<br/>
&lt;B&gt; rdf:type skos:Concept .</div>
</td>
</tr>
</tbody>
</table>
<p>Note also that, because different people might re-organize concepts into
concept schemes in different ways, a graph might assert
<strong>mapping</strong> links between concepts in the <strong>same</strong>
concept scheme, and there are <strong>no</strong> formal integrity conditions
in the SKOS data model that would make such a graph inconsistent, e.g., the
graph below is <strong>consistent</strong> with the SKOS data model. However,
in practice it is expected that such a graph would only ever arise from the
merge of two or more graphs from different sources.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-58">Example 58 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broadMatch &lt;B&gt; ; skos:relatedMatch &lt;C&gt;
.<br />
<br />
&lt;A&gt; skos:inScheme &lt;MyScheme&gt; .<br />
&lt;B&gt; skos:inScheme &lt;MyScheme&gt; .<br />
&lt;C&gt; skos:inScheme &lt;MyScheme&gt; .</div>
</td>
</tr>
</tbody>
</table>
<h4 id="L4394">10.6.2. Clashes Between Hierarchical and Associative
Links</h4>
<p>Examples below illustrate "clashes" between hierarchical and associative
mapping links, which are <strong>not consistent</strong> with the SKOS data
model (because of the sub-property relationships illustrated above, and
because of the data model for SKOS semantic relation properties defined in <a
href="#semantic-relations">Section 8</a>).</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-59">Example 59 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broadMatch &lt;B&gt; ; skos:relatedMatch &lt;B&gt;
.</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-60">Example 60 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:narrowMatch &lt;B&gt; ; skos:relatedMatch &lt;B&gt;
.</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-61">Example 61 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broadMatch &lt;B&gt; .<br />
&lt;B&gt; skos:broadMatch &lt;C&gt; .<br />
&lt;A&gt; skos:relatedMatch &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<h4 id="L4414">10.6.3. Mapping Properties and Transitivity</h4>
<p>The only SKOS mapping property which is declared as transitive is
<code>skos:exactMatch</code>. An example entailment is illustrated below:</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-62">Example 62 (entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:exactMatch &lt;B&gt; .<br />
&lt;B&gt; skos:exactMatch &lt;C&gt; .</div>
<p><em>entails</em></p>
<div>
&lt;A&gt; skos:exactMatch &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>All other SKOS mapping properties are not transitive. Therefore,
entailments as illustrated in examples below are <strong>not</strong>
supported by the SKOS data model.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-63">Example 63 (non-entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broadMatch &lt;B&gt; .<br />
&lt;B&gt; skos:broadMatch &lt;C&gt; .</div>
<p><em>does not entail</em></p>
<div>
&lt;A&gt; skos:broadMatch &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-64">Example 64 (non-entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:relatedMatch &lt;B&gt; .<br />
&lt;B&gt; skos:relatedMatch &lt;C&gt; .</div>
<p><em>does not entail</em></p>
<div>
&lt;A&gt; skos:relatedMatch &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-65">Example 65 (non-entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:closeMatch &lt;B&gt; .<br />
&lt;B&gt; skos:closeMatch &lt;C&gt; .</div>
<p><em>does not entail</em></p>
<div>
&lt;A&gt; skos:closeMatch &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<!--
<p class="editorial"><strong>Editors' note:</strong> The Working Group has
recognized that it might be reasonable and useful to define skos:exactMatch
as a transitive property. This is recorded as <a
href="http://www.w3.org/2006/07/SWD/track/issues/72">ISSUE-72</a> in the
Working Group's issue process. Comments on this issue are invited, and should
be sent in an <a
href="mailto:public-swd-wg@w3.org?subject=Comment: ISSUE-72">email to the SWD
Working Group mailing list (public-swd-wg@w3.org)</a>, starting the subject
line with "Comment: ISSUE-72". </p>
-->
<h4 id="L4499">10.6.4. Mapping Properties and Reflexivity</h4>
<p><strong>None</strong><strong></strong> of the SKOS mapping properties are
reflexive, <strong>neither</strong> are they irreflexive.</p>
<p>Because <code>skos:exactMatch</code>, <code>skos:broadMatch</code> and
<code>skos:relatedMatch</code> are <strong>not</strong>
<strong>irreflexive</strong>, the graph below is <strong>consistent</strong>
with the SKOS data model.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-66">Example 66 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:exactMatch &lt;A&gt; .<br />
&lt;B&gt; skos:broadMatch &lt;B&gt; .<br />
&lt;C&gt; skos:relatedMatch &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>However, see also <a href="#semantic-relations">Section 8</a> on the
reflexivity of SKOS semantic relation properties.</p>
<!--
<p class="editorial"><strong>Editors' note:</strong> Intuitively, an exact
mapping link asserts something fundamentally different from a hierarchical or
associative mapping link. Therefore, it might be reasonable and useful to
define skos:exactMatch as disjoint with skos:broadMatch (or skos:broader),
and disjoint with skos:relatedMatch (or skos:related). This is recorded as <a
href="http://www.w3.org/2006/07/SWD/track/issues/73">ISSUE-73</a> in the
Working Group's issue process. Comments on this issue are invited, and should
be sent in an <a
href="mailto:public-swd-wg@w3.org?subject=Comment: ISSUE-73">email to the SWD
Working Group mailing list (public-swd-wg@w3.org)</a>, starting the subject
line with "Comment: ISSUE-73". </p>
-->
<h4 id="L4564">10.6.5. Cycles and Alternate Paths Involving
skos:broadMatch</h4>
<p>There are no formal integrity conditions preventing either cycles or
alternative paths in a graph of hierarchical mapping links.</p>
<p>In the graph below there are two cycles involving
<code>skos:broadMatch</code>. This graph is <strong>consistent</strong> with
the SKOS data model.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-67">Example 67 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broadMatch &lt;B&gt; .<br />
&lt;B&gt; skos:broadMatch &lt;A&gt; .<br />
<br />
&lt;X&gt; skos:broadMatch &lt;Y&gt; .<br />
&lt;Y&gt; skos:broadMatch &lt;Z&gt; .<br />
&lt;Z&gt; skos:broadMatch &lt;X&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>In the graph below there are two alternative paths involving
<code>skos:broadMatch</code>. This graph is <strong>consistent</strong> with
the SKOS data model.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-68">Example 68 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broadMatch &lt;B&gt; .<br />
&lt;B&gt; skos:broadMatch &lt;C&gt; .<br />
&lt;A&gt; skos:broadMatch &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>See however <a href="#semantic-relations">Section 8</a> on cycles and
alternative paths involving <code>skos:broader</code>.</p>
<h4 id="mapping-cycles-exactMatch">10.6.6. Cycles Involving skos:exactMatch and skos:closeMatch</h4>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-69">Example 69 (entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:exactMatch &lt;B&gt; </div>
<p><em>entails</em></p>
<div>
&lt;A&gt; skos:exactMatch &lt;A&gt; .<br/>
&lt;A&gt; skos:closeMatch &lt;A&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>Due to the entailment above (which arises through a combination
of <a href="#S42">S42</a>, <a href="#S44">S44</a>
and <a href="#S45">S45</a>), applications must be able to cope with
cycles in <code>skos:exactMatch</code>
and <code>skos:closeMatch</code>. </p>
<h4 id="L5675">10.6.7. Sub-Property Chains Involving skos:exactMatch</h4>
<p>There are no sub-property chain axioms in the SKOS data model involving the
<code>skos:exactMatch</code> or <code>skos:closeMatch</code> properties.
Hence the entailments illustrated below are <strong>not</strong>
supported.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-70">Example 70 (non-entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:exactMatch &lt;B&gt; .<br />
&lt;B&gt; skos:broadMatch &lt;C&gt; .</div>
<p><em>does not entail</em></p>
<div>
&lt;A&gt; skos:broadMatch &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-71">Example 71 (non-entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:exactMatch &lt;B&gt; .<br />
&lt;B&gt; skos:relatedMatch &lt;C&gt; .</div>
<p><em>does not entail</em></p>
<div>
&lt;A&gt; skos:relatedMatch &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-72">Example 72 (non-entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:closeMatch &lt;B&gt; .<br />
&lt;B&gt; skos:broadMatch &lt;C&gt; .</div>
<p><em>does not entail</em></p>
<div>
&lt;A&gt; skos:broadMatch &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-73">Example 73 (non-entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:closeMatch &lt;B&gt; .<br />
&lt;B&gt; skos:relatedMatch &lt;C&gt; .</div>
<p><em>does not entail</em></p>
<div>
&lt;A&gt; skos:relatedMatch &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<div id="div-mapping1">
<h4 id="L4858">10.6.8. skos:closeMatch, skos:exactMatch, owl:sameAs,
owl:equivalentClass, owl:equivalentProperty</h4>
<p>OWL provides three properties which might, at first glance, appear similar
to <code>skos:closeMatch</code> or <code>skos:exactMatch</code>.
<code>owl:sameAs</code> is used to link two individuals in an ontology, and
indicates that they are the same individual (i.e., the same resource).
<code>owl:equivalentClass</code> is used to link two classes in an ontology,
and indicates that those classes have the same class extension.
<code>owl:equivalentProperty</code> is used to link two properties in an
ontology and indicates that both properties have the same property
extension.</p>
<p><code>skos:closeMatch</code> and <code>skos:exactMatch</code> are used to
link SKOS concepts in different schemes. A <code>skos:closeMatch</code> link
indicates that two concepts are sufficiently similar that they can be used
interchangeably in <strong>some</strong> information retrieval applications.
A <code>skos:exactMatch</code> link indicates a high degree of confidence
that two concepts can be used interchangeably across a wide range of
information retrieval applications. </p>
<p><code>owl:sameAs</code>, <code>owl:equivalentClass</code> or
<code>owl:equivalentProperty</code> would typically be inappropriate for
linking SKOS concepts in different concept schemes, because the formal
consequences that follow could be undesirable. </p>
<p>The example below illustrates some undesirable entailments that would
follow from using <code>owl:sameAs</code> in this way.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-74">Example 74 (entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; rdf:type skos:Concept ; <br />
  skos:prefLabel "love"@en ;<br />
  skos:inScheme &lt;MyScheme&gt; .<br />
<br />
&lt;B&gt; rdf:type skos:Concept ; <br />
  skos:prefLabel "adoration"@en ;<br />
  skos:inScheme &lt;AnotherScheme&gt; .<br />
<br />
&lt;A&gt; owl:sameAs &lt;B&gt; . </div>
<p><em>entails</em></p>
<div>
&lt;A&gt; <br />
  skos:prefLabel "love"@en ;<br />
  skos:prefLabel "adoration"@en ;<br />
  skos:inScheme &lt;MyScheme&gt; ;<br />
  skos:inScheme &lt;AnotherScheme&gt; .<br />
<br />
&lt;B&gt;   <br />
  skos:prefLabel "love"@en ;<br />
  skos:prefLabel "adoration"@en ;<br />
  skos:inScheme &lt;MyScheme&gt; ;<br />
  skos:inScheme &lt;AnotherScheme&gt; .<br />
</div>
</td>
</tr>
</tbody>
</table>
<p>In this example, using <code>owl:sameAs</code> to link two SKOS concepts
in different concept schemes does actually lead to an inconsistency with the
SKOS data model, because both <code>&lt;A&gt;</code> and
<code>&lt;B&gt;</code> now have two preferred lexical labels in the same
language. This will not always be the case, however. </p>
<hr />
</div>
</div>
</div>
<a id="references"></a>
<h2 id="L744">11. References</h2>
<dl>
<dt>[<a id="ref-AGROVOC">AGROVOC</a>]</dt>
<dd><a rel="dct:references" href="http://www.fao.org/agrovoc" class="reference-title">AGROVOC
Thesaurus</a>, Food and Agriculture Organization of the United Nations
(FAO). Available at http://www.fao.org/agrovoc</dd>
<dt>[<a id="ref-BCP47">BCP47</a>]</dt>
<dd><a rel="dct:references" href="http://www.rfc-editor.org/rfc/bcp/bcp47.txt"
class="reference-title">Tags for Identifying Languages</a>, A. Phillips
and M. Davis, Editors, September 2006. Available at
http://www.rfc-editor.org/rfc/bcp/bcp47.txt</dd>
<dt>[<a id="ref-BS8723-2">BS8723-2</a>]</dt>
<dd><span class="reference-title">BS8723 Structured Vocabularies for
Information Retrieval Part 2: Thesauri</span>, British Standards
Institution (BSI), 2005.</dd>
<dt>[<a id="ref-BS8723-3">BS8723-3</a>]</dt>
<dd><span class="reference-title">BS8723 Structured Vocabularies for
Information Retrieval Part 3: Vocabularies Other Than Thesauri</span>,
British Standards Institution (BSI), 2005.</dd>
<dt>[<a id="ref-COOLURIS">COOLURIS</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/2008/NOTE-cooluris-20080331/"
class="reference-title">Cool URIs for the Semantic Web</a>, Leo
Sauermann and Richard Cyganiak, Editors, W3C Interest Group Note, 31
March 2008, http://www.w3.org/TR/2008/NOTE-cooluris-20080331/. <a
href="http://www.w3.org/TR/cooluris/">Latest version</a> available at
http://www.w3.org/TR/cooluris/ </dd>
<dt>[<a id="ref-ISO2788">ISO2788</a>]</dt>
<dd><span class="reference-title">ISO 2788:1986 Documentation --
Guidelines for the establishment and development of monolingual
thesauri</span>, International Organization for Standardization (ISO),
1986.</dd>
<dt>[<a id="ref-LCSH">LCSH</a>]</dt>
<dd><a rel="dct:references" href="http://www.loc.gov/cds/lcsh.html"
class="reference-title">Library of Congress Subject Headings</a>, The
Library of Congress Cataloging Distribution Service. Available at
http://www.loc.gov/cds/lcsh.html and at <a
href="http://id.loc.gov/">http://id.loc.gov/</a></dd>
<dt>[<a id="ref-NTRIPLES">NTRIPLES</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/"
class="reference-title">RDF Test Cases</a>, Jan Grant and Dave Beckett,
Editors, W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/. <a
href="http://www.w3.org/TR/rdf-testcases/">Latest version</a> available
at http://www.w3.org/TR/rdf-testcases/</dd>
<dt>[<a id="ref-OWL-GUIDE">OWL-GUIDE</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/2004/REC-owl-guide-20040210/"
class="reference-title">OWL Web Ontology Language Guide</a>, Michael K.
Smith, Chris Welty and Deborah L. McGuinness, Editors, W3C
Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-owl-guide-20040210/. <a
href="http://www.w3.org/TR/owl-guide/">Latest version</a> available at
http://www.w3.org/TR/owl-guide/ </dd>
<dt>[<a id="ref-OWL-REFERENCE">OWL-REFERENCE</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/2004/REC-owl-ref-20040210/"
class="reference-title">OWL Web Ontology Language Reference</a>, Mike
Dean and Guus Schreiber, Editors, W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-owl-ref-20040210/. <a
href="http://www.w3.org/TR/owl-ref/">Latest version</a> available at
http://www.w3.org/TR/owl-ref/</dd>
<dt>[<a id="ref-OWL-SEMANTICS">OWL-SEMANTICS</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/2004/REC-owl-semantics-20040210/"
class="reference-title">OWL Web Ontology Language Semantics and
Abstract Syntax</a>, Peter F. Patel-Schneider, Patrick Hayes and Ian
Horrocks, Editors, W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-owl-semantics-20040210/. <a
href="http://www.w3.org/TR/owl-semantics/">Latest version</a> available
at http://www.w3.org/TR/owl-semantics/</dd>
<dt>[<a id="ref-RDF-CONCEPTS">RDF-CONCEPTS</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/"
class="reference-title">Resource Description Framework (RDF): Concepts
and Abstract Syntax</a>, Graham Klyne and Jeremy J. Carroll, Editors,
W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/. <a
href="http://www.w3.org/TR/rdf-concepts/">Latest version</a> available
at http://www.w3.org/TR/rdf-concepts/</dd>
<dt>[<a id="ref-RDF-PRIMER">RDF-PRIMER</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/"
class="reference-title">RDF Primer</a>, Frank Manola and Eric Miller,
Editors, W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-primer-20040210/. <a
href="http://www.w3.org/TR/rdf-primer/">Latest version</a> available at
http://www.w3.org/TR/rdf-primer/</dd>
<dt>[<a id="ref-RDF-SEMANTICS">RDF-SEMANTICS</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/2004/REC-rdf-mt-20040210/"
class="reference-title">RDF Semantics</a>, Patrick Hayes, Editor, W3C
Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-mt-20040210/. <a
href="http://www.w3.org/TR/rdf-mt/">Latest version</a> available at
http://www.w3.org/TR/rdf-mt/</dd>
<dt>[<a id="ref-RDF-XML">RDF-XML</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/"
class="reference-title">RDF/XML Syntax Specification (Revised)</a>,
Dave Beckett, Editor, W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/. <a
href="http://www.w3.org/TR/rdf-syntax-grammar/">Latest version</a>
available at http://www.w3.org/TR/rdf-syntax-grammar/</dd>
<dt>[<a id="ref-RDFS">RDFS</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/2004/REC-rdf-schema-20040210/"
class="reference-title">RDF Vocabulary Description Language 1.0: RDF
Schema</a>, Dan Brickley and R. V. Guha, Editors, W3C Recommendation,
10 February 2004, http://www.w3.org/TR/2004/REC-rdf-schema-20040210/.
<a href="http://www.w3.org/TR/rdf-schema/">Latest version</a> available
at http://www.w3.org/TR/rdf-schema/</dd>
<dt>[<a id="ref-RECIPES">RECIPES</a>]</dt>
<dd><a href="http://www.w3.org/TR/2008/WD-swbp-vocab-pub-20080123/"
class="reference-title">Best Practice Recipes for Publishing RDF
Vocabularies</a>, Diego Berrueta and Jon Phipps, Editors, W3C Working
Draft, 23 January 2008,
http://www.w3.org/TR/2008/WD-swbp-vocab-pub-20080123/. <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="ref-SKOS-HTML">SKOS-HTML</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/skos-reference/skos.html"
class="reference-title">SKOS Namespace Document - HTML Variant</a>.
<a href="http://www.w3.org/TR/skos-reference/skos.html">Latest version</a>
available at http://www.w3.org/TR/skos-reference/skos.html</dd>
<dt>[<a id="ref-SKOS-PRIMER">SKOS-PRIMER</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/2009/NOTE-skos-primer-20090818" class="reference-title">SKOS
Simple Knowledge Organization System Primer</a>, Antoine Isaac and Ed Summers,
Editors, W3C Working Group Note, 18 August 2009, http://www.w3.org/TR/2009/NOTE-skos-primer-20090818. <a href="http://www.w3.org/TR/skos-primer">Latest version</a>
available at http://www.w3.org/TR/skos-primer</dd>
<dt>[<a id="ref-SKOS-RDF">SKOS-RDF</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/skos-reference/skos.rdf"
class="reference-title">SKOS Namespace Document - RDF/XML Variant</a>.
<a href="http://www.w3.org/TR/skos-reference/skos.rdf">Latest version</a>
available at http://www.w3.org/TR/skos-reference/skos.rdf</dd>
<dt>[<a id="ref-SKOS-RDF-OWL1-DL">SKOS-RDF-OWL1-DL</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/skos-reference/skos-owl1-dl.rdf"
class="reference-title">SKOS RDF Schema - OWL 1 DL Sub-set</a>.
<a href="http://www.w3.org/TR/skos-reference/skos-owl1-dl.rdf">Latest version</a>
available at http://www.w3.org/TR/skos-reference/skos-owl1-dl.rdf</dd>
<dt>[<a id="ref-SKOS-UCR">SKOS-UCR</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/2009/NOTE-skos-ucr-20090818" class="reference-title">SKOS
Use Cases and Requirements</a>, Antoine Isaac, Jon Phipps and Daniel Rubin,
Editors, W3C Working Group Note, 18 August 2009, http://www.w3.org/TR/2009/NOTE-skos-ucr-20090818. <a href="http://www.w3.org/TR/skos-ucr">Latest version</a>
available at http://www.w3.org/TR/skos-ucr</dd>
<dt>[<a id="ref-SKOS-XL-HTML">SKOS-XL-HTML</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/skos-reference/skos-xl.html"
class="reference-title">SKOS-XL Namespace Document - HTML Variant</a>.
<a href="http://www.w3.org/TR/skos-reference/skos-xl.html">Latest version</a>
available at http://www.w3.org/TR/skos-reference/skos-xl.html</dd>
<dt>[<a id="ref-SKOS-XL-RDF">SKOS-XL-RDF</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/skos-reference/skos-xl.rdf"
class="reference-title">SKOS-XL Namespace Document - RDF/XML Variant</a>.
<a href="http://www.w3.org/TR/skos-reference/skos-xl.rdf">Latest version</a>
available at http://www.w3.org/TR/skos-reference/skos-xl.rdf</dd>
<dt>[<a id="ref-SPARQL">SPARQL</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/"
class="reference-title">SPARQL Query Language for RDF</a>, Eric
Prud'hommeaux and Andy Seaborne, Editors, W3C Recommendation, 15
January 2008, http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/.
<a href="http://www.w3.org/TR/rdf-sparql-query/">Latest version</a>
available at http://www.w3.org/TR/rdf-sparql-query/</dd>
<dt>[<a id="ref-SW">SW</a>]</dt>
<dd><a rel="rec:cites" href="http://www.w3.org/2001/sw/" class="reference-title">W3C
Semantic Web Activity</a>. Available at http://www.w3.org/2001/sw/</dd>
<dt>[<a id="ref-SWBP-DATATYPES">SWBP-DATATYPES</a>]</dt>
<dd><a rel="dct:references"
href="http://www.w3.org/TR/2006/NOTE-swbp-xsch-datatypes-20060314/"
class="reference-title">XML Schema Datatypes in RDF and OWL</a>, Jeremy
J. Carroll and Jeff Z. Pan, Editors, W3C Working Group Note, 14 March
2006, http://www.w3.org/TR/2006/NOTE-swbp-xsch-datatypes-20060314/. <a
href="http://www.w3.org/TR/swbp-xsch-datatypes/">Latest version</a>
available at http://www.w3.org/TR/swbp-xsch-datatypes/</dd>
<dt>[<a id="ref-TURTLE">TURTLE</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TeamSubmission/2008/SUBM-turtle-20080114/"
class="reference-title">Turtle - Terse RDF Triple Language</a>, David
Beckett and Tim Berners-Lee, W3C Team Submission, 14 January 2008,
http://www.w3.org/TeamSubmission/2008/SUBM-turtle-20080114/. <a
href="http://www.w3.org/TeamSubmission/turtle/">Latest version</a>
available at http://www.w3.org/TeamSubmission/turtle/</dd>
<dt>[<a id="ref-WEBARCH">WEBARCH</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/2004/REC-webarch-20041215/"
class="reference-title">Architecture of the World Wide Web, Volume
One</a>, Ian Jacobs and Norman Walsh, Editors, W3C Recommendation, 15
December 2004, http://www.w3.org/TR/2004/REC-webarch-20041215/. <a
href="http://www.w3.org/TR/webarch/">Latest version</a> available at
http://www.w3.org/TR/webarch/</dd>
<dt>[<a id="ref-XML-SCHEMA">XML-SCHEMA</a>]</dt>
<dd><a rel="dct:references" href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"
class="reference-title">XML Schema Part 2: Datatypes Second
Edition</a>, Paul V. Biron and Ashok Malhotra, Editors, W3C
Recommendation, 28 October 2004,
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. <a
href="http://www.w3.org/TR/xmlschema-2/">Latest version</a> available
at http://www.w3.org/TR/xmlschema-2/</dd>
</dl>
<hr/>
<h2 id="ack">12. Acknowledgments</h2>
<p>This document is the result of extensive discussions within the
<a href="http://www.w3.org/2006/07/SWD/">W3C Semantic Web
Deployment Working Group</a>. The document drew on the experiences of
earlier groups and projects, including <a
href="http://www.w3.org/2001/sw/Europe/">SWAD-Europe</a> and the <a
href="http://www.w3.org/2001/sw/BestPractices/">W3C Semantic Web Best
Practices and Deployment Working Group</a>. Members of the W3C's <a
href="http://lists.w3.org/Archives/Public/public-esw-thes/">public-esw-thes</a>
mailing list also made valuable contributions.</p>
<hr />
<div id="div-appendices">
<div id="div-appendix-overview">
<a id="overview"></a>
<h2 id="L7127">Appendix A. SKOS Properties and Classes</h2>
<div id="div-appendix-overview-classes">
<h3 id="L7130">A.1. Classes in the SKOS Data Model</h3>
<table class="quick-reference">
<caption></caption>
<colgroup><col class="quick-ref-key" /><col class="quick-ref-value"
/></colgroup>
<tbody>
<tr>
<th colspan="2"><a href="#Collection" id="Collection">skos:Collection</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#Collection</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#collections">Section 9. Concept Collections</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>Collection</em></td>
</tr>
<tr>
<td>Disjoint classes: </td>
<td><code><a href="#Concept">skos:Concept</a></code><br />
<code><a href="#ConceptScheme">skos:ConceptScheme</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#Concept" id="Concept">skos:Concept</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#Concept</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#concepts">Section 3. The skos:Concept Class</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>Concept</em></td>
</tr>
<tr>
<td>Disjoint classes: </td>
<td><code><a href="#Collection">skos:Collection</a></code><br />
<code><a href="#ConceptScheme">skos:ConceptScheme</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#ConceptScheme" id="ConceptScheme">skos:ConceptScheme</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#ConceptScheme</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#schemes">Section 4. Concept Schemes</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>Concept Scheme</em></td>
</tr>
<tr>
<td>Disjoint classes: </td>
<td><code><a href="#Collection">skos:Collection</a></code><br />
<code><a href="#Concept">skos:Concept</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#OrderedCollection" id="OrderedCollection">skos:OrderedCollection</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#OrderedCollection</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#collections">Section 9. Concept Collections</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>Ordered Collection</em></td>
</tr>
<tr>
<td>Super-classes: </td>
<td><code><a href="#Collection">skos:Collection</a></code><br />
</td>
</tr>
</tbody>
</table>
</div>
<div id="div-appendix-overview-properties">
<h3 id="L7307">A.2. Properties in the SKOS Data Model</h3>
<table class="quick-reference">
<caption></caption>
<colgroup><col class="quick-ref-key" /><col class="quick-ref-value"
/></colgroup>
<tbody>
<tr>
<th colspan="2"><a href="#altLabel" id="altLabel">skos:altLabel</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#altLabel</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#labels">Section 5. Lexical Labels</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>alternative label</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code>http://www.w3.org/2000/01/rdf-schema#label</code></td>
</tr>
<tr>
<th colspan="2"><a href="#broadMatch" id="broadMatch">skos:broadMatch</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#broadMatch</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#mapping">Section 10. Mapping Properties</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>has broader match</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a href="#broader">skos:broader</a></code><br />
<code><a href="#mappingRelation">skos:mappingRelation</a></code><br />
</td>
</tr>
<tr>
<td>Inverse of:</td>
<td><code><a href="#narrowMatch">skos:narrowMatch</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#broader" id="broader">skos:broader</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#broader</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#semantic-relations">Section 8. Semantic Relations</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>has broader</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a
href="#broaderTransitive">skos:broaderTransitive</a></code><br />
</td>
</tr>
<tr>
<td>Inverse of:</td>
<td><code><a href="#narrower">skos:narrower</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#broaderTransitive" id="broaderTransitive">skos:broaderTransitive</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#broaderTransitive</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#semantic-relations">Section 8. Semantic Relations</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>has broader transitive</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a
href="#semanticRelation">skos:semanticRelation</a></code><br />
</td>
</tr>
<tr>
<td>Inverse of:</td>
<td><code><a
href="#narrowerTransitive">skos:narrowerTransitive</a></code><br />
</td>
</tr>
<tr>
<td>Other characteristics:</td>
<td>Transitive<br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#changeNote" id="changeNote">skos:changeNote</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#changeNote</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#notes">Section 7. Documentation Properties</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>change note</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a href="#note">skos:note</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#closeMatch" id="closeMatch">skos:closeMatch</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#closeMatch</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#mapping">Section 10. Mapping Properties</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>has close match</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a href="#mappingRelation">skos:mappingRelation</a></code><br
/>
</td>
</tr>
<tr>
<td>Other characteristics:</td>
<td>Symmetric<br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#definition" id="definition">skos:definition</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#definition</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#notes">Section 7. Documentation Properties</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>definition</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a href="#note">skos:note</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#editorialNote" id="editorialNote">skos:editorialNote</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#editorialNote</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#notes">Section 7. Documentation Properties</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>editorial note</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a href="#note">skos:note</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#exactMatch" id="exactMatch">skos:exactMatch</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#exactMatch</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#mapping">Section 10. Mapping Properties</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>has exact match</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a href="#closeMatch">skos:closeMatch</a></code><br />
</td>
</tr>
<tr>
<td>Other characteristics:</td>
<td>Transitive<br />
Symmetric<br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#example" id="example">skos:example</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#example</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#notes">Section 7. Documentation Properties</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>example</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a href="#note">skos:note</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#hasTopConcept" id="hasTopConcept">skos:hasTopConcept</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#hasTopConcept</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#schemes">Section 4. Concept Schemes</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>label</em></td>
</tr>
<tr>
<td>Domain:</td>
<td><code><a href="#ConceptScheme">skos:ConceptScheme</a></code><br />
</td>
</tr>
<tr>
<td>Range:</td>
<td><code><a href="#Concept">skos:Concept</a></code><br />
</td>
</tr>
<tr>
<td>Inverse of:</td>
<td><code><a href="#topConceptOf">skos:topConceptOf</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#hiddenLabel" id="hiddenLabel">skos:hiddenLabel</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#hiddenLabel</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#labels">Section 5. Lexical Labels</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>hidden label</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code>http://www.w3.org/2000/01/rdf-schema#label</code></td>
</tr>
<tr>
<th colspan="2"><a href="#historyNote" id="historyNote">skos:historyNote</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#historyNote</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#notes">Section 7. Documentation Properties</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>history note</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a href="#note">skos:note</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#inScheme" id="inScheme">skos:inScheme</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#inScheme</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#schemes">Section 4. Concept Schemes</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>is in scheme</em></td>
</tr>
<tr>
<td>Range:</td>
<td><code><a href="#ConceptScheme">skos:ConceptScheme</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#mappingRelation" id="mappingRelation">skos:mappingRelation</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#mappingRelation</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#mapping">Section 10. Mapping Properties</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>is in mapping relation with</em></td>
</tr>
<tr>
<td>Super-properties:</td>
<td><code><a href="#semanticRelation">skos:semanticRelation</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#member" id="member">skos:member</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#member</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#collections">Section 9. Concept Collections</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>has member</em></td>
</tr>
<tr>
<td>Domain:</td>
<td><code><a href="#Collection">skos:Collection</a></code><br />
</td>
</tr>
<tr>
<td>Range:</td>
<td>union of <code><a href="#Concept">skos:Concept</a></code> and <code><a href="#Collection">skos:Collection</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#memberList" id="memberList">skos:memberList</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#memberList</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#collections">Section 9. Concept Collections</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>has member list</em></td>
</tr>
<tr>
<td>Domain:</td>
<td><code><a
href="#OrderedCollection">skos:OrderedCollection</a></code><br />
</td>
</tr>
<tr>
<td>Range:</td>
<td><code>http://www.w3.org/1999/02/22-rdf-syntax-ns#List</code><br />
</td>
</tr>
<tr>
<td>Other characteristics:</td>
<td>Functional<br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#narrowMatch" id="narrowMatch">skos:narrowMatch</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#narrowMatch</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#mapping">Section 10. Mapping Properties</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>has narrower match</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a href="#mappingRelation">skos:mappingRelation</a></code><br
/>
<code><a href="#narrower">skos:narrower</a></code><br />
</td>
</tr>
<tr>
<td>Inverse of:</td>
<td><code><a href="#broadMatch">skos:broadMatch</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#narrower" id="narrower">skos:narrower</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#narrower</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#semantic-relations">Section 8. Semantic Relations</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>has narrower</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a
href="#narrowerTransitive">skos:narrowerTransitive</a></code><br />
</td>
</tr>
<tr>
<td>Inverse of:</td>
<td><code><a href="#broader">skos:broader</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#narrowerTransitive" id="narrowerTransitive">skos:narrowerTransitive</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#narrowerTransitive</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#semantic-relations">Section 8. Semantic Relations</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>has narrower transitive</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a
href="#semanticRelation">skos:semanticRelation</a></code><br />
</td>
</tr>
<tr>
<td>Inverse of:</td>
<td><code><a
href="#broaderTransitive">skos:broaderTransitive</a></code><br />
</td>
</tr>
<tr>
<td>Other characteristics:</td>
<td>Transitive<br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#notation" id="notation">skos:notation</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#notation</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#notations">Section 6. Notations</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>notation</em></td>
</tr>
<tr>
<th colspan="2"><a href="#note" id="note">skos:note</a>
</th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#note</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#notes">Section 7. Documentation Properties</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>note</em></td>
</tr>
<tr>
<th colspan="2"><a href="#prefLabel" id="prefLabel">skos:prefLabel</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#prefLabel</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#labels">Section 5. Lexical Labels</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>preferred label</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code>http://www.w3.org/2000/01/rdf-schema#label</code></td>
</tr>
<tr>
<th colspan="2"><a href="#related" id="related">skos:related</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#related</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#semantic-relations">Section 8. Semantic Relations</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>has related</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a
href="#semanticRelation">skos:semanticRelation</a></code><br />
</td>
</tr>
<tr>
<td>Other characteristics:</td>
<td>Symmetric<br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#relatedMatch" id="relatedMatch">skos:relatedMatch</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#relatedMatch</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#mapping">Section 10. Mapping Properties</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>has related match</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a href="#mappingRelation">skos:mappingRelation</a></code><br
/>
<code><a href="#related">skos:related</a></code><br />
</td>
</tr>
<tr>
<td>Other characteristics:</td>
<td>Symmetric<br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#scopeNote" id="scopeNote">skos:scopeNote</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#scopeNote</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#notes">Section 7. Documentation Properties</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>scope note</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a href="#note">skos:note</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#semanticRelation" id="semanticRelation">skos:semanticRelation</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#semanticRelation</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#semantic-relations">Section 8. Semantic Relations</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>is in semantic relation with</em></td>
</tr>
<tr>
<td>Domain:</td>
<td><code><a href="#Concept">skos:Concept</a></code><br />
</td>
</tr>
<tr>
<td>Range:</td>
<td><code><a href="#Concept">skos:Concept</a></code><br />
</td>
</tr>
<tr>
<th colspan="2"><a href="#topConceptOf" id="topConceptOf">skos:topConceptOf</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2004/02/skos/core#topConceptOf</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="#schemes">Section 4. Concept Schemes</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>is top concept in scheme</em></td>
</tr>
<tr>
<td>Super-properties: </td>
<td><code><a href="#inScheme">skos:inScheme</a></code><br />
</td>
</tr>
<tr>
<td>Inverse of:</td>
<td><code><a href="#hasTopConcept">skos:hasTopConcept</a></code><br />
</td>
</tr>
</tbody>
</table>
</div>
</div>
<hr />
<div id="div-appendix-xl">
<a id="xl"></a>
<h2 id="L4945">Appendix B. SKOS eXtension for Labels (SKOS-XL)</h2>
<p>This appendix defines an <strong>optional</strong> extension to the Simple
Knowledge Organization System, called the SKOS eXtension for Labels (SKOS-XL).
This extension provides additional support for identifying, describing and
linking lexical entities. </p>
<p>A special class of lexical entities, called <code>skosxl:Label</code>, is
defined. Each instance of this class has a single RDF plain literal form, but
two instances of this class are not necessarily the same individual if they
share the same literal form.</p>
<p>Three labeling properties, <code>skosxl:prefLabel</code>,
<code>skosxl:altLabel</code> and <code>skosxl:hiddenLabel</code>, are
defined. These properties are used to label SKOS concepts with instances of
<code>skosxl:Label</code>, and are otherwise analogous to the properties of
the same local name defined in SKOS (<code>skos:prefLabel</code>,
<code>skos:altLabel</code> and <code>skos:hiddenLabel</code>
respectively).</p>
<p>The SKOS data model also defines the property
<code>skosxl:labelRelation</code>. This property can be used to assert a
direct (binary) link between instances of <code>skosxl:Label</code>. It is
primarily intended as an extension point, to be refined for more specific
types of link. No built-in refinements of <code>skosxl:labelRelation</code>
are provided, although some examples of how this could be done are given. </p>
<a id="xl-vocab"></a>
<h3 id="L5212">B.1. SKOS-XL Namespace and Vocabulary</h3>
<p>The SKOS-XL namespace URI is:</p>
<ul>
<li><strong>http://www.w3.org/2008/05/skos-xl#</strong></li>
</ul>
<p>Here the prefix <code>skosxl:</code> is used as an abbreviation for the SKOS-XL
namespace URI.</p>
<p>The SKOS-XL vocabulary is the set of URIs given in the left-hand column of the
table below.</p>
<table border="0" class="vocab">
<caption>Table 2. The SKOS-XL Vocabulary</caption>
<tbody>
<tr>
<th>URI</th>
<th>Defined by (section of this appendix)</th>
</tr>
<tr>
<td><code>skosxl:Label</code></td>
<td><a href="#xl-Label">The skosxl:Label Class</a></td>
</tr>
<tr>
<td><code>skosxl:literalForm</code></td>
<td><a href="#xl-Label">The skosxl:Label Class</a></td>
</tr>
<tr>
<td><code>skosxl:prefLabel</code></td>
<td><a href="#xl-labels">Preferred, Alternate and Hidden
skosxl:Labels</a></td>
</tr>
<tr>
<td><code>skosxl:altLabel</code></td>
<td><a href="#xl-labels">Preferred, Alternate and Hidden
skosxl:Labels</a></td>
</tr>
<tr>
<td><code>skosxl:hiddenLabel</code></td>
<td><a href="#xl-labels">Preferred, Alternate and Hidden
skosxl:Labels</a></td>
</tr>
<tr>
<td><code>skosxl:labelRelation</code></td>
<td><a href="#xl-label-relations">Links Between skosxl:Labels</a></td>
</tr>
</tbody>
</table>
<p>Here "the SKOS-XL vocabulary" refers to the union of the SKOS vocabulary
and the SKOS-XL vocabulary. </p>
<p>Here "the XL data model" refers to the class and property definitions
stated in this appendix only. "The SKOS+XL data model" refers to the union of
the data model defined in sections 3-10 above and the XL data model.</p>
<a id="xl-Label"></a>
<h3 id="L5444">B.2. The skosxl:Label Class</h3>
<h4 id="L375">B.2.1. Preamble</h4>
<p>The class <code>skosxl:Label</code> is a special class of lexical
entities.</p>
<p>An instance of the class <code>skosxl:Label</code> is a resource and may
be named with a URI.</p>
<p>An instance of the class <code>skosxl:Label</code> has a single literal
form. This literal form is an RDF plain literal (which is a string of UNICODE
characters and an optional language tag [<a class="citation" rel="citation"
href="#ref-RDF-CONCEPTS">RDF-CONCEPTS</a>]). The property
<code>skosxl:literalForm</code> is used to give the literal form of an
<code>skosxl:Label</code>.</p>
<p>If two instances of the class <code>skosxl:Label</code> have the same
literal form, they are <strong>not</strong> necessarily the same resource.</p>
<h4 id="L5518">B.2.2. Class and Property Definitions</h4>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S47">S47</td>
<td><code>skosxl:Label</code> is an instance of
<code>owl:Class</code>.</td>
</tr>
<tr>
<td id="S48">S48</td>
<td><code>skosxl:Label</code> is disjoint with each of
<code>skos:Concept</code>, <code>skos:ConceptScheme</code> and
<code>skos:Collection</code>.</td>
</tr>
<tr>
<td id="S49">S49</td>
<td><code>skosxl:literalForm</code> is an instance of
<code>owl:DatatypeProperty</code>.</td>
</tr>
<tr>
<td id="S50">S50</td>
<td>The <code>rdfs:domain</code> of <code>skosxl:literalForm</code> is
the class <code>skosxl:Label</code>.</td>
</tr>
<tr>
<td id="S51">S51</td>
<td>The <code>rdfs:range</code> of <code>skosxl:literalForm</code> is
the class of RDF plain literals.</td>
</tr>
<tr>
<td id="S52">S52</td>
<td><code>skosxl:Label</code> is a sub-class of a restriction on
<code>skosxl:literalForm</code> cardinality exactly 1.</td>
</tr>
</tbody>
</table>
<h4 id="L5525">B.2.3. Examples</h4>
<p>The example below describes a <code>skosxl:Label</code> named with the
URI <code>&lt;http://example.com/ns/A&gt;</code>, with the literal form
"love" in English. </p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-75">Example 75 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; rdf:type skosxl:Label ; skosxl:literalForm "love"@en .</div>
</td>
</tr>
</tbody>
</table>
<p>The four examples below are each <strong>not consistent</strong> with the
XL data model, because an <code>skosxl:Label</code> is described with two
different literal forms.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-76">Example 76 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;B&gt; rdf:type skosxl:Label ; skosxl:literalForm "love" ;
skosxl:literalForm "adoration" .<br />
</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-77">Example 77 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;B&gt; rdf:type skosxl:Label ; skosxl:literalForm "love"@en ;
skosxl:literalForm "love"@fr .<br />
</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-78">Example 78 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;B&gt; rdf:type skosxl:Label ; skosxl:literalForm "love"@en-GB ;
skosxl:literalForm "love"@en-US .<br />
</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-79">Example 79 (not consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;B&gt; rdf:type skosxl:Label ; skosxl:literalForm "東"@ja-Hani ;
skosxl:literalForm "ひがし"@ja-Hira .<br />
</div>
</td>
</tr>
</tbody>
</table>
<h4 id="L5716">B.2.4. Notes</h4>
<h5 id="L5739">B.2.4.1. Identity and Entailment</h5>
<p>As stated above, each instance of the class <code>skosxl:Label</code> has
<strong>one and only one literal form</strong>. In other words, there is a
function mapping the class extension of <code>skosxl:Label</code> to the set
of RDF plain literals. This function is defined by the property extension of
<code>skosxl:literalForm</code>. Note especially two facts about this
function. </p>
<p>First, the function is <strong>not</strong> injective. In other words,
there is <strong>not</strong> a one-to-one mapping from instances of
<code>skosxl:Label</code> to the set of RDF plain literals (in fact it is
many-to-one). This means that two instances of <code>skosxl:Label</code>
which have the same literal form are <strong>not necessarily</strong> the
same individual. So, for example, the entailment illustrated below is
<strong>not</strong> supported by the XL data model.</p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-80">Example 80 (non-entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skosxl:literalForm "love"@en .<br />
&lt;B&gt; skosxl:literalForm "love"@en .</div>
<p><em>does not entail</em></p>
<div>
&lt;A&gt; owl:sameAs &lt;B&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>Second, the function is <strong>not</strong> surjective. In other words,
for a given plain literal <code>l</code>, there might not be any instances of
<code>skosxl:Label</code> with literal form <code>l</code>.</p>
<h5 id="L648">B.2.4.2. Membership of Concept Schemes</h5>
<p>The membership of an instance of <code>skosxl:Label</code> within a SKOS
concept scheme can be asserted using the <code>skos:inScheme</code>
property.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-81">Example 81 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; rdf:type skosxl:Label ; skosxl:literalForm "love"@en ;
skos:inScheme &lt;MyScheme&gt; .</div>
</td>
</tr>
</tbody>
</table>
<a id="xl-labels"></a>
<h3 id="L5981">B.3. Preferred, Alternate and Hidden skosxl:Labels</h3>
<h4 id="L661">B.3.1. Preamble</h4>
<p>The three properties <code>skosxl:prefLabel</code>,
<code>skosxl:altLabel</code> and <code>skosxl:hiddenLabel</code> are used to
give the preferred, alternative and hidden labels of a resource respectively,
where those labels are instances of the class <code>skosxl:Label</code>.
These properties are analogous to the properties of the same local name
defined in the SKOS vocabulary, and there are logical dependencies between
these two sets of properties defined below.</p>
<h4 id="L677">B.3.2. Class and Property Definitions</h4>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S53">S53</td>
<td><code>skosxl:prefLabel</code>, <code>skosxl:altLabel</code> and
<code>skosxl:hiddenLabel</code> are each instances of
<code>owl:ObjectProperty</code>.</td>
</tr>
<tr>
<td id="S54">S54</td>
<td>The <code>rdfs:range</code> of each of
<code>skosxl:prefLabel</code>, <code>skosxl:altLabel</code> and
<code>skosxl:hiddenLabel</code> is the class
<code>skosxl:Label</code>.</td>
</tr>
<tr>
<td id="S55">S55</td>
<td>The property chain (<code>skosxl:prefLabel</code>,
<code>skosxl:literalForm</code>) is a sub-property of
<code>skos:prefLabel</code>.</td>
</tr>
<tr>
<td id="S56">S56</td>
<td>The property chain (<code>skosxl:altLabel</code>,
<code>skosxl:literalForm</code>) is a sub-property of
<code>skos:altLabel</code>.</td>
</tr>
<tr>
<td id="S57">S57</td>
<td>The property chain (<code>skosxl:hiddenLabel</code>,
<code>skosxl:literalForm</code>) is a sub-property of
<code>skos:hiddenLabel</code>.</td>
</tr>
<tr>
<td id="S58">S58</td>
<td><code>skosxl:prefLabel</code>, <code>skosxl:altLabel</code> and <code>skosxl:hiddenLabel</code> are pairwise disjoint properties.</td>
</tr>
</tbody>
</table>
<h4 id="L724">B.3.3. Examples</h4>
<p>The example below illustrates the use of all three XL labeling properties,
and is consistent with the SKOS+XL data model.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-82">Example 82 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;Love&gt; <br />
  skosxl:prefLabel &lt;A&gt; ;<br />
  skosxl:altLabel &lt;B&gt; ;<br />
  skosxl:hiddenLabel &lt;C&gt; .<br />
<br />
&lt;A&gt; rdf:type skosxl:Label ;<br />
  skosxl:literalForm "love"@en .<br />
<br />
&lt;B&gt; rdf:type skosxl:Label ;<br />
  skosxl:literalForm "adoration"@en .<br />
<br />
&lt;C&gt; rdf:type skosxl:Label ;<br />
  skosxl:literalForm "luv"@en .</div>
</td>
</tr>
</tbody>
</table>
<h4 id="L778">B.3.4. Notes</h4>
<h5 id="L780">B.3.4.1. Dumbing-Down to SKOS Lexical Labels</h5>
<p>The sub-property chain axioms <a href="#S55">S55</a>, <a href="#S56">S56</a>
and <a href="#S57">S57</a> support the dumbing-down of XL labels
to vanilla SKOS lexical labels via inference. This is illustrated in the
example below.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-83">Example 83 (entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;Love&gt; <br />
  skosxl:prefLabel &lt;A&gt; ;<br />
  skosxl:altLabel &lt;B&gt; ;<br />
  skosxl:hiddenLabel &lt;C&gt; .<br />
<br />
&lt;A&gt; rdf:type skosxl:Label ;<br />
  skosxl:literalForm "love"@en .<br />
<br />
&lt;B&gt; rdf:type skosxl:Label ;<br />
  skosxl:literalForm "adoration"@en .<br />
<br />
&lt;C&gt; rdf:type skosxl:Label ;<br />
  skosxl:literalForm "luv"@en .</div>
<p><em>entails</em></p>
<div>
&lt;Love&gt; <br />
  skos:prefLabel "love"@en ;<br />
  skos:altLabel "adoration"@en ;<br />
  skos:hiddenLabel "luv"@en .</div>
</td>
</tr>
</tbody>
</table>
<h5 id="L899">B.3.4.2. SKOS+XL Labeling Integrity</h5>
<p>In <a href="#labels">Section 5</a>, two integrity conditions were defined
on the basic SKOS labeling properties. First, the properties
<code>skos:prefLabel</code>, <code>skos:altLabel</code> and
<code>skos:hiddenLabel</code> are pairwise disjoint. Second, a resource has
no more than one value of <code>skos:prefLabel</code> per language. Because
of the sub-property chain axioms defined above, the following four examples,
whilst consistent w.r.t. the XL data model alone, are <strong>not</strong>
consistent with the SKOS+XL data model. </p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-84">Example 84 (not consistent)</th>
</tr>
<tr>
<td>
<div>
# Two different preferred labels in the same language<br />
<br />
&lt;Love&gt; skosxl:prefLabel &lt;A&gt; ; skosxl:prefLabel &lt;B&gt;
.<br />
&lt;A&gt; skosxl:literalForm "love"@en .<br />
&lt;B&gt; skosxl:literalForm "adoration"@en .<br />
</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-85">Example 85 (not consistent)</th>
</tr>
<tr>
<td>
<div>
# Clash between preferred and alternative labels<br />
<br />
&lt;Love&gt; skosxl:prefLabel &lt;A&gt; ; skosxl:altLabel &lt;B&gt;
.<br />
&lt;A&gt; skosxl:literalForm "love"@en .<br />
&lt;B&gt; skosxl:literalForm "love"@en .<br />
</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-86">Example 86 (not consistent)</th>
</tr>
<tr>
<td>
<div>
# Clash between alternative and hidden labels<br />
<br />
&lt;Love&gt; skosxl:altLabel &lt;A&gt; ; skosxl:hiddenLabel &lt;B&gt;
.<br />
&lt;A&gt; skosxl:literalForm "love"@en .<br />
&lt;B&gt; skosxl:literalForm "love"@en .<br />
</div>
</td>
</tr>
</tbody>
</table>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-87">Example 87 (not consistent)</th>
</tr>
<tr>
<td>
<div>
# Clash between preferred and hidden labels<br />
<br />
&lt;Love&gt; skosxl:prefLabel &lt;A&gt; ; skosxl:hiddenLabel
&lt;B&gt; .<br />
&lt;A&gt; skosxl:literalForm "love"@en .<br />
&lt;B&gt; skosxl:literalForm "love"@en .<br />
</div>
</td>
</tr>
</tbody>
</table>
<a id="xl-label-relations"></a>
<h3 id="L7196">B.4. Links Between skosxl:Labels</h3>
<h4 id="L1120">B.4.1. Preamble</h4>
<p>This section defines a pattern for representing binary links between
instances of the class <code>skosxl:Label</code>.</p>
<p>Note that the vocabulary defined in this section is not intended to be
used directly, but rather as an extension point which can be refined for more
specific labeling scenarios.</p>
<h4 id="L1129">B.4.2. Class and Property Definitions</h4>
<table border="0" class="semantics">
<caption></caption>
<tbody>
<tr>
<td id="S59">S59</td>
<td><code>skosxl:labelRelation</code> is an instance of
<code>owl:ObjectProperty</code>.</td>
</tr>
<tr>
<td id="S60">S60</td>
<td>The <code>rdfs:domain</code> of <code>skosxl:labelRelation</code>
is the class <code>skosxl:Label</code>.</td>
</tr>
<tr>
<td id="S61">S61</td>
<td>The <code>rdfs:range</code> of <code>skosxl:labelRelation</code> is
the class <code>skosxl:Label</code>.</td>
</tr>
<tr>
<td id="S62">S62</td>
<td><code>skosxl:labelRelation</code> is an instance of
<code>owl:SymmetricProperty</code>.</td>
</tr>
</tbody>
</table>
<h4 id="L1160">B.4.3. Examples</h4>
<p>The example below illustrates a link between two instances of the class
<code>skosxl:Label</code>.</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-88">Example 88 (consistent)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; rdf:type skosxl:Label ; skosxl:literalForm "love" .<br />
&lt;B&gt; rdf:type skosxl:Label ; skosxl:literalForm "adoration" .<br
/>
&lt;A&gt; skosxl:labelRelation &lt;B&gt; .<br />
</div>
</td>
</tr>
</tbody>
</table>
<h4 id="L1193">B.4.4. Notes</h4>
<h5 id="L1195">B.4.4.1. Refinements of this Pattern</h5>
<p>As mentioned above, the <code>skosxl:labelRelation</code> property serves
as an extension point, which can be refined for more specific labeling
scenarios.</p>
<p>In the example below, a third party has refined the property
<code>skos:labelRelation</code> to express acronym relationships, and used it
to express the fact that "FAO" is an acronym for "Food and Agriculture
Organization".</p>
<table border="0" class="example-good">
<caption></caption>
<tbody>
<tr>
<th id="example-89">Example 89 (consistent)</th>
</tr>
<tr>
<td>
<div>
# First define an extension to skosxl:labelRelation<br />
ex:acronym rdfs:subPropertyOf skosxl:labelRelation .<br />
<br />
# Now use it<br />
&lt;A&gt; rdf:type skosxl:Label ; skosxl:literalForm "FAO"@en .<br />
&lt;B&gt; rdf:type skosxl:Label ; skosxl:literalForm "Food and
Agriculture Organization"@en .<br />
&lt;B&gt; ex:acronym &lt;A&gt; .<br />
</div>
</td>
</tr>
</tbody>
</table>
<p>Note that a sub-property of a symmetric property is not necessarily
symmetric.</p>
<h3 id="xl-overview">B.5. SKOS-XL Schema Overview</h3>
<p>The following table gives an overview of the SKOS-XL vocabulary. </p>
<div id="div-xl-overview-classes">
<h3>B.5.1 Classes in the SKOS-XL Data Model</h3>
<table class="quick-reference">
<caption></caption>
<colgroup><col class="quick-ref-key" /><col class="quick-ref-value"
/></colgroup>
<tbody>
<tr>
<th colspan="2"><a href="#Label" id="Label"
name="Label">skosxl:Label</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2008/05/skos-xl#Label</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="http://www.w3.org/TR/skos-reference#xl-Label">Section B.2. The skosxl:Label Class</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>Label</em></td>
</tr>
<tr>
<td>Super-classes:</td>
<td>restriction on <code><a href="#xl-literalForm">skosxl:literalForm</a></code> cardinality exactly 1</td>
</tr>
<tr>
<td>Disjoint classes: </td>
<td><code><a href="http://www.w3.org/2008/05/skos#Collection">skos:Collection</a></code><br /><code><a href="http://www.w3.org/2008/05/skos#Concept">skos:Concept</a></code><br /><code><a href="http://www.w3.org/2008/05/skos#ConceptScheme">skos:ConceptScheme</a></code><br /></td>
</tr>
</tbody>
</table>
</div>
<div id="div-xl-overview-properties">
<h3>B.5.2.Properties in the SKOS-XL Data Model</h3>
<table class="quick-reference">
<caption></caption>
<colgroup><col class="quick-ref-key" /><col class="quick-ref-value"
/></colgroup>
<tbody>
<tr>
<th colspan="2"><a href="#xl-altLabel" id="xl-altLabel"
name="xl-altLabel">skosxl:altLabel</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2008/05/skos-xl#altLabel</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="http://www.w3.org/TR/skos-reference#xl-labels">Section B.3. Preferred, Alternate and Hidden skosxl:Labels</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>alternative label</em></td>
</tr>
<tr>
<td>Range:</td>
<td><code><a href="#xl-Label">skosxl:Label</a></code><br /></td>
</tr>
<tr>
<th colspan="2"><a href="#xl-hiddenLabel" id="xl-hiddenLabel"
name="xl-hiddenLabel">skosxl:hiddenLabel</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2008/05/skos-xl#hiddenLabel</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="http://www.w3.org/TR/skos-reference#xl-labels">Section B.3. Preferred, Alternate and Hidden skosxl:Labels</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>hidden label</em></td>
</tr>
<tr>
<td>Range:</td>
<td><code><a href="#xl-Label">skosxl:Label</a></code><br /></td>
</tr>
<tr>
<th colspan="2"><a href="#xl-labelRelation" id="xl-labelRelation"
name="xl-labelRelation">skosxl:labelRelation</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2008/05/skos-xl#labelRelation</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="http://www.w3.org/TR/skos-reference#xl-label-relations">Section B.4. Links Between skosxl:Labels</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>label relation</em></td>
</tr>
<tr>
<td>Domain:</td>
<td><code><a href="#xl-Label">skosxl:Label</a></code><br /></td>
</tr>
<tr>
<td>Range:</td>
<td><code><a href="#xl-Label">skosxl:Label</a></code><br /></td>
</tr>
<tr>
<td>Other characteristics:</td>
<td>Symmetric<br/></td>
</tr>
<tr>
<th colspan="2"><a href="#xl-literalForm" id="xl-literalForm"
name="xl-literalForm">skosxl:literalForm</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2008/05/skos-xl#literalForm</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="http://www.w3.org/TR/skos-reference#xl-Label">Section B.2. The skosxl:Label Class</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>literal form</em></td>
</tr>
<tr>
<td>Domain:</td>
<td><code><a href="#xl-Label">skosxl:Label</a></code><br /></td>
</tr>
<tr>
<th colspan="2"><a href="#xl-prefLabel" id="xl-prefLabel"
name="xl-prefLabel">skosxl:prefLabel</a> </th>
</tr>
<tr>
<td>URI: </td>
<td><code>http://www.w3.org/2008/05/skos-xl#prefLabel</code> </td>
</tr>
<tr>
<td>Definition: </td>
<td><a href="http://www.w3.org/TR/skos-reference#xl-labels">Section B.3. Preferred, Alternate and Hidden skosxl:Labels</a></td>
</tr>
<tr>
<td>Label: </td>
<td><em>preferred label</em></td>
</tr>
<tr>
<td>Range:</td>
<td><code><a href="#xl-Label">skosxl:Label</a></code><br /></td>
</tr></tbody>
</table>
</div>
<!--
<p>The SKOS eXtension for Labels (XL) Data Model as RDF Triples can be found
at <a
href="http://www.w3.org/2008/05/skos-xl">http://www.w3.org/2008/05/skos-xl</a>.</p>
<p>Note also that it is not possible to express all of the statements of the
XL data model as RDF triples and thus the schema forms a normative subset of
this specification.</p>
-->
<hr />
</div>
<div id="div-appendix-semantics-as-triples">
<a id="namespace-documents"></a>
<h2 id="L2994">Appendix C. SKOS and SKOS-XL Namespace Documents</h2>
<p>Following Architecture of the World Wide Web, Volume One [<a
class="citation" rel="citation" href="#ref-WEBARCH">WEBARCH</a>], a
"namespace document" is an "information resource that contains useful
information, machine-usable and/or human-usable, about terms in the
namespace".</p>
<p>The SKOS vocabulary is a conceptual resource identified by the
namespace URI <code><a href="http://www.w3.org/TR/skos-reference/">http://www.w3.org/2004/02/skos/core#</a></code>. The
normative definition of the SKOS vocabulary is found in SKOS Reference
(this document).</p>
<p>The following namespace documents provide alternative
representations of the SKOS vocabulary:</p>
<h3 id="namespace-document-html">C.1. SKOS Namespace Document - HTML Variant (normative)</h3>
<p>The SKOS vocabulary is summarized in SKOS Namespace Document - HTML
Variant [<a class="citation" rel="citation"
href="#ref-SKOS-HTML">SKOS-HTML</a>], which is served from the
namespace URI <code><a
href="http://www.w3.org/2004/02/skos/core#">http://www.w3.org/2004/02/skos/core#</a></code>
via content negotiation using Recipe 3 of "Best Practice Recipes for
Publishing Vocabularies" [<a class="citation" rel="citation"
href="#ref-RECIPES">RECIPES</a>]. Clients requiring HTML or XHTML
should include an appropriate "Accept" header in the HTTP
request. Alternatively, the SKOS Namespace Document - HTML Variant can
be referenced directly by citing its URI: <code><a
href="http://www.w3.org/TR/skos-reference/skos.html">http://www.w3.org/TR/skos-reference/skos.html</a></code>.</p>
<p>The
SKOS Namespace Document - HTML Variant replicates <a
href="#overview">Appendix
A. SKOS Properties and Classes</a> of this document.</p>
<h3 id="namespace-document-rdf">C.2. SKOS Namespace Document - RDF/XML Variant (normative)</h3>
<p>The SKOS Namespace Document - RDF/XML Variant [<a class="citation"
rel="citation" href="#ref-SKOS-RDF">SKOS-RDF</a>] expresses the SKOS
vocabulary and data model (in so far as possible) as RDF triples. It
is served via content negotiation using Recipe 3 of "Best Practice
Recipes for Publishing Vocabularies" [<a class="citation"
rel="citation" href="#ref-RECIPES">RECIPES</a>]. Clients requiring
RDF/XML should include an appropriate "Accept" header in the HTTP
request. Alternatively, the RDF schema can be referenced directly
(and downloaded) by citing its URI: <code><a
href="http://www.w3.org/TR/skos-reference/skos.rdf">http://www.w3.org/TR/skos-reference/skos.rdf</a></code>.</p>
<p>It is not possible to express all of the statements of the SKOS
data model as RDF triples, so this schema forms a normative subset of
SKOS Reference. The RDF schema defines an OWL Full ontology
[<a class="citation" rel="citation"
href="#ref-OWL-SEMANTICS">OWL-SEMANTICS</a>] [<a class="citation"
rel="citation" href="#ref-OWL-REFERENCE">OWL-REFERENCE</a>]. SKOS vocabularies can be defined as
instances of this ontology.</p>
<h3 id="rdf-schema-owl-dl">C.3. SKOS RDF Schema - OWL 1 DL Sub-set (informative)</h3>
<p>For the convenience of tools and applications that wish to work
within the constraints of OWL DL, the SKOS RDF Schema - OWL 1 DL
Sub-set [<a class="citation" rel="citation"
href="#ref-SKOS-RDF-OWL1-DL">SKOS-RDF-OWL1-DL</a>] provides a
modified, informative, schema which conforms to those constraints.
Note that this schema is obtained through the deletion of triples
representing axioms that violate OWL DL constraints. Alternative
prunings could be performed.</p>
<p>The SKOS OWL 1 DL Sub-set is available
by citing its URI: <code><a
href="http://www.w3.org/TR/skos-reference/skos-owl1-dl.rdf">http://www.w3.org/TR/skos-reference/skos-owl1-dl.rdf</a></code></p>
<h3 id="xl-namespace-document-html">C.4. SKOS-XL Namespace Document - HTML Variant (normative)</h3>
<p>The SKOS-XL vocabulary is summarized in SKOS-XL Namespace Document
- HTML Variant [<a class="citation" rel="citation"
href="#ref-SKOS-XL-HTML">SKOS-XL-HTML</a>], which is served from the
namespace URI <code><a
href="http://www.w3.org/2008/05/skos-xl#">http://www.w3.org/2008/05/skos-xl#</a></code>
via content negotiation using Recipe 3 of "Best Practice Recipes for
Publishing Vocabularies" [<a class="citation" rel="citation"
href="#ref-RECIPES">RECIPES</a>]. Clients requiring HTML or XHTML
should include an appropriate "Accept" header in the HTTP
request. Alternatively, the SKOS-XL Namespace Document - HTML Variant
can be referenced directly by citing its URI: <code><a
href="http://www.w3.org/TR/skos-reference/skos-xl.html">http://www.w3.org/TR/skos-reference/skos-xl.html</a></code>.</p>
<p>The SKOS-XL HTML Variant Namespace Document replicates <a
href="#xl-overview">Appendix
B.5 SKOS-XL Schema Overview</a> of this document.</p>
<h3 id="xl-namespace-document-rdf">C.5. SKOS-XL Namespace Document - RDF/XML Variant (normative)</h3>
<p>This RDF schema document expresses the SKOS vocabulary and data
model (in so far as possible) as RDF triples. It is served
from the namespace URI <code><a href="http://www.w3.org/2008/05/skos-xl#">http://www.w3.org/2008/05/skos-xl#</a></code> via content
negotiation using Recipe 3 of "Best Practice Recipes for Publishing
Vocabularies" [<a class="citation" rel="citation"
href="#ref-RECIPES">RECIPES</a>]. Clients requiring RDF/XML should
include an appropriate "Accept" header in the HTTP request.
Alternatively, the RDF schema can be referenced directly (and
downloaded) by citing its URI: <code><a href="http://www.w3.org/TR/skos-reference/skos-xl.rdf">http://www.w3.org/TR/skos-reference/skos-xl.rdf</a></code>.</p>
<hr />
</div>
<!-- end div-appendix-semantics-as-triples -->
<div id="div-appendix-namespace">
<a id="namespace"></a>
<h2>Appendix D. SKOS Namespace: a historical note</h2>
<p>The SKOS schema defines vocabulary using the namespace <a
href="http://www.w3.org/2004/02/skos/core#">http://www.w3.org/2004/02/skos/core#</a>.
This namespace was used to define the original SKOS schema which
served as a starting point for this Recommendation. As a result of
this, elements present in previous versions of the machine-readable schema have been removed from the current version. In a number of cases, the definition or semantics of
elements in the schema has changed. </p>
<p>Retaining the existing SKOS namespace avoids some issues with
existing KOS that are already using the SKOS schema. Users
should, however, be aware of the change in the semantics of
<code>skos:broader</code> (and <code>skos:narrower</code>) which <em>may</em>
impact on SKOS applications.</p>
<p>Where elements have been removed, no explicit deprecation axioms
have been expressed in the schema. Historical versions of the SKOS schema, are,
however, available from the <a href="http://www.w3.org/2004/02/skos/history">SKOS Web site "version history" page</a>, and those elements which have been removed
from the recent version of the vocabulary are listed below.</p>
<ul>
<li><code>skos:symbol</code></li>
<li><code>skos:prefSymbol</code></li>
<li><code>skos:altSymbol</code></li>
<li><code>skos:CollectableProperty</code></li>
<li><code>skos:subject</code></li>
<li><code>skos:isSubjectOf</code></li>
<li><code>skos:primarySubject</code></li>
<li><code>skos:isPrimarySubjectOf</code></li>
<li><code>skos:subjectIndicator</code></li>
</ul>
<p>In the case of <code>skos:broader</code> and
<code>skos:narrower</code>, the semantics of the vocabulary elements
have been changed &mdash; these properties are no longer declared to be
transitive. Thus the follow entailment does not hold. </p>
<table border="0" class="example-bad">
<caption></caption>
<tbody>
<tr>
<th id="example-90">Example 90 (non-entailment)</th>
</tr>
<tr>
<td>
<div>
&lt;A&gt; skos:broader &lt;B&gt; .<br />
&lt;B&gt; skos:broader &lt;C&gt; .</div>
<p><em>does not entail</em></p>
<div>
&lt;A&gt; skos:broader &lt;C&gt; .</div>
</td>
</tr>
</tbody>
</table>
<p>A transitive super property of <code>skos:broader</code> &mdash;
<code>skos:broaderTransitive</code> &mdash; is provided which allows for
query across the transitive closure of <code>skos:broader</code>
relations. A similar property
&mdash; <code>skos:narrowerTransitive</code> &mdash; is provided
for query across the transitive closure of <code>skos:narrower</code>.</p>
</div>
<!-- end div-appendix-semantics-as-triples -->
<div id="div-appendix-uri-dereference-behavior">
<a id="dereference"></a> </div>
<!-- end div-appendix-uri-dereference-behavior -->
</div>
<!-- end div-appendices -->
<div id="div-ft">
<hr/>
<p>
<a href="http://validator.w3.org/check?uri=referer"><img
src="http://www.w3.org/Icons/valid-xhtml-rdfa-blue"
alt="Valid XHTML + RDFa" /></a>
</p>
</div>
</div>
</body>
</html>