• 1. Introduction
  • 1.1. Background and Motivation
  • 1.2. SKOS Overview
  • 1.3. SKOS, RDF and OWL
  • 1.4. Consistency and Integrity
  • 1.5. Inference, Dependency and the Open-World Assumption
  • 1.6. Design Rationale
  • 1.7. How to Read this Document
    • 1.7.1. Formal Definitions
    • 1.7.2. URI Abbreviations
    • 1.7.3. Examples
  • 1.8. Conformance
• 2. SKOS Namespace and Vocabulary
• 3. The skos:Concept Class
  • 3.1. Preamble
  • 3.2. Vocabulary
  • 3.3. Class & Property Definitions
  • 3.4. Examples
  • 3.5. Notes
    • 3.5.1. SKOS Concepts, OWL Classes and OWL Properties
• 4. Concept Schemes
  • 4.1. Preamble
  • 4.2. Vocabulary
  • 4.3. Class & Property Definitions
  • 4.4. Integrity Conditions
  • 4.5. Examples
  • 4.6. Notes
    • 4.6.1. Closed vs. Open Systems
    • 4.6.2. SKOS Concept Schemes and OWL Ontologies
    • 4.6.3. Top Concepts and Semantic Relations
    • 4.6.4. Scheme Containment and Semantic Relations
    • 4.6.5. Domain of skos:inScheme
• 5. Lexical Labels
  • 5.1. Preamble
  • 5.2. Vocabulary
  • 5.3. Class & Property Definitions
  • 5.4. Integrity Conditions
  • 5.5. Examples
  • 5.6. Notes
    • 5.6.1. Domain of SKOS Lexical Labeling Properties
    • 5.6.2. Range of SKOS Lexical Labeling Properties
    • 5.6.3. Defining Label Relations
    • 5.6.4. Alternates Without Preferred
    • 5.6.5. Labeling and Language Tags
• 6. Notations
  • 6.1. Preamble
  • 6.2. Vocabulary
  • 6.3. Class & Property Definitions
  • 6.4. Examples
  • 6.5. Notes
    • 6.5.1. Notations, Typed Literals and Datatypes
    • 6.5.2. Multiple Notations
    • 6.5.3. Unique Notations in Concept Schemes
    • 6.5.4. Notations and Preferred Labels
    • 6.5.5. Domain of skos:notation
• 7. Documentation Properties (Note Properties)
  • 7.1. Preamble
  • 7.2. Vocabulary
  • 7.3. Class & Property Definitions
  • 7.4. Examples
  • 7.5. Notes
    • 7.5.1. Domain of the SKOS Documentation Properties
    • 7.5.2. Range of the SKOS Documentation Properties
• 8. Semantic Relations
  • 8.1. Preamble
  • 8.2. Vocabulary
  • 8.3. Class & Property Definitions
  • 8.4. Integrity Conditions
  • 8.5. Examples
  • 8.6. Notes
    • 8.6.1. Sub-Property Relationships
    • 8.6.2. Domain and Range of SKOS Semantic Relation Properties
    • 8.6.3. Symmetry of skos:related
    • 8.6.4. skos:related and Transitivity
    • 8.6.5. skos:related and Reflexivity
    • 8.6.6. skos:broader and Transitivity
    • 8.6.7. skos:broader and Reflexivity
    • 8.6.8. Cycles in the Hierarchical Relation (skos:broaderTransitive and Reflexivity)
    • 8.6.9. Alternate Paths in the Hierarchical Relation
    • 8.6.10. Disjointness of skos:related and skos:broaderTransitive
• 9. Concept Collections
  • 9.1. Preamble
  • 9.2. Vocabulary
  • 9.3. Class & Property Definitions
  • 9.4. Integrity Conditions
  • 9.5. Examples
  • 9.6. Notes
    • 9.6.1. Inferring Collections from Ordered Collections
    • 9.6.2. skos:memberList Integrity
    • 9.6.3. Nested Collections
    • 9.6.4. SKOS Concepts, Concept Collections and Semantic Relations
• 10. Mapping Properties
  • 10.1. Preamble
  • 10.2. Vocabulary
  • 10.3. Class & Property Definitions
  • 10.4. Integrity Conditions
  • 10.5. Examples
  • 10.6. Notes
    • 10.6.1. Mapping Properties, Semantic Relation Properties and Concept Schemes
    • 10.6.2. Clashes Between Hierarchical and Associative Links
    • 10.6.3. Mapping Properties and Transitivity
    • 10.6.4. Mapping Properties and Reflexivity
    • 10.6.5. Cycles and Alternate Paths Involving skos:broadMatch
    • 10.6.6. Cycles Involving skos:exactMatch and skos:closeMatch
    • 10.6.7. Sub-Property Chains Involving skos:exactMatch
    • 10.6.8. skos:closeMatch, skos:exactMatch, owl:sameAs, owl:equivalentClass, owl:equivalentProperty
• 11. References
• 12. Acknowledgments
• Appendix A. SKOS Properties and Classes
  • A.1. Classes in the SKOS Data Model
  • A.2. Properties in the SKOS Data Model
• Appendix B. SKOS eXtension for Labels (SKOS-XL)
  • B.1. SKOS-XL Namespace and Vocabulary
  • B.2. The skosxl:Label Class
    • B.2.1. Preamble
    • B.2.2. Class and Property Definitions
    • B.2.3. Examples
    • B.2.4. Notes
      • B.2.4.1. Identity and Entailment
      • B.2.4.2. Membership of Concept Schemes
  • B.3. Preferred, Alternate and Hidden skosxl:Labels
    • B.3.1. Preamble
    • B.3.2. Class and Property Definitions
    • B.3.3. Examples
    • B.3.4. Notes
      • B.3.4.1. Dumbing-Down to SKOS Lexical Labels
      • B.3.4.2. SKOS-XL Labeling Integrity
  • B.4. Links Between skosxl:Labels
    • B.4.1. Preamble
    • B.4.2. Class and Property Definitions
    • B.4.3. Examples
    • B.4.4. Notes
      • B.4.4.1. Refinements of this Pattern
• Appendix C. SKOS and SKOS-XL Namespace Documents
• Appendix D. SKOS Namespace: a historical note

1. Introduction

1.1. Background and Motivation

The Simple Knowledge Organization System is a data-sharing standard,bridging several different fields of knowledge, technology and practice.

In the library and information sciences, a long and distinguished heritageis devoted to developing tools for organizing large collections of objectssuch as books or museum artifacts. These tools are known generally as"knowledge organization systems" (KOS) or sometimes as "controlled structuredvocabularies". Several similar yet distinct traditions have emerged overtime, 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 arewidely recognized and applied in both modern and traditional informationsystems. In practice it can be hard to draw an absolute distinction betweenthesauri and classification schemes or taxonomies, although someproperties can be used to broadly characterize these different families (seee.g., [BS8723-3]).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 insimilar ways [SKOS-UCR]. However, there is currently no widely deployed standard forrepresenting these knowledge organization systems as data and exchanging thembetween computer systems.

The W3C's Semantic Web Activity [SW] has stimulated a new field of integrative research andtechnology development, at the boundaries between database systems, formallogic and the World Wide Web. This work has led to the development offoundational standards for the Semantic Web. The Resource DescriptionFramework (RDF) provides a common data abstraction and syntax for the Web [RDF-PRIMER]. TheRDF Vocabulary Description language (RDFS) and the Web Ontology language(OWL) together provide a common data modeling (schema) language for data inthe Web [RDFS] [OWL-GUIDE]. TheSPARQL Query Language and Protocol provide a standard means for interactingwith data in the Web [SPARQL].

These technologies are being applied across diverse applications, becausemany applications require a common framework for publishing, sharing,exchanging and integrating ("joining up") data from different sources. Theability to link data from different sources is motivating many projects,as different communities seek to exploit the hidden value in datapreviously spread across isolated sources.

One facet of the Semantic Web vision is the hope of better organizing thevast amounts of unstructured (i.e., human-readable) information in the Web,providing new routes to discovering and sharing that information. RDFS andOWL are formally defined knowledge representation languages, providing waysof expressing meaning that are amenable to computation, meaning thatcomplements and gives structure to information already present in the Web [RDF-PRIMER] [OWL-GUIDE]. However, to actually apply these technologies over large bodies of informationrequires the construction of detailed maps of particular domains ofknowledge, in addition to the accurate description (i.e., annotation orcataloging) of information resources on a large scale, much of which cannotbe done automatically. The accumulated experience and best practices in thelibrary and information sciences regarding the organization of informationand knowledge are obviously complementary and applicable to this vision, asare the many existing knowledge organization systems already developed and inuse, such as the Library of Congress Subject Headings [LCSH] or the United Nations Food andAgriculture Organization's AGROVOC Thesaurus [AGROVOC].

The Simple Knowledge Organization System therefore aims to provide abridge between different communities of practice within the library andinformation sciences involved in the design and application of knowledgeorganization systems. In addition, SKOS aims to provide a bridge betweenthese communities and the Semantic Web, by transferring existing models ofknowledge organization to the Semantic Web technology context, and byproviding a low-cost migration path for porting existing knowledgeorganization systems to RDF.

Looking to the future, SKOS occupies a position between the exploitationand analysis of unstructured information, the informal and socially-mediatedorganization of information on a large scale, and the formal representationof knowledge. By making the accumulated experience andwisdom of knowledge organization in the library and information sciencesaccessible, applicable and transferable to the technological contextof the Semantic Web, in a way that is complementary to existing Semantic Webtechnology (and in particular formal systems of knowledge representation suchas OWL), it is hoped that SKOS will enable many new and valuable applications, and will alsolead to new integrative lines of research and development in both technologyand practice.

1.2. SKOS Overview

The Simple Knowledge Organization System is a common data model forknowledge organization systems such as thesauri, classification schemes,subject heading systems and taxonomies. Using SKOS, a knowledge organizationsystem can be expressedas machine-readable data. It canthen be exchanged between computer applications and published in amachine-readable format in the Web.

The SKOS data model is formally defined in this specification as an OWLFull ontology [OWL-SEMANTICS]. SKOS data are expressed as RDFtriples [RDF-CONCEPTS], and may be encoded using anyconcrete RDF syntax (such as RDF/XML [RDF-XML] or Turtle [TURTLE]). For more on the relationshipsbetween SKOS, RDF and OWL, see the next sub-section below.

The SKOS data model views a knowledge organization system as aconcept scheme comprising a set ofconcepts. These SKOS concept schemes and SKOS concepts areidentified by URIs, enabling anyone to refer to them unambiguously from anycontext, and making them a part of the World Wide Web. SeeSection 3. The skos:Concept Class for more onidentifying and describing SKOS concepts, andSection 4.Concept Schemes for more on concept schemes.

SKOS concepts can belabeled with any number of lexical(UNICODE) strings, such as "romantic love" or "れんあい", in any givennatural language, such as English or Japanese (written here in hiragana). One of these labelsin any given language can be indicated as the preferred label for thatlanguage, and the others as alternative labels. Labels may also be "hidden",which is useful where a knowledge organization system is being queriedvia a text index. SeeSection 5. Lexical Labels formore on the SKOS lexical labeling properties.

SKOS concepts can be assigned one or morenotations,which are lexical codes used to uniquely identify the concept within thescope of a given concept scheme. While URIs are the preferred means ofidentifying SKOS concepts within computer systems, notations provide a bridgeto other systems of identification already in use such as classificationcodes used in library catalogs. SeeSection 6.Notations for more on notations.

SKOS concepts can bedocumented with notes of varioustypes. The SKOS data model provides a basic set of documentation properties,supporting scope notes, definitions and editorial notes, among others. Thisset is not meant to be exhaustive, but rather to provide a framework that canbe extended by third parties to provide support for more specific types ofnote. SeeSection 7. Documentation Properties for moreon notes.

SKOS concepts can belinked to other SKOS concepts viasemantic relation properties. The SKOS data model provides support forhierarchical and associative links between SKOS concepts. Again, as with anypart of the SKOS data model, these can be extended by third parties toprovide support for more specific needs. SeeSection 8. Semantic Relations for more onlinking SKOS concepts.

SKOS concepts can be grouped intocollections, which canbe labeled and/or ordered. This feature of the SKOS data model is intended toprovide support for node labels within thesauri, and for situations where theordering of a set of concepts is meaningful or provides some usefulinformation. SeeSection 9. Concept Collectionsfor more on collections.

SKOS concepts can bemapped to other SKOS concepts indifferent concept schemes. The SKOS data model provides support for fourbasic types of mapping link: hierarchical, associative, close equivalent andexact equivalent. SeeSection 10. Mapping Propertiesfor more on mapping.

Finally, an optional extension to SKOS is defined inAppendix B. SKOS eXtension for Labels (SKOS-XL). SKOS-XL provides moresupport for identifying, describing and linking lexical entities.

1.3. SKOS, RDF and OWL

The elements of the SKOS data model are classes and properties, and thestructure and integrity of the data model is defined by the logicalcharacteristics of, and interdependencies between, those classes andproperties. This is perhaps one of the most powerful and yet potentiallyconfusing aspects of SKOS, because SKOS can, in more advanced applications,also be used side-by-side with OWL to express and exchange knowledge about adomain. However, SKOS isnot a formal knowledgerepresentation language.

To understand this distinction, consider that the "knowledge" madeexplicit in a formal ontology is expressed as sets of axioms and facts. Athesaurus or classification scheme is of a completely different nature, anddoes not assert any axioms or facts. Rather, a thesaurus or classificationscheme identifies and describes, through natural language and other informalmeans, a set of distinct ideas or meanings, which are sometimesconveniently referred to as "concepts". These "concepts" may also be arrangedand organized into various structures, most commonly hierarchies andassociation networks. These structures, however, do not have any formalsemantics, and cannot be reliably interpreted as either formal axioms orfacts about the world. Indeed they were never intended to be so, for theyserve only to provide a convenient and intuitive map of some subjectdomain, which can then be used as an aid to organizing and finding objects,such as documents, which are relevant to that domain.

To make the "knowledge" embedded in a thesaurus or classification schemeexplicit in any formal sense requires that the thesaurus or classificationscheme bere-engineered as a formal ontology. In other words, someperson has to do the work of transforming the structure and intellectualcontent of a thesaurus or classification scheme into a set of formal axiomsand facts. This work of transformation is both intellectually demanding andtime consuming, and therefore costly. Much can be gained from using thesauri, etc., as-is, as informal, convenient structures for navigation within asubject domain. Using them as-is does not require any re-engineering andis therefore much less costly. In addition, some KOS are, by design, notintended to represent a logical view of their domain. Converting such KOS to aformal logic-based representation may, in practice, involve changes which resultin a representation that no longer meets the originally intended purpose.

OWL does, however, provide a powerful data modeling language. We can,therefore, use OWL to construct a data model for representing thesauri orclassification schemes as-is. This is exactly what SKOS does. Taking thisapproach, the "concepts" of a thesaurus or classification scheme are modeledas individuals in the SKOS data model, and the informal descriptions aboutand links between those "concepts" as given by the thesaurus orclassification scheme are modeled as facts about those individuals, never asclass or property axioms. Note that these are factsaboutthe thesaurus or classification schemeitself, such as "concept Xhas preferred label 'Y' and is part of thesaurus Z"; these arenot facts about the way the world is arranged within aparticular subject domain, as might be expressed in a formal ontology.

SKOS data are then expressed as RDF triples. The RDF graphbelow (in [TURTLE]as discussed inSection 1.7.3) expresses some factsabout a thesaurus.

<A> rdf:type skos:Concept ;  skos:prefLabel "love"@en ;  skos:altLabel "adoration"@en ;  skos:broader <B> ;  skos:inScheme <S> .<B> rdf:type skos:Concept ;  skos:prefLabel "emotion"@en ;  skos:altLabel "feeling"@en ;  skos:topConceptOf <S> .<S> rdf:type skos:ConceptScheme ;  dct:title "My First Thesaurus" ;  skos:hasTopConcept <B> .

This point is vital to understanding the formal definition of the SKOSdata model and how it may be implemented in software systems. This point isalso vital to more advanced applications of SKOS, especially where SKOS andOWL are used in combination as part of a hybrid formal/semi-formal design.

From a user's point of view, however, the distinction between a formalknowledge representation system and an informal or semi-formal knowledgeorganization system may naturally become blurred. In other words, it may notbe relevant to a user that<A> and<B>in the graph below are individuals (instances ofskos:Concept),and<C> and<D> are classes (instancesofowl:Class) .

<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 .

An information system that has any awareness of the SKOS data model will,however, need to appreciate the distinction.

RDF schemas for SKOS and the SKOS eXtension for Labels (SKOS-XL) are describedinAppendix C. SKOS and SKOS-XL Namespace Documents. Notethat, as there are constraints that cannot be completely captured in theschema, the RDF/XML document provides a normative subset of thisspecification.

1.4. Consistency and Integrity

Under the RDF and OWL Full semantics, the formal meaning(interpretation) of an RDF graph is a truth value [RDF-SEMANTICS][OWL-SEMANTICS], i.e., an RDF graph isinterpreted as either true or false.

In general, an RDF graph is said to beinconsistent if it cannotpossibly be true. In other words, an RDF graph is inconsistent if it containsa contradiction.

Using the RDF and RDFS vocabularies alone, it is virtually impossible tomake a contradictory statement. When the OWL vocabulary is used as well,there are many ways to state a contradiction, e.g., consider the RDFgraph below.

<Dog> rdf:type owl:Class .<Cat> rdf:type owl:Class .<Dog> owl:disjointWith <Cat> .<dogcat> rdf:type <Dog> , <Cat> .

The graph states that<Dog> and<Cat> are both classes, and that they are disjoint, i.e.,that they do not have any members in common. This is contradicted by thestatement that<dogcat> has type both<Dog> and<Cat>. There is no OWL Fullinterpretation which can satisfy this graph, and therefore this graph isnot OWL Full consistent.

When OWL Full is used as a knowledge representation language, the notionof inconsistency is useful because it reveals contradictions within theaxioms and facts that are asserted in an ontology. By resolving theseinconsistencies we learn more about a domain of knowledge, and come to abetter model of that domain from which interesting and valid inferences canbe drawn.

When OWL Full is used as a data modeling (i.e., schema) language, thenotion of inconsistency is again useful, but in a different way. Here we arenot concerned with the logical consistency of human knowledge itself. We aresimply interested in formally defining a data model, so that we can establishwith certainty whether or not some given data fit with (i.e., conform to) thegiven data model. If the data are inconsistent with respect to the datamodel, then the data does not fit.

Here, we are not concerned with whether or not some given data have anycorrespondence with the real world, i.e., whether they are true or false in anyabsolute sense. We are simply interested in whether or not the data fit thedata model, because interoperability within a given class of applicationsdepends on data conforming to a common data model.

Another way to express this view is via the notion ofintegrity.Integrity conditions are statements within the formal definition of a datamodel, which are used to establish whether or not given data are consistentwith respect to the data model, e.g., the statement that<Dog> and<Cat> are disjoint classes can be viewed as an integritycondition on a data model. Given this condition, the data below are then not consistent.

<dogcat> rdf:type <Dog> , <Cat> .

The definition of the SKOS data model given in this document contains alimited number of statements that are intended as integrity conditions. Theseintegrity conditions are included to promote interoperability, by definingthe circumstances under which data arenot consistent withrespect to the SKOS data model. Tools can then be implemented which checkwhether some or all of these integrity conditions are met for given data, andtherefore whether the data are consistent with the SKOS data model.

These integrity conditions are part of the formal definition of theclasses and properties of the SKOS data model. However, they are presentedseparately from other parts of the formal definition because they serve adifferent purpose. Integrity conditions serve primarily to establish whethergiven data are consistent with the SKOS data model. All other statementswithin the definition of the SKOS data model serveonly tosupport logical inferences. (See also the next sub-section.)

Integrity conditions are defined for the SKOS data model in a way that isindependent of strategies for their implementation, in so far as that ispossible. This is because there are several different ways in which aprocedure to find inconsistencies with the SKOS data model could beimplemented. Inconsistencies could be found using an OWLreasoner. Alternatively, some inconsistencies could be found by searching forspecific patterns within the data, or by a hybrid strategy (e.g., drawing inferencesusing an RDFS or OWL reasoner, then searching for patterns in the inferredgraph).

The integrity conditions on the SKOS data model are fewer than might beexpected, especially for those used to working within the closed world ofdatabase systems. See also the next sub-section, and the notes in sections3-10 below.

1.5. Inference, Dependency and the Open World Assumption

This document defines the SKOS data model as an OWL Full ontology. Thereare other ways in which the SKOS data model could have beendefined, for example as an entity-relationship model, or a UML class model.Although OWL Full as a data modeling language appears intuitively similar inmany ways to these other modeling approaches, there is an importantfundamental distinction.

RDF and OWL Full are designed for systems in which data may be widelydistributed (e.g., the Web). As such a system becomes larger, it becomes bothimpractical and virtually impossible to know where all of the data in thesystem are located. Therefore, one cannot generally assume that data obtainedfrom such a system are complete. If some data appear to be missing,one has to assume, in general, that the datamight exist somewhereelse in the system. This assumption, roughly speaking, is known as theopen world assumption [OWL-GUIDE].

This means in practice that, for a data model defined as an OWL Fullontology, some definitions can have a counter-intuitive meaning. Noconclusions can be drawn from missing data, and removing something willnever make the remaining data inconsistent. This is illustrated, for example, by the definition ofskos:semanticRelation inSection 8 below. Thepropertyskos:semanticRelation is defined to have domain andrangeskos:Concept. These domain and range definitions givelicense toinferences. Consider the graph below.

<A> skos:semanticRelation <B>.

In this case, the graph above entails the followinggraph.

<A> rdf:type skos:Concept .<B> rdf:type skos:Concept .

Thus, we do not need toexplicitly state here that<A> and<B> are instances ofskos:Concept, because such statements are entailed by the definition ofskos:semanticRelation.

In the SKOS data model, most statements of definition arenot integrity conditions, but are statements of logicaldependency between different elements of the data model, which (under theopen world assumption) give license to a number of simple inferences. This is illustrated, forexample, by the statement inSection 7 below thatskos:broader andskos:narrower are inverse properties. This statement means that

<A> skos:narrower <B> .

entails

<B> skos:broader <A> .

Both of these two graphs are, by themselves, consistent with the SKOS datamodel.

Knowledge organization systems such as thesauri and classification schemesare applied in a wide range of situations, and an individual knowledgeorganization system can be used in many different information systems. Bydefining the SKOS data model as an OWL Full ontology, the Semantic Web canthen be used as a medium for publishing, exchanging, sharing and linkingdata involving these knowledge organization systems. For this reason, for theexpressiveness of OWL Full as a data modeling language, and for thepossibility of using thesauri, classification schemes, etc., side-by-side withformal ontologies, OWL Full has been used to define the SKOS data model. Theopen world assumption is therefore a fundamental premise of the SKOS datamodel, and should be borne in mind when reading this document.

See also [RDF-PRIMER] and [OWL-GUIDE].

1.7. How to Read this Document

This document formally defines the Simple Knowledge Organization Systemdata model as an OWL Full ontology. The elements of the SKOS data model areOWL classes and properties, and a Uniform Resource Identifier (URI) isprovided for each of these classes and properties so that they may be usedunambiguously in the Web. This set of URIs is the SKOS vocabulary.

The complete SKOS vocabulary is given in section 2 below. Sections 3 to 10then formally define the SKOS data model. The definition of the data model isbroken down into a number of sections purely for convenience. Each of thesesections 3 to 10 follows a common layout:

• Preamble — the main ideas covered in the section are introduced informally.
• Vocabulary — URIs from the SKOS vocabulary which are defined in the section are given.
• Class & Property Definitions — the logical characteristics and interdependencies between the classes and properties denoted by those URIs are formally defined.
• Integrity Conditions — if there are any integrity conditions, those are given.
• Examples — some canonical examples are given, both of data whichare consistent with the SKOS data model, and (where appropriate) of data which arenot consistent with the SKOS data model.
• Notes — any further notes and discussion are presented.

1.7.1. Formal Definitions

Most of the class and property definitions and integrity conditions statedin this document could be stated as RDF triples, using the RDF, RDFS and OWLvocabularies. However, a small number cannot, either because of limitationsin the expressiveness of OWL Full or lack of a standard URI for some class. Toimprove the overall readability of this document, rather than mix RDF triplesand other notations, the formal definitions and integrity conditions arestated throughout using prose.

The style of this prose generally follows the style used in [RDFS], and should beclear to a reader with a working knowledge of RDF and OWL.

So, for example, "ex:Person is an instance ofowl:Class" means

ex:Person rdf:type owl:Class .

"ex:hasParent andex:hasMother are eachinstances ofowl:ObjectProperty" means:

ex:hasParent rdf:type owl:ObjectProperty .ex:hasMother rdf:type owl:ObjectProperty .

"ex:hasMother is a sub-property ofex:hasParent"means

ex:hasMother rdfs:subPropertyOf ex:hasParent .

"therdfs:range ofex:hasParent is the classex:Person" means:

ex:hasParent rdfs:range ex:Person .

Where some formal aspects of the SKOS data model cannot be stated as RDFtriples using either RDF, RDFS or OWL vocabularies, it should be clear to areader with a basic understanding of the RDF and OWL semantics how thesestatements might be translated into formal conditions on the interpretationof an RDF vocabulary (e.g., fromSection 5, "A resource has no morethan one value ofskos:prefLabel per language tag" means for anyresource x, no two members of the set { y | <x,y> is inIEXT(I(skos:prefLabel)) } share the same language tag, where Iand IEXT are functions as defined in [RDF-SEMANTICS]).

1.7.2. URI Abbreviations

Full URIs are cited in the text of this document in monospace font,enclosed by angle brackets, e.g.,<http://example.org/ns/example>. Relative URIs are citedin the same way, and are relative to the base URI<http://example.org/ns/>, e.g.,<example> and<http://example.org/ns/example> are the same URI.

URIs are also cited in the text of this document in an abbreviated form.Abbreviated URIs are cited in monospace font without angle brackets, andshould be expanded using the table of abbreviations below.

So, for example,skos:Concept is an abbreviation of<http://www.w3.org/2004/02/skos/core#Concept>.

1.7.3. Examples

Examples of RDF graphs are given using the Terse RDF Triple language(Turtle) [TURTLE].All examples assume that they are preceded by the following prefix and URIbase directives:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@base <http://example.org/ns/> .

Therefore, the example given below

is equivalent to the following Turtle document

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@base <http://example.org/ns/> .    <MyConcept> rdf:type skos:Concept .

which is equivalent to the following RDF/XML document [RDF-XML]

<?xml version="1.0" encoding="UTF-8"?><rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
    xmlns:skos="http://www.w3.org/2004/02/skos/core#"
    xmlns:owl="http://www.w3.org/2002/07/owl#"
    xml:base="http://example.org/ns/">        <skos:Concept rdf:about="MyConcept"/>    </rdf:RDF>

which is equivalent to the following N-TRIPLES document [NTRIPLES]

<http://example.org/ns/MyConcept> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2004/02/skos/core#Concept> .

Note the use in Turtle of the ";" and "," characters to abbreviatemultiple triples with the same subject or predicate. Some examples also makeuse of the Turtle syntax "(...)", representing an RDF Collection.

1.8. Conformance

This specification does not define a formal notion of conformance.

However, an RDF graph will beinconsistent with the SKOSdata model if that graph and the SKOS data model (as defined formally below)taken together lead to a logical contradiction.

Where URIs are used to identify resources of typeskos:Concept,skos:ConceptScheme,skos:Collection orskosxl:Label, this specificationdoes not require specific behavior when dereferencing thoseURIs via the Web [WEBARCH]. It is, however, strongly recommended thatpublishers of SKOS data follow the guidelines given in [COOLURIS] and [RECIPES].

2. SKOS Namespace and Vocabulary

The SKOS namespace URI is:

• http://www.w3.org/2004/02/skos/core#

The SKOS vocabulary is a set of URIs, given in the left-hand column in thetable below.

All URIs in the SKOS vocabulary are constructed by appending a local name(e.g., "prefLabel") to the SKOS namespace URI.

See also the SKOS overview inAppendix B and thequick access panel.

3. The skos:Concept Class

3.1. Preamble

The classskos:Concept is the class of SKOS concepts.

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 thisdefinition is meant to be suggestive, rather than restrictive.

The notion of a SKOS concept is useful when describing the conceptual orintellectual structure of a knowledge organization system, and when referringto specific ideas or meanings established within a KOS.

Note that, because SKOS is designed to be a vehicle for representingsemi-formal KOS, such as thesauri and classification schemes, a certainamount of flexibility has been built in to the formal definition of thisclass.

See the [SKOS-PRIMER] formore examples of identifying and describing SKOS concepts.

3.2. Vocabulary

3.3. Class & Property Definitions

3.4. Examples

The graph below states that<MyConcept> is a SKOSconcept (i.e., an instance ofskos:Concept).

3.5. Notes

3.5.1. SKOS Concepts, OWL Classes and OWL Properties

Other than the assertion thatskos:Concept is an instance ofowl:Class, this specification doesnot make anyadditional statement about the formal relationship between the class of SKOSconcepts and the class of OWL classes. The decisionnot tomake any such statement has been made to allow applications the freedom toexplore different design patterns for working with SKOS in combination withOWL.

In the example graph below,<MyConcept> is aninstance ofskos:Conceptand an instance ofowl:Class.

This example isconsistent with the SKOS datamodel.

Similarly, this specification doesnot make anystatement about the formal relationship between the class of SKOSconcepts and the class of OWL properties.

In the example graph below,<MyConcept> isan instance ofskos:Conceptand aninstance ofowl:ObjectProperty.

This example isconsistent with the SKOS datamodel.

4. Concept Schemes

4.1. Preamble

A SKOS concept scheme can be viewed as an aggregation of one or more SKOSconcepts. Semantic relationships (links) between those concepts may also beviewed as part of a concept scheme. This definition is, however, meant to besuggestive rather than restrictive, and there is some flexibility in theformal data model stated below.

The notion of a concept scheme is useful when dealing with data from anunknown source, and when dealing with data that describes two or moredifferent knowledge organization systems.

See the [SKOS-PRIMER] formore examples of identifying and describing concept schemes.

4.2. Vocabulary

4.3. Class & Property Definitions

4.4. Integrity Conditions

4.5. Examples

The graph below describes a concept scheme with two SKOS concepts, one ofwhich is a top-level concept in that scheme.

4.6. Notes

4.6.1. Closed vs. Open Systems

The notion of an individual SKOS concept scheme correspondsroughly to the notion of an individual thesaurus,classification scheme, subject heading system or other knowledge organizationsystem.

However, in most current information systems, a thesaurus orclassification scheme is treated as aclosed system —conceptual units defined within that system cannot take part in other systems(although they can bemapped to units in other systems).

Although SKOS does take a similar approach, there arenoconditions preventing a SKOS concept from taking part in zero, one, or morethan one concept scheme.

So, for example, in the graph below the SKOS concept<MyConcept> takes part in two different concept schemes— this isconsistent with the SKOS data model.

This flexibility is desirable because it allows, for example, new conceptschemes to be described by linking two or more existing concept schemestogether.

Also, note that there is no way to close the boundary of a concept scheme.So, while it is possible usingskos:inScheme to say that SKOSconcepts X, Y and Z take part in concept scheme A, there is no way to saythatonly X, Y and Z take part in A.

Therefore, while SKOS can be used todescribe a conceptscheme, SKOS does not provide any mechanism to completelydefine a concept scheme.

4.6.2. SKOS Concept Schemes and OWL Ontologies

This specification doesnot make any statement about theformal relationship between the class of SKOS concept schemes and the classof OWL ontologies. The decisionnot to make any suchstatement has been made to allow different design patterns to be explored forusing SKOS in combination with OWL [OWL-GUIDE].

In the example graph below,<MyScheme> isboth a SKOS concept scheme and an OWL ontology. Thisisconsistent with the SKOS data model.

4.6.3. Top Concepts and Semantic Relations

The propertyskos:hasTopConcept is, by convention, used tolink a concept scheme to the SKOS concept(s) which are topmost in thehierarchical relations for that scheme. However, there are no integrityconditions enforcing this convention. Therefore, the graph below, whilst notstrictly adhering to the usage convention forskos:hasTopConcept, is neverthelessconsistentwith the SKOS data model.

An application may reject such data but is not required to.

4.6.4. Scheme Containment and Semantic Relations

A link between two SKOS conceptsdoes not entailcontainment within the same concept scheme. This is illustrated in theexample below.

See alsoSection 8 below.

4.6.5. Domain of skos:inScheme

Note thatno domain is stated for the propertyskos:inScheme, i.e., the domain is effectively the class of allresources (rdfs:Resource). The decision not to state any domainhas been made to provide some flexibility, enabling extensions to SKOS todefine new classes of resource but still useskos:inScheme tolink them to askos:ConceptScheme. See alsoexample 82 below.

5. Lexical Labels

5.1. Preamble

A lexical label is a string of UNICODE characters, such as "romantic love"or "れんあい", in a given natural language, such as English or Japanese (written here in hiragana).

The Simple Knowledge Organization System provides some basic vocabularyfor associating lexical labels with resources of any type. In particular,SKOS enables a distinction to be made between the preferred, alternativeand "hidden" lexical labels for any given resource.

The preferred and alternative labels are useful when generating orcreating human-readable representations of a knowledge organization system.These labels provide the strongest clues as to the meaning of a SKOSconcept.

The hidden labels are useful when a user is interacting with a knowledgeorganization system via a text-based search function. The user may, forexample, enter mis-spelled words when trying to find a relevant concept. Ifthe mis-spelled query can be matched against a hidden label, the user willbe able to find the relevant concept, but the hidden label won't otherwisebe visible to the user (so further mistakes aren't encouraged).

Formally, a lexical label is an RDF plain literal [RDF-CONCEPTS]. An RDF plainliteral is composed of a lexical form, which is a string of UNICODEcharacters, and an optional language tag, which is a string of charactersconforming to the syntax defined by [BCP47].

See the [SKOS-PRIMER] for more examples of labeling SKOS concepts. Note especially that the examples below serve only to illustrate general features of the SKOS data model, anddo not necessarily indicate best practice for the provision of labels with different language tags. The SKOS Reference aims to establish a data model that is applicable across a range of situations, which may then be refined and/or constrained by usage conventions for more specific situations. Application- and language-specific usage conventions with respect to labels and language tags are out of scope for the SKOS Reference.

5.2. Vocabulary

5.3. Class & Property Definitions

5.4. Integrity Conditions

5.5. Examples

The following graph isconsistent, and illustrates theprovision of lexical labels in two different languages (French andEnglish).

The following graph isconsistent and illustrates the provision of lexical labels in four different variations (Japanese written with kanji, the hiragana script, the katakana script or with latin characters (rōmaji)).

The following graph isnot consistent with the SKOS datamodel, because two different preferred lexical labels have been given with thesame language tag.

The following graph isnot consistent with the SKOS datamodel, because there is a clash between the preferred and alternative lexicallabels.

The following graph isnot consistent with the SKOS datamodel, because there is a clash between alternative and hidden lexicallabels.

The following graph isnot consistent with the SKOS datamodel, because there is a clash between preferred and hidden lexicallabels.

5.6. Notes

5.6.1. Domain of SKOS Lexical Labeling Properties

Note thatno domain is stated forskos:prefLabel,skos:altLabel andskos:hiddenLabel. Thus, the effective domain of these propertiesis the class of all resources (rdfs:Resource).

Therefore, using the propertiesskos:prefLabel,skos:altLabel andskos:hiddenLabel tolabelany type of resource isconsistent with the SKOSdata model.

In the example graph below,skos:prefLabel,skos:altLabel andskos:hiddenLabel have been usedto label a resource of typeowl:Class — this isconsistent with the SKOS data model.

5.6.2. Range of SKOS Lexical Labeling Properties

Note that the range ofskos:prefLabel,skos:altLabel andskos:hiddenLabel is the class ofRDF plain literals [RDF-CONCEPTS].

By convention, RDF plain literals are always used in the object positionof a triple, where the predicate is one ofskos:prefLabel,skos:altLabel orskos:hiddenLabel. If agraphdoes not follow this usage convention anapplication may reject such data but is not required to. See also thenote below.

5.6.3. Defining Label Relations

Some applications require additional functionality relating to labels, forexample allowing the description of those labels or the definition ofadditional relations between the labels (such as acronyms). This can beachieved through the identification of labels using URIs. The SKOS eXtensionfor Labels defined inAppendix A provides support forthis.

5.6.4. Alternates Without Preferred

In the graph below, a resource has two alternative lexical labels, but nopreferred lexical label. This isconsistent with the SKOSdata model, and there are no additional entailments which follow from thedata model. However, note that many applications will require a preferredlexical label in order to generate an optimum human-readable display.

5.6.5. Labeling and Language Tags

[BCP47]defines tags for identifying languages. Note that "en", "en-GB", "en-US" are three different languagetags, used with English, British English and US English respectively.Similarly "ja", "ja-Hani", "ja-Hira", "ja-Kana" and "ja-Latn" are fivedifferent language tags used with Japanese, Japanese written with kanji, the hiragana script, the katakana script or with latin characters (rōmaji) respectively.

The graph below isconsistent with the SKOS datamodel, because "en", "en-US" and "en-GB" are different language tags.

In the graph below, there is no clash between the lexical labelingproperties, again because "en" and "en-GB" are different language tags, and therefore the graph isconsistent with the SKOS data model.

Note however that, as stated above in section 5.1, these examples serve only to illustrate general features of the SKOS data model, anddo not necessarily indicate best practice for the provision of labels with different language tags. Application- and language-specific usage conventions with respect to labels and language tags are out of scope for the SKOS Reference.

It is suggested that applications match requests for labels in a given language to labels with related language tags that are provided by a SKOS concept scheme, e.g., by implementing the "lookup" algorithm defined by [BCP 47]. Applications that perform matching in this way do not require labels to be provided in all possible language variations (of which there could be many), and are compatible with SKOS concept schemes that provide only those labels whose lexical forms are distinct for a given language or collection of languages.

6. Notations

6.1. Preamble

A notation is a string of characters such as "T58.5" or "303.4833" used touniquely identify a concept within the scope of a given concept scheme.

A notation is different from a lexical label in that a notation is notnormally recognizable as a word or sequence of words in any naturallanguage.

This section defines theskos:notation property. Thisproperty is used to assign a notation as a typed literal[RDF-CONCEPTS].

6.2. Vocabulary

6.3. Class & Property Definitions

6.4. Examples

The example below illustrates a resource<http://example.com/ns/MyConcept> with a notation whoselexical form is the UNICODE string "303.4833" and whose datatype is denotedby the URI<http://example.com/ns/MyNotationDatatype>.

6.5. Notes

6.5.1. Notations, Typed Literals and Datatypes

A typed literal is a UNICODE string combined with a datatype URI [RDF-CONCEPTS].

Typed literals are commonly used to denote values such as integers,floating point numbers and dates, and there are a number of datatypespre-defined by the XML Schema specification [XML-SCHEMA] such asxs:integer,xs:float andxs:date.

For other situations, new datatypes can be defined, and these arecommonly called "user-defined datatypes" [SWBP-DATATYPES].

By convention, the propertyskos:notation is only used with atyped literal in the object position of the triple, where the datatype URIdenotes a user-defined datatype corresponding to a particular system ofnotations or classification codes.

For many situations it may be sufficient to simply coin a datatype URI fora particular notation system, and define the datatype informally via adocument that describes how the notations are constructed and/or whichlexical forms are allowed. Note, however, that it is also possible to defineat least the lexical space of a datatype more formally via the XML Schemalanguage, see [SWBP-DATATYPES] section 2. Usersshould be aware that tools may vary in their support ofdatatypes. However, as discussed in [OWL-REFERENCE] section6.3, tools should at least treat lexically identical literals asequal.

6.5.2. Multiple Notations

There are no constraints on the cardinality of theskos:notation property. A concept may have zero, 1 or morenotations.

Where a concept has more than 1 notation, these may be from the same ordifferent notation systems. In the case where notations are from differentsystems, different datatypes may be used to indicate this. It is notcommon practice to assign more than one notation from the same notationsystem (i.e., with the same datatype URI).

6.5.3. Unique Notations in Concept Schemes

By convention, no two concepts in the same concept scheme are given thesame notation. If they were, it would not be possible to use the notation touniquely refer to a concept (i.e., the notation would become ambiguous).

6.5.4. Notations and Preferred Labels

There are no constraints on the combined use ofskos:notationandskos:prefLabel. In the example below, the same string isgiven both as the lexical form of a notation and as a the lexical form of apreferred label.

Typed literals consist of a string of characters and a datatypeURI. By convention,skos:notation is only usedwithtyped literals in the object position of thetriple.

Plain literals consist of a string of characters and a language tag. Byconvention,skos:prefLabel (andskos:altLabel andskos:hiddenLabel) are only used withplainliterals in the object position of the triple.

There is no such thing as an RDF literal with both a language tag and adatatype URI, i.e., a typed literal does not have a language tag, and a plainliteral does not have a datatype URI.

6.5.5. Domain of skos:notation

Note thatno domain is stated forskos:notation. Thus, the effective domain is the class of all resources (rdfs:Resource).Therefore, usingskos:notation with any type of resource is consistent with the SKOS data model.

7. Documentation Properties (Note Properties)

7.1. Preamble

Notes are used to provide information relating to SKOS concepts. There isno restriction on the nature of this information, e.g., it could beplain text, hypertext, or an image; it could be a definition, informationabout the scope of a concept, editorial information, or any other type ofinformation.

There are seven properties in SKOS for associating notes with concepts,defined formally in this section. For more information on the recommendedusage of each of the SKOS documentation properties, see the [SKOS-PRIMER].

These seven properties are not intended to cover every situation, butrather to be useful in some of the most common situations, and to provide aset of extension points for defining more specific types of note. For moreinformation on recommended best practice for extending SKOS, see the [SKOS-PRIMER].

Three different usage patterns are recommended in the [SKOS-PRIMER] for the SKOSdocumentation properties — "documentation as an RDF literal","documentation as a related resource description" and "documentation as adocument reference". The data model defined in this section is intendedto accommodate all three design patterns.

7.2. Vocabulary

7.3. Class & Property Definitions

7.4. Examples

The graph below gives an example of the "documentation as an RDF literal"pattern.

The graph below gives an example of the "documentation as a documentreference" pattern.

7.5. Notes

7.5.1. Domain of the SKOS Documentation Properties

Note thatno domain is stated for the SKOS documentationproperties. Thus, the effective domain for these properties is the class ofall resources (rdfs:Resource). Therefore, using the SKOSdocumentation properties to provide information onany type ofresource is consistent with the SKOS data model.

In the example graph below,skos:definition has beenused to provide a plain text definition for a resource of typeowl:Class — this is consistent with the SKOS data model.

7.5.2. Range of the SKOS DocumentationProperties

Note that no range is stated for the SKOS documentation properties,and thus the range of these properties is effectively the class of allresources (rdfs:Resource). Under the RDF and OWL Full semantics,everything is a resource, including RDF plain literals.

8. Semantic Relations

8.1. Preamble

SKOS semantic relations are links between SKOS concepts, where the link isinherent in the meaning of the linked concepts.

The Simple Knowledge Organization System distinguishes between two basiccategories of semantic relation:hierarchical andassociative. A hierarchical link between two conceptsindicates that one is in some way more general ("broader") than the other("narrower"). An associative link between two concepts indicates that the twoare inherently "related", but that one isnot in any waymore general than the other.

The propertiesskos:broader andskos:narrowerare used to assert a direct hierarchical link between two SKOS concepts. Atriple<A> skos:broader <B> asserts that<B>, the object of the triple, is a broader concept than<A>, the subject of the triple. Similarly, a triple<C> skos:narrower <D> asserts that<D>, the object of the triple, is a narrower concept than<C>, the subject of the triple.

By convention,skos:broader andskos:narrowerareonly used to assert adirect (i.e.,immediate) hierarchical link between two SKOS concepts. This providesapplications with a convenient and reliable way to access the direct broaderand narrower links for any given concept. Note that, to support this usageconvention, the propertiesskos:broader andskos:narrower arenot declared as transitiveproperties.

Some applications need to make use ofboth direct andindirect hierarchical links between concepts, for instance toimprove search recall through query expansion. For this purpose, thepropertiesskos:broaderTransitive andskos:narrowerTransitive are provided. A triple<A>skos:broaderTransitive<B> represents a direct or indirect hierarchical link,where<B> is a broader "ancestor" of<A>. Similarly a triple<C>skos:narrowerTransitive <D> represents a direct or indirecthierarchical link, where<D> is a narrower "descendant" of<C>.

By convention, the propertiesskos:broaderTransitive andskos:narrowerTransitive arenot used to makeassertions. Rather, these properties are used to infer the transitive closureof the hierarchical links, which can then be used to access direct orindirect hierarchical links between concepts.

The propertyskos:related is used to assert an associativelink between two SKOS concepts.

For more examples of stating hierarchical and associative links, see the[SKOS-PRIMER].

8.2. Vocabulary

8.3. Class & Property Definitions

8.4. Integrity Conditions

Note that becauseskos:related is a symmetric property, andskos:broaderTransitive andskos:narrowerTransitiveare inverses,skos:related is therefore also disjoint withskos:narrowerTransitive.

8.5. Examples

The graph below asserts a direct hierarchical link between<A> and<B> (where<B> is broader than<A>), and anassociative link between<A> and<C>,and isconsistent with the SKOS data model.

The graph below isnot consistent with the SKOS datamodel, because there is a clash between associative links and hierarchicallinks.

The graph below isnot consistent with the SKOS datamodel, again because there is a clash between associative links andhierarchical links.

In the example above, the clash is not immediately obvious. The clashbecomes apparent when inferences are drawn, based on the class and propertydefinitions above, giving the following graph.

The graph below isnot consistent with the SKOS datamodel, again because there is a clash between associative links andhierarchical links, which can be inferred from the class and propertydefinitions given above.

8.6. Notes

8.6.1. Sub-Property Relationships

The diagram below illustrates informally the sub-property relationshipsbetween the SKOS semantic relation properties.

skos:semanticRelation | +— skos:related | +— skos:broaderTransitive |    | |    +— skos:broader | +— skos:narrowerTransitive      |      +— skos:narrower

8.6.2. Domain and Range of SKOS Semantic RelationProperties

Note that the domain and range ofskos:semanticRelation isthe classskos:Concept. Becauseskos:broader,skos:narrower andskos:related are eachsub-properties ofskos:semanticRelation, the graph inexample 26above entails that<A>,<B> and<C> are each instances ofskos:Concept.

8.6.3. Symmetry of skos:related

skos:related is a symmetric property. The example belowillustrates an entailment which follows from this condition.

Note that, althoughskos:related is a symmetric property,this condition doesnot place any restrictions onsub-properties ofskos:related (i.e., sub-properties ofskos:related could be symmetric, not symmetric or antisymmetric,and still be consistent with the SKOS data model).

To illustrate this point, in the example below, two new properties whicharenot symmetric are declared as sub-properties ofskos:related. The example, which isconsistentwith the SKOS data model, also shows some of the entailments which follow.

See also the [SKOS-PRIMER]for best practice recommendations on extending SKOS.

8.6.4. skos:related and Transitivity

Note thatskos:related isnot a transitiveproperty. Therefore, the SKOS data model doesnot support anentailment as illustrated in the example below.

8.6.5. skos:related and Reflexivity

Note that this specification does not state thatskos:relatedis areflexive property,neither does itstate thatskos:related is an irreflexive property.

Becauseskos:related isnot defined as anirreflexive property, the graph below isconsistent with theSKOS data model.

However, for many applications that use knowledge organization systems,statements of the form Xskos:related X are a potential problem.Where this is the case, an application may wish to search for such statementsprior to processing SKOS data, although how an application should handle suchstatements is not defined in this specification and may vary betweenapplications.

8.6.6. skos:broader and Transitivity

Note thatskos:broader isnot a transitiveproperty. Similarly,skos:narrower isnot atransitive property. Therefore, the SKOS data model doesnotsupport an entailment as illustrated in the example below.

However,skos:broader is a sub-property ofskos:broaderTransitive, whichis a transitiveproperty. Similarly,skos:narrower is a sub-property ofskos:narrowerTransitive, whichis a transitiveproperty. Therefore the SKOS data modeldoes support theentailments illustrated below.

Note especially that, by convention,skos:broader andskos:narrower areonly used to assert immediate(i.e., direct) hierarchical links between two SKOS concepts. By convention,skos:broaderTransitive andskos:narrowerTransitivearenot used to make assertions, but are instead used onlyto draw inferences.

This pattern allows the information about direct (i.e., immediate)hierarchical links to be preserved, which is necessary for many tasks (e.g.,building various types of visual representation of a knowledge organizationsystem), whilst also providing a mechanism for conveniently querying thetransitive closure of those hierarchical links (which will include bothdirect and indirect links), which is useful in other situations (e.g., queryexpansion algorithms).

Note also that a sub-property of a transitive property isnot necessarily transitive.

See also the note on alternative paths below.

8.6.7. skos:broader and Reflexivity

Note that this specification makes no statements regarding the reflexivecharacteristics of theskos:broader relationship. It does notstate thatskos:broader is areflexiveproperty,neither does it state thatskos:broader is an irreflexive property. Thus for any graph andresource<A>, the triple:

may or may not be present. This conservative position allows SKOS to beused to model both KOS where the interpretation ofskos:broaderis reflexive (e.g., a direct translation of an inferred OWL sub-classhierarchy), or KOS whereskos:broader could be consideredirreflexive (as would be appropriate for most thesauri or classificationschemes).

Similarly, there are no assertions made as to the reflexivity orirreflexivity ofskos:narrower.

However, for many applications that use knowledge organization systems,statements of the form Xskos:broader X or Yskos:narrower Y represent a potential problem. Where this is thecase, an application may wish to search for such statements prior toprocessing SKOS data, although how an application should handle suchstatements is not defined in this specification and may vary betweenapplications.

8.6.8. Cycles in the Hierarchical Relation(skos:broaderTransitive and Reflexivity)

In the graph below, a cycle has been stated in the hierarchical relation.Note that this graph isconsistent with the SKOS data model,i.e., there isno condition requiring thatskos:broaderTransitive be irreflexive.

However, for many applications where knowledge organization systems areused, a cycle in the hierarchical relation represents a potential problem.For these applications, computing the transitive closure ofskos:broaderTransitive then looking for statements of the formXskos:broaderTransitive X is aconvenient strategy for finding cycles in the hierarchical relation. How anapplication should handle such statements is not defined in thisspecification and may vary between applications.

8.6.9. Alternate Paths in the Hierarchical Relation

In the graph below, there are two alternative paths from A to C in thehierarchical relation.

In the graph below, there are two alternative paths from A to D in thehierarchical relation.

This is a pattern which arises naturally in poly-hierarchical knowledgeorganization systems.

Both of these graphs areconsistent with the SKOS datamodel, i.e., there isno condition requiring that there beonly one path between any two nodes in the hierarchical relation.

8.6.10. Disjointness of skos:related andskos:broaderTransitive

This specification treats the hierarchical and associative relations asfundamentally distinct in nature. Therefore a clash between hierarchicaland associative links isnot consistent with the SKOS datamodel. The examples above illustrate some situations in which a clash isseen to arise.

This position follows the usual definitions given to hierarchical andassociative relations in thesaurus standards [ISO2788] [BS8723-2], and supports commonpractice in many existing knowledge organization systems.

Note that this specification takes the stronger position that, not onlyare the immediate (i.e., direct) hierarchical and associative links disjoint,but associative links are also disjoint withindirect hierarchicallinks. This is captured formally in the integrity condition asserting thatskos:related andskos:broaderTransitive aredisjoint properties.

9. Concept Collections

9.1. Preamble

SKOS concept collections are labeled and/or ordered groups of SKOSconcepts.

Collections are useful where a group of concepts shares something incommon, and it is convenient to group them under a common label, or wheresome concepts can be placed in a meaningful order.

9.2. Vocabulary

9.3. Class & Property Definitions

9.4. Integrity Conditions

9.5. Examples

The graph below illustrates a SKOS collection with 3 members.

The graph below illustrates an ordered SKOS collection with 3 members.Note the use of the Turtle syntax(...), representing an RDFCollection (list).

9.6. Notes

9.6.1. Inferring Collections from Ordered Collections

StatementS36 states the logical relationship between theskos:memberList andskos:member properties. Thisrelationship means that a collection can be inferred from an orderedcollection. This is illustrated in the example below.

Note that SKOS does not provide any way to explicitly state that acollection isnot ordered.

9.6.2. skos:memberList Integrity

Note thatskos:memberList is a functional property, i.e., itdoes not have more than one value. This is intended to capture within theSKOS data model that it doesn't make sense for an ordered collection to havemore than one member list. Unfortunately, there is no way to use thiscondition as an integrity condition without explicitly stating that two listsare different objects. In other words, although the graph below isconsistent with the SKOS data model, it entails nonsense (alist with two first elements and a forked tail).

However, as stated in [RDF-SEMANTICS] section 3.3.3, semanticextensions to RDF may place extra syntactic well-formednessrestrictions on the use of the RDF collection vocabulary(rdf:first,rdf:rest,rdf:nil)in order to rule out such graphs.

9.6.3. Nested Collections

In the example below, a collection is nested within another collection.

This example isconsistent with the SKOS datamodel, because the range ofskos:member is theunion ofskos:Conceptandskos:Collection.

9.6.4. SKOS Concepts, Concept Collections and SemanticRelations

In the SKOS data model,skos:Concept andskos:Collection are disjoint classes. The domain and range ofthe SKOS semantic relation properties isskos:Concept.Therefore, if any of the SKOS semantic relation properties (e.g.,skos:narrower) are used to link to or from a collection, thegraph willnot be consistent with the SKOS data model.

This is illustrated in the example below, which isnotconsistent with the SKOS data model.

Similarly, the graph below isnot consistent with theSKOS data model.

Similarly, the graph below isnot consistent with theSKOS data model.

However, the graph below is consistent with the SKOS data model.

This means that, for thesauri and other knowledge organization systemswhere node labels are used within the systematic display for thatthesaurus, the appropriate SKOS representation requires carefulconsideration. Furthermore, where node labels are used in the systematicdisplay, it may not always be possible to fully reconstruct the systematicdisplay from a SKOS representation alone. Fully representing all of theinformation represented in a systematic display of a thesaurus or otherknowledge organization system, including details of layout and presentation,is beyond the scope of SKOS.

10. Mapping Properties

10.1. Preamble

The SKOS mapping properties areskos:closeMatch,skos:exactMatch,skos:broadMatch,skos:narrowMatch andskos:relatedMatch. Theseproperties are used to state mapping (alignment) links between SKOS conceptsin different concept schemes, where the links are inherent in the meaning ofthe linked concepts.

The propertiesskos:broadMatch andskos:narrowMatch are used to state a hierarchical mapping linkbetween two concepts.

The propertyskos:relatedMatch is used to state anassociative mapping link between two concepts.

The propertyskos:closeMatch is used to link two conceptsthat are sufficiently similar that they can be used interchangeably insome information retrieval applications. In order to avoidthe possibility of "compound errors" when combining mappings across more thantwo concept schemes,skos:closeMatch isnotdeclared to be a transitive property.

The propertyskos:exactMatch is used to link two concepts,indicating a high degree of confidence that the concepts can be usedinterchangeably across a wide range of information retrieval applications.skos:exactMatch is a transitive property, and is a sub-propertyofskos:closeMatch.

10.2. Vocabulary

10.3. Class & Property Definitions

10.4. Integrity Conditions

Note that becauseskos:exactMatch is a symmetric property, andskos:broadMatch andskos:narrowMatch are inverses,skos:exactMatch is therefore also disjoint withskos:narrowMatch.

10.5. Examples

The graph below asserts an exact equivalence mapping link between<A> and<B>.

The graph below asserts a close equivalence mapping link between<A> and<B>.

The graph below asserts a hierarchical mapping link between<A> and<B> (where<B> is broader than<A>), and anassociative mapping link between<A> and<C>.

The graph below isnot consistent with the SKOS datamodel, because there is a clash between exact and hierarchical mappinglinks.

The graph below isnot consistent with the SKOS datamodel, because there is a clash between exact and associative mappinglinks.

10.6. Notes

10.6.1. Mapping Properties, Semantic Relation Properties andConcept Schemes

By convention, the SKOS mapping properties are only used to link conceptsindifferent concept schemes. However, note that using theSKOS semantic relation properties (skos:broader,skos:narrower,skos:related) to link concepts indifferent concept schemes is alsoconsistent with the SKOS data model (seeSection 8).

The mapping propertiesskos:broadMatch,skos:narrowMatch andskos:relatedMatch are providedas a convenience, for situations where the provenance of data is known, andit is useful to be able to tell at a glance the difference between internallinks within a concept scheme and mapping links between concept schemes.

However, using the SKOS mapping properties isnosubstitute for the careful management of RDF graphs or the use ofprovenance mechanisms.

The rationale behind this design is that it is hard to draw an absolutedistinction between internal links within a concept scheme and mapping linksbetween concept schemes. This is especially true in an open environment wheredifferent people might re-organize concepts into concept schemes in differentways. What one person views as two concept schemes with mapping linksbetween, another might view as one single concept scheme with internal linksonly. This specification allows both points of view to co-exist, which (it ishoped) will promote flexibility and innovation in the re-use of SKOS data inthe Web.

There is therefore an intimate connection between the SKOS semanticrelation properties and the SKOS mapping properties. The propertyskos:broadMatch is a sub-property ofskos:broader,skos:narrowMatch is a sub-property ofskos:narrower, andskos:relatedMatch is asub-property ofskos:related. The full set of sub-propertyrelationships is illustrated below.

skos:semanticRelation | +- skos:related |   | |   +- skos:relatedMatch | +- skos:broaderTransitive |   | |   +- skos:broader |       | |       +- skos:broadMatch | +- skos:narrowerTransitive |   | |   +- skos:narrower |       | |       +- skos:narrowMatch | +- skos:mappingRelation     |     +- skos:closeMatch     |   |     |   +- skos:exactMatch     |     +- skos:relatedMatch     |     +- skos:broadMatch     |     +- skos:narrowMatch

Examples below illustrate some entailments which follow from thissub-property tree, and from the domain and range ofskos:semanticRelation.

Note also that, because different people might re-organize concepts intoconcept schemes in different ways, a graph might assertmapping links between concepts in thesameconcept scheme, and there areno formal integrity conditionsin the SKOS data model that would make such a graph inconsistent, e.g., thegraph below isconsistent with the SKOS data model. However,in practice it is expected that such a graph would only ever arise from themerge of two or more graphs from different sources.

10.6.2. Clashes Between Hierarchical and AssociativeLinks

Examples below illustrate "clashes" between hierarchical and associativemapping links, which arenot consistent with the SKOS datamodel (because of the sub-property relationships illustrated above, andbecause of the data model for SKOS semantic relation properties defined inSection 8).

10.6.3. Mapping Properties and Transitivity

The only SKOS mapping property which is declared as transitive isskos:exactMatch. An example entailment is illustrated below:

All other SKOS mapping properties are not transitive. Therefore,entailments as illustrated in examples below arenotsupported by the SKOS data model.

10.6.4. Mapping Properties and Reflexivity

None of the SKOS mapping properties arereflexive,neither are they irreflexive.

Becauseskos:exactMatch,skos:broadMatch andskos:relatedMatch arenotirreflexive, the graph below isconsistentwith the SKOS data model.

However, see alsoSection 8 on thereflexivity of SKOS semantic relation properties.

10.6.5. Cycles and Alternate Paths Involvingskos:broadMatch

There are no formal integrity conditions preventing either cycles oralternative paths in a graph of hierarchical mapping links.

In the graph below there are two cycles involvingskos:broadMatch. This graph isconsistent withthe SKOS data model.

In the graph below there are two alternative paths involvingskos:broadMatch. This graph isconsistent withthe SKOS data model.

See howeverSection 8 on cycles andalternative paths involvingskos:broader.

10.6.6. Cycles Involving skos:exactMatch and skos:closeMatch

Due to the entailment above (which arises through a combinationofS42,S44andS45), applications must be able to cope withcycles inskos:exactMatchandskos:closeMatch.

10.6.7. Sub-Property Chains Involving skos:exactMatch

There are no sub-property chain axioms in the SKOS data model involving theskos:exactMatch orskos:closeMatch properties.Hence the entailments illustrated below arenotsupported.

Appendix A. SKOS Properties and Classes

Appendix B. SKOS eXtension for Labels (SKOS-XL)

This appendix defines anoptional extension to the SimpleKnowledge Organization System, called the SKOS eXtension for Labels (SKOS-XL).This extension provides additional support for identifying, describing andlinking lexical entities.

A special class of lexical entities, calledskosxl:Label, isdefined. Each instance of this class has a single RDF plain literal form, buttwo instances of this class are not necessarily the same individual if theyshare the same literal form.

Three labeling properties,skosxl:prefLabel,skosxl:altLabel andskosxl:hiddenLabel, aredefined. These properties are used to label SKOS concepts with instances ofskosxl:Label, and are otherwise analogous to the properties ofthe same local name defined in SKOS (skos:prefLabel,skos:altLabel andskos:hiddenLabelrespectively).

The SKOS data model also defines the propertyskosxl:labelRelation. This property can be used to assert adirect (binary) link between instances ofskosxl:Label. It isprimarily intended as an extension point, to be refined for more specifictypes of link. No built-in refinements ofskosxl:labelRelationare provided, although some examples of how this could be done are given.

B.1. SKOS-XL Namespace and Vocabulary

The SKOS-XL namespace URI is:

• http://www.w3.org/2008/05/skos-xl#

Here the prefixskosxl: is used as an abbreviation for the SKOS-XLnamespace URI.

The SKOS-XL vocabulary is the set of URIs given in the left-hand column of thetable below.

Here "the SKOS-XL vocabulary" refers to the union of the SKOS vocabularyand the SKOS-XL vocabulary.

Here "the XL data model" refers to the class and property definitionsstated in this appendix only. "The SKOS+XL data model" refers to the union ofthe data model defined in sections 3-10 above and the XL data model.

B.2. The skosxl:Label Class

B.2.1. Preamble

The classskosxl:Label is a special class of lexicalentities.

An instance of the classskosxl:Label is a resource and maybe named with a URI.

An instance of the classskosxl:Label has a single literalform. This literal form is an RDF plain literal (which is a string of UNICODEcharacters and an optional language tag [RDF-CONCEPTS]). The propertyskosxl:literalForm is used to give the literal form of anskosxl:Label.

If two instances of the classskosxl:Label have the sameliteral form, they arenot necessarily the same resource.

B.2.2. Class and Property Definitions

B.2.3. Examples

The example below describes askosxl:Label named with theURI<http://example.com/ns/A>, with the literal form"love" in English.

The four examples below are eachnot consistent with theXL data model, because anskosxl:Label is described with twodifferent literal forms.

B.2.4. Notes

B.2.4.1. Identity and Entailment

As stated above, each instance of the classskosxl:Label hasone and only one literal form. In other words, there is afunction mapping the class extension ofskosxl:Label to the setof RDF plain literals. This function is defined by the property extension ofskosxl:literalForm. Note especially two facts about thisfunction.

First, the function isnot injective. In other words,there isnot a one-to-one mapping from instances ofskosxl:Label to the set of RDF plain literals (in fact it ismany-to-one). This means that two instances ofskosxl:Labelwhich have the same literal form arenot necessarily thesame individual. So, for example, the entailment illustrated below isnot supported by the XL data model.

Second, the function isnot surjective. In other words,for a given plain literall, there might not be any instances ofskosxl:Label with literal forml.

B.2.4.2. Membership of Concept Schemes

The membership of an instance ofskosxl:Label within a SKOSconcept scheme can be asserted using theskos:inSchemeproperty.

B.3. Preferred, Alternate and Hidden skosxl:Labels

B.3.1. Preamble

The three propertiesskosxl:prefLabel,skosxl:altLabel andskosxl:hiddenLabel are used togive the preferred, alternative and hidden labels of a resource respectively,where those labels are instances of the classskosxl:Label.These properties are analogous to the properties of the same local namedefined in the SKOS vocabulary, and there are logical dependencies betweenthese two sets of properties defined below.

B.3.2. Class and Property Definitions

B.3.3. Examples

The example below illustrates the use of all three XL labeling properties,and is consistent with the SKOS+XL data model.

B.3.4. Notes

B.3.4.1. Dumbing-Down to SKOS Lexical Labels

The sub-property chain axiomsS55,S56 andS57 support the dumbing-down of XL labelsto vanilla SKOS lexical labels via inference. This is illustrated in theexample below.

B.3.4.2. SKOS+XL Labeling Integrity

InSection 5, two integrity conditions were definedon the basic SKOS labeling properties. First, the propertiesskos:prefLabel,skos:altLabel andskos:hiddenLabel are pairwise disjoint. Second, a resource hasno more than one value ofskos:prefLabel per language. Becauseof the sub-property chain axioms defined above, the following four examples,whilst consistent w.r.t. the XL data model alone, arenotconsistent with the SKOS+XL data model.

B.4. Links Between skosxl:Labels

B.4.1. Preamble

This section defines a pattern for representing binary links betweeninstances of the classskosxl:Label.

Note that the vocabulary defined in this section is not intended to beused directly, but rather as an extension point which can be refined for morespecific labeling scenarios.

B.4.2. Class and Property Definitions

B.4.3. Examples

The example below illustrates a link between two instances of the classskosxl:Label.

B.4.4. Notes

B.4.4.1. Refinements of this Pattern

As mentioned above, theskosxl:labelRelation property servesas an extension point, which can be refined for more specific labelingscenarios.

In the example below, a third party has refined the propertyskos:labelRelation to express acronym relationships, and used itto express the fact that "FAO" is an acronym for "Food and AgricultureOrganization".

Note that a sub-property of a symmetric property is not necessarilysymmetric.

B.5. SKOS-XL Schema Overview

The following table gives an overview of the SKOS-XL vocabulary.

Appendix C. SKOS and SKOS-XL Namespace Documents

Following Architecture of the World Wide Web, Volume One [WEBARCH], a"namespace document" is an "information resource that contains usefulinformation, machine-usable and/or human-usable, about terms in thenamespace".

The SKOS vocabulary is a conceptual resource identified by thenamespace URIhttp://www.w3.org/2004/02/skos/core#. Thenormative definition of the SKOS vocabulary is found in SKOS Reference(this document).

The following namespace documents provide alternativerepresentations of the SKOS vocabulary:

C.1. SKOS Namespace Document - HTML Variant (normative)

The SKOS vocabulary is summarized in SKOS Namespace Document - HTMLVariant [SKOS-HTML], which is served from thenamespace URIhttp://www.w3.org/2004/02/skos/core#via content negotiation using Recipe 3 of "Best Practice Recipes forPublishing Vocabularies" [RECIPES]. Clients requiring HTML or XHTMLshould include an appropriate "Accept" header in the HTTPrequest. Alternatively, the SKOS Namespace Document - HTML Variant canbe referenced directly by citing its URI:http://www.w3.org/TR/skos-reference/skos.html.

TheSKOS Namespace Document - HTML Variant replicatesAppendixA. SKOS Properties and Classes of this document.

C.2. SKOS Namespace Document - RDF/XML Variant (normative)

The SKOS Namespace Document - RDF/XML Variant [SKOS-RDF] expresses the SKOSvocabulary and data model (in so far as possible) as RDF triples. Itis served via content negotiation using Recipe 3 of "Best PracticeRecipes for Publishing Vocabularies" [RECIPES]. Clients requiringRDF/XML should include an appropriate "Accept" header in the HTTPrequest. Alternatively, the RDF schema can be referenced directly(and downloaded) by citing its URI:http://www.w3.org/TR/skos-reference/skos.rdf.

It is not possible to express all of the statements of the SKOSdata model as RDF triples, so this schema forms a normative subset ofSKOS Reference. The RDF schema defines an OWL Full ontology[OWL-SEMANTICS] [OWL-REFERENCE]. SKOS vocabularies can be defined asinstances of this ontology.

C.3. SKOS RDF Schema - OWL 1 DL Sub-set (informative)

For the convenience of tools and applications that wish to workwithin the constraints of OWL DL, the SKOS RDF Schema - OWL 1 DLSub-set [SKOS-RDF-OWL1-DL] provides amodified, informative, schema which conforms to those constraints.Note that this schema is obtained through the deletion of triplesrepresenting axioms that violate OWL DL constraints. Alternativeprunings could be performed.

The SKOS OWL 1 DL Sub-set is availableby citing its URI:http://www.w3.org/TR/skos-reference/skos-owl1-dl.rdf

C.4. SKOS-XL Namespace Document - HTML Variant (normative)

The SKOS-XL vocabulary is summarized in SKOS-XL Namespace Document- HTML Variant [SKOS-XL-HTML], which is served from thenamespace URIhttp://www.w3.org/2008/05/skos-xl#via content negotiation using Recipe 3 of "Best Practice Recipes forPublishing Vocabularies" [RECIPES]. Clients requiring HTML or XHTMLshould include an appropriate "Accept" header in the HTTPrequest. Alternatively, the SKOS-XL Namespace Document - HTML Variantcan be referenced directly by citing its URI:http://www.w3.org/TR/skos-reference/skos-xl.html.

The SKOS-XL HTML Variant Namespace Document replicatesAppendixB.5 SKOS-XL Schema Overview of this document.

C.5. SKOS-XL Namespace Document - RDF/XML Variant (normative)

This RDF schema document expresses the SKOS vocabulary and datamodel (in so far as possible) as RDF triples. It is served from the namespace URIhttp://www.w3.org/2008/05/skos-xl# via contentnegotiation using Recipe 3 of "Best Practice Recipes for PublishingVocabularies" [RECIPES]. Clients requiring RDF/XML shouldinclude an appropriate "Accept" header in the HTTP request.Alternatively, the RDF schema can be referenced directly (anddownloaded) by citing its URI:http://www.w3.org/TR/skos-reference/skos-xl.rdf.

Appendix D. SKOS Namespace: a historical note

The SKOS schema defines vocabulary using the namespacehttp://www.w3.org/2004/02/skos/core#. This namespace was used to define the original SKOS schema which served as a starting point for this Recommendation. As a result of this, elements present in previous versions of the machine-readable schema have been removed from the current version. In a number of cases, the definition or semantics of elements in the schema has changed.

Retaining the existing SKOS namespace avoids some issues with existing KOS that are already using the SKOS schema. Users should, however, be aware of the change in the semantics ofskos:broader (andskos:narrower) whichmay impact on SKOS applications.

Where elements have been removed, no explicit deprecation axioms have been expressed in the schema. Historical versions of the SKOS schema, are, however, available from theSKOS Web site "version history" page, and those elements which have been removed from the recent version of the vocabulary are listed below.

• skos:symbol
• skos:prefSymbol
• skos:altSymbol
• skos:CollectableProperty
• skos:subject
• skos:isSubjectOf
• skos:primarySubject
• skos:isPrimarySubjectOf
• skos:subjectIndicator

In the case ofskos:broader andskos:narrower, the semantics of the vocabulary elements have been changed — these properties are no longer declared to be transitive. Thus the follow entailment does not hold.

A transitive super property ofskos:broader —skos:broaderTransitive — is provided which allows for query across the transitive closure ofskos:broader relations. A similar property —skos:narrowerTransitive — is provided for query across the transitive closure ofskos:narrower.