SKOS Simple Knowledge Organization System Reference

<?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="https://www.w3.org/StyleSheets/TR/W3C-WD" 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="https://www.w3.org/"><img height="48" width="72" alt="W3C" src="https://www.w3.org/Icons/w3c_home" /></a> <h1>SKOS Simple Knowledge Organization System <br /> Reference</h1> <h2><a id="w3c-doctype" name="w3c-doctype"></a>W3C Working Draft 9 June 2008</h2> <dl> <dt>This version: </dt> <dd><a href="https://www.w3.org/TR/2008/WD-skos-reference-20080609/">http://www.w3.org/TR/2008/WD-skos-reference-20080609/</a></dd> <dt>Latest version:</dt> <dd><a href="https://www.w3.org/TR/skos-reference">http://www.w3.org/TR/skos-reference</a></dd> <dt>Previous version:</dt> <dd><a href="https://www.w3.org/TR/2008/WD-skos-reference-20080125/">http://www.w3.org/TR/2008/WD-skos-reference-20080125/</a></dd> <dt>Editors:</dt> <dd><a href="http://purl.org/net/aliman">Alistair Miles</a>, STFC Rutherford Appleton Laboratory / University of Oxford<br /> <a href="http://www.cs.man.ac.uk/~seanb/">Sean Bechhofer</a>, University of Manchester<br /> </dd> </dl> <p class="copyright"><a href="https://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2008 <a href="https://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="https://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="https://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="https://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p> <hr /> </div> <div id="div-abstract"> <h2><a id="abstract" name="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 Semantic 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 light weight, 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 href="https://www.w3.org/TR/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-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="#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> </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 <code>skos:Concept</code> 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="#xl">A. SKOS eXtension for Labels (XL)</a></li> <li><a href="#overview">B. SKOS Overview</a></li> <li><a href="#triples">C. SKOS Data Model as Triples</a></li> </ul> </div> <div id="div-sotd"> <h2><a id="status" name="status">Status of This Document</a></h2>  <p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="https://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p> <p>This document is a Working Draft published by the <a href="https://www.w3.org/2006/07/SWD/">Semantic Web Deployment Working Group</a>, part of the <a href="https://www.w3.org/2001/sw/Activity">W3C Semantic Web Activity</a>. This Working Draft updates the the <a href="https://www.w3.org/TR/2008/WD-skos-reference-20080125/">25 Jan 2008 Working Draft</a> with the Working Group decisions since that time. The changes are summarized below.</p> <p>The Working Group solicits review and feedback on this draft specification. All comments are welcome and may be sent to <a href="mailto:public-swd-wg@w3.org">public-swd-wg@w3.org</a>; please include the text "SKOS comment" in the subject line. All messages received at this address are viewable in a <a href="http://lists.w3.org/Archives/Public/public-swd-wg/" >public archive</a>. Certain open issues are indicated with Editors' notes to particularly draw the attention of readers.</p> <p id ="_TODO" class="editorial"><strong>Editors' note:</strong> Anything marked in the document with an "@@" indicates something still to be done or fixed. For example, "@@TODO" indicates an outstanding task, "@@REF" indicates a reference that needs to be properly cited.</p> <p>The Working Group intends to advance the SKOS Reference to W3C Recommendation after further review and comment. Per W3C Process, a future Last Call Working Draft will signal the Working Group's belief that it has met its design objectives for SKOS and has resolved all open issues. Based on its current schedule, the Working Group hopes to issue the Last Call Working Draft in July 2008.</p> <p> This document was produced by a group operating under the <a href="https://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. W3C maintains a <a rel="disclosure" href="https://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="https://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>. </p> <p>Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p> <hr /> <h2 id="changes">Changes</h2> <h3 id="changes0125">Changes Since 2008-01-25 Working Draft</h3> <p>The major changes are:</p> <ul> <li>A new section on notations has been included.</li> <li>A new appendix "SKOS eXtension for Labels" has been included.</li> <li>The section on label relations has been dropped. This is replaced by the xl:labelRelation property in the eXtension for Labels appendix.</li> <li>The section on mapping properties has been rewritten to reflect the decision to make skos:broadMatch, skos:narrowMatch and skos:relatedMatch sub-properties of skos:broader, skos:narrower and skos:related respectively.</li> <li>Appendices on SKOS Rules of Thumb, SKOS/OWL Patterns, SKOS/SPARQL Patterns and Extending SKOS have been dropped as out of scope for this document, to be covered in the SKOS Primer and/or other specifications. </li> </ul> <hr /> </div> <div id="div-toc"> <a name="toc" 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="#L155">1. Introduction</a> <ul> <li><a href="#L879">1.1. Background and Motivation</a></li> <li><a href="#L895">1.2. What is SKOS?</a></li> <li><a href="#L1045">1.4. SKOS, RDF and OWL</a></li> <li><a href="#L831">1.5. Consistency and Integrity </a></li> <li><a href="#L881">1.6. Inference, Dependency and the Open-World Assumption</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="#L1302">2. SKOS Namespace and Vocabulary</a></li> <li><a href="#L1289">3. The skos:Concept Class</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 & 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="#L2430">4. Concept Schemes</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 & 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="#L1232">4.6.3. SKOS Concept Schemes and Named RDF Graphs</a></li> <li><a href="#L2446">4.6.4. Top Concepts and Semantic Relations</a></li> </ul> </li> </ul> </li> <li><a href="#L2831">5. Lexical Labels</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 & 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="#L1606">5.6.3. Alternates Without Preferred</a></li> <li><a href="#L1629">5.6.4. Definition of a "Language"</a></li> </ul> </li> </ul> </li> <li><a href="#L2064">6. Notations</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 & 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> </ul> </li> </ul> </li> <li><a href="#L2860">7. Documentation Properties (Note Properties)</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 & 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. Type & Range of the SKOS Documentation Properties</a></li> </ul> </li> </ul> </li> <li><a href="#L1930">8. Semantic Relations</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 & 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. Transitivity of skos:related</a></li> <li><a href="#L2376">8.6.5. Reflexivity of skos:related</a></li> <li><a href="#L2413">8.6.6. Transitivity of skos:broader</a></li> <li><a href="#L2449">8.6.7. Reflexivity of skos:broader</a></li> <li><a href="#L2484">8.6.8. Cycles in the Hierarchical Relation (Reflexivity of skos:broaderTransitive)</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="#L2942">9. Concept Collections</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 & 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="#L1309">10. Mapping Properties</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 & Property Definitions</a></li> <li><a href="#L4316">10.4. Examples</a></li> <li><a href="#L4412">10.5. Notes</a> <ul> <li><a href="#L4160">10.5.1. Mapping Properties, Semantic Relation Properties and Concept Schemes</a></li> <li><a href="#L4394">10.5.2. "Clashes" Between Hierarchical and Associative Links</a></li> <li><a href="#L4414">10.5.3. Transitivity of Mapping Properties</a></li> <li><a href="#L4499">10.5.4. Reflexivity of Mapping Properties</a></li> <li><a href="#L4534">10.5.5. "Clashes" with skos:exactMatch</a></li> <li><a href="#L4564">10.5.6. Cycles and Alternate Paths Involving skos:broadMatch</a></li> <li><a href="#L5675">10.5.7. Property Chains Involving skos:exactMatch</a></li> <li><a href="#L4858">10.5.8. skos:exactMatch, owl:sameAs, owl:equivalentClass, owl:equivalentProperty</a></li> </ul> </li> </ul> </li> <li><a href="#L744">11. References</a></li> <li><a href="#L4945">Appendix A. SKOS eXtension for Labels (XL)</a> <ul> <li><a href="#L5212">A.1. XL Namespace and Vocabulary</a></li> <li><a href="#L5444">A.2. The xl:Label Class</a> <ul> <li><a href="#L375">A.2.1. Preamble</a></li> <li><a href="#L5518">A.2.2. Class and Property Definitions</a></li> <li><a href="#L5525">A.2.3. Examples</a></li> <li><a href="#L5716">A.2.4. Notes</a> <ul> <li><a href="#L5739">A.2.4.1. Identity and Entailment</a></li> <li><a href="#L648">A.2.4.2. Membership of Concept Schemes</a></li> </ul> </li> </ul> </li> <li><a href="#L5981">A.3. Preferred, Alternate and Hidden xl:Labels</a> <ul> <li><a href="#L661">A.3.1. Preamble</a></li> <li><a href="#L677">A.3.2. Class and Property Definitions</a></li> <li><a href="#L724">A.3.3. Examples</a></li> <li><a href="#L778">A.3.4. Notes</a> <ul> <li><a href="#L780">A.3.4.1. "Dumbing-Down" to SKOS Lexical Labels</a></li> <li><a href="#L899">A.3.4.2. SKOS+XL Labeling Integrity</a></li> </ul> </li> </ul> </li> <li><a href="#L7196">A.4. Links Between xl:Labels</a> <ul> <li><a href="#L1120">A.4.1. Preamble</a></li> <li><a href="#L1129">A.4.2. Class and Property Definitions</a></li> <li><a href="#L1160">A.4.3. Examples</a></li> <li><a href="#L1193">A.4.4. Notes</a> <ul> <li><a href="#L1195">A.4.4.1. Refinements of this Pattern</a></li> </ul> </li> </ul> </li> </ul> </li> <li><a href="#L7127">Appendix B. SKOS Overview</a> <ul> <li><a href="#L7130">B.1. Classes in the SKOS Data Model</a></li> <li><a href="#L7307">B.2. Properties in the SKOS Data Model</a></li> </ul> </li> <li><a href="#L2994">Appendix C. SKOS Data Model as RDF Triples</a></li> </ul> </div> <hr /> </div> <div id="div-content"> <div id="div-intro"> <a id="intro" name="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 "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. [@@REF-BS8723-X]). 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. </p> <p>The W3C's Semantic Web Activity [@@REF-SW] 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 [@@REF-RDF-PRIMER]. 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 [@@REF-RDFS] [@@REF-OWL-GUIDE]. The SPARQL Query language and Protocol provide a standard means for interacting with data in the Web [@@REF-SPARQL]. </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. This ability to "join up" data from different sources is motivating many projects, as different communities seek to exploit the hidden value in linking 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 [@@REF-RDF-PRIMER] [@@REF-OWL-GUIDE]. They go a long way towards supporting that vision, but the story doesn't end there. 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 is 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 [@@REF-LCSH] or the United Nations Food and Agriculture Organization's Agrovoc Thesaurus [@@REF-AGROVOC].</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. It is hoped that, by making the accumulated experience and wisdom of knowledge organization in the library and information sciences accessible, applicable within 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), 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. What is SKOS?</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 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 [@@REF-OWL-SEMANTICS]. SKOS data are expressed as RDF triples, and may be encoded using any concrete RDF syntax (such as RDF/XML [@@REF-RDF-XML] or Turtle [@@REF-TURTLE]). 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 Hiragana. One of these labels in any given language can be indicated as the "preferred" label for that language, and the others as "alternate" labels. Labels may also be "hidden", which is useful e.g. 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 (also known as classification codes). 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 three basic types of mapping link: hierarchical, associative 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 A. SKOS eXtension for Labels (XL)</a>. XL provides more support for identifying, describing and linking lexical entities. </p> <h3 id="L1045">1.4. SKOS, RDF and OWL</h3> <p>As mentioned above, the SKOS data model is formally defined as an OWL Full ontology. I.e. SKOS is itself an OWL Full ontology. 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. </p> <p>I.e. it <strong>is</strong> appropriate (if one has the time, effort and need) to manually re-engineer a thesaurus or classification scheme as a formal OWL ontology, using the "concepts" of the thesaurus as a starting point for creating classes, properties and individuals in the ontology, and using the informal hierarchies and association networks of the thesaurus as a starting point for creating the axioms and facts of the ontology. However, OWL is a formal ontology language, and it does not <em>by itself</em> provide a natural or suitable data model for expressing a thesaurus or classification scheme. I.e. it is <strong>not</strong> appropriate to express the "concepts" of a thesaurus or classification scheme directly <em>as</em> classes of an ontology, <strong>nor</strong> to express the informal (broader/narrower) hierarchy of a thesaurus directly <em>as</em> a set of class subsumption axioms. The reason for this is that, because a thesaurus or classification scheme has not been developed with formal semantics in mind, but rather as an informal or semi-formal aid to navigation and information retrieval, expressing a thesaurus hierarchy directly <em>as</em> a set of ontology classes with subsumption axioms typically leads to a number of inappropriate or nonsensical conclusions.</p> <p>OWL does, however, provide a powerful data modeling language. We can, therefore, use OWL to construct a data model which is appropriate to the level of formality in a thesaurus or classification scheme. 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 "facts" 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, as are typically expressed in a formal ontology. </p> <p>SKOS data are then expressed as RDF triples. For example, the RDF graph below expresses some facts about a thesaurus.</p> <pre><A> rdf:type skos:Concept ; skos:prefLabel "love"@en ; skos:altLabel "adoration"@en ; skos:broader <B> ; skos:inScheme <C> . <B> rdf:type skos:Concept ; skos:prefLabel "emotion"@en ; skos:altLabel "feeling"@en ; skos:inScheme <C> . <C> rdf:type skos:ConceptScheme ; dc:title "My First Thesaurus" ; skos:hasTopConcept <B> .</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 users 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, and can often be ignored without any serious repercussions. In other words, it may not be relevant to a user that <code><A></code> and <code><B></code> in the graph below are individuals (instances of <code>skos:Concept</code>), and <code><C></code> and <code><D></code> are classes (instances of <code>owl:Class</code>) .</p> <p></p> <pre><A> rdf:type skos:Concept ; skos:prefLabel "love"@en ; skos:broader <B> . <B> rdf:type skos:Concept ; skos:prefLabel "emotion"@en . <C> rdf:type owl:Class ; rdfs:label "mammals"@en ; rdfs:subClassOf <D> . <D> 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> </div> <div id="div-intro2"> <h3 id="L831">1.5. 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 [@@REF-RDF-SEMANTICS] [@@REF-OWL-SEMANTICS]. 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. For example, consider the RDF graph below.</p> <pre><Foo> rdf:type owl:Class . <Bar> rdf:type owl:Class . <Foo> owl:disjointWith <Bar> . <foobar> rdf:type <Foo> , <Bar> .</pre> <p>The graph states that <code><Foo></code> and <code><Bar></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><foobar></code> has type both <code><Foo></code> and <code><Bar></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 conforms to or "fits" with the given data model. If the data is inconsistent with respect to the data model, then it does not "fit".</p> <p>Here, we are not concerned with whether or not some given data has any correspondence with the "real world", i.e. whether it is true or false in any absolute sense. We are simply interested in whether or not the data fits 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 is consistent with respect to the data model. </p> <p>For example, the statement that <code><Foo></code> and <code><Bar></code> are disjoint classes can be viewed as an integrity condition on a data model. Given this condition, the data below is then not (OWL Full) consistent.</p> <pre><foobar> rdf:type <Foo> , <Bar> .</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 is <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 "fits" 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 is 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. For example, 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 (draw inferences using an RDFS or OWL reasoner, then search 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-11 below.</p> <h3 id="L881">1.6. Inference, Dependency and the Open-World Assumption</h3> <p>This document defines the SKOS data model as an OWL Full ontology. There are other, alternate 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 is located. Therefore, one cannot generally assume that data obtained from such a system is "complete". I.e. if some data appears 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 "open world" assumption [@@REF-OWL-GUIDE]. </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.</p> <p>For example, 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 statements are <strong>not</strong> integrity conditions. I.e. the graph below is perfectly <strong>consistent</strong> with the SKOS data model, despite the fact that <code><A></code> and <code><B></code> have not been explicitly declared as instances of <code>skos:Concept</code>.</p> <pre><A> skos:semanticRelation <B> .</pre> <p>In fact, the domain and range definitions give license to <strong>inferences</strong>. In this case, the graph above (RDFS and OWL Full) entails the following graph. I.e. the following graph can be deduced or inferred.</p> <pre><A> rdf:type skos:Concept . <B> rdf:type skos:Concept .</pre> <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. For example, in <a href="#semantic-relations">section 7</a> below, <code>skos:broader</code> and <code>skos:narrower</code> are defined as inverse properties. This statement means that</p> <pre><A> skos:narrower <B> .</pre> <p>entails</p> <pre><B> skos:broader <A> .</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 "joining up" 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 then 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 [@@REF-RDF-PRIMER] and [@@OWL-GUIDE].</p> </div> <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 comprises 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 & 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 next.</li> <li><strong>Examples</strong> — some canonical examples are given, both of data which <strong>is</strong> consistent with the SKOS data model, and (where appropriate) of data which is <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 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 [@@REF-RDFS], and should be clear to a reader with a working knowledge of RDF and OWL. </p> <p>So, for example, "<code>ex:Foo</code> is an instance of <code>owl:Class</code>" means</p> <pre>ex:Foo rdf:type owl:Class .</pre> <p>"<code>ex:p</code> and <code>ex:q</code> are each instances of <code>owl:ObjectProperty</code>" means</p> <pre>ex:p rdf:type owl:ObjectProperty . ex:q rdf:type owl:ObjectProperty .</pre> <p>"<code>ex:p</code> is a sub-property of <code>ex:q</code>" means</p> <pre>ex:p rdfs:subPropertyOf ex:q .</pre> <p>"the <code>rdfs:range</code> of <code>ex:p</code> is the class <code>ex:Foo</code>" means</p> <pre>ex:p rdfs:range ex:Foo .</pre> <p>etc.</p> <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.</p> <p>For example, from <a href="#labels">Section 5</a>, "A resource has no more than one value of <code>skos:prefLabel</code> per language" means for any resource x, no two members of the set { y | <x,y> is in IEXT(I(<code>skos:prefLabel</code>)) } share the same language tag (where I and IEXT are functions as defined in [@@REF-RDF-SEMANTICS]).</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. For example, <code><http://example.org/ns/example></code>. Relative URIs are cited in the same way, and are relative to the base URI <code><http://example.org/ns/></code>. For example, <code><example></code> and <code><http://example.org/ns/example></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/2008/05/skos#</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><http://www.w3.org/2008/05/skos#Concept></code>.</p> <h4 id="L1501">1.7.3. Examples</h4> <p>Examples of RDF graphs are given using the Terse RDF Triple language (Turtle) [@@REF-TURTLE]. All examples assume that they are preceded by the following prefix and URI base directives:</p> <pre>@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix owl: <http://www.w3.org/2002/07/owl#> .<br />@prefix skos: <http://www.w3.org/2008/05/skos#> .<br />@base <http://example.org/ns/> .<br /></pre> <p>Therefore, the example given below</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 1</th> </tr> <tr> <td> <div> <MyConcept> rdf:type skos:Concept .</div> </td> </tr> </tbody> </table> <p>is equivalent to the following Turtle document</p> <pre>@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix owl: <http://www.w3.org/2002/07/owl#> .<br />@prefix skos: <http://www.w3.org/2008/05/skos#> .<br />@base <http://example.org/ns/> . <MyConcept> rdf:type skos:Concept .</pre> <p>which is equivalent to the following RDF/XML document [@@REF-RDF-XML]</p> <pre><?xml version="1.0" encoding="UTF-8"?> <rdf:RDF <br /> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" <br /> xmlns:rdfs="http://www.w3.org/1999/02/22-rdf-syntax-ns#" <br /> xmlns:skos="http://www.w3.org/2008/05/skos#"<br /> xmlns:owl="http://www.w3.org/2002/07/owl#"<br /> xml:base="http://example.org/ns/"> <skos:Concept rdf:about="MyConcept"/> </rdf:RDF></pre> <p>which is equivalent to the following N-TRIPLES document [@@REF-NTRIPLES]</p> <pre><http://example.org/ns/MyConcept> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2008/05/skos#Concept> .</pre> <p>Note the use in Turtle of the ";" and "," characters to abbreviate multiple triples with the same subject or predicate.</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> <hr /> </div> <div id="div-vocab"> <a id="vocab" name="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/2008/05/skos#</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 2. SKOS Vocabulary</caption> <tbody> <tr> <th>URI</th> <th>Defined by (section of this document)</th> </tr> <tr> <td>skos:Concept</td> <td><a href="#concepts">3. The skos:Concept Class</a></td> </tr> <tr> <td>skos:ConceptScheme</td> <td><a href="#schemes">4. Concept Schemes</a></td> </tr> <tr> <td>skos:inScheme</td> <td><a href="#schemes">4. Concept Schemes</a></td> </tr> <tr> <td>skos:hasTopConcept</td> <td><a href="#schemes">4. Concept Schemes</a></td> </tr> <tr> <td>skos:altLabel</td> <td><a href="#labels">5. Lexical Labels</a></td> </tr> <tr> <td>skos:hiddenLabel</td> <td><a href="#labels">5. Lexical Labels</a></td> </tr> <tr> <td>skos:prefLabel</td> <td><a href="#labels">5. Lexical Labels</a></td> </tr> <tr> <td>skos:notation</td> <td><a href="#notations">6. Notations</a></td> </tr> <tr> <td>skos:changeNote</td> <td><a href="#notes">7. Documentation Properties</a></td> </tr> <tr> <td>skos:definition</td> <td><a href="#notes">7. Documentation Properties</a></td> </tr> <tr> <td>skos:editorialNote</td> <td><a href="#notes">7. Documentation Properties</a></td> </tr> <tr> <td>skos:example</td> <td><a href="#notes">7. Documentation Properties</a></td> </tr> <tr> <td>skos:historyNote</td> <td><a href="#notes">7. Documentation Properties</a></td> </tr> <tr> <td>skos:note</td> <td><a href="#notes">7. Documentation Properties</a></td> </tr> <tr> <td>skos:scopeNote</td> <td><a href="#notes">7. Documentation Properties</a></td> </tr> <tr> <td>skos:broader</td> <td><a href="#semantic-relations">8. Semantic Relations</a></td> </tr> <tr> <td>skos:broaderTransitive</td> <td><a href="#semantic-relations">8. Semantic Relations</a></td> </tr> <tr> <td>skos:narrower</td> <td><a href="#semantic-relations">8. Semantic Relations</a></td> </tr> <tr> <td>skos:narrowerTransitive</td> <td><a href="#mapping">8. Semantic Relations</a></td> </tr> <tr> <td>skos:related</td> <td><a href="#semantic-relations">8. Semantic Relations</a></td> </tr> <tr> <td>skos:semanticRelation</td> <td><a href="#semantic-relations">8. Semantic Relations</a></td> </tr> <tr> <td>skos:Collection</td> <td><a href="#collections">9. Concept Collections</a></td> </tr> <tr> <td>skos:OrderedCollection</td> <td><a href="#collections">9. Concept Collections</a></td> </tr> <tr> <td>skos:member</td> <td><a href="#collections">9. Concept Collections</a></td> </tr> <tr> <td>skos:memberList</td> <td><a href="#collections">9. Concept Collections</a></td> </tr> <tr> <td>skos:broadMatch</td> <td><a href="#mapping">10. Mapping Properties</a></td> </tr> <tr> <td>skos:exactMatch</td> <td><a href="#mapping">10. Mapping Properties</a></td> </tr> <tr> <td>skos:mappingRelation</td> <td><a href="#mapping">10. Mapping Properties</a></td> </tr> <tr> <td>skos:narrowMatch</td> <td><a href="#mapping">10. Mapping Properties</a></td> </tr> <tr> <td>skos:relatedMatch</td> <td><a href="#mapping">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 href="#_TODO">quick access panel</a>.</p> <hr /> </div> <div id="div-conceptual-resources"> <a id="concepts" name="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 href="#_TODO">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 & Property Definitions</h3> <table border="0" class="semantics"> <caption></caption> <tbody> <tr> <td>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><MyConcept></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>Example 2 (consistent)</th> </tr> <tr> <td> <div> <MyConcept> 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>This specification does <strong>not</strong> make any 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>For example, in the graph below, <code><MyConcept></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>Example 3 (consistent)</th> </tr> <tr> <td> <div> <MyConcept> rdf:type skos:Concept , owl:Class .</div> </td> </tr> </tbody> </table> <p>This example is <strong>consistent</strong> with the SKOS data model. However, note that it is <strong>not</strong> compatible with OWL DL, because the URI <code><MyConcept></code> has been used to denote both a class and an individual [@@REF-OWL-SEMANTICS]. To work within the OWL DL language, take care <strong>not</strong> to use the same URI to denote both an OWL class and a SKOS concept.</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>For example, in the graph below, <code><MyConcept></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>Example 4 (consistent)</th> </tr> <tr> <td> <div> <MyConcept> rdf:type skos:Concept , owl:ObjectProperty .</div> </td> </tr> </tbody> </table> <p>This example is <strong>consistent</strong> with the SKOS data model. However, it is <strong>not</strong> compatible with OWL DL, because the URI <code><MyConcept></code> has been used to denote both an object property and an individual [@@REF-OWL-SEMANTICS].</p> <hr /> </div> <div id="div-concept-schemes"> <a id="schemes" name="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 a certain amount of flexibility in the formal semantics stated below (see also the <a href="#_TODO">notes</a> 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 href="#_TODO">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> </tbody> </table> <h3 id="L8421">4.3. Class & Property Definitions</h3> <table border="0" class="semantics"> <caption></caption> <tbody> <tr> <td>S2</td> <td><code>skos:ConceptScheme</code> is an instance of <code>owl:Class</code>.</td> </tr> <tr> <td>S3</td> <td><code>skos:inScheme</code> and <code>skos:hasTopConcept</code> are each instances of <code>owl:ObjectProperty</code>.</td> </tr> <tr> <td>S4</td> <td>The <code>rdfs:range</code> of <code>skos:inScheme</code> is the class <code>skos:ConceptScheme</code>.</td> </tr> <tr> <td>S5</td> <td>The <code>rdfs:domain</code> of <code>skos:hasTopConcept</code> is the class <code>skos:ConceptScheme</code>.</td> </tr> <tr> <td>S6</td> <td>The <code>rdfs:range</code> of <code>skos:hasTopConcept</code> is the class <code>skos:Concept</code>.</td> </tr> </tbody> </table> <h3 id="L1228">4.4. Integrity Conditions</h3> <table border="0" class="semantics"> <caption></caption> <tbody> <tr> <td>S7</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>Example 5 (consistent)</th> </tr> <tr> <td> <div> <MyScheme> rdf:type skos:ConceptScheme ; <br /> skos:hasTopConcept <MyConcept> . <br /> <br /> <MyConcept> skos:inScheme <MyScheme> . <br /> <br /> <AnotherConcept> skos:inScheme <MyScheme> .</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><MyConcept></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>Example 6 (consistent)</th> </tr> <tr> <td> <div> <MyScheme> rdf:type skos:ConceptScheme . <br /> <br /> <AnotherScheme> rdf:type skos:ConceptScheme ; <br /> owl:differentFrom <MyScheme> . <br /> <br /> <MyConcept> skos:inScheme <MyScheme> , <AnotherScheme> .</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 [@@REF-OWL-GUIDE].</p> <p>For example, in the graph below, <code><MyScheme></code> is both a 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>Example 7 (consistent)</th> </tr> <tr> <td> <div> <MyScheme> rdf:type skos:ConceptScheme , owl:Ontology . <br /> <br /> <MyConcept> skos:inScheme <MyScheme> .</div> </td> </tr> </tbody> </table> <h4 id="L1232">4.6.3. SKOS Concept Schemes and Named RDF Graphs</h4> <p><strong></strong>This specification does <strong>not</strong> make any statement about the formal relationship between the class of SKOS concept schemes and the class of named RDF Graphs. The decision <strong>not</strong> to make any such statement has been made to allow different design patterns to be explored for using SKOS with query languages such as SPARQL [@@REF-SPARQL].</p> <h4 id="L2446">4.6.4. 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, note that 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>Example 8 (consistent)</th> </tr> <tr> <td> <div> <MyScheme> skos:hasTopConcept <MyConcept> .<br /> <MyConcept> skos:inScheme <MyScheme> ; skos:broader <AnotherConcept> .<br /> <AnotherConcept> skos:inScheme <MyScheme> .</div> </td> </tr> </tbody> </table> <hr /> </div> <div id="div-lexical-labels"> <a id="labels" name="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 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", "alternate" and "hidden" lexical labels for any given resource. </p> <p>The "preferred" and "alternate" 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 [@@REF-RDF-CONCEPTS]. 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 [@@REF-BCP47].</p> <p>See the @@Primer for more examples of labeling SKOS concepts.</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 & Property Definitions</h3> <table border="0" class="semantics"> <caption></caption> <tbody> <tr> <td>S8</td> <td><code></code><code>skos:prefLabel</code>, <code>skos:altLabel</code> and <code>skos:hiddenLabel</code> are each instances of <code>owl:DatatypeProperty</code>.</td> </tr> <tr> <td>S9</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>S10</td> <td><code>skos:prefLabel</code>, <code>skos:altLabel</code> and <code>skos:hiddenLabel</code> are pairwise disjoint properties.</td> </tr> <tr> <td>S11</td> <td><code></code>A resource has no more than one value of <code>skos:prefLabel</code> per language.</td> </tr> </tbody> </table> <p>N.B. the conditions above assume that each distinct language tag allowed by [@@REF-BCP47] denotes a different "language". E.g. "en", "en-GB" and "en-US" denote three different languages (English, British English and US English respectively). E.g. "ja", "ja-Hani", "ja-Hira", "ja-Kana" and "ja-Latn" denote five different languages (Japanese, Japanese Kanji, Japanese Hiragana, Japanese Katakana and Japanese Rōmaji respectively).</p> <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>Example 9 (consistent)</th> </tr> <tr> <td> <div> <MyResource> <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 languages (Japanese Kanji, Japanese Hiragana, Japanese Katakana and Japanese Rōmaji).</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 10 (consistent)</th> </tr> <tr> <td> <div> <AnotherResource> <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 for the same language.</p> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 11 (not consistent)</th> </tr> <tr> <td> <div> <FooResource> skos:prefLabel "foo"@en ; skos:prefLabel "bar"@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 alternate lexical labels.</p> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 12 (not consistent)</th> </tr> <tr> <td> <div> <FooResource> skos:prefLabel "foo"@en ; skos:altLabel "foo"@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 alternate and hidden lexical labels.</p> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 13 (not consistent)</th> </tr> <tr> <td> <div> <FooResource> skos:altLabel "foo"@en ; skos:hiddenLabel "foo"@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>Example 14 (not consistent)</th> </tr> <tr> <td> <div> <FooResource> skos:prefLabel "foo"@en ; skos:hiddenLabel "foo"@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>For example, in the 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>Example 15 (consistent)</th> </tr> <tr> <td> <div> <MyClass> 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> <p>This example is, however, incompatible with OWL DL, because a datatype property has been used to make assertions about a class [@@REF-OWL-SEMANTICS]. </p> <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 [@@REF-RDF-CONCEPTS]. </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>. However, there is nothing in the RDF or OWL Full semantics which prevents the use of a URI or a blank node to denote an RDF plain literal. Therefore, although the graph below does not adhere to the usage convention stated above, it is nevertheless <strong>consistent</strong> with the SKOS data model. </p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 16 (consistent)</th> </tr> <tr> <td> <div> <FooResource> skos:prefLabel <bar> .</div> </td> </tr> </tbody> </table> <p>For an application that needs to identify labels using URIs, consider using the SKOS eXtension for Labels defined in <a href="#xl">Appendix A</a>. </p> <h4 id="L1606">5.6.3. Alternates Without Preferred</h4> <p>In the graph below, a resource has two alternate 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 semantics. 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>Example 17 (consistent)</th> </tr> <tr> <td> <div> <FooResource> skos:altLabel "foo"@en , "bar"@en .</div> </td> </tr> </tbody> </table> <h4 id="L1629">5.6.4. Definition of a "Language"</h4> <p>Note how "language" has been defined for the conditions above. Each different language tag permissible by [@@REF-BCP47] is taken to denote a different "language". Therefore the graph below is <strong>consistent</strong> with the SKOS data model, because "en", "en-US" and "en-GB" are taken to denote different languages.</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 18 (consistent)</th> </tr> <tr> <td> <div> <FooResource> 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 taken to denote different languages, and therefore the graph is <strong>consistent</strong>. </p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 19 (consistent)</th> </tr> <tr> <td> <div> <FooResource> skos:prefLabel "foo"@en ; skos:altLabel "foo"@en-GB .</div> </td> </tr> </tbody> </table> <hr /> </div> <div id="div-notations"> <a name="notations" 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 to a concept as a typed literal [@@REF-RDF-CONCEPTS]. </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 & Property Definitions</h3> <table border="0" class="semantics"> <caption></caption> <tbody> <tr> <td>S12</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><http://example.com/ns/MyConcept></code> with a notation whose lexical form is the UNICODE string "303.4833" and whose datatype is denoted by the URI <code><http://example.com/ns/MyNotationDatatype></code>.</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 20 (consistent)</th> </tr> <tr> <td> <div> <MyConcept> skos:notation "303.4833"^^<MyNotationDatatype> .</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 [@@REF-RDF-CONCEPTS]. </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 [@@REF-XML-SCHEMA] 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" [@@REF-SWBP-DATATYPES].</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 [@@REF-SWBP-DATATYPES] section 2.</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 (i.e. datatypes). However, 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> <p>However, this usage convention is not part of the formal SKOS data model. I.e. there are no integrity conditions on the use of <code>skos:notation</code>. </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>Example 21 (consistent)</th> </tr> <tr> <td> <div> <Potassium> <br /> skos:prefLabel "K"@en ;<br /> skos:notation "K"^^<ChemicalSymbolNotation> .</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 typed literals 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 plain literals 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> <p>Usually a notation system does not have any correspondance with a natural language — it is language-independent (and hence typed literals are an appropriate representation). However, in some cases a system of notation might be associated with a particular language and/or script. One possible strategy in this situation is to use the private use language sub-tags [@@REF-BCP47] with <code>skos:prefLabel</code>, as illustrated in the example below — this is consistent with the SKOS data model. An alternative strategy is to define one or more sub-properties of <code>skos:prefLabel</code> and/or <code>skos:altLabel</code>.</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 22 (consistent)</th> </tr> <tr> <td> <div> <Potassium> <br /> skos:prefLabel "Potassium"@en ;<br /> skos:prefLabel "K"@en-x-chemicalsymbol ;<br /> skos:notation "K"^^<ChemicalSymbolNotation> .</div> </td> </tr> </tbody> </table> <hr /> </div> <div id="div-notes"> <a name="notes" 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. For example, 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 7 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 @@Primer.</p> <p>These 7 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 @@Primer.</p> <p>Three different usage patterns are recommended in the @@Primer for the SKOS documentation properties — "documentation as an RDF literal", "documentation as a related resource description" and "documentation as a document reference". The formal semantics stated in this section are intended to accommodate all three design patterns. See also the <a href="#_TODO">notes</a> below.</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 & Property Definitions</h3> <table border="0" class="semantics"> <caption></caption> <tbody> <tr> <td>S13</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:ObjectProperty</code>.</td> </tr> <tr> <td>S14</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>Example 23 (consistent)</th> </tr> <tr> <td> <div> <MyResource> skos:note "foo bar"@en .</div> </td> </tr> </tbody> </table> <p>The graph below gives an example of the "documentation as a related resource description" pattern.</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 24 (consistent)</th> </tr> <tr> <td> <div> <MyResource> skos:note [ rdf:value "foo bar"@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>Example 25 (consistent)</th> </tr> <tr> <td> <div> <MyResource> skos:note <MyNote> .</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>For example, in the 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>Example 26 (consistent)</th> </tr> <tr> <td> <div> <Protein> 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> <p>This example is, however, incompatible with OWL DL, because an object property has been used to make an assertion about a class [@@REF-OWL-SEMANTICS]. </p> <h4 id="L1917">7.5.2. Type & Range of the SKOS Documentation Properties</h4> <p>Note that the basis for the SKOS data model is the RDF-compatible model-theoretic semantics for OWL Full [@@REF-OWL-SEMANTICS]. Under the OWL Full semantics, the class of OWL datatype properties is a sub-class of the class of OWL object properties [@@REF-OWL-REFERENCE]. Therefore, stating that the SKOS documentation properties are all instances of <code>owl:ObjectProperty</code> is the most general statement that can be made, and is consistent with all three usage patterns described in the @@Primer. </p> <p>Note also 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 name="semantic-relations" 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 hierarchical link between two SKOS concepts. A triple <code><A> skos:broader <B></code> asserts that <code><B></code>, the object of the triple, is in some way a broader concept than <code><A></code>, the subject of the triple. Similarly, a triple <code><C> skos:narrower <D></code> asserts that <code><D></code>, the object of the triple is, in some way a narrower concept than <code><C></code>, the subject of the triple. </p> <p>Note that the properties <code>skos:broader</code> and <code>skos:narrower</code> are <strong>not</strong> defined as transitive properties. Applications may wish to make use of the transitive closure of <code>skos:broader</code> (or <code>skos:narrower</code>), for instance to improve search recall through query expansion. For these purposes, transitive super-properties <code>skos:broaderTransitive</code> and <code>skos:narrowerTransitive</code> are provided.</p> <p>By convention, <code>skos:broader</code> and <code>skos:narrower</code> are <strong>only</strong> used to assert an immediate (i.e. direct) hierarchical link between two SKOS concepts.</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 draw inferences about the transitive closure of the hierarchical relation, which is useful e.g. when implementing a simple query expansion algorithm in a search application. </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 @@Primer.</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 & Property Definitions</h3> <table border="0" class="semantics"> <caption></caption> <tbody> <tr> <td>S15</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>S16</td> <td>The <code>rdfs:domain</code> of <code>skos:semanticRelation</code> is the class <code>skos:Concept</code>.</td> </tr> <tr> <td>S17</td> <td>The <code>rdfs:range</code> of <code>skos:semanticRelation</code> is the class <code>skos:Concept</code>.</td> </tr> <tr> <td>S18</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>S19</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>S20</td> <td><code>skos:related</code> is an instance of <code>owl:SymmetricProperty</code>.</td> </tr> <tr> <td>S21</td> <td><code>skos:broader</code>, <code>skos:narrower</code> and <code>skos:related</code> are each <strong>not</strong> instances of <code>owl:TransitiveProperty</code>.</td> </tr> <tr> <td>S22</td> <td><code>skos:broaderTransitive</code> and <code>skos:narrowerTransitive</code> are each instances of <code>owl:TransitiveProperty</code>.</td> </tr> <tr> <td>S23</td> <td><code>skos:narrower</code> is the <code>owl:inverseOf</code> the property <code>skos:broader</code>.</td> </tr> <tr> <td>S24</td> <td><code>skos:narrowerTransitive</code> is the <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>S25</td> <td><code>skos:related</code> is disjoint with the property <code>skos:broaderTransitive</code>.</td> </tr> </tbody> </table> <h3 id="L2157">8.5. Examples</h3> <p>The graph below asserts a hierarchical link between <code><A></code> and <code><B></code> (where <code><B></code> is broader than <code><A></code>), and an associative link between <code><A></code> and <code><C></code>, and is <strong>consistent</strong> with the SKOS data model.</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 27 (consistent)</th> </tr> <tr> <td> <div> <A> skos:broader <B> ; skos:related <C> .</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>Example 28 (not consistent)</th> </tr> <tr> <td> <div> <A> skos:broader <B> ; skos:related <B> .</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>Example 29 (not consistent)</th> </tr> <tr> <td> <div> <A> skos:broader <B> ; skos:related <C> .<br /> <B> skos:broader <C> .</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>Example 30 (not consistent)</th> </tr> <tr> <td> <div> <A> skos:broaderTransitive <C> ; skos:related <C> .<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>Example 31 (not consistent)</th> </tr> <tr> <td> <div> <A> skos:narrower <B> ; skos:related <C> .<br /> <B> skos:narrower <C> .</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 example 27 above entails that <code><A></code>, <code><B></code> and <code><C></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>Example 32 (entailment)</th> </tr> <tr> <td> <div> <A> skos:related <B> .</div> <p><em>entails</em></p> <div> <B> skos:related <A> .</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>Example 33 (entailment)</th> </tr> <tr> <td> <div> <cause> rdf:type owl:ObjectProperty ;<br /> rdfs:subPropertyOf skos:related .<br /> <br /> <effect> rdf:type owl:ObjectProperty ;<br /> rdfs:subPropertyOf skos:related ;<br /> owl:inverseOf <cause> .<br /> <br /> <A> <cause> <B> .</div> <p><em>entails</em></p> <div> <A> skos:related <B> .<br /> <br /> <B> <effect> <A> ; skos:related <A> .</div> </td> </tr> </tbody> </table> <p>See also the @@Primer for best practice recommendations on extending SKOS.</p> <h4 id="L2344">8.6.4. Transitivity of skos:related</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>Example 34 (non-entailment)</th> </tr> <tr> <td> <div> <A> skos:related <B> .<br /> <B> skos:related <C> .</div> <p><em>does not entail</em></p> <div> <A> skos:related <C> .</div> </td> </tr> </tbody> </table> <h4 id="L2376">8.6.5. Reflexivity of skos:related</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>Example 35 (consistent)</th> </tr> <tr> <td> <div> <A> skos:related <A> .</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. Transitivity of skos:broader</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>Example 36 (non-entailment)</th> </tr> <tr> <td> <div> <A> skos:broader <B> .<br /> <B> skos:broader <C> .</div> <p><em>does not entail</em></p> <div> <A> skos:broader <C> .</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 entailment illustrated below.</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 37 (entailment)</th> </tr> <tr> <td> <div> <A> skos:broader <B> .<br /> <B> skos:broader <C> .</div> <p><em>entails</em></p> <div> <A> skos:broaderTransitive <C> .</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 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 is useful in other situations (e.g. simple 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 alternate paths below.</p> <h4 id="L2449">8.6.7. Reflexivity of skos:broader</h4> <p>Note that this specification makes no statements regarding the reflexive characteristics of the skos:broader 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><A></code>, the triple:</p> <table class="example-good" border="0"> <caption></caption> <tbody> <tr> <th>Example 38 (consistent)</th> </tr> <tr> <td> <div> <A> skos:broader <A> .</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 subclass 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 (Reflexivity of skos:broaderTransitive)</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>Example 39 (consistent)</th> </tr> <tr> <td> <div> <A> skos:broader <B> .<br /> <B> skos:broader <A> .</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 alternate paths from A to C in the hierarchical relation.</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 40 (consistent)</th> </tr> <tr> <td> <div> <A> skos:broader <B> , <C> .<br /> <B> skos:broader <C> .</div> </td> </tr> </tbody> </table> <p>In the graph below, there are two alternate paths from A to D in the hierarchical relation.</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 41 (consistent)</th> </tr> <tr> <td> <div> <A> skos:broader <B> , <C> .<br /> <B> skos:broader <D> .<br /> <C> skos:broader <D> .</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, and that 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 [@@REF-ISO2788] [@@REF-BS8273-2], 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" name="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 & Property Definitions</h3> <table border="0" class="semantics"> <caption></caption> <tbody> <tr> <td>S26</td> <td><code>skos:Collection</code> and <code>skos:OrderedCollection</code> are each instances of <code>owl:Class</code>.</td> </tr> <tr> <td>S27</td> <td><code>skos:OrderedCollection</code> is a sub-class of <code>skos:Collection</code>.</td> </tr> <tr> <td>S28</td> <td><code>skos:member</code> and <code>skos:memberList</code> are each instances of <code>owl:ObjectProperty</code>.</td> </tr> <tr> <td>S29</td> <td>The <code>rdfs:domain</code> of <code>skos:member</code> is the class <code>skos:Collection</code>.</td> </tr> <tr> <td>S30</td> <td>The <code>rdfs:domain</code> of <code>skos:memberList</code> is the class <code>skos:OrderedCollection</code>.</td> </tr> <tr> <td>S31</td> <td>The <code>rdfs:range</code> of <code>skos:memberList</code> is the class <code>rdf:List</code>.</td> </tr> <tr> <td>S32</td> <td><code>skos:memberList</code> is an instance of <code>owl:FunctionalProperty</code>.</td> </tr> <tr> <td>S33</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>S34</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>Example 42 (consistent)</th> </tr> <tr> <td> <div> <MyCollection> rdf:type skos:Collection ; <br /> skos:member <X> , <Y> , <Z> .</div> </td> </tr> </tbody> </table> <p>The graph below illustrates an ordered SKOS collection with 3 members.</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 43 (consistent)</th> </tr> <tr> <td> <div> <MyOrderedCollection> rdf:type skos:OrderedCollection ; <br /> skos:memberList ( <X> <Y> <Z> ) .</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 S33 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>Example 44 (entailment)</th> </tr> <tr> <td> <div> <MyOrderedCollection> rdf:type skos:OrderedCollection ; <br /> skos:memberList ( <X> <Y> <Z> ) .</div> <p><em>entails</em></p> <div> <MyOrderedCollection> rdf:type skos:Collection ;<br /> skos:member <X> , <Y> , <Z> .</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 constraint 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>Example 45 (entailment)</th> </tr> <tr> <td> <div> <FooOrderedCollection> <br /> skos:memberList ( <A> <B> ) , ( <X> <Y> ) . </div> <p><em>entails</em></p> <div> <FooOrderedCollection> <br /> skos:memberList [ rdf:first <A> , <X> ; rdf:rest [ rdf:first <B> ; rdf:rest rdf:nil ] , [ rdf:first <Y> ; rdf:rest rdf:nil ] .</div> </td> </tr> </tbody> </table> <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>Example 46 (consistent)</th> </tr> <tr> <td> <div> <MyCollection> rdf:type skos:Collection ; <br /> skos:member <A> , <B> , <MyNestedCollection> .<br /> <br /> <MyNestedCollection> rdf:type skos:Collection ;<br /> skos:member <X> , <Y> , <Z> .</div> </td> </tr> </tbody> </table> <p>This example is <strong>consistent</strong> with the SKOS data model.</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>Example 47 (not consistent)</th> </tr> <tr> <td> <div> <A> skos:narrower <B> .<br /> <B> 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>Example 48 (not consistent)</th> </tr> <tr> <td> <div> <A> skos:broader <B> .<br /> <B> 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>Example 49 (not consistent)</th> </tr> <tr> <td> <div> <A> skos:related <B> .<br /> <B> 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>Example 50 (consistent)</th> </tr> <tr> <td> <div> <A> skos:narrower <B> , <C> , <D> .<br /> <br /> <FooCollection> rdfs:label "Foo Collection"@en ; <br /> skos:member <B> , <C> , <D> .</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" name="mapping"></a> <h2 id="L1309">10. Mapping Properties</h2> <h3 id="L4307">10.1. Preamble</h3> <p>The SKOS mapping properties are <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 concepts in different concept schemes, where the links are inherent in the meaning of the linked concepts. </p> <p>The property <code>skos:exactMatch</code> is used to link two concepts that are sufficiently similar that they can be used interchangeably in an information retrieval application.</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>See also the <a href="#_TODO">notes</a> below.</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: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 & Property Definitions</h3> <table border="0" class="semantics"> <caption></caption> <tbody> <tr> <td>S35</td> <td><code>skos:mappingRelation</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>S36</td> <td>The <code>rdfs:domain</code> of <code>skos:mappingRelation</code> is the class <code>skos:Concept</code>.</td> </tr> <tr> <td>S37</td> <td>The <code>rdfs:range</code> of <code>skos:mappingRelation</code> is the class <code>skos:Concept</code> </td> </tr> <tr> <td>S38</td> <td><code>skos:exactMatch</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>S39</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>S40</td> <td><code>skos:narrowMatch</code> is the <code>owl:inverseOf</code> the property <code>skos:broadMatch</code>.</td> </tr> <tr> <td>S41</td> <td><code>skos:relatedMatch</code> is an instance of <code>owl:SymmetricProperty</code>.</td> </tr> <tr> <td>S42</td> <td><code>skos:exactMatch</code> is an instance of <code>owl:SymmetricProperty</code>.</td> </tr> </tbody> </table> <h3 id="L4316">10.4. Examples</h3> <p>The graph below asserts an exact mapping link between <code><A></code> and <code><B></code>.</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 51 (consistent)</th> </tr> <tr> <td> <div> <A> skos:exactMatch <B> .</div> </td> </tr> </tbody> </table> <p>The graph below asserts a hierarchical mapping link between <code><A></code> and <code><B></code> (where <code><B></code> is broader than <code><A></code>), and an associative mapping link between <code><A></code> and <code><C></code>.</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 52 (consistent)</th> </tr> <tr> <td> <div> <A> skos:broadMatch <B> ; skos:relatedMatch <C> .</div> </td> </tr> </tbody> </table> <h3 id="L4412">10.5. Notes</h3> <h4 id="L4160">10.5.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-organise 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:exactMatch | +- skos:relatedMatch | +- skos:broadMatch | +- skos:narrowMatch </pre> <p>Examples below illustrate some entailments which follow from this sub-property tree.</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 53 (entailment)</th> </tr> <tr> <td> <div> <A> skos:broadMatch <B> .</div> <p><em>entails</em></p> <div> <A> skos:broader <B> .<br /> <A> skos:broaderTransitive <B> .<br /> <A> skos:semanticRelation <B> .<br /> <A> skos:mappingRelation <B> .</div> </td> </tr> </tbody> </table> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 54 (entailment)</th> </tr> <tr> <td> <div> <A> skos:narrowMatch <B> .</div> <p><em>entails</em></p> <div> <A> skos:narrower <B> .<br /> <A> skos:narrowerTransitive <B> .<br /> <A> skos:semanticRelation <B> .<br /> <A> skos:mappingRelation <B> .</div> </td> </tr> </tbody> </table> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 55 (entailment)</th> </tr> <tr> <td> <div> <A> skos:relatedMatch <B> .</div> <p><em>entails</em></p> <div> <A> skos:related <B> .<br /> <A> skos:semanticRelation <B> .<br /> <A> skos:mappingRelation <B> .</div> </td> </tr> </tbody> </table> <p>Note also that, because different people might re-organise 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>Example 56 (consistent)</th> </tr> <tr> <td> <div> <A> skos:broadMatch <B> ; skos:relatedMatch <C> .<br /> <br /> <A> skos:inScheme <MyScheme> .<br /> <B> skos:inScheme <MyScheme> .<br /> <C> skos:inScheme <MyScheme> .</div> </td> </tr> </tbody> </table> <h4 id="L4394">10.5.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>Example 57 (not consistent)</th> </tr> <tr> <td> <div> <A> skos:broadMatch <B> ; skos:relatedMatch <B> .</div> </td> </tr> </tbody> </table> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 58 (not consistent)</th> </tr> <tr> <td> <div> <A> skos:narrowMatch <B> ; skos:relatedMatch <B> .</div> </td> </tr> </tbody> </table> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 59 (not consistent)</th> </tr> <tr> <td> <div> <A> skos:broadMatch <B> .<br /> <B> skos:broadMatch <C> .<br /> <A> skos:relatedMatch <C> .</div> </td> </tr> </tbody> </table> <h4 id="L4414">10.5.3. Transitivity of Mapping Properties</h4> <p><strong>None</strong> of the SKOS mapping properties are transitive properties. 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>Example 60 (non-entailment)</th> </tr> <tr> <td> <div> <A> skos:exactMatch <B> .<br /> <B> skos:exactMatch <C> .</div> <p><em>does not entail</em></p> <div> <A> skos:exactMatch <C> .</div> </td> </tr> </tbody> </table> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 61 (non-entailment)</th> </tr> <tr> <td> <div> <A> skos:broadMatch <B> .<br /> <B> skos:broadMatch <C> .</div> <p><em>does not entail</em></p> <div> <A> skos:broadMatch <C> .</div> </td> </tr> </tbody> </table> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 62 (non-entailment)</th> </tr> <tr> <td> <div> <A> skos:relatedMatch <B> .<br /> <B> skos:relatedMatch <C> .</div> <p><em>does not entail</em></p> <div> <A> skos:relatedMatch <C> .</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="https://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.5.4. Reflexivity of Mapping Properties</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>Example 63 (consistent)</th> </tr> <tr> <td> <div> <A> skos:exactMatch <A> .<br /> <B> skos:broadMatch <B> .<br /> <C> skos:relatedMatch <C> .</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> <h4 id="L4534">10.5.5. "Clashes" with skos:exactMatch</h4> <p>The property <code>skos:exactMatch</code> is <strong>not</strong> disjoint with any of the other mapping properties. Therefore the graph below is <strong>consistent</strong> with the SKOS data model.</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 64 (consistent)</th> </tr> <tr> <td> <div> <A> skos:exactMatch <B> ; skos:broadMatch <B> ;<br /> skos:exactMatch <C> ; skos:relatedMatch <C> .</div> </td> </tr> </tbody> </table> <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="https://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.5.6. Cycles and Alternate Paths Involving skos:broadMatch</h4> <p>There are no formal integrity conditions preventing either cycles or alternate 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>Example 65 (consistent)</th> </tr> <tr> <td> <div> <A> skos:broadMatch <B> .<br /> <B> skos:broadMatch <A> .<br /> <br /> <X> skos:broadMatch <Y> .<br /> <Y> skos:broadMatch <Z> .<br /> <Z> skos:broadMatch <X> .</div> </td> </tr> </tbody> </table> <p>In the graph below there are two alternate 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>Example 66 (consistent)</th> </tr> <tr> <td> <div> <A> skos:broadMatch <B> .<br /> <B> skos:broadMatch <C> .<br /> <A> skos:broadMatch <C> .</div> </td> </tr> </tbody> </table> <p>See however <a href="#semantic-relations">Section 8.</a> on cycles and alternate paths involving <code>skos:broader</code>.</p> <h4 id="L5675">10.5.7. Property Chains Involving skos:exactMatch</h4> <p>There are no property chain axioms in the SKOS data model involving the <code>skos:exactMatch</code> property. Hence the entailments illustrated below are <strong>not</strong> supported.</p> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 67 (non-entailment)</th> </tr> <tr> <td> <div> <A> skos:exactMatch <B> .<br /> <B> skos:broadMatch <C> .</div> <p><em>does not entail</em></p> <div> <A> skos:broadMatch <C> .</div> </td> </tr> </tbody> </table> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 68 (non-entailment)</th> </tr> <tr> <td> <div> <A> skos:exactMatch <B> .<br /> <B> skos:relatedMatch <C> .</div> <p><em>does not entail</em></p> <div> <A> skos:relatedMatch <C> .</div> </td> </tr> </tbody> </table> <p class="editorial"><strong>Editors' note:</strong> Whether any property chain axioms could reasonably be defined for skos:exactMatch is under discussion within the Working Group. This is recorded as <a href="https://www.w3.org/2006/07/SWD/track/issues/75">ISSUE-75</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-75">email to the SWD Working Group mailing list (public-swd-wg@w3.org)</a>, starting the subject line with "Comment: ISSUE-75". </p> <div id="div-mapping1"> <h4 id="L4858">10.5.8. skos:exactMatch, owl:sameAs, owl:equivalentClass, owl:equivalentProperty</h4> <p>OWL provides three properties which might, at first glance, appear similar to <code>skos:exactMatch</code>. <code>owl:sameAs</code> is used to link to 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:exactMatch</code> is used to link two SKOS concepts. It is typically used to indicate that two concepts are sufficiently similar that they can be used interchangeably in an information retrieval application. </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>Example 69 (entailment)</th> </tr> <tr> <td> <div> <A> rdf:type skos:Concept ; <br /> skos:prefLabel "foo"@en ;<br /> skos:inScheme <MyScheme> .<br /> <br /> <B> rdf:type skos:Concept ; <br /> skos:prefLabel "bar"@en ;<br /> skos:inScheme <AnotherScheme> .<br /> <br /> <A> owl:sameAs <B> . </div> <p><em>entails</em></p> <div> <A> <br /> skos:prefLabel "foo"@en ;<br /> skos:prefLabel "bar"@en ;<br /> skos:inScheme <MyScheme> ;<br /> skos:inScheme <AnotherScheme> .<br /> <br /> <B> <br /> skos:prefLabel "foo"@en ;<br /> skos:prefLabel "bar"@en ;<br /> skos:inScheme <MyScheme> ;<br /> skos:inScheme <AnotherScheme> .<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><A></code> and <code><B></code> now have two preferred lexical labels in the same language. This will not always be the case, however. Generally speaking, using <code>owl:sameAs</code> in this way will lead to inappropriate inferences, which may sometimes (but not always) be detectable by checking consistency with the SKOS data model.</p> <hr /> </div> </div> </div> <a id='references'></a> <h2 id="L744">11. References</h2> <p>@@TODO</p> <hr /> <div id="div-appendices"> <div id="div-appendix-xl"> <a name="xl" id="xl"></a> <h2 id="L4945">Appendix A. SKOS eXtension for Labels (XL)</h2> <p>This appendix defines an OPTIONAL extension to the Simple Knowledge Organization System, called the SKOS eXtension for Labels (XL). This extension provides additional support for identifying, describing and linking lexical entities. </p> <p>A special class of lexical entities, called <code>xl: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>xl:prefLabel</code>, <code>xl:altLabel</code> and <code>xl:hiddenLabel</code>, are defined. These properties are used to label SKOS concepts with instances of <code>xl: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>A property <code>xl:labelRelation</code> is defined. This property can be used to assert a direct (binary) link between instances of <code>xl: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>xl:labelRelation</code> are provided, although some examples of how this could be done are given. </p> <h3 id="L5212">A.1. XL Namespace and Vocabulary</h3> <a name="xl-vocab" id="xl-vocab"></a> <p>The XL namespace URI is:</p> <ul> <li><strong>http://www.w3.org/2008/05/skos-xl#</strong></li> </ul> <p>Here the prefix <code>xl:</code> is used as an abbreviation for the XL namespace URI.</p> <p>The 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 3. The XL Vocabulary</caption> <tbody> <tr> <th>URI</th> <th>Defined by (section of this appendix)</th> </tr> <tr> <td><code>xl:Label</code></td> <td><a href="#xl-Label">The xl:Label Class</a></td> </tr> <tr> <td><code>xl:literalForm</code></td> <td><a href="#xl-Label">The xl:Label Class</a></td> </tr> <tr> <td><code>xl:prefLabel</code></td> <td><a href="#xl-labels">Preferred, Alternate and Hidden xl:Labels</a></td> </tr> <tr> <td><code>xl:altLabel</code></td> <td><a href="#xl-labels">Preferred, Alternate and Hidden xl:Labels</a></td> </tr> <tr> <td><code>xl:hiddenLabel</code></td> <td><a href="#xl-labels">Preferred, Alternate and Hidden xl:Labels</a></td> </tr> <tr> <td><code>xl:labelRelation</code></td> <td><a href="#xl-label-relations">Links Between xl:Labels</a></td> </tr> </tbody> </table> <p>Here "the SKOS+XL vocabulary" refers to the union of the SKOS vocabulary and the 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 name="xl-Label" id="xl-Label"></a> <h3 id="L5444">A.2. The xl:Label Class</h3> <h4 id="L375">A.2.1. Preamble</h4> <p>The class <code>xl:Label</code> is a special class of lexical entities.</p> <p>An instance of the class <code>xl:Label</code> is a resource and may be named with a URI.</p> <p>An instance of the class <code>xl: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 [@@REF-RDF-CONCEPTS]). The property <code>xl:literalForm</code> is used to give the literal form of an <code>xl:Label</code>.</p> <p>If two instances of the class <code>xl:Label</code> have the same literal form, they are <strong>not</strong> necessarily the same resource.</p> <h4 id="L5518">A.2.2. Class and Property Definitions</h4> <table border="0" class="semantics"> <caption></caption> <tbody> <tr> <td>S43</td> <td><code>xl:Label</code> is an instance of <code>owl:Class</code>.</td> </tr> <tr> <td>S44</td> <td><code>xl:Label</code> is disjoint with each of <code>skos:Concept</code>, <code>skos:ConceptScheme</code> and <code>skos:Collection</code>.</td> </tr> <tr> <td>S45</td> <td><code>xl:literalForm</code> is an instance of <code>owl:DatatypeProperty</code>.</td> </tr> <tr> <td>S46</td> <td>The <code>rdfs:domain</code> of <code>xl:literalForm</code> is the class <code>xl:Label</code>.</td> </tr> <tr> <td>S47</td> <td>The <code>rdfs:range</code> of <code>xl:literalForm</code> is the class of RDF plain literals.</td> </tr> <tr> <td>S48</td> <td><code>xl:literalForm</code> is an instance of <code>owl:FunctionalProperty</code>.</td> </tr> </tbody> </table> <h4 id="L5525">A.2.3. Examples</h4> <p>The example below describes an <code>xl:Label</code> named with the URI <code><http://example.com/ns/A></code>, with the literal form "foo" in English. </p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 70 (consistent)</th> </tr> <tr> <td> <div> <A> rdf:type xl:Label ; xl:literalForm "foo"@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>xl:Label</code> is described with two different literal forms.</p> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 71 (not consistent)</th> </tr> <tr> <td> <div> <B> rdf:type xl:Label ; xl:literalForm "foo" ; xl:literalForm "bar" .<br /> </div> </td> </tr> </tbody> </table> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 72 (not consistent)</th> </tr> <tr> <td> <div> <B> rdf:type xl:Label ; xl:literalForm "foo"@en ; xl:literalForm "foo"@fr .<br /> </div> </td> </tr> </tbody> </table> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 73 (not consistent)</th> </tr> <tr> <td> <div> <B> rdf:type xl:Label ; xl:literalForm "foo"@en-GB ; xl:literalForm "foo"@en-US .<br /> </div> </td> </tr> </tbody> </table> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 74 (not consistent)</th> </tr> <tr> <td> <div> <B> rdf:type xl:Label ; xl:literalForm "東"@ja-Hani ; xl:literalForm "ひがし"@ja-Hira .<br /> </div> </td> </tr> </tbody> </table> <h4 id="L5716">A.2.4. Notes</h4> <h5 id="L5739">A.2.4.1. Identity and Entailment</h5> <p>As stated above, each instance of the class <code>xl:Label</code> has <strong>one and only one literal form</strong>. In other words, there is a function mapping the class extension of <code>xl:Label</code> to the set of RDF plain literals. This function is defined by the property extension of <code>xl: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>xl:Label</code> to the set of RDF plain literals (in fact it is many-to-one). This means that two instances of <code>xl: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>Example 75 (non-entailment)</th> </tr> <tr> <td> <div> <A> xl:literalForm "foo"@en .<br /> <B> xl:literalForm "foo"@en .</div> <p><em>does not entail</em></p> <div> <A> owl:sameAs <B> .</div> </td> </tr> </tbody> </table> <p>Second, the function is <strong>not</strong> surjective. In other words, there may be <strong>no</strong> instances of <code>xl:Label</code> with a literal form corresponding to a given plain literal. </p> <h5 id="L648">A.2.4.2. Membership of Concept Schemes</h5> <p>The membership of an instance of <code>xl: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>Example 76 (consistent)</th> </tr> <tr> <td> <div> <A> rdf:type xl:Label ; xl:literalForm "foo"@en ; skos:inScheme <MyScheme> .</div> </td> </tr> </tbody> </table> <a name="xl-labels" id="xl-labels"></a> <h3 id="L5981">A.3. Preferred, Alternate and Hidden xl:Labels</h3> <h4 id="L661">A.3.1. Preamble</h4> <p>The three properties <code>xl:prefLabel</code>, <code>xl:altLabel</code> and <code>xl:hiddenLabel</code> are used to give the preferred, alternate and hidden labels of a resource respectively, where those labels are instances of the class <code>xl: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">A.3.2. Class and Property Definitions</h4> <table border="0" class="semantics"> <caption></caption> <tbody> <tr> <td>S49</td> <td><code>xl:prefLabel</code>, <code>xl:altLabel</code> and <code>xl:hiddenLabel</code> are each instances of <code>owl:ObjectProperty</code>.</td> </tr> <tr> <td>S50</td> <td>The <code>rdfs:range</code> of each of <code>xl:prefLabel</code>, <code>xl:altLabel</code> and <code>xl:hiddenLabel</code> is the class <code>xl:Label</code>.</td> </tr> <tr> <td>S51</td> <td>The property chain (<code>xl:prefLabel</code>, <code>xl:literalForm</code>) is a sub-property of <code>skos:prefLabel</code>.</td> </tr> <tr> <td>S52</td> <td>The property chain (<code>xl:altLabel</code>, <code>xl:literalForm</code>) is a sub-property of <code>skos:altLabel</code>.</td> </tr> <tr> <td>S53</td> <td>The property chain (<code>xl:hiddenLabel</code>, <code>xl:literalForm</code>) is a sub-property of <code>skos:hiddenLabel</code>.</td> </tr> </tbody> </table> <h4 id="L724">A.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>Example 77 (consistent)</th> </tr> <tr> <td> <div> <foo> <br /> xl:prefLabel <bar> ;<br /> xl:altLabel <baz> ;<br /> xl:hiddenLabel <qux> .<br /> <br /> <bar> rdf:type xl:Label ;<br /> xl:literalForm "bar"@en .<br /> <br /> <baz> rdf:type xl:Label ;<br /> xl:literalForm "baz"@en .<br /> <br /> <qux> rdf:type xl:Label ;<br /> xl:literalForm "qux"@en .</div> </td> </tr> </tbody> </table> <h4 id="L778">A.3.4. Notes</h4> <h5 id="L780">A.3.4.1. "Dumbing-Down" to SKOS Lexical Labels</h5> <p>The property chain axioms S51-S53 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>Example 78 (entailment)</th> </tr> <tr> <td> <div> <foo> <br /> xl:prefLabel <bar> ;<br /> xl:altLabel <baz> ;<br /> xl:hiddenLabel <qux> .<br /> <br /> <bar> rdf:type xl:Label ;<br /> xl:literalForm "bar"@en .<br /> <br /> <baz> rdf:type xl:Label ;<br /> xl:literalForm "baz"@en .<br /> <br /> <qux> rdf:type xl:Label ;<br /> xl:literalForm "qux"@en .</div> <p><em>entails</em></p> <div> <foo> <br /> skos:prefLabel "bar"@en ;<br /> skos:altLabel "baz"@en ;<br /> skos:hiddenLabel "qux"@en .</div> </td> </tr> </tbody> </table> <h5 id="L899">A.3.4.2. SKOS+XL Labeling Integrity</h5> <p>Note the two integrity conditions on the SKOS labeling properties defined in <a href="#labels">Section 5</a>. 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 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>Example 79 (not consistent)</th> </tr> <tr> <td> <div> # Two different preferred labels in the same language<br /> <br /> <foo> xl:prefLabel <A> ; xl:prefLabel <B> .<br /> <A> xl:literalForm "foo"@en .<br /> <B> xl:literalForm "bar"@en .<br /> </div> </td> </tr> </tbody> </table> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 80 (not consistent)</th> </tr> <tr> <td> <div> # "Clash" between preferred and alternate labels<br /> <br /> <foo> xl:prefLabel <A> ; xl:altLabel <B> .<br /> <A> xl:literalForm "foo"@en .<br /> <B> xl:literalForm "foo"@en .<br /> </div> </td> </tr> </tbody> </table> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 81 (not consistent)</th> </tr> <tr> <td> <div> # "Clash" between alternate and hidden labels<br /> <br /> <foo> xl:altLabel <A> ; xl:hiddenLabel <B> .<br /> <A> xl:literalForm "foo"@en .<br /> <B> xl:literalForm "foo"@en .<br /> </div> </td> </tr> </tbody> </table> <table border="0" class="example-bad"> <caption></caption> <tbody> <tr> <th>Example 82 (not consistent)</th> </tr> <tr> <td> <div> # "Clash" between preferred and hidden labels<br /> <br /> <foo> xl:prefLabel <A> ; xl:hiddenLabel <B> .<br /> <A> xl:literalForm "foo"@en .<br /> <B> xl:literalForm "foo"@en .<br /> </div> </td> </tr> </tbody> </table> <a name="xl-label-relations" id="xl-label-relations"></a> <h3 id="L7196">A.4. Links Between xl:Labels</h3> <h4 id="L1120">A.4.1. Preamble</h4> <p>This section defines a pattern for representing binary links between instances of the class <code>xl: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">A.4.2. Class and Property Definitions</h4> <table border="0" class="semantics"> <caption></caption> <tbody> <tr> <td>S54</td> <td><code>xl:labelRelation</code> is an instance of <code>owl:ObjectProperty</code>.</td> </tr> <tr> <td>S55</td> <td>The <code>rdfs:domain</code> of <code>xl:labelRelation</code> is the class <code>xl:Label</code>.</td> </tr> <tr> <td>S56</td> <td>The <code>rdfs:range</code> of <code>xl:labelRelation</code> is the class <code>xl:Label</code>.</td> </tr> <tr> <td>S57</td> <td><code>xl:labelRelation</code> is an instance of <code>owl:SymmetricProperty</code>.</td> </tr> </tbody> </table> <h4 id="L1160">A.4.3. Examples</h4> <p>The example below illustrates a link between two instances of the class <code>xl:Label</code>.</p> <table border="0" class="example-good"> <caption></caption> <tbody> <tr> <th>Example 83 (consistent)</th> </tr> <tr> <td> <div> <A> rdf:type xl:Label ; xl:literalForm "foo" .<br /> <B> rdf:type xl:Label ; xl:literalForm "bar" .<br /> <A> xl:labelRelation <B> .<br /> </div> </td> </tr> </tbody> </table> <h4 id="L1193">A.4.4. Notes</h4> <h5 id="L1195">A.4.4.1. Refinements of this Pattern</h5> <p>As mentioned above, the <code>xl:labelRelation</code> property serves as an extension point, which can be refined for more specific labeling scenarios.</p> <p>For 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>Example 84 (consistent)</th> </tr> <tr> <td> <div> # First define an extension to xl:labelRelation<br /> ex:acronym rdfs:subPropertyOf xl:labelRelation .<br /> <br /> # Now use it<br /> <A> rdf:type xl:Label ; xl:literalForm "FAO"@en .<br /> <B> rdf:type xl:Label ; xl:literalForm "Food and Agriculture Organization"@en .<br /> <B> ex:acronym <A> .<br /> </div> </td> </tr> </tbody> </table> <p>Note that a sub-property of a symmetric property is not necessarily symmetric.</p> <hr /> </div> <div id="div-appendix-overview"> <a name="overview" id="overview"></a> <h2 id="L7127">Appendix B. SKOS Overview</h2> <div id="div-appendix-overview-classes"> <h3 id="L7130">B.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" name="Collection">skos:Collection</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#Collection</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#collections">Section 9. Concept Collections</a></td> </tr> <tr> <td>Disjoint classes: </td> <td><code><a href="#ConceptScheme">skos:ConceptScheme</a></code><br /> <code><a href="#Concept">skos:Concept</a></code><br /> </td> </tr> <tr> <th colspan="2"><a href="#Concept" id="Concept" name="Concept">skos:Concept</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#Concept</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#concepts">Section 3. The <code>skos:Concept</code> Class</a></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" name="ConceptScheme">skos:ConceptScheme</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#ConceptScheme</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#schemes">Section 4. Concept Schemes</a></td> </tr> <tr> <td>Disjoint classes: </td> <td><code><a href="#Concept">skos:Concept</a></code><br /> <code><a href="#Collection">skos:Collection</a></code><br /> </td> </tr> <tr> <th colspan="2"><a href="#OrderedCollection" id="OrderedCollection" name="OrderedCollection">skos:OrderedCollection</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#OrderedCollection</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#collections">Section 9. Concept Collections</a></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">B.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" name="altLabel">skos:altLabel</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#altLabel</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#labels">Section 5. Lexical Labels</a></td> </tr> <tr> <th colspan="2"><a href="#broadMatch" id="broadMatch" name="broadMatch">skos:broadMatch</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#broadMatch</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#mapping">Section 10. Mapping Properties</a></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" name="broader">skos:broader</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#broader</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#semantic-relations">Section 8. Semantic Relations</a></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" name="broaderTransitive">skos:broaderTransitive</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#broaderTransitive</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#semantic-relations">Section 8. Semantic Relations</a></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" name="changeNote">skos:changeNote</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#changeNote</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#notes">Section 7. Documentation Properties</a></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="#definition" id="definition" name="definition">skos:definition</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#definition</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#notes">Section 7. Documentation Properties</a></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" name="editorialNote">skos:editorialNote</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#editorialNote</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#notes">Section 7. Documentation Properties</a></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" name="exactMatch">skos:exactMatch</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#exactMatch</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#mapping">Section 10. Mapping Properties</a></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="#example" id="example" name="example">skos:example</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#example</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#notes">Section 7. Documentation Properties</a></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" name="hasTopConcept">skos:hasTopConcept</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#hasTopConcept</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#schemes">Section 4. Concept Schemes</a></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> <th colspan="2"><a href="#hiddenLabel" id="hiddenLabel" name="hiddenLabel">skos:hiddenLabel</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#hiddenLabel</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#labels">Section 5. Lexical Labels</a></td> </tr> <tr> <th colspan="2"><a href="#historyNote" id="historyNote" name="historyNote">skos:historyNote</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#historyNote</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#notes">Section 7. Documentation Properties</a></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" name="inScheme">skos:inScheme</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#inScheme</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#schemes">Section 4. Concept Schemes</a></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" name="mappingRelation">skos:mappingRelation</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#mappingRelation</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#mapping">Section 10. Mapping Properties</a></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="#member" id="member" name="member">skos:member</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#member</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#collections">Section 9. Concept Collections</a></td> </tr> <tr> <td>Domain:</td> <td><code><a href="#Collection">skos:Collection</a></code><br /> </td> </tr> <tr> <th colspan="2"><a href="#memberList" id="memberList" name="memberList">skos:memberList</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#memberList</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#collections">Section 9. Concept Collections</a></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" name="narrowMatch">skos:narrowMatch</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#narrowMatch</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#mapping">Section 10. Mapping Properties</a></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" name="narrower">skos:narrower</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#narrower</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#semantic-relations">Section 8. Semantic Relations</a></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" name="narrowerTransitive">skos:narrowerTransitive</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#narrowerTransitive</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#semantic-relations">Section 8. Semantic Relations</a></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" name="notation">skos:notation</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#notation</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#notations">Section 6. Notations</a></td> </tr> <tr> <th colspan="2"><a href="#note" id="note" name="note">skos:note</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#note</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#notes">Section 7. Documentation Properties</a></td> </tr> <tr> <th colspan="2"><a href="#prefLabel" id="prefLabel" name="prefLabel">skos:prefLabel</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#prefLabel</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#labels">Section 5. Lexical Labels</a></td> </tr> <tr> <th colspan="2"><a href="#related" id="related" name="related">skos:related</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#related</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#semantic-relations">Section 8. Semantic Relations</a></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" name="relatedMatch">skos:relatedMatch</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#relatedMatch</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#mapping">Section 10. Mapping Properties</a></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" name="scopeNote">skos:scopeNote</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#scopeNote</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#notes">Section 7. Documentation Properties</a></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" name="semanticRelation">skos:semanticRelation</a> </th> </tr> <tr> <td>URI: </td> <td><code>http://www.w3.org/2008/05/skos#semanticRelation</code> </td> </tr> <tr> <td>Definition: </td> <td><a href="#semantic-relations">Section 8. Semantic Relations</a></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> </tbody> </table> </div> </div> <hr /> <div id="div-appendix-semantics-as-triples"> <a id="triples" name="triples"></a> <h2 id="L2994">Appendix C. SKOS Data Model as RDF Triples</h2> <p>The SKOS Data Model as RDF Triples can be found at <a href="https://www.w3.org/2008/05/skos">http://www.w3.org/2008/05/skos</a>.</p> <p>Note that it is not possible to express all of the statements of the SKOS data model as RDF triples. </p> <p>The SKOS eXtension for Labels (XL) Data Model as RDF Triples can be found at <a href="https://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.</p> <hr /> </div>  </div>  <div id="div-ft"> <pre>—- Change Log —- $Log: Overview.html,v $ Revision 1.9 2018/10/09 13:20:05 denis fix validation of xhtml documents Revision 1.8 2017/10/02 10:36:36 denis add fixup.js to old specs Revision 1.7 2008/06/06 17:54:02 swick Expand one link (in Abstract) to the SKOS Primer. Revision 1.6 2008/06/06 17:49:05 swick @@ not valid in ID Revision 1.5 2008/06/06 17:46:09 swick No @@TODO external document Revision 1.4 2008/06/06 17:43:31 swick Quiet link checker a bit Revision 1.3 2008/06/06 17:24:00 swick Update SOTD, closer to pubrules-OK Revision 1.2 2008/06/06 14:57:12 swick Prepare for pubrules Revision 1.1 2008/06/06 14:52:16 swick Copied from /2006/07/SWD/SKOS/reference/20080603/ Revision 1.7 2008/06/04 20:52:54 ajm65 Added changes section. Revision 1.6 2008/06/04 20:39:31 ajm65 No changes, only whitespace? Revision 1.5 2008/06/04 20:35:58 ajm65 Fixed heading numbering for appendices. Revision 1.4 2008/06/04 16:39:02 ajm65 Removed mention of skos:LabelRelation from statement S34 Revision 1.3 2008/06/04 16:13:10 ajm65 Fixed topmost headings and page title. Revision 1.2 2008/06/04 16:11:29 ajm65 Sorted header section and CVS log. Revision 1.1 2008/06/04 16:08:16 ajm65 Copy of master.html rev 1.63 </pre> <p></p> <p></p> </div> </div> <script type="application/javascript" src="https://www.w3.org/scripts/TR/fixup.js"></script></body> </html>

CINXE.COM

SKOS Simple Knowledge Organization System Reference