Movatterモバイル変換

SKOS Simple Knowledge Organization System Primer

W3C Working Group Note 18 August 2009

Document Status Update 2023-10-30: This paragraph is informative. This document was updated to replace a broken link to the Willpower glossary.

This version:

http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/

Latest version:

http://www.w3.org/TR/skos-primer

Previous version:

http://www.w3.org/TR/2009/WD-skos-primer-20090615/

Editors:

Antoine Isaac, Vrije Universiteit Amsterdam

Ed Summers, Library Of Congress

Please refer to theerrata for thisdocument, which may include some corrections.

See alsotranslations.

Copyright©2009W3C^® (MIT,ERCIM,Keio), All Rights Reserved. W3Cliability,trademarkanddocumentuse rules apply.

---

Abstract

SKOS—Simple Knowledge Organization System—provides a model forexpressing the basic structure and content of concept schemes such asthesauri, classification schemes, subject heading lists, taxonomies,folksonomies, and other similar types of controlled vocabulary. As anapplication of theResource DescriptionFramework (RDF), SKOS allows concepts to be composed and published on theWorld Wide Web, linked with data on the Web and integrated into other conceptschemes.

This document is a user guide for those who would like to represent theirconcept scheme using SKOS.

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

In advanced SKOS, conceptual resources can be mapped across conceptschemes and grouped into labeled or ordered collections. Relationships can bespecified between concept labels. Finally, the SKOS vocabulary itself can beextended to suit the needs of particular communities of practice or combinedwith other modeling vocabularies.

This document is a companion to theSKOS Reference, which providesthe normative reference on SKOS.

Status of this Document

This section describes the status of this document at the time of itspublication. Other documents may supersede this document. A list of currentW3C publications and the latest revision of this technical report can befound in theW3C technical reports indexat http://www.w3.org/TR/.

This document is a Working Group Note published by theSemantic Web Deployment WorkingGroup, part of theW3CSemantic Web Activity. This version is an update to thepreviousWorking Draft of 15 June 2009. This version includes several minoreditorial changes as well as removing an example that suggested onemeans to reference a system of notation (e.g. a symbolic notation)in a label where the system of notation does not correspond to anatural language. This suggestion was deemed inconsistent withIETFBest Current Practice 47 on the use of tags for identifyinglanguages. Users should consider theSKOS Extension vocabulary for support of alternate systems of notation.

This is a companion document to theSKOS SimpleKnowledge Organization System Reference W3C Recommendation dated18 August 2009.

Comments on this document may be sent topublic-swd-wg@w3.org;please include the text "SKOS comment" in the subject line. All messagesreceived at this address are viewable in apublicarchive.

This document was produced by a group operating under the5 February 2004W3C Patent Policy. W3C maintains apublic list of anypatent disclosures made in connection with the deliverables of the group;that page also includes instructions for disclosing a patent. An individualwho has actual knowledge of a patent which the individual believes containsEssentialClaim(s) must disclose the information in accordance withsection6 of the W3C Patent Policy.

Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Table of Contents

• 1 Introduction
• 2 SKOS Essentials
  • 2.1 Concepts
  • 2.2 Labels
    • 2.2.1 Preferred Lexical Labels
    • 2.2.2 Alternative Lexical Labels
    • 2.2.3 Hidden Lexical Labels
  • 2.3 Semantic Relationships
    • 2.3.1 Broader/Narrower Relationships
    • 2.3.2 Associative Relationships
  • 2.4 Documentary Notes
  • 2.5 Concept Schemes
• 3 Networking Knowledge Organization Systems on the Semantic Web
  • 3.1 Mapping Concept Schemes
  • 3.2 Re-using and Extending Concept Schemes
  • 3.3 Subject Indexing and SKOS
• 4 Advanced SKOS: When KOSs are not Simple Anymore
  • 4.1 Collections of Concepts
  • 4.2 Advanced Documentation Features
  • 4.3 Relationships between Labels
  • 4.4 Coordinating Concepts
  • 4.5 Transitive Hierarchies
  • 4.6 Notations
  • 4.7 On Specializing the SKOS Model
• 5 Combining SKOS with other Modeling Approaches
  • 5.1 Use of Labels Outside of SKOS
  • 5.2 SKOS Concepts and OWL Classes
  • 5.3 SKOS, RDF Datasets and Information Containment
• References
• Acknowledgments
• Appendix. Correspondences between ISO-2788/5964 and SKOS constructs

1 Introduction

The Simple Knowledge Organization System (SKOS) is an RDF vocabulary forrepresenting semi-formalknowledge organization systems (KOSs), suchas thesauri, taxonomies, classification schemes and subject heading lists.Because SKOS is based on the Resource Description Framework (RDF) [RDF-PRIMER] these representations aremachine-readable and can be exchanged between software applications andpublished on the World Wide Web.

SKOS has been designed to provide a low-cost migration path for portingexisting organization systems to the Semantic Web. SKOS also provides alightweight, intuitive conceptual modeling language for developing andsharing new KOSs. It can be used on its own, or in combination withmore-formal languages such as the Web Ontology Language (OWL) [OWL]. SKOS can also be seen as a bridgingtechnology, providing the missing link between the rigorous logical formalismof ontology languages such as OWL and the chaotic, informal andweakly-structured world of Web-based collaboration tools, as exemplified bysocial tagging applications.

The aim of SKOS is not to replace original conceptual vocabularies intheir initial context of use, but to allow them to be ported to a sharedspace, based on a simplified model, enabling wider re-use and betterinteroperability.

1.1 About this Primer

This document is intended to help users who have a basic understanding ofRDF to represent and publish their concept schemes as SKOS data. The Primeraims to provide introductory examples and guidance in the use of the SKOSvocabulary.

For a systematic account of all SKOS vocabulary elements, including theirreference semantics, the reader should consult the normativeSKOSReference [SKOS-REFERENCE].This can be done, at the level of classes and properties, by clicking ontheir occurrences in the text (e.g.skos:Concept). For anoverview of the use cases for SKOS and the elicited requirements that guidedits design, the reader should consult theSKOS Use Cases andRequirements [SKOS-UCR].

This Primer, together with theSKOS Reference [SKOS-REFERENCE], replaces the earlierSKOS Core Guide [SWBP-SKOS-CORE-GUIDE] and theSKOS Core Vocabulary Specification [SWBP-SKOS-CORE-SPEC], which are nowdeprecated.

The essential features of the SKOS model are explained in Section 2. Here,the reader is presented with the set of vocabulary elements that are mostcommonly used for representing KOSs. In Section 3, the reader is shown how toadd value to these representations, either by linking them together or byrelating them to other kinds of Semantic Web resources. It is expected thatmany SKOS applications will employ some of the features presented in Section3. Section 4 is focused on more-advanced representation needs, which arelikely to be required for a limited number of SKOS applications. Section 5discusses the use of SKOS in conjunction with other modeling approaches,specifically OWL.

About Examples in this Primer

Most of the examples in this guide are given as a serialization of RDFgraphs using the Turtle syntax for RDF [TURTLE]. Examples serialized as Turtle appear incode lines such as:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.@prefix ex: <http://www.example.com/>.ex:aResource ex:aProperty ex:anotherResource;  ex:anotherProperty "An RDF Literal"@en.

The above is equivalent to the following expression, in the RDF/XMLreference syntax [RDF/XML-SYNTAX]:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"          xmlns:ex="http://www.example.com/"><rdf:Description rdf:about="http://www.example.com/aResource">  <ex:aProperty rdf:resource="http://www.example.com/anotherResource"/>  <ex:anotherProperty xml:lang="en">An RDF Literal</ex:anotherProperty></rdf:Description></rdf:RDF>

For the sake of brevity a number of namespace declarations are omittedfrom the examples. This applies to standard namespaces (SKOS, RDF/RDFS[RDF-PRIMER], OWL [OWL] and Dublin Core [DC]) but also to the ones that are coined for theexamples. Generally, these namespaces could be declared as in the followingcode:

@prefix skos: <http://www.w3.org/2004/02/skos/core#> .@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .@prefix owl: <http://www.w3.org/2002/07/owl#> .@prefix dct: <http://purl.org/dc/terms/> .@prefix foaf: <http://xmlns.com/foaf/0.1/> .@prefix ex: <http://www.example.com/> .@prefix ex1: <http://www.example.com/1/> .@prefix ex2: <http://www.example.com/2/> .

2 SKOS Essentials

This section introduces the core of the SKOS model, namely the featuresthat are needed to represent most KOSs, as observed in the majority of usecases [SKOS-UCR].

In basic SKOS,conceptual resources (concepts)can be identified with URIs,labeled with lexicalstrings in one or more natural languages,documented with various types of note,semantically related to each other in informal hierarchiesand association networks and aggregated intoconceptschemes.

2.1 Concepts

The fundamental element of the SKOS vocabulary is theconcept.Concepts are theunits of thought [WillpowerGlossary]—ideas, meanings, or(categories of) objects and events—which underlie many knowledgeorganization systems [SKOS-UCR]. Assuch, concepts exist in the mind as abstract entities which are independentof the terms used to label them.

SKOS introduces the classskos:Concept,which allows implementors to assert that a given resource is a concept. Thisis done in two steps:

1. by creating (or reusing) a Uniform Resource Identifier (URI [URI]) to uniquely identify the concept.
2. by asserting in RDF, using the propertyrdf:type, that the resource identified by this URI is of typeskos:Concept.

For example:

<http://www.example.com/animals> rdf:type skos:Concept.

This can also be represented in Turtle more compactly using the namespaceprefixex defined above:

ex:animals rdf:type skos:Concept.

Using SKOS to publish concept schemes makes it easy to reference theconcepts in resource descriptions on the Semantic Web. Implementors areencouraged to use HTTP URIs when minting concept URIs since they areresolvable to representations that can be accessed using standard Webtechnologies. For more information about URIs on the Semantic Web, seeCool URIs for the Semantic Web [COOLURIS] andBest Practice Recipes forPublishing RDF Vocabularies [RECIPES].

2.2 Labels

The first characterizations of concepts are the expressions that are usedto refer to them in natural language: theirlabels. SKOS providesthree properties to attach labels to conceptual resources:skos:prefLabel,skos:altLabelandskos:hiddenLabel.Each property implies a specific status for the label it introduces, rangingfrom a strong, univocal denotation relationship, to a string to aid inlookup. These properties are formally defined as being pairwise disjoint.This means, for example, that it is an error if a concept has a same literalboth as its preferred label and as an alternative label.

As specified inSection 5 of theSKOS Reference,skos:prefLabel,skos:altLabel andskos:hiddenLabel provide simplelabels. They are all sub-properties ofrdfs:label, andare used to link askos:Concept to anRDF plainliteral, which is a character string (e.g."love") combinedwith an optional language tag (e.g."en-US") [RDF-CONCEPTS].

2.2.1 Preferred Lexical Labels

Theskos:prefLabelproperty makes it possible to assign a preferred lexical label to a resource.Terms used asdescriptors in indexing systems [WillpowerGlossary] will for instance berepresented using this property, as in the following example:

ex:animals rdf:type skos:Concept;  skos:prefLabel "animals".

RDF plain literals are formally defined as character strings with optionallanguage tags. SKOS thereby enables a simple form of multilingual labeling.This is done by using the language tag of a lexical label to restrict itsscope to a particular language. The following example illustrates how aconcept is given one preferred label in English and another in French:

ex:animals rdf:type skos:Concept;  skos:prefLabel "animals"@en;  skos:prefLabel "animaux"@fr.

Note that the notion ofpreferred label implies that a resourcecan only have one such label per language tag, as explained inSection 5 of theSKOS Reference [SKOS-REFERENCE].

Following common practice in KOS design, the preferred label of a conceptmay also be used to unambiguously represent this concept within a KOS and itsapplications. So even though the SKOS data model does not formally enforceit, it is recommended that no two concepts in the same KOS be given the samepreferred lexical label for any given language tag.

2.2.2 Alternative Lexical Labels

Theskos:altLabelproperty makes it possible to assign an alternative lexical label to aconcept. This is especially helpful when assigning labels beyond the one thatis preferred for the concept, for instance when synonyms need to berepresented:

ex:animals rdf:type skos:Concept;  skos:prefLabel "animals"@en;  skos:altLabel "creatures"@en;  skos:prefLabel "animaux"@fr;  skos:altLabel "créatures"@fr.

Note that representation of synonyms for preferred labels is not the onlyuse forskos:altLabel.Near-synonyms, abbreviations andacronyms can be represented the same way:

ex:fao rdf:type skos:Concept;  skos:prefLabel "Food and Agriculture Organization"@en;  skos:altLabel "FAO"@en.

Note on upward posting: It is also possibleto useskos:altLabel to represent cases ofupwardposting [ISO-2788]. That is, when aconcept aggregates more-specialized notions that are not explicitlyintroduced as concepts in the considered KOS:

ex:rocks rdf:type skos:Concept;  skos:prefLabel "rocks"@en;  skos:altLabel "basalt"@en;  skos:altLabel "granite"@en;  skos:altLabel "slate"@en.

However, even though SKOS is not intended to replace existingguides for KOS design [ISO-2788,BS8723-2], the reader should be aware that upwardposting is not recommended. A more appropriate KOS for this domain wouldintroduce askos:Concept for each kind of rock considered(basalt, granite and slate) and assert it as a narrower concept ofex:rock.

2.2.3 Hidden Lexical Labels

Ahidden lexical label, represented by means of theskos:hiddenLabelproperty, is a lexical label for a resource, where a KOS designer would likethat character string to be accessible to applications performing text-basedindexing and search operations, but wouldnot like thatlabel to be visible otherwise. Hidden labels may for instance be used toinclude misspelled variants of other lexical labels. For example:

ex:animals rdf:type skos:Concept;  skos:prefLabel "animaux"@fr;  skos:altLabel "bêtes"@fr;  skos:hiddenLabel "betes"@fr.

2.3 Semantic Relationships

In KOSssemantic relations play a crucial role for definingconcepts. The meaning of a concept is defined not just by thenatural-language words in its labels but also by its links to other conceptsin the vocabulary. Mirroring the fundamental categories of relations that areused in vocabularies such as thesauri [ISO2788], SKOS supplies three standardproperties:

• skos:broader andskos:narrower enable the representation of hierarchical links, such as the relationship between onegenre and its more specificspecies, or, depending on interpretations, the relationship between onewhole and itsparts;
• skos:related enables the representation of associative (non-hierarchical) links, such as the relationship between one type ofevent and a category of entities which typicallyparticipate in it. Another use forskos:related is between two categories where neither is more general or more specific. Note thatskos:related enables the representation of associative (non-hierarchical) links, which can also be used to represent part-whole links that are not meant as hierarchical relationships.

2.3.1 Broader/Narrower Relationships

To assert that one concept is broader in meaning (i.e. more general) thananother, theskos:broaderproperty is used. Theskos:narrowerproperty is used to assert the inverse, namely when one concept is narrowerin meaning (i.e. more specific) than another. For example:

ex:animals rdf:type skos:Concept;  skos:prefLabel "animals"@en;  skos:narrower ex:mammals.ex:mammals rdf:type skos:Concept;  skos:prefLabel "mammals"@en;  skos:broader ex:animals.

As is often the case in KOS, a SKOS concept can be attached to severalbroader concepts at the same time. For example, a conceptex:dogcould have bothex:mammals andex:domesticatedAnimals as broader concepts.

Note onskos:broader direction:for historic reasons, the name of theskos:broader property (theword "broader") does not provide an explicit indication of its direction. Theword "broader" should read here as "has broader concept"; the subject of askos:broader statement is the more specific concept involved inthe assertion and its object is the more generic one.

Note on implicitskos:broader/skos:narrower statements: thepropertiesskos:broader andskos:narrower are eachother's inverse. Whenever a concept X is broader than another concept Y, thenY is a narrower concept of X according to the SKOS data model [SKOS-REFERENCE]. This can be useful formaking SKOS representations more efficient by limiting the information theycontain. In the above example, for instance, the statementex:mammalsskos:broader ex:animals can be left out if, before using the conceptscheme data, an OWL reasoner is used to infer it from the statementex:animals skos:narrower ex:mammals.

In many cases, hierarchical relations in a concept scheme can beconsidered astransitive[OWL]. Ifex:animalsis broader thanex:mammals, which is itself broader thanex:cats, it makes sense to assert thatex:animalsis broader thanex:cats. However, there are "dirtier"hierarchies, especially in KOSs different from standard well-designedthesauri, where such a feature would not be judged appropriate. Consider forinstance a case whereex2:vehicles is said to be broader thanex2:cars, which is itself asserted to be broader thanex2:wheels. It may be problematic if "wheels" is automaticallyinferred to be a narrower concept with respect to "vehicles". SKOSanticipates such problems bynot definingskos:broader andskos:narrower as generallytransitive properties. The reader interested in representing "transitivehierarchies" is encouraged to readSection4.5, which presents a way to do this while retaining compatibility withthe semantics ofskos:broader defined in this section.

Note on not transitive vs. intransitive: theSKOS model does not state thatskos:broader andskos:narrower are transitive. Yet this does not imply that theseproperties areintransitive. Consider a conceptcatswhich is narrower than a conceptmammals, itself narrower thananimals: one can assert thatcats is narrower thananimals as well, while staying compatible with the SKOS model.Not specifyingskos:broader as transitive implies that no newskos:broader statement can beinferred betweencats andanimals by applying SKOS axioms. This doesnot prevent the publishers of a SKOS concept scheme fromasserting hierarchical statements that reflect a locally transitivebehaviour.

Similarly, SKOS does not assume that hierarchical relations are by defaultirreflexive. In many thesaurus guidelines, it is prohibited to have a conceptbroader than itself. However, in specific cases beyond classical thesauri,some reflexiveskos:broader statements may occur. Consider theconversion of an existing RDFS/OWL ontology into a SKOS concept scheme. Insuch a case, it is legitimate that everyrdfs:subClassOfstatement will be re-interpreted as askos:broader statement.However,rdfs:subClassOf is a reflexive property, which meansthat for every classC, the statementC rdfs:subClassOfC istrue[OWL]. In this case every conceptwould therefore have itself among its broader concepts.

Not covered in basic SKOS is the distinction between types of hierarchicalrelation: for example, instance-class and part-whole relationships. Theinterested reader is referred toSection4.7, which describes how to create specializations of semantic relationsto deal with this issue.

2.3.2 Associative Relationships

To assert an associative relationship between two concepts,skos:relatedcan be used:

ex:birds rdf:type skos:Concept;  skos:prefLabel "birds"@en;  skos:related ex:ornithology.ex:ornithology rdf:type skos:Concept;  skos:prefLabel "ornithology"@en.

As described in theSKOS Reference [SKOS-REFERENCE], theskos:related property issymmetric[OWL]. From the above RDF graph,for instance, it follows thatex:ornithology is the subject of askos:related statement that hasex:birds as anobject.

Note on (non-)transitivity ofskos:related: The reader should be aware that in theSKOS data modelskos:related is not defined as a transitiveproperty. A transitiveskos:related could have unwantedconsequences, as in the following example:

ex:renaissance skos:related ex:humanism.ex:humanism skos:related ex:philosophicalAnthropology.ex:philosophicalAnthropology skos:related ex:philosophyOfMind.ex:philosophyOfMind skos:related ex:cognitiveScience.

Shouldskos:related be transitive,ex:renaissance would be thendirectly related toex:cognitiveScence. While every individual statement makessense, the inferred statement may not fit what the designer of the KOSoriginally intended.

Note on mixing hierarchy with association:The transitive closure ofskos:broader is disjoint fromskos:related. If resources A and B are related viaskos:related, there must not be a chain ofskos:broader relationships from A to B. The same holds ofskos:narrower.

2.4 Documentary Notes

Semantic relationships are crucial to the definition of concepts, as manyKOS guidelines emphasize it. However, next to these structuredcharacterizations, concepts sometimes have to be further defined usinghuman-readable ("informal") documentation, such asscope notes ordefinitions.

SKOS provides askos:note propertyfor general documentation purposes. Inspired by existing KOS guidelines, suchas [ISO2788] or [BS8723-2], this property is further specializedintoskos:scopeNote,skos:definition,skos:example, andskos:historyNote to fitmore-specific types of documentation.

skos:scopeNotesupplies some, possibly partial, information about the intended meaning of aconcept, especially as an indication of how the use of a concept is limitedin indexing practice. The following example is adapted from [ISO2788]:

ex:microwaveFrequencies skos:scopeNote     "Used for frequencies between 1GHz to 300Ghz"@en.

skos:definitionsupplies a complete explanation of the intended meaning of a concept. Thefollowing example is adapted from [ISO2788]:

ex:documentation skos:definition     "the process of storing and retrieving information     in all fields of knowledge"@en.

skos:examplesupplies an example of the use of a concept:

ex:organizationsOfScienceAndCulture skos:example     "academies of science, general museums, world fairs"@en.

skos:historyNotedescribes significant changes to the meaning or the form of a concept:

ex:childAbuse skos:historyNote     "estab. 1975; heading was: Cruelty to children [1952-1975]"@en.

In addition to these notes that are intended for users of a conceptscheme, SKOS includes two specializations ofskos:note that areuseful for KOS managers or editors:skos:editorialNote andskos:changeNote.

skos:editorialNotesupplies information that is an aid to administrative housekeeping, such asreminders of editorial work still to be done, or warnings in the event thatfuture editorial changes might be made:

ex:doubleclick skos:editorialNote "Review this term after company merger                                   complete"@en.ex:folksonomy skos:editorialNote "Check spelling with Thomas Vander Wal"@en.

skos:changeNotedocuments fine-grained changes to a concept, for the purposes ofadministration and maintenance:

ex:tomato skos:changeNote   "Moved from under 'fruits' to under 'vegetables' by Horace Gray"@en.

It is important to notice that the hierarchical link betweenskos:note and its different specializations allows all thedocumentation associated with a concept to be retrieved in a straightforwardway. Everyskos:definition is askos:note, everyskos:scopeNote is askos:note, and so on.

As illustrated above, SKOS documentation properties can be simply usedwith RDF plain literals.Section 4.2will show that there are other possible patterns, as the range of theseproperties is not be restricted to literals. One important feature of simpleliterals, however, is the ability to use language tags, as done for labelingproperties. Documentation may thus be provided in multiple languages:

ex:pineapples rdf:type skos:Concept;  skos:prefLabel "pineapples"@en;  skos:prefLabel "ananas"@fr;  skos:definition "The fruit of plants of the family Bromeliaceae"@en;  skos:definition        "Le fruit d'une plante herbacée de la famille des broméliacées"@fr.

Before concluding this section, it is important to note that other,non-SKOS properties could be used to document concepts. Thedct:creator propertyfrom Dublin Core [DC] can for instance be usedto point to a person that created the concept:

ex:madagascarFishEagle dct:creator [ foaf:name "John Smith" ].

2.5 Concept Schemes

Concepts can be created and used as stand-alone entities. However,especially in indexing practice, concepts usually come in carefully compiledvocabularies, such as thesauri or classification schemes. SKOS offers themeans of representing such KOSs using theskos:ConceptSchemeclass.

The following example shows how to define a concept scheme resource(representing a thesaurus) and to describe that resource using thedct:title anddct:creator propertiesfrom Dublin Core [DC]:

ex:animalThesaurus rdf:type skos:ConceptScheme;  dct:title "Simple animal thesaurus";  dct:creator ex:antoineIsaac.

Once the concept scheme resource has been created, it can be linked withthe concepts it contains using theskos:inSchemeproperty:

ex:mammals rdf:type skos:Concept;  skos:inScheme ex:animalThesaurus.ex:cows rdf:type skos:Concept;  skos:broader ex:mammals;  skos:inScheme ex:animalThesaurus.ex:fish rdf:type skos:Concept;  skos:inScheme ex:animalThesaurus.

In order to provide an efficient access to the entry points ofbroader/narrower concept hierarchies, SKOS defines askos:hasTopConceptproperty. This property allows one to link a concept scheme to the (possiblymany) most general concepts it contains, as in the (continued) animalthesaurus example:

ex:animalThesaurus rdf:type skos:ConceptScheme;  skos:hasTopConcept ex:mammals;  skos:hasTopConcept ex:fish.

Concept schemes are designed to represent traditional vocabularies, anddesigners are encouraged to follow existing KOS guidelines (e.g., [ISO2788] or [BS8723-2]) when compiling a SKOS concept scheme.For example, as described inSection 2.2, it isrecommended that no two concepts have the same preferred lexical label in agiven language when they belong to the same concept scheme.

The reader should however be aware that there are some subtle differencesbetween SKOS concept schemes and "traditional" KOSs, mainly due to theSemantic Web context for SKOS.Section 4.6 of theSKOS Reference [SKOS-REFERENCE] gives an account of thesedifferences. One important feature of SKOS is that it is possible for thesame concept to be linked to several concept schemes, using theskos:inScheme property. This will be discussed in the nextsection.

Finally, it is important to notice that the SKOS vocabulary only offerslimited support for containment of KOS information in a concept scheme.skos:inScheme andskos:hasTopConcept link conceptschemes and concepts. Yet, there is no mechanism in SKOS to record that aspecific statement concerning these concepts, e.g. askos:broader assertion, pertains to a specific concept scheme,whereas a KOS is usually seen as consisting of both its concepts and thelinks that define them. The interested reader is referred toSection 5.3 for a discussion on this topic.

3 Networking Knowledge Organization Systems on theSemantic Web

Representing a KOS with SKOS not only serves as a publication mechanism,but also allows it to participate in a network of concept schemes. On theSemantic Web the true potential of data is unleashed when it is interlinked.As concepts from different concept schemes are connected together they beginto form a distributed, heterogeneous global concept scheme. A web of conceptschemes can serve as the foundation for new applications that allowmeaningful navigation between KOSs. This section introduces the SKOS featuresthat enable the interlinking of concept schemes and explains how to relateconceptual resources to other resources on the Semantic Web.

3.1 Mapping Concept Schemes

Every SKOS concept is assigned a URI [COOLURIS], which makes it possible tounambiguously reference a concept in any SKOS application. This can beespecially useful for establishing semantic relations between pre-existingconcepts. Suchmappings are crucial for applications such asinformation retrieval tools that use several KOSs at the same time, wherethese KOSs have overlapping scopes and need to be semantically reconciled;examplescan be found in theSKOS Use cases and Requirements document[SKOS-UCR].

A crucial feature of mapping is the possibility to state that two conceptsfrom different schemes have comparable meanings, and to specify how thesemeanings compare, even though they come from different contexts and possiblyfollow different modeling principles [BS8723-4]. Conceptual mappings are expected to bea key advantage of making KOSs available on the Semantic Web using SKOS.

SKOS provides several properties that map concepts between differentconcept schemes. This can be done by asserting that two concepts have asimilar meaning, using theskos:exactMatchandskos:closeMatchproperties. Two concepts from different concept schemes can also be mappedusing properties that parallel the semantic relations introduced inSection 2.3:skos:broadMatch,skos:narrowMatchandskos:relatedMatch.

Consider the following example, where two concept schemes representdifferent views on animals:

ex1:referenceAnimalScheme rdf:type skos:ConceptScheme;   dct:title "Extensive list of animals"@en. ex1:animal rdf:type skos:Concept;   skos:prefLabel "animal"@en;   skos:inScheme ex1:referenceAnimalScheme.ex1:platypus rdf:type skos:Concept;   skos:prefLabel "platypus"@en;   skos:inScheme ex1:referenceAnimalScheme.ex2:eggSellerScheme rdf:type skos:ConceptScheme;   dct:title "Obsessed egg-seller's vocabulary"@en. ex2:eggLayingAnimals rdf:type skos:Concept;   skos:prefLabel "animals that lay eggs"@en;   skos:inScheme ex2:eggSellerScheme.ex2:animals rdf:type skos:Concept;   skos:prefLabel "animals"@en;   skos:inScheme ex2:eggSellerScheme.ex2:eggs rdf:type skos:Concept;   skos:prefLabel "eggs"@en;   skos:inScheme ex2:eggSellerScheme.

It is possible to map the concepts inex1:referenceAnimalScheme to the concepts inex2:eggSellerScheme by using the mapping assertions below:

 ex1:platypus skos:broadMatch ex2:eggLayingAnimals. ex1:platypus skos:relatedMatch ex2:eggs. ex1:animal skos:exactMatch ex2:animals.

Askos:closeMatch assertion indicates that two concepts aresufficiently similar that they can be used interchangeably in applicationsthat consider the two concept schemes they belong to. However,skos:closeMatch is not defined as transitive, which preventssuch similarity assessments to propagate beyond these two schemes. If aconceptex1:A is a close match for another conceptex2:B which is itself a close match forex3:C, itdoes not follow from the SKOS data model thatex1:A is a close match forex3:C.

skos:exactMatch also indicates semantic similarity—it is asub-property ofskos:closeMatch. However, it denotes an evenhigher degree of closeness: the two concepts have equivalent meaning, and thelink can be exploited across a wider range of applications and schemes.skos:exactMatch is indeed transitive: if a conceptex1:A is an exact match for another conceptex2:Bwhich is itself an exact match forex3:C, itdoes follow from the SKOS data model thatex1:Ais an exact match forex3:C.

Note onskos:exactMatch vs.owl:sameAs: SKOS providesskos:exactMatchto map concepts with equivalent meaning, and intentionally does not useowl:sameAs fromthe OWL ontology language [OWL].When two resources are linked withowl:sameAs they areconsidered to be the same resource, and triples involving these resources aremerged. This does not fit what is needed in most SKOS applications. In theabove example,ex1:animal is said to be equivalent toex2:animals. If this equivalence relation were represented usingowl:sameAs, the following statements would hold forex:animal:

ex1:animal rdf:type skos:Concept;   skos:prefLabel "animal"@en;   skos:inScheme ex1:referenceAnimalScheme.   skos:prefLabel "animals"@en;   skos:inScheme ex2:eggSellerScheme.

This would makeex:animal inconsistent, as aconcept cannot possess two different preferred labels in the same language.Had the concepts been assigned other information, such as semanticrelationships to other concepts, or notes, these would be merged as well,causing these concepts to acquire new meanings.

By convention, mapping properties are used to represent links that havethe same intended meaning as the "standard" semantic properties, but with adifferent application scope. One might say that mapping relationships arelessinherent to the meaning of the concepts they involve. From thepoint of view of the original designer of a mapped KOS, they might evensometimes be wrong.

Mapping properties are expected to be useful inspecificapplications that use multiple, conceptually overlapping KOSs. By convention,mapping relationships are expected to be asserted between concepts thatbelong to different concept schemes.

The reader should be aware that according to the SKOS data model, themapping properties that "mirror" a given semantic relation property are alsosub-properties of it in the RDFS sense. For instance,skos:broadMatch is a sub-property ofskos:broader.Consequently, every assertion ofskos:broadMatch between twoconcepts leads by inference to asserting askos:broader betweenthese concepts.

3.2 Re-using and Extending Concept Schemes

Linking concepts by means of mappings is not the only way to interlinkconcept schemes. The use of URIs on the Semantic Web allows resources to beshared and reused in a distributed fashion. As a result it is possible for aSKOS concept to participate in several concept schemes at the same time. Forexample, a SKOS publisher can choose to locally extend an existing conceptscheme by declaring any new concepts that may be needed and simplylinking to concepts that have already been defined in the existingscheme.

Extension of a KOS can be especially useful when its designers (orthird-party KOS publishers) want to achieve a better coverage of a domain orsub-domain, while following the principles that guided the design of theexisting KOS—e.g., by re-using some of its concepts. Explicit KOS extensionand re-use can also be used as a modularization mechanism, when a family ofarticulated KOSs (for instance microthesauri that belong to an overarchingvocabulary) is designed to cover several domains and its designers want toallow specific applications to operate on given subsets of concepts.

A new concept scheme can re-use existing concepts using theskos:inSchemeproperty. Consider the example below, where a first concept scheme foranimals defines a concept for "cats":

ex1:referenceAnimalScheme rdf:type skos:ConceptScheme;   dct:title "Reference list of animals"@en. ex1:cats rdf:type skos:Concept;   skos:prefLabel "cats"@en;   skos:inScheme ex1:referenceAnimalScheme.

The creator of another concept scheme devoted to cat descriptions canfreely include the referenceex1:cats concept in her scheme, andthen reference it as follows:

ex2:catScheme rdf:type skos:ConceptScheme;   dct:title "The Complete Cat Thesaurus"@en. ex1:cats skos:inScheme ex2:catScheme.ex2:abyssinian rdf:type skos:Concept;   skos:prefLabel "Abyssinian Cats"@en;   skos:broader ex1:cats;   skos:inScheme ex2:catScheme.ex2:siamese rdf:type skos:Concept;   skos:prefLabel "Siamese Cats"@en;   skos:broader ex1:cats;   skos:inScheme ex2:catScheme.

Note that the information source defining the new concept scheme does notreplicate information about theex1:cats concept, such as itspreferred label. Assumingex1:cats has been published, aSemantic Web application is able to retrieve the information for this conceptby simply resolving the concept's URI(http://www.example.com/1/cats).

Note onowl:imports and re-usingKOSs: Theowl:importsproperty provides a mechanism for importing the assertions of one OWLontology into another.owl:imports may be used with SKOSvocabularies to provide a special case of re-use/extension where a conceptscheme "imports" another concept scheme as a whole. To continue the exampleabove, this is achieved by including the following statement in the sourcedefiningex2:catScheme:

ex2:catScheme owl:imports ex1:referenceAnimalScheme.

Usingowl:imports in this way has someramifications. First, the domain and range ofowl:imports isowl:Ontology, whileskos:ConceptScheme is definedas anowl:Class. Thus asserting that a concept scheme importsanother viaowl:imports leads to the consequence that theinstances ofskos:conceptScheme involved in the import are alsoinferred to be instances ofowl:Ontology. This in turn resultsin an OWL Full ontology (due to the dual use of a URI as a class andontology, seeSection 4.2 oftheOWL Semantics document [OWL-SEMANTICS]).

Second, under the OWL Full semantics (seeSection 5.3 oftheOWL Semantics [OWL-SEMANTICS]), the intended interpretationofowl:imports is that the RDF graph retrieved from the importedURI is added to the importing graph. Users should be aware of this, and anyalternative interpretations should be avoided. In particular, there is nological dependency betweenskos:inScheme andowl:imports: the use ofowl:imports will not resultin the presence of anyskos:inScheme statements other than theones already asserted in the imported graph. If we consider the exampleabove,owl:imports has been used to state that one conceptscheme logically imports another. But even thoughex1:referenceAnimalScheme contains the triple

ex1:Elephant skos:inScheme ex1:referenceAnimalsScheme.

the triple

ex1:Elephant skos:inScheme ex2:catScheme.

shouldnot be inferred to be present in thegraph definingex2:catScheme.

If an application is concerned with practical provenance orownership information, additional steps may be required in order to maintainthe provenance or assert the authority of imported triples, as mentioned inSection 5.3.

3.3 Subject Indexing and SKOS

Though formally not belonging to the features defining a KOS, the linkbetween a concept and the resources which are about this concept isfundamental in many KOS applications, such as document indexing and documentretrieval. This becomes even more important in a Semantic Web context, wherethere is a crucial need to annotate documents with conceptual units whichdefine their subject.

While the SKOS vocabulary itself does not include a mechanism forassociating an arbitrary resource with askos:Concept,implementors can turn to other vocabularies. Dublin Core, for instance,provides adct:subject property[DC]:

ex1:platypus rdf:type skos:Concept;   skos:prefLabel "platypus"@en.<http://en.wikipedia.org/wiki/Platypus> rdf:type foaf:Document;   dct:subject ex1:platypus.

Note that a single resource can have several subjects, and hence beinvolved in severaldct:subject statements. These subjects canclearly come from different concept schemes, resulting for instance from adistributed annotation process.

4 Advanced SKOS: When KOSs are not Simple Anymore

Beyond the above mentioned features, SKOS proposes a number of vocabularyelements or guidelines that deal with more-advanced representation needs,making SKOS compatible with a broad range of KOS modeling approaches. Theseare especially designed to meet requirements which were raised in theSKOS Use Cases and Requirements [SKOS-UCR], but which were only present in asmaller number of use cases:

• Grouping of concepts based on specific criteria,
• Advanced documentation by means of complex resources,
• Establishing relationships between labels of concepts,
• Creation of complex concepts from simple ones (coordination),
• Accessing transitive hierarchical relationships,
• Representing notations for concepts.

This section concludes with a general note on the extensibility of theSKOS model, paving the way for even more specialized refinements of thevocabulary presented in this Primer.

4.1 Collections of Concepts

SKOS makes it possible to define meaningful groupings or "collections" ofconcepts. Such groupings are normally rendered in thesauri as in thefollowing example:

milk  <milk by source animal>    cow milk    goat milk    buffalo milk

These collections can be used to represent "arrays" in thesaurusterminology, in which the term "milk by source animal" is a "node label"[WillpowerGlossary]. There isconsensus that a node label doesnot represent a label for aconcept in its own right. Therefore, specific entities have to be introducedto represent them.

Labeled Collections

To correctly model such concept collection structures, SKOS introduces askos:Collectionclass. Instances of this class group specific concepts by means of theskos:memberproperty, as in the following example:

ex:milk rdf:type skos:Concept;  skos:prefLabel "milk"@en.ex:cowMilk rdf:type skos:Concept;   skos:prefLabel "cow milk"@en;  skos:broader ex:milk.ex:goatMilk rdf:type skos:Concept;   skos:prefLabel "goat milk"@en;  skos:broader ex:milk.ex:buffaloMilk rdf:type skos:Concept;   skos:prefLabel "buffalo milk"@en;  skos:broader ex:milk._:b0 rdf:type skos:Collection;   skos:prefLabel "milk by source animal"@en;   skos:member ex:cowMilk;   skos:member ex:goatMilk;   skos:member ex:buffaloMilk.

Note that in the example above the collection was defined as a blank node,i.e. no defined URI was allocated. URIs may be allocated to collections, butusually this is not necessary. Also,skos:prefLabel has beenused to assign a lexical label to the Collection, as this property (as otherSKOS labeling properties) can be used with non-conceptual resources.

Ordered Collections

Sometimes it is important to capture the order of concepts in acollection, such as when concepts are listed in alphabetical or chronologicalorder. To define an ordered collection of concepts theskos:OrderedCollectionclass is used, together with theskos:memberListproperty. This property links an instance ofskos:OrderedCollection to a (possibly blank) node of typerdf:List, following the pattern that enables the definition ofRDFcollections [RDF-PRIMER]. Forexample:

ex:infants rdf:type skos:Concept;   skos:prefLabel "infants"@en.ex:children rdf:type skos:Concept;   skos:prefLabel "children"@en.ex:adults rdf:type skos:Concept;   skos:prefLabel "adults"@en._:b0 rdf:type skos:OrderedCollection;   skos:prefLabel "people by age"@en;   skos:memberList _:b1._:b1 rdf:first ex:infants;   rdf:rest _:b2._:b2 rdf:first ex:children;   rdf:rest _:b3._:b3 rdf:first ex:adults;   rdf:rest rdf:nil.

SKOS Collections, Semantic Relations andSystematic Displays

Note that, according to the SKOS data model, collections are disjoint fromconcepts. It is therefore impossible to use SKOS semantic relations (seeSection 2.3) to have a collection directly fit into a SKOSsemantic network. In other words, grouping concepts into collections does notreplace assertions about the concepts' place in a concept scheme. Forinstance, in the above "milk" example, all source-defined milks must beexplicitly attached to a more genericex:milk using theskos:broader property:

ex:cowMilk skos:broader ex:milk.ex:goatMilk skos:broader ex:milk.ex:buffaloMilk skos:broader ex:milk.

A systematic (hierarchical) display can then be generated including theconcept grouping "milk by source animal", as presented in the exampleintroducing this sub-section. Theskos:broader hierarchy and thecollection membership information can be used for this, but the process stillrequires a dedicated algorithm, the implementation of which is left tospecific applications.

One may wonder whether using collections is desirable, as they addcomplexity to the representations applications have to manipulate. In fact,for some cases, e.g. when KOSs are mainly intended as navigation hierarchies,it seems more intuitive to represent "node labels" or "guide terms" asinstances ofskos:Concept, and to use normal semanticrelationships for linking them to other concepts. Take the following variantof the "milk" example:

ex3:milkBySourceAnimal rdf:type skos:Concept;   skos:prefLabel "milk by source animal"@en;   skos:broader ex3:milk;   skos:narrower ex3:cowMilk;   skos:narrower ex3:goatMilk;   skos:narrower ex3:buffaloMilk.

The choice between the two representation options remains open, dependingon the application at hand. Readers should however be aware that not usingcollections, even if that is more intuitive, may result in a harmful loss ofsemantic accuracy. For many description applications, for instance, "nodelabels" are entities of a really specific nature, and must not be used asobject indices alongside "normal" concepts. Representing them as mereconcepts is therefore clearly not a best practice.

4.2 Advanced Documentation Features

As shown inSection 2.4, SKOS allowsconcepts to be annotated by attaching various notes to them. It is worthnoticing that theSKOSReference does not restrict the range of resources that assertions canuse in the object position. This leads to different usage patterns, three ofwhich are explained—and recommended—in this document.

Here, documentation statements have simple RDF literals as objects, asillustrated byall examples ofSection2.4. This is the simplest way to document concepts, and it is expected tofit most common applications.

In this second pattern, the object of a documentation statement consistsof a general non-literal RDF node—that is, a resource node (possibly blank)that can be the subject of further RDF statements [RDF-PRIMER]. This is especially useful torepresent with RDF more information about the documentation itself, such asits creator or creation date. This is typically done using the RDFrdf:value utilityproperty, as in the following example, which uses a blank node:

ex:tomato skos:changeNote [  rdf:value "Moved from under 'fruits' to under 'vegetables'"@en;  dct:creator ex:HoraceGray;   dct:date "1999-01-23" ].ex:HoraceGray rdf:type foaf:Person; foaf:name "Horace Gray".

Documentation as a Document Reference

A third option consists of introducing, as the object of a documentationstatement, the URI of adocument, for instance a Web page. Note thatthis pattern, closely related to the previous one, also allows the definitionof further metadata for this document using RDF:

ex:zoology skos:definition ex:zoology.txt.ex:zoology.txt dct:creator ex:JohnSmith.

4.3 Relationships between Labels

Some applications require the creation of explicit links between thelabels associated with concepts. For example, consider the relationshipbetween a preferred label for a concept "Corporation" and its abbreviation"Corp." coined as an alternative label, or a translation link between twolabels in different languages:"Cow"@en and"Vache"@fr. The use of SKOS lexical labeling properties, e.g.skos:prefLabel, is restricted to RDF literals. Therefore theselabels cannot be the subject of an RDF statement, and a direct relationshipcannot be asserted between them.

To solve this representation issue, the SKOS vocabulary has been augmentedwith an optional extension for labels,SKOS-XL [SKOS-REFERENCE]. This extension introducesaskosxl:Labelclass that allows labels to be treated as first-order RDF resources. Eachinstance of this class shall first be attached to a single RDF literal viatheskosxl:literalForm property. Consider the example where theconcept "Food and Agriculture Organization" is labeled by both the officialname and the acronym of the institution. The two labels can be represented inthe following way:

ex:FAOlabel1 rdf:type skosxl:Label;  skosxl:literalForm "Food and Agriculture Organization"@en.ex:FAOlabel2 rdf:type skosxl:Label;  skosxl:literalForm "FAO"@en.

skosxl:Label instances can then be related to concepts usingproperties (skosxl:prefLabel,skosxl:altLabel,skosxl:hiddenLabel)that mirror the standardliteral-based labelingconstructs. Finally, these instances can be linked together byskosxl:labelRelationstatements:

ex:FAO rdf:type skos:Concept;  skosxl:prefLabel ex:FAOlabel1;   skosxl:altLabel ex:FAOlabel2.ex:FAOlabel2 skosxl:labelRelation ex:FAOlabel1.

Such a solution is however not complete: an "acronym-sensitive"application would miss the actual information that the two labels are indeedin anacronymy relationship. Such an application would also miss thedirection of the link. SKOS-XL users are therefore encouraged tospecializeskosxl:labelRelation so as to fit theirapplication-specific requirements, as in the following:

ex:isAcronymOf rdfs:subPropertyOf skosxl:labelRelation.ex:FAOlabel2 ex:isAcronymOf ex:FAOlabel1.

Note that the SKOS-XL data model ensures that using such a pattern remainscompatible with the standard SKOS labeling practice. If an instance ofskosxl:Label is attached to a concept by, say, askosxl:altLabel statement, it follows from the SKOS-XL datamodel that the literal form of theskosxl:Label instance isrelated to this concept by a standardskos:altLabel statement.In the above example,ex:FAO therefore has"FAO"@en" as alternative (literal) label.

4.4 Coordinating Concepts

Indexing practices involving thesauri and other KOSs often include thenotion ofcoordination. Coordination is an activity in whichconcepts from a KOS are combined. In general there are two kinds ofcoordination:pre-coordinationandpost-coordination[WillpowerGlossary]. The keydistinction between the two hinges on when the actual coordination occurs inrelation to an information retrieval event.

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

Post-coordination on the other hand is performed as part of an informationretrieval task—for example, if a given document is indexed with twodistinct concepts "Bicycles" and "Repairing" and a user decides to perform asearch for all documents that are indexed with "Bicycles" and "Repairing".

Post-coordination as an information retrieval activity lends itself toindirect representation as a SPARQL query to access RDF data[SPARQL]. For example, given two distinctconcepts:

ex:bicycles skos:prefLabel "Bicycles"@en.ex:repairing skos:prefLabel "Repairing"@en.

one could construct a SPARQL query to return only the documents that areindexed with both concepts

SELECT ?documentWHERE {  ?document dct:subject ex:bicycles.  ?document dct:subject ex:repairing.}

However the SKOS vocabulary itself does not provide any mechanism forexpressing that a given concept consists of a pre-coordination of otherconcepts. Of course it is perfectly feasible toextend SKOS to establish a pattern forrepresenting coordinated concepts. For example it has beensuggestedthat a new property such asex:coordinationOf could beestablished:

ex:coordinationOf a rdf:Property;  rdfs:domain skos:Concept;  rdfs:range rdf:List.

which could then be used in assertions such as:

ex:bicyclesRepairing a skos:Concept;  ex:coordinationOf (ex:bicycles ex:repairing);  skos:prefLabel "Bicycles--Repairing"@en.

It has also been suggested that OWL itself could be used to coordinateconcepts:

ex:bicyclesRepairing a skos:Concept;  owl:intersectionOf (ex:bicycles ex:repairing);  skos:prefLabel "Bicycles--Repairing"@en.

However, established patterns for pre-coordinations of this kind have notyet emerged in the SKOS community.ex:coordinationOf (or someequivalent extension), and the ramifications ofusingSKOS with OWL have not been explored fully enough yet to warrantinclusion in the SKOS vocabulary. Rather than commit to a design pattern thathas not been proven useful, the Semantic Web Deployment Group decided topostpone the issue ofcoordination, toallow extension patterns to organically emerge as SKOS is deployed. The hopeis that as successful patterns are established, they can be published on theWeb as anextension vocabulary to SKOSand documented as a W3C Note or some equivalent.

4.5 Transitive Hierarchies

As described inSection 2.3.1, the propertiesused to represent KOS hierarchies,skos:broader andskos:narrower, are not defined as transitive. As shown in Fig.4.5.1 (i) & (ii), this means that their semantics donotsupport inferences of the type:if "animals" is broader than "mammals"and "mammals" is broader than "cats", then "animals" is broader than"cats".

Figure 4.5.1:skos:broader is nottransitive

Dotted arrows represent statements inferred from the SKOSdata model.
Solid arrows represent asserted statements.

For the applications that require such semantics—for instance to performquery expansion—SKOS features two specific properties,skos:broaderTransitiveandskos:narrowerTransitive.These are defined as transitive super-properties ofskos:broaderandskos:narrower [SKOS-REFERENCE]. This pattern enables,using a Semantic Web inferencing tool, access to the "transitive closure" ofa hierarchy expressed withskos:broader andskos:narrower.

Consider the example of Fig. 4.5.1 (i):

ex:animals skos:prefLabel "animals"@en.ex:mammals skos:prefLabel "mammals"@en;  skos:broader ex:animals.ex:cats skos:prefLabel "cats"@en;  skos:broader ex:mammals.

When reading the above triples, a reasoner makes use the definition ofskos:broaderTransitive as a super-property ofskos:broader to infer the following statements:

ex:cats skos:broaderTransitive ex:mammals.ex:mammals skos:broaderTransitive ex:animals.

The transitivity ofskos:broaderTransitive then causes thedesired statement to be inferred:

ex:cats skos:broaderTransitive ex:animals.

These two steps are showed in the following figure:

Figure 4.5.2: inferring a transitive hierarchy fromassertedskos:broader statements

Dotted arrows represent statements inferred from the SKOSdata model.
Solid arrows represent asserted statements.

The use of theskos:broaderTransitive super-property allowscommunities of practice to exploit transitive interpretations of hierarchicalnetworks as they see fit, while not interfering with the semantics ofskos:broader, which cannot enforce such transitivity.Intuitively, one can interpretskos:broader statements asexplicitly asserteddirect parent links, whileskos:broaderTransitive is used to reflect more-general (andpossibly indirect)ancestor relationships.

Note on supposed "transitivenessinheritance": the super-property link betweenskos:broader andskos:broaderTransitive may lookcounter-intuitive at first glance. Here, a non-transitive property is definedas a child of a transitive one, while not inheriting its transitiveness. Thisis however fully compliant withRDFS/OWL semantics forrdfs:subPropertyOf [OWL]: a property P is a sub-property of Q ifand only if every time P holds between two resources, then Q also holdsbetween them. This does not enforce any transitiveness inheritance: on thecontrary, the set of all couples of resources related by P (itsgraph), as a subset of Q's, is likely to miss some of the couplesthat make Q transitive.

4.6 Notations

Some KOSs, for example classification systems such as the UniversalDecimal Classification [UDC], usenotations (orcaptions) as the primary means of access tothe concepts they contain. Notations are symbols which are not normallyrecognizable as words or sequences of words in any natural language and arethus usable independently of natural-language contexts. They are typicallycomposed of digits, complemented with punctuation signs and other characters,as in the following UDC example:

512 Algebra512.6 Special branches of algebra

SKOS allows notations to be represented in two ways, depending on thepriorities of the concept scheme publisher. The first, preferred technique isto use theskos:notationproperty. This property allows a concept to be attached to anRDF typedliteral—a literal with an explicit datatype [RDF-PRIMER]. The datatype of the literalspecifies a syntax encoding scheme, which fits the usage of notations in theconcerned KOS. The value of the literal is the notation itself (in this casethe classification code itself):

ex:udc512 skos:prefLabel "Algebra"@en ;  skos:notation "512"^^ex:UDCNotation .

Section 6.5.1 oftheSKOS Reference gives more detail on how to handle datatypes[SKOS-REFERENCE]. This approachcan be especially useful if a KOS publisher wants to provide users withprocessing rules that are specific to the KOS's notation scheme. Forinstance, many classification systems have specific syntax rules which allowcomplex notations to be decomposed, leading to the linking of thecorresponding concept to other, simpler concepts. Also, this pattern can helpcreators of SKOS tools and KOS publishers who want to have notationsdisplayed in a dedicated way.

However, the management of such datatypes can be cumbersome. Further, theprevious pattern is not really needed when publishers consider the notationsthemselves to be simple language-independent labels. In such cases, it ispossible to use one SKOS labeling property, for instanceskos:prefLabel, without any language tag, as in:

ex:udc512 skos:prefLabel "Algebra"@en ;  skos:notation "512"^^ex:UDCNotation ;  skos:prefLabel "512" .

Note that it is unlikely that notations represented in such a manner willbenefit from notation-specific mechanisms (such as display procedures) inSKOS tools. By default, users should expect these notations to be treated, inaccordance with the SKOS model, as mere labels.

4.7 On Specializing the SKOS Model

SKOS is intended to serve as a common denominator between differentmodeling approaches. As such, the current vocabulary specification will allowmany existing KOSs to be ported to the Semantic Web. However, the greatvariety of KOS models makes it impossible to capture every detail of thesemodels while still retaining the first "S" ("simple") in "SKOS".

Applications that require finer granularity will greatly benefit fromSKOS's being a Semantic Web vocabulary. SKOS can indeed be seamlesslyextended to suit the specific needs of a particular KOS communitywhile retaining compatibility with applications that are based on the coreSKOS features.

This can mostly be done byspecializing existing SKOS constructsinto more-specific ones. Users can create their own properties and classesand attach them to the standard SKOS vocabulary elements by using therdfs:subPropertyOf andrdfs:subClassOf propertiesfrom the RDF Schema vocabulary [RDF-PRIMER].

The example inSection 4.3illustrates howskosxl:labelRelation can be specialized into asemantically richer property devoted to acronym link representation. Otheruses are possible, such as creating different "flavors" of the propertiesskos:broader andskos:narrower. Thesaurus standardsindeed identify a small number of kinds of hierarchical relation, such asgeneric, part-whole, or instance-class [ISO2788]. The SKOS approach allows an applicationdesigner to create new properties to capture this distinction, and to declarethem as sub-properties ofskos:broader:

ex:broaderGeneric rdfs:subPropertyOf skos:broader.ex:broaderPartitive rdfs:subPropertyOf skos:broader.ex:broaderInstantive rdfs:subPropertyOf skos:broader.

Everyex:broaderPartitive statement between two concepts, forinstance, can be formally interpreted by a proper Semantic Web reasoningengine. This interpretation will yield the inference of askos:broader statement between these concepts—a piece ofinformation which may then be exploited by basic SKOS tools.

Note on tampering with the SKOS vocabularyitself: In general, it is best to avoid stating triples where a URIfrom the SKOS vocabulary is in thesubject position. By doing so,one may alter the SKOS data model and introduce unwanted side effects. Thismay then compromise the interoperability of vocabularies. If one wants toadapt the behavior of the "built-in" vocabulary to specific cases, one shouldfirst consider introducing one's own constructs as sub-classes orsub-properties.

Of course the creators of extensions to SKOS are encouraged to publishthem, e.g., using the SKOSpublic mailinglist (public-esw-thes@w3.org). Suchextensions might correspond to shared concerns and thus be re-usable acrossdifferent applications. In turn, re-use is likely to bring communityfeedback, helping to enhance the quality of published extensions.

5 Combining SKOS with other Modeling Approaches

As seen above, SKOS is an RDF/OWL vocabulary which can be seamlesslyextended to fit specific requirements. Likewise, SKOS features can also beused on the Semantic Web as a complement to other modeling vocabularies. Thissection gives examples of re-using SKOS labeling properties to describeresources that are not necessarily SKOS concepts. It then deals with thespecific problem of articulating SKOS concepts withclasses asdefined by the ontology language OWL.

Note: this section deals with the issuesarising when an application requires SKOS features to be used in coordinationwith other modeling approaches. Users not having such a requirement may skipit.

5.1 Use of Labels Outside of SKOS

It is possible to use SKOS labeling properties to label resources that arenot of typeskos:Concept. Consider these triples that describeTim Berners-Lee:

<http://www.w3.org/People/Berners-Lee/card#i> rdf:type foaf:Person;  foaf:name "Timothy Berners-Lee";  rdfs:label "TBL";  skos:prefLabel "Tim Berners-Lee"@en.

An application that wishes to display a label for this resource is able toidentify "Tim Berners-Lee" as the preferred label instead of having to choosebetween the equally compatible labelsrdfs:label "TBL"or thefoaf:name "TimothyBerners-Lee"—these labels are compatible becausefoaf:name isa sub-property ofrdfs:label.

Another example is human-readable labels on classes, properties andindividuals in OWL ontologies, which are normally expressed usingrdfs:label alone. Consider the following triples that describehumans:

ex:Human rdf:type owl:Class;  rdfs:label "human"@en;  rdfs:label "man"@en.

An application would have difficulty determining the correct label todisplay to the user since both labels have the same weight. The semantics ofskos:prefLabel allow implementors to explicitly define thepreferred label for a given resource. In general the ability to reusevocabulary elements from SKOS and other RDF vocabularies as needed is whatgives RDF much of its expressive power.

5.2 SKOS Concepts and OWL Classes

TheSKOSReference definesskos:Concept as an OWL class [SKOS-REFERENCE]:

skos:Concept rdf:type owl:Class.

Thus, instances ofskos:Concept (e.g.ex:Painting in an art vocabulary) are in OWL termsindividuals.

ex:Painting rdf:type skos:Concept.

This raises the question whether a SKOS concept instance such asex:Painting can be treated as a class in its own right. Forexample, can users define properties ofex:painting such asex:support:

ex:support rdf:type owl:DatatypeProperty.ex:support rdfs:domain ex:Painting.

One might ask the question: why would someone want to do this? Well,conceptually a class such asskos:Concept can be seen as ametaclass: its instances are the concepts occurring in a vocabulary. So, itis conceivable that SKOS users want to specify class-level characteristics ofSKOS concepts, for example that paintings have supports or that cheese has acountry of origin.

It should be pointed out that SKOS does not take a stance with respect tothe flavor of OWL—OWL Full or OWL-DL [OWL-REFERENCE]—to be used together withSKOS. OWL Full users will be able to handle the situation above by treatinginstances of SKOS concepts explicitly as classes, e.g. by adding statementsof the form:

ex:Painting rdf:type owl:Class.

This is possible because OWL Full does not require the sets of classes andindividuals to be disjoint. People who wish to use the DL flavor of OWLcannot use this metamodeling mechanism, as the disjointness condition betweenclasses and individuals must hold for any OWL-DL ontology. The OWL-DL usersinterested in linking OWL classes to SKOS concepts have to keep theseformally distinct. They can nevertheless use dedicatedOWL annotationproperties to bridge them, provided they can create and use their ownextension for SKOS, as in:

ex:PaintingClass rdf:type owl:Class.ex:PaintingConcept rdf:type skos:Concept.ex:PaintingClass ex:correspondingConcept ex:PaintingConcept.

Note that at the time of writing, the recently startedOWL WorkingGroup [OWL-WG] had been charteredto handle (some forms of) metamodeling within a description-logic framework.This might allow OWL-DL users to opt for patterns that are easier toexploit.

Summarizing, the relationship between SKOS concepts and OWLclasses/individuals is as follows:

• SKOS concepts are OWL individuals;
• SKOS does not take a stance on whether it must also be possible to treat SKOS concepts as OWL classes;
• The restrictions on OWL-DL prevent treating SKOS concepts as OWL classes;
• There is an expectation that an ongoing OWL revision will alleviate the latter problem by offering some form of metamodeling.

5.3 SKOS, RDF Datasets and InformationContainment

In a context of networked KOSs, some applications may require theprovenance or ownership of SKOS statements to be tracked, for instance fortrust purposes. A specific issue is how to establish explicit links between aconcept scheme and every piece of information that is stated in the originalKOS it represents, including for instance semantic relationships betweenconcepts.

Such functionality, albeit identified as acandidaterequirement [SKOS-UCR], is currentlyoutside the scope of SKOS. In RDF, statements comes as context-free triples,which makes it difficult to represent containment and provenance.

However, solutions for such problems have been proposed, such as namedgraphs [NAMED-GRAPHS], and the useofRDFDatasets in SPARQL [SPARQL]. A SKOSconcept scheme can be related to an RDF Dataset, or even asserted to be sucha Dataset, which enables the creation of SPARQL queries dealing with someform of provenance or containment. Continuing the example ofSection 3.2, and assuming thatex1:referenceAnimalScheme andex2:catScheme havebeen managed as appropriate RDF Datasets (here, named graphs), the query

SELECT  ?x ?yWHERE   {  GRAPH ex2:catScheme { ?x skos:broader ?y }}

may return(ex2:abyssinian, ex1:cat) as a result, while thistuple would not appear among the results of

SELECT  ?x ?WHERE   {   GRAPH ex1:referenceAnimalScheme { ?x skos:broader ?y }}

Readers should nevertheless be aware that these mechanisms have not beenwidely used at the time of writing, and that different standard practicescould emerge in the future.

References

[BS8723-2]

BS 8723-2:2005 Structured vocabularies for information retrieval. Guide. Thesauri, British Standards Institution, London, 2005.

[BS8723-4]

BS 8723-4:2007 Structured vocabularies for information retrieval. Guide. Interoperability between vocabularies, British Standards Institution, London, 2007.

[COOLURIS]

Cool URIs for the Semantic Web, Leo Sauermann, Richard Cyganiak, Editors, W3C Interest Group Note, 3 December 2008.Latest version available at http://www.w3.org/TR/cooluris/ .

[DC]

DCMI Metadata Terms, 14 January 2008.Latest version available at http://dublincore.org/documents/dcmi-terms/ .

[ISO2788]

ISO 2788:1986 Documentation - Guidelines for the establishment and development of monolingual thesauri. Second edition. ISO TC 46/SC 9, 1986.

[ISO5964]

ISO 5964:1985 Documentation - Guidelines for the establishment and development of multilingual thesauri. First edition. ISO TC 46/SC 9, 1985.

[NAMED-GRAPHS]

Named graphs, provenance and trust, Jeremy Carroll, Christian Bizer, Patrick Hayes, Patrick Stickler, WWW 2005.

[RDF/XML-SYNTAX]

RDF/XML Syntax Specification (Revised), Dave Beckett, Editor. W3C Recommendation, 10 February 2004.Latest version available at http://www.w3.org/TR/rdf-syntax-grammar/ .

[RECIPES]

Best Practice Recipes for Publishing RDF Vocabularies. Diego Berrueta, Jon Phipps. W3C Working Draft, 23 January 2008.Latest version available at http://www.w3.org/TR/swbp-vocab-pub/ .

[OWL-WG]

OWL Working Group, http://www.w3.org/2007/OWL/.

[OWL]

OWL Web Ontology Language Reference, Mike Dean, Guus Schreiber, Editors, W3C Recommendation, 10 February 2004.Latest version available at http://www.w3.org/TR/owl-ref/ .

[OWL-SEMANTICS]

OWL Web Ontology Language Semantics and Abstract Syntax, Peter F. Patel-Schneider, Patrick Hayes, Ian Horrocks, Editors, W3C Recommendation, 10 February 2004.Latest version available at http://www.w3.org/TR/owl-semantics/ .

[RDF-PRIMER]

RDF Primer, Frank Manola, Eric Miller, Editors, W3C Recommendation, 10 February 2004.Latest version available at http://www.w3.org/TR/rdf-primer/ .

[RDF-CONCEPTS]

Resource Description Framework (RDF): Concepts and Abstract Syntax, Graham Klyne, Jeremy Carroll, Editors, W3C Recommendation, 10 February 2004.Latest version available at http://www.w3.org/TR/rdf-concepts/ .

[RFC4646]

Tags for Identifying Languages, A. Phillips , M. Davis, Editors, September 2006. Available at http://www.ietf.org/rfc/rfc4646.txt .

[SWBP-SKOS-CORE-GUIDE]

SKOS Core Guide, Alistair Miles, Dan Brickley, Editors, W3C Working Draft, 2 November 2005.Latest version available at http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/ .

[SKOS-REFERENCE]

SKOS Reference, Alistair Miles, Sean Bechhofer, Editors, W3C Recommendation, 18 August 2009.Latest version available at http://www.w3.org/TR/skos-reference .

[SKOS-UCR]

SKOS Use Cases and Requirements, Antoine Isaac, Jon Phipps, Daniel Rubin, Editors, W3C Working Group Note, 18 August 2009.Latest version available at http://www.w3.org/TR/skos-ucr .

[SPARQL]

SPARQL Query Language for RDF, Eric Prud'hommeaux, Andy Seaborne, Editors, W3C Working Draft, 15 January 2008.Latest version available at http://www.w3.org/TR/rdf-sparql-query/ .

[SWBP-SKOS-CORE-SPEC]

SKOS Core Vocabulary Specification, Alistair Miles, Dan Brickley, Editors, W3C Working Draft, 2 November 2005. Available at http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20051102/ .

[SWD]

The Semantic Web Deployment Working Group, http://www.w3.org/2006/07/SWD/ .

[TURTLE]

Turtle - Terse RDF Triple Language, David Beckett, Tim Berners-Lee. W3C Team Submission, 14 January 2008.Latest version available at http://www.w3.org/TeamSubmission/turtle/ .

[UDC]

UDC - Universal Decimal Classification, UDC Consortium, http://www.udcc.org/ .

[URI]

RFC 3986 - Uniform Resource Identifiers (URI): Generic Syntax, Tim Berners-Lee, Roy Fielding, Larry Masinter, IETF, January 2005. Available at http://tools.ietf.org/html/rfc3986 .

[WillpowerGlossary]

Glossary of terms relating to thesauri and other forms of structured vocabulary for information retrieval, Stella Dextre Clarke, Alan Gilchrist, Ron Davies and Leonard Will,Willpower Information. Available at https://www.iskouk.org/resources/Documents/Willarchives/Will2021/glossary.html .

Acknowledgments

The authors would like to thank Alistair Miles and Dan Brickley who editedthe SKOS Core Guide (which this Primer is largely based on); as well as TomBaker, Guus Schreiber and Sean Bechhofer who contributed significant portionsof this text. Semantic Web Deployment Group members Tom Baker, MargheritaSini, Quentin Reul also provided extensive reviews during the publicationprocess.

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

Public comments (especially via the public-esw-thes@w3.org mailing list)from the following individuals provided invaluable guidance, suggestions andcorrections: Mark van Assem, Stephen Bounds, Dan Brickley, Johan De Smedt,Stella Dextre-Clarke, Alasdair Gray, Andrew Houghton, Simon Jupp, CarlMattocks, Emma McCulloch, Mikael Nilsson, Alan Ruttenberg, Aida Slavic, SimonSpero, Doug Tudhope, Bernard Vatant, Jakob Voss, Leonard Will, Sue EllenWright.

Appendix. Correspondences betweenISO-2788/5964 and SKOS constructs

SKOS owes much to decades of efforts in the KOS community, in the form ofapplications, guidelines and standard formats. The compatibility between theSKOS model and two such efforts, ISO 2788 specifications for monolingualthesauri [ISO-2788] and ISO 5964specifications for multilingual thesauri [ISO-5964] was specifically raised as a candidaterequirement in theSKOS Use Case and Requirements [SKOS-UCR].

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

The reader should be aware that this comparison must not by any means beinterpreted as a limitation of the scope of SKOS to standard thesauri. Asalready said in this document, SKOS can be used—possibly with appropriateextensions—for other types of KOS, or thesauri that do not follow the ISOguidelines.