Copyright ©2004 W3C ® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
SKOS Core is a supporting RDF Vocabulary for describing concepts and concept schemes. (A 'concept scheme' is defined here as 'a description of a set of concepts, optionally including a description of relationships between those concepts'.) In general terms, the main function of SKOS Core is to support structured descriptions of conceptualisations, for the purpose of establishing common meaning within a community of people.
SKOS Core is also proposed as a standard framework for creating RDF descriptions of the more linguistically oriented types of knowledge organisation system, such as thesauri, subject heading schemes, terminologies, glossaries, classifications schemes, other controlled vocabulary types etc.
This guide is an introduction to the features of SKOS Core for readers who already have a understanding of basic RDF concepts. It is also a normative guide to the proper use of the SKOS Core vocabulary. It accompanies the SKOS Core Vocabulary Specification [CORESPEC].
This section describes the status of this document at the time of its publication.
This document is an Editor's Draft for review by the Semantic Web Best Practices and Deployment Working Group (hereafter 'the Working Group') and the participants of the public-esw-thes@w3.org mailing list and is subject to change without notice. This document has no formal standing within W3C. Please consult the Working Group's home page and the W3C technical reports index for information about the latest publications by this group. This document 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.
This document is published by the Semantic Web Best Practices and Deployment Working Group, part of the W3C Semantic Web Activity. The Working Group intends the SKOS Core Guide to become a W3C Working Group Note. However, other outcomes are possible within the framework of the W3C process and will be considered in response to deployment experience and feedback from the W3C membership. The Working Group has discussed the potential for SKOS Core to evolve into possible future W3C Recommendation Track work items, and would value feedback on the level of formal standardization that is appropriate.
We encourage public comments. Please send comments to public-esw-thes@w3.org [archive] and start the subject line of the message with "comment:".
Publication as a Working Draft does not imply endorsement by the W3C Membership.
SKOS Core is a supporting RDF vocabulary for publishing concept schemes on the semantic web. Here a 'concept scheme' is defined as 'a description of a set of concepts, which may include a description of relationships between those concepts'.
This guide is an introduction to SKOS Core for readers who already have an understanding of basic RDF concepts. This document is also a normative guide to the proper use of the SKOS Core vocabulary. It should be read in conjunction with the SKOS Core Vocabulary Specification [CORESPEC] which provides an up-to-date overview and summary of the SKOS Core vocabulary, including all textual annotations and formal schema assertions.
Because SKOS Core is an RDF vocabulary, it may be freely used in combination with any other published RDF vocabulary. Many of the examples in this guide use SKOS Core in combination with RDFS [RDFS], OWL [OWL], FOAF [FOAF], and Dublin Core Metadata Initiative (DCMI) Terms [DCMITERMS]. It is considered good practise to re-use terms from other well-defined and maintained RDF vocabularies wherever possible, and this has been a fundamental principle in the design of SKOS Core.
Most of the examples in this guide are written using the RDF/XML syntax for RDF [RDFXML]. For some examples a graphical representation of the set of RDF statements encoded by the example is also included. The reader should understand that an RDF description consists fundamentally of a set of RDF statements (also known as triples) which can be visualised as a directed labelled graph. SKOS Core is not an XML syntax for concept schemes. An RDF description of a concept scheme using the SKOS Core vocabulary could be serialised according to any of the alternative syntaxes for RDF (RDF/XML [RDFXML], N-Triple [NTRIPLE], N3/Turtle [TURTLE]).
In this document, examples appear in boxes like the following:
A SKOS Core example
Constraints on the SKOS Core model are described in prose in this document, and appear in boxes like the following:
A SKOS Core constraint
Inference rules implied by the SKOS Core vocabulary appear in boxes like the following:
A SKOS Core rule
The Jena 2 rule syntax [JENA] is used here to express inference rules.
SKOS Core constraints are also listed in appendix I. SKOS Core rules are also listed in appendix II.
SKOS Core has an open-ended maintenance policy, which means that new terms may be added at any time in the future. Each new term goes through a series of stability stages, and when a term is declared 'stable' it may be relied upon not to change further. Some of the SKOS Core features described in this guide are not yet completely stable. The SKOS Core Vocabulary Specification [CORESPEC] contains an up-to-date overview of the SKOS Core Vocabulary, and should be consulted for latest definitions and status values.
SKOS Core is maintained by an open community of developers. All SKOS Core development work is mediated via the public mailing list public-esw-thes@w3.org [online archive], and active participation is most welcome.
A concept is the fundamental unit you can describe using SKOS Core. Here 'concept' is meant in its broadest sense, and could be loosely defined as 'a unit of thought'.
The following snippet of RDF/XML contains a declaration of a concept:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.com/bananas#concept"/> </rdf:RDF>
As a short note about the RDF/XML syntax, the above snippet is in fact a contracted form of the following:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="http://www.example.com/bananas#concept"> <rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/> </rdf:Description> </rdf:RDF>
In this guide, wherever possible, RDF statements involving the rdf:type
property are expressed in RDF/XML in the contracted form.
The important thing to understand is that both of the above snippets contain the same single RDF statement, which could be visualised as the following:
This RDF statement should be interpreted as saying that,
'the resource identified by the URI http://www.example.com/bananas#concept
is a concept'.
N.B. A URI from the HTTP URI scheme need not have been used as an identifier for this example concept. A URI from any of the various URI schemes that are appropriate for identification of abstract entities could equally have been used. This guide attempts to remain neutral about the applicability of various types of URI for this purpose. A note addressing this issue is currently under development by the Vocabulary Management Task Force [VMTF] of the W3C SWBPD-WG [SWBP].
Also, the fact that this example URI happens to contain the character string 'bananas' should not be interpreted as implying anything at all about the meaning of this concept. I might have used the URI http://www.example.com/123#456
for example. I might equally be using the URI http://www.example.com/bananas#concept
to identify the concept 'washing machines'. See also the section on opaque URIS in [WEBARCH].
Here labelling means assigning some sort of token to a concept, where the token may be used to denote the concept in documents intended for human consumption.
The sub-sections below describe different labelling scenarios.
Lexical labelling means labelling a concept with a plain literal (i.e. a character string with optional language tag).
To label a concept with a single word or phrase, use the rdfs:label
property. For example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <skos:Concept rdf:about="http://www.example.com/bananas#concept"> <rdfs:label>bananas</rdfs:label> </skos:Concept> </rdf:RDF>
The graph for this example is below:
Often it is useful to assign a number of alternative lexical labels to a concept. In this situation, one of these labels is normally selected as the preferred label. The skos:prefLabel
and skos:altLabel
properties may be used for this purpose, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.com/animals#concept"> <skos:prefLabel>animals</skos:prefLabel> <skos:altLabel>creatures</skos:altLabel> <skos:altLabel>fauna</skos:altLabel> </skos:Concept> </rdf:RDF>
The graph for this example is below:
The labels in the above example, 'animals' 'creatures' and 'fauna', would under normal circumstances be considered to be synonyms of each other. However, it is not necessary to restrict preferred and alternative lexical labels to precise synonyms. The following are all valid:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.com/wetness#concept"> <skos:prefLabel>wetness</skos:prefLabel> <skos:altLabel>dryness</skos:altLabel> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/shrubs#concept"> <skos:prefLabel>shrubs</skos:prefLabel> <skos:altLabel>bushes</skos:altLabel> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/rocks#concept"> <skos:prefLabel>rocks</skos:prefLabel> <skos:altLabel>basalt</skos:altLabel> <skos:altLabel>granite</skos:altLabel> <skos:altLabel>slate</skos:altLabel> </skos:Concept> </rdf:RDF>
N.B. The following constraints apply for lexical labelling of concepts:
When used with resources of type skos:Concept
, the range of statements involving the rdfs:label
skos:prefLabel
and skos:altLabel
properties and any sub-property thereof should be restricted to RDF plain literals.
A concept must not have more than one preferred lexical label per language (see also multilingual labelling below).
All concepts within the same concept scheme should have different preferred lexical labels within the scope of a particular language (see also multilingual labelling below).
Abbreviations and acronyms may also be used to label concepts, and the choice of whether to use them as preferred or alternative terms is unconstrained. However, misspelled words are normally included among the hidden labels (see see hidden labels below).
A hidden label is a lexical label for a concept, where you would like that character string to be accessible to applications performing search operations on a concept scheme, but you would not like that label to be visible otherwise.
The most common use of hidden labels is to include misspelt variants of other lexical labels. For example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.com/abattoirs#concept"> <skos:prefLabel>abattoirs</skos:prefLabel> <skos:hiddenLabel>abatoirs</skos:hiddenLabel> <skos:hiddenLabel>abbatoirs</skos:hiddenLabel> <skos:hiddenLabel>abbattoirs</skos:hiddenLabel> </skos:Concept> </rdf:RDF>
As mentioned above, lexical labelling means labelling a concept with a plain literal, which is a character string with optional language tag. The language tag may be used to restrict the scope of a lexical label to a particular language. For example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <skos:Concept rdf:about="http://www.example.com/pineapples#concept"> <rdfs:label xml:lang="en">pineapples</rdfs:label> <rdfs:label xml:lang="fr">ananas</rdfs:label> </skos:Concept> </rdf:RDF>
The graph of this example is below:
The values permissable as language tags are given by [XMLLANG].
Language tags may be used with any of the SKOS Core labelling properties, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.com/shrubs#concept"> <skos:prefLabel xml:lang="en">shrubs</skos:prefLabel> <skos:altLabel xml:lang="en">bushes</skos:altLabel> <skos:prefLabel xml:lang="fr">arbuste</skos:prefLabel> <skos:altLabel xml:lang="fr">buisson</skos:altLabel> </skos:Concept> </rdf:RDF>
When labelling a concept in more than one language, bear in mind that subtle differences in the common meaning of translated words or phrases between languages may result in differing interpretations of a particular concept by different language communities.
Symbolic labelling means labelling a concept with an image.
To assign preferred and alternative symbolic labels to a concept, use the skos:prefSymbol
and skos:altSymbol
properties. For example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.com/love#concept"> <skos:prefSymbol rdf:resource="http://www.example.com/symbols/love1.jpg"/> <skos:altSymbol rdf:resource="http://www.example.com/symbols/love2.jpg"/> </skos:Concept> </rdf:RDF>
A concept should have no more than one preferred symbolic label.
The content of a lexical or symbolic label may help to indicate the meaning of a concept, but it should not be taken as definitive. For example, if I label a concept with the literal 'bananas' that does not necessarily imply that the meaning of my concept is the same as the common understanding of the word 'bananas'. Similarly, in a symbolic concept scheme, a heart shape as a symbol for a concept does not imply the concept is 'love'.
The labels of a concept will be used to generate visual representations of that concept, for human consumption. Choosing labels that convey as effectively as possible the intended meaning of a concept increases the extent to which that concept will be consistently applied and understood, hence increasing its value as a resource on the semantic web. When assigning a preferred or single lexical label to a concept, all of the considerations relevant to choosing good descriptors for a thesaurus may be applied (for example see [BS8723]).
This section describes how to assert a semantic relationship between two concepts. These types of relationship are also known as paradigmatic relationships [BS8723]. That is, they are relationships that are inherent in the meaning of the concepts.
N.B. Types of semantic relationship other than those included in SKOS Core can be defined and used with SKOS Core, see also [section extended semantic relation properties].
To assert that one concept is broader in meaning (i.e. more general) than another, where the scope (i.e. meaning) of one falls completely within the scope of the other, use the skos:broader
property, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.com/mammals#concept"> <skos:prefLabel>mammals</skos:prefLabel> <skos:broader rdf:resource="http://www.example.com/animals#concept"/> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/animals#concept"> <skos:prefLabel>animals</skos:prefLabel> </skos:Concept> </rdf:RDF>
To assert that one concept is narrower in meaning (i.e. more specific) than another, use the skos:narrower
property, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.com/animals#concept"> <skos:prefLabel>animals</skos:prefLabel> <skos:narrower rdf:resource="http://www.example.com/mammals#concept"/> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/mammals#concept"> <skos:prefLabel>mammals</skos:prefLabel> </skos:Concept> </rdf:RDF>
The properties skos:broader
and skos:narrower
are each other's inverse.
(?x skos:broader ?y) -> (?y skos:narrower ?x)
... and vice versa.
See also section on hierarchies in [BS8723].
To assert an associative relationship between two concepts, use the skos:related
property, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.com/birds#concept"> <skos:prefLabel>birds</skos:prefLabel> <skos:related rdf:resource="http://www.example.com/ornithology#concept"/> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/ornithology#concept"> <skos:prefLabel>ornithology</skos:prefLabel> <skos:related rdf:resource="http://www.example.com/birds#concept"/> </skos:Concept> </rdf:RDF>
The property skos:related
is a symmetric property.
(?x skos:related ?y) -> (?y skos:related ?x)
See also the section on associative relationships in [BS8723].
This section describes how to attach useful annotations to a concept. Here an annotation is any sort of human readable documentation.
This section describes four simple types of annotation: definitions, scope notes, examples and depictions.
A definition is a statement or formal explanation of the meaning of a concept. To attach a definition to a concept, use the skos:definition
property, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.org/bananarepublic#concept"> <skos:prefLabel>banana republic</skos:prefLabel> <skos:definition>A small country, especially in South and Central America, that is poor and often badly and immorally ruled.</skos:definition> </skos:Concept> </rdf:RDF>
A scope note is used to restrict or expand the meaning of a concept. A scope note need not be a full definition of the concept, but should clarify the intended use of the concept. To attach a scope note to a concept, use the skos:scopeNote
property, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.org/european#concept"> <skos:prefLabel>European</skos:prefLabel> <skos:scopeNote>Refers to the cultures of the continent of Europe, which is in the northern hemisphere, is bounded by the Arctic Ocean, the Atlantic Ocean, and the Mediterranean Sea, and is delimited on the east by the Ural Mountains.</skos:scopeNote> </skos:Concept> </rdf:RDF>
See also the section on scope notes in [BS8723].
An example of the intended use of a concept may be attached to a concept with the skos:example
property. For example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.org/bananas#concept"> <skos:prefLabel>bananas</skos:prefLabel> <skos:example>a bunch of bananas</skos:example> <skos:example>banana milkshake</skos:example> </skos:Concept> </rdf:RDF>
To attach an image depicting a concept to the concept, use the foaf:depiction
property, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <skos:Concept rdf:about="http://www.example.org/spottedbowerbird#concept"> <skos:prefLabel>spotted bowerbird</skos:prefLabel> <skos:altLabel>Chlamydera maculata</skos:altLabel> <foaf:depiction rdf:resource="http://www.example.org/images/spottedbowerbird1.jpg"/> </skos:Concept> </rdf:RDF>
This section introduces all of the SKOS Core annotation properties, and the ways in which they may be used.
There are 8 annotation properties included in SKOS Core:
skos:publicNote
skos:privateNote
skos:definition
skos:scopeNote
skos:example
skos:historyNote
skos:editorialNote
skos:changeNote
These annotation properties may be used in three styles: simple literal, structured value, document reference. The sections below describe these styles of usage.
These annotation properties may also be extended to create more specialised types of annotation. See the section [extended annotation properties].
The SKOS Core annotation properties are arranged in a property hierarchy, as follows:
rdfs:comment | +-- skos:publicNote | | | +-- skos:definition | | | +-- skos:scopeNote | | | +-- skos:example | | | +-- skos:historyNote | +-- skos:privateNote | +-- skos:editorialNote | +-- skos:changeNote
An annotation using the skos:publicNote
property is a general note intended for public display.
The properties skos:definition
, skos:scopeNote
and skos:example
are described above.
An annotation using the skos:historyNote
property describes information about the past form, meaning and/or use of a concept, intended for public display. See also section history notes in [BS8723].
An annotation using the skos:privateNote
property is a general note not intended for public display.
An annotation using the skos:editorialNote
property is any note intended for the internal use of the editor and/or editorial team responsible for the concept.
An annotation using the skos:changeNote
property describes changes made to a concept. Whereas a history note is intended for public consumption, change notes are usually private notes used to document fine grained changes to concepts, primarily to support the work of the editorial team.
In this usage style the range of an annotation property is constrained to be a plain literal. This style was used in the Basic Annotations section.
For example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.org/bananarepublic#concept"> <skos:prefLabel>banana republic</skos:prefLabel> <skos:definition>A small country, especially in South and Central America, that is poor and often badly and immorally ruled.</skos:definition> </skos:Concept> </rdf:RDF>
Note that a plain literal may include a language tag. Where a concept is labelled in more than one language, annotations may also be provided in multiple languages, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.com/pineapples#concept"> <skos:prefLabel xml:lang="en">pineapples</skos:prefLabel> <skos:definition xml:lang="en">The fruit of plants of the family Bromeliaceae.</skos:definition> <skos:prefLabel xml:lang="fr">ananas</skos:prefLabel> <skos:definition xml:lang="fr">Le fruit de la plante herbacée de la famille des broméliacées.</skos:definition> </skos:Concept> </rdf:RDF>
For some types of annotation it is extremely useful to represent the information in a structured form. This allows you to assert additional statements about the annotation itself.
A structured value annotation, encoded in RDF/XML, looks like the following:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.com/any#concept"> <skos:generalNote rdf:parseType="Resource"> <rdf:value>** Text of the annotation goes here. **</rdf:value> <!-- Any other properties of the annotation. --> </skos:generalNote> </skos:Concept> </rdf:RDF>
Properties from other RDF vocabularies such as the Dublin Core Elements [DCMITERMS] and FOAF [FOAF] can be extremely useful for asserting additional properties of a structured value annotation. For example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <skos:Concept rdf:about="http://www.example.org/laptops#concept"> <skos:prefLabel>notebook computers</skos:prefLabel> <skos:changeNote rdf:parseType="Resource"> <rdf:value>The preferred label for this concept changed from 'laptop computers' to 'notebook computers' on 23 Jan 1999.</rdf:value> <dc:creator> <foaf:Person> <foaf:name>John Smith</foaf:name> <foaf:mbox rdf:resource="mailto:jsmith@example.org"/> </foaf:Person> </dc:creator> <dc:date>1999-01-23</dc:date> </skos:changeNote> </skos:Concept> </rdf:RDF>
Another example, using the skos:definition
property:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/"> <skos:Concept rdf:about="http://www.example.org/penguins#concept"> <skos:prefLabel xml:lang="en">penguins</skos:prefLabel> <skos:definition rdf:parseType="Resource"> <rdf:value>Any of various stout flightless marine birds of the family Spheniscidae, of cool regions of the Southern Hemisphere, having flipperlike wings and webbed feet adapted for swimming and diving, and short scalelike feathers that are white in front and black on the back.</rdf:value> <dc:language> <dcterms:RFC1766> <rdf:value>EN</rdf:value> <rdfs:label>English</rdfs:label> </dcterms:RFC1766> </dc:language> <dc:source>The American Heritage® Dictionary of the English Language, Fourth Edition</dc:source> </skos:definition> </skos:Concept> </rdf:RDF>
See FOAF [FOAF] and DC [DCMITERMS] specifications for more properties and usage guidelines.
This style of usage may be applied where the text of an annotation is the content of another document. The URI of that document is referred to as the value of the annotation property.
An example of this usage style:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.com/zoology#concept"> <skos:prefLabel>zoology</skos:prefLabel> <skos:scopeNote rdf:resource="http://www.example.com/notes/zoology.txt"/> </skos:Concept> </rdf:RDF>
It is possible to include metaproperties of this document within the same RDF description, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <skos:Concept rdf:about="http://www.example.com/botany#concept"> <skos:prefLabel>botany</skos:prefLabel> <skos:scopeNote> <foaf:Document rdf:about="http://www.example.com/notes/botany.txt"> <dc:creator> <foaf:Person> <foaf:name>John Smith</foaf:name> <foaf:mbox rdf:resource="mailto:jsmith@example.org"/> </foaf:Person> </dc:creator> <dc:language> <dcterms:RFC1766> <rdf:value>EN</rdf:value> <rdfs:label>English</rdfs:label> </dcterms:RFC1766> </dc:language> </foaf:Document> </skos:scopeNote> </skos:Concept> </rdf:RDF>
A concept may have no more than one definition per language.
A concept may have no mote than one scope note per language.
This section introduces the features of SKOS Core that allow you to define meaningful groupings of concepts ('collections').
There are two types of collections: collections where the order of the member concepts is unspecified (unordered), and collections where the order of the member concepts is explicitly stated (ordered).
Ordered collections are useful where the order of a group of concepts has some meaning, and should be preserved by applications creating visual representations that include those concepts. (The default mode for displaying a set of concepts is to order them alphabetically according to the value of the preferred lexical label.)
Both ordered and unordered collections can be labelled. A collection label (also known as a 'node label') can provide some helpful indication as to why some concepts have been grouped together. This can be useful in generating visual representations that include those concepts.
To define a collection of concepts, use the skos:Collection
class and the skos:member
property. To assign a lexical label to a collection, use the rdfs:label
property. For example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <skos:Collection> <rdfs:label>milk by source animal</rdfs:label> <skos:member rdf:resource="http://www.example.com/buffalomilk#concept"/> <skos:member rdf:resource="http://www.example.com/cowmilk#concept"/> <skos:member rdf:resource="http://www.example.com/goatmilk#concept"/> <skos:member rdf:resource="http://www.example.com/sheepmilk#concept"/> </skos:Collection> <skos:Concept rdf:about="http://www.example.com/buffalomilk#concept"> <skos:prefLabel>buffalo milk</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/cowmilk#concept"> <skos:prefLabel>cow milk</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/goatmilk#concept"> <skos:prefLabel>goat milk</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/sheepmilk#concept"> <skos:prefLabel>sheep milk</skos:prefLabel> </skos:Concept> </rdf:RDF>
Note that in the example above the collection was defined as a blank node, i.e. no URI was allocated. URIs may be allocated to collections, but usually this is not necessary.
The most common use of a labelled collection such as the above is to enhance a hierarchical display. You can describe narrower and broader relationships between a concept and a collection, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <skos:Concept rdf:about="http://www.example.com/milk#concept"> <skos:prefLabel>milk</skos:prefLabel> <skos:narrower> <skos:Collection> <rdfs:label>milk by source animal</rdfs:label> <skos:member rdf:resource="http://www.example.com/buffalomilk#concept"/> <skos:member rdf:resource="http://www.example.com/cowmilk#concept"/> <skos:member rdf:resource="http://www.example.com/goatmilk#concept"/> <skos:member rdf:resource="http://www.example.com/sheepmilk#concept"/> </skos:Collection> </skos:narrower> </skos:Concept> </rdf:RDF>
The usual rendering of this structure is:
milk .<milk by source animal> ..buffalo milk ..cow milk ..goat milk ..sheep milk
The class skos:CollectableProperty
supports a generic mechanism by which collections can be involved in statements. For this property the following rule applies:
(?x ?p ?c) (?c skos:member ?m) (?p rdf:type skos:CollectableProperty) -> (?x ?p ?m)
The properties skos:narrower
, skos:broader
and skos:related
are all collectable properties.
This rule means that the example from the section above implies the following statements:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <rdf:Description rdf:about="http://www.example.com/milk#concept"> <skos:narrower rdf:resource="http://www.example.com/buffalomilk#concept"/> <skos:narrower rdf:resource="http://www.example.com/cowmilk#concept"/> <skos:narrower rdf:resource="http://www.example.com/goatmilk#concept"/> <skos:narrower rdf:resource="http://www.example.com/sheepmilk#concept"/> </rdf:Description> </rdf:RDF>
To define an explicitly ordered collection of concepts, use the skos:OrderedCollection
class with the skos:memberList
property. An ordered collection may also have a label, although this is optional. For example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <skos:OrderedCollection> <rdfs:label>people by age</rdfs:label> <skos:memberList rdf:parseType="Collection"> <skos:Concept rdf:about="http://www.example.com/infants#concept"/> <skos:Concept rdf:about="http://www.example.com/children#concept"/> <skos:Concept rdf:about="http://www.example.com/adults#concept"/> </skos:memberList> </skos:OrderedCollection> <skos:Concept rdf:about="http://www.example.com/infants#concept"> <skos:prefLabel>infants</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/children#concept"> <skos:prefLabel>children</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/adults#concept"> <skos:prefLabel>adults</skos:prefLabel> </skos:Concept> </rdf:RDF>
Ordered collections can be used in the same way as unordered collections (skos:OrderedCollection
is a sub-class of skos:Collection
) for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <skos:Concept rdf:about="http://www.example.com/people#concept"> <skos:prefLabel>people</skos:prefLabel> <skos:narrower> <skos:OrderedCollection> <rdfs:label>people by age</rdfs:label> <skos:memberList rdf:parseType="Collection"> <skos:Concept rdf:about="http://www.example.com/infants#concept"/> <skos:Concept rdf:about="http://www.example.com/children#concept"/> <skos:Concept rdf:about="http://www.example.com/adults#concept"/> </skos:memberList> </skos:OrderedCollection> </skos:narrower> </skos:Concept> </rdf:RDF>
This structure could be rendered for display as:
people .<people by age> ..infants ..children ..adults
N.B. ordered collections should only be used where the ordering of a set of concepts is in some way meaningful.
For ordered collections the following rule applies:
(?c skos:memberList ?l) elementOfList(?e,?l) -> (?c skos:member ?e)
... where 'elementOfList' is a builtin function that returns true if the first argument is an element of the RDF list for which the second argument is the head.
This rule, in combination with the collectable properties rule, means that the example above implies the following statements:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <rdf:Description rdf:about="http://www.example.com/people#concept"> <skos:narrower rdf:resource="http://www.example.com/infants#concept"/> <skos:narrower rdf:resource="http://www.example.com/children#concept"/> <skos:narrower rdf:resource="http://www.example.com/adults#concept"/> </rdf:Description> </rdf:RDF>
Collections may also be nested inside other collections, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <skos:Concept rdf:about="http://www.example.com/chairs#concept"> <skos:prefLabel>chairs</skos:prefLabel> <skos:narrower> <skos:Collection> <rdfs:label>chairs by form</rdfs:label> <skos:member rdf:resource="http://www.example.com/armchairs#concept"/> <skos:member rdf:resource="http://www.example.com/easychairs#concept"/> <skos:member> <skos:Collection> <rdfs:label>chairs by form: back form</rdfs:label> <skos:member rdf:resource="http://www.example.com/heartbackchairs#concept"/> <skos:member rdf:resource="http://www.example.com/ovalbackchairs#concept"/> </skos:Collection> </skos:member> </skos:Collection> </skos:narrower> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/armchairs#concept"> <skos:prefLabel>armchairs</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/easychairs#concept"> <skos:prefLabel>easy chairs</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/heartbackchairs#concept"> <skos:prefLabel>heart-back chairs</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/ovalbackchairs#concept"> <skos:prefLabel>oval-back chairs</skos:prefLabel> </skos:Concept> </rdf:RDF>
This structure could be rendered for display as:
chairs .<chairs by form> ..armchairs ..easy chairs ..<chairs by form: back form> ...heart-back chairs ...oval-back chairs
This example adapted from the AAT [AAT] (@@TODO request permission).
Ordered collections may also be nested, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <skos:Concept rdf:about="http://www.example.com/people#concept"> <skos:prefLabel>people</skos:prefLabel> <skos:narrower> <skos:OrderedCollection> <rdfs:label>people by age</rdfs:label> <skos:memberList rdf:parseType="Collection"> <skos:OrderedCollection> <rdfs:label>infants by age</rdfs:label> <skos:memberList rdf:parseType="Collection"> <skos:Concept rdf:about="http://www.example.com/babies#concept"/> <skos:Concept rdf:about="http://www.example.com/toddlers#concept"/> </skos:memberList> </skos:OrderedCollection> <skos:Concept rdf:about="http://www.example.com/children#concept"/> <skos:Concept rdf:about="http://www.example.com/adults#concept"/> </skos:memberList> </skos:OrderedCollection> </skos:narrower> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/babies#concept"> <skos:prefLabel>babies</skos:prefLabel> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/toddlers#concept"> <skos:prefLabel>toddlers</skos:prefLabel> </skos:Concept> </rdf:RDF>
This structure could be rendered for display as:
people .<people by age> ..<infants by age> ...babies ...toddlers ..children ..adults
Also ordered collections may be nested inside unordered collections, and vice versa.
Usually concepts are defined in relation to other concepts, as part of some sort of internally coherent concept scheme. As mentioned in the introduction, a concept scheme is defined here as a description of a set of concepts, which may include a description of relationships between those concepts.
To declare a concept scheme, use the skos:ConceptScheme
class, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:ConceptScheme rdf:about="http://www.example.com/conceptscheme"/> </rdf:RDF>
This statement says that 'the resource identified by the URI http://www.example.com/conceptscheme
is a concept scheme'.
A concept does not have to be a part of a concept scheme - concepts may be defined and published as independent entities. However, where a concept is defined as part of a scheme, use the rdfs:isDefinedBy
property to represent this relationship. For example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <skos:Concept rdf:about="http://www.example.com/bananas#concept"> <rdfs:isDefinedBy rdf:resource="http://www.example.com/conceptscheme"/> </skos:Concept> </rdf:RDF>
A concept may have no more than one value for the rdfs:isDefinedBy
property.
For concept schemes where the concepts are arranged in a hierarchy, use the skos:hasTopConcept
property to make an explicit statement linking a concept scheme to the concepts that are the top-level concepts in the hierarchy. For example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:ConceptScheme rdf:about="http://www.example.com/conceptscheme"> <skos:hasTopConcept rdf:resource="http://www.example.com/biology#concept"/> <skos:hasTopConcept rdf:resource="http://www.example.com/geology#concept"/> <skos:hasTopConcept rdf:resource="http://www.example.com/agriculture#concept"/> <skos:hasTopConcept rdf:resource="http://www.example.com/culturalheritage#concept"/> </skos:ConceptScheme> </rdf:RDF>
It is recommended that you use the skos:hasTopConcept
property, as this gives applications an efficient way of locating the top level concepts for a given scheme.
When declaring a concept scheme you can of course use properties from other RDF vocabularies such as DCMI Terms [DCMITERMS] to describe attributes of the scheme, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <skos:ConceptScheme rdf:about="http://www.example.com/conceptscheme"> <skos:hasTopConcept rdf:resource="http://www.example.com/biology#concept"/> <skos:hasTopConcept rdf:resource="http://www.example.com/geology#concept"/> <skos:hasTopConcept rdf:resource="http://www.example.com/agriculture#concept"/> <skos:hasTopConcept rdf:resource="http://www.example.com/culturalheritage#concept"/> <dc:title>The example.com concept scheme</dc:title> <dc:description>An concept scheme for the SKOS Core guide.</dc:description> <dc:creator> <foaf:Person> <foaf:name>Alistair Miles</foaf:name> <foaf:mbox rdf:resource="mailto:a.j.miles@rl.ac.uk"/> </foaf:Person> </dc:creator> <dc:rights>Free to all.</dc:rights> <dcterms:issued>2004-11-25</dcterms:issued> <dcterms:modified>2004-11-26</dcterms:modified> </skos:ConceptScheme> </rdf:RDF>
Consult the specifications of these vocabularies for other useful properties and usage guidelines.
SKOS Core places no constraints on the number of concept schemes in which a concept may participate. The skos:inScheme
property allows you to state that a concept is included in a given concept scheme, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept rdf:about="http://www.example.com/bananas#concept"> <skos:inScheme rdf:resource="http://www.example.com/anotherconceptscheme"/> <skos:inScheme rdf:resource="http://www.example.com/yetanotherconceptscheme"/> </skos:Concept> </rdf:RDF>
(?x rdfs:isDefinedBy ?y) -> (?x skos:inScheme ?y)
SKOS Core operates on the basis that each concept is intentional. That is to say, a concept means what it means, and the meaning is not affected by any statements made about it. In other words, the concept's owner determines the meaning of a concept, and the set of statements about the concept serve only to explain the meaning of the concept to others. This means that it is up to the concept's owner to provide an informative set of statements about the concept, to ensure that other people will correctly interpret the meaning, and so share the same understanding.
In practise, this means that a concept may be used in any context, and the meaning of the concept will remain unchanged. However, bear in mind that the set of semantic relationships involving a concept are an important part of the explanation of that concept, and will influence the interpretation made by other people. Where a concept has no definition or scope note, people will rely heavily on the context of the concept to form an idea of meaning. Therefore the extent to which a concept is effectively explained via labels and annotations will determine how usable that concept is outside of the originally anticipated context.
OWL [OWL] and DCMI Terms [DCMITERMS] have some useful properties for declaring information about and relationships between scheme versions. For example, if I allocated the URI http://www.example.com/conceptscheme
as the identifier for my concept scheme (in its current state), and then allocated the URIs http://www.example.com/conceptscheme/1
and http://www.example.com/conceptscheme/2
as identifiers for specific versions of the scheme, I can declare that:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:owl="http://www.w3.org/2002/07/owl#"> <skos:ConceptScheme rdf:about="http://www.example.com/conceptscheme"> <dcterms:hasVersion rdf:resource="http://www.example.com/conceptscheme/1"/> <dcterms:hasVersion rdf:resource="http://www.example.com/conceptscheme/2"/> </skos:ConceptScheme> <skos:ConceptScheme rdf:about="http://www.example.com/conceptscheme/1"> <dcterms:isVersionOf rdf:resource="http://www.example.com/conceptscheme"/> </skos:ConceptScheme> <skos:ConceptScheme rdf:about="http://www.example.com/conceptscheme/2"> <dcterms:isVersionOf rdf:resource="http://www.example.com/conceptscheme"/> <owl:priorVersion rdf:resource="http://www.example.com/conceptscheme/1"/> </skos:ConceptScheme> </rdf:RDF>
I could then use the skos:inScheme
property to explicitly declare which scheme versions a concept is included in, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dcterms="http://purl.org/dc/terms/"> <skos:Concept rdf:about="http://www.example.com/bananas#concept"> <skos:prefLabel>bananas</skos:prefLabel> <skos:altLabel>plantains</skos:altLabel> <rdfs:isDefinedBy rdf:resource="http://www.example.com/conceptscheme"/> <skos:inScheme rdf:resource="http://www.example.com/conceptscheme/1"/> <skos:inScheme rdf:resource="http://www.example.com/conceptscheme/2"/> <dcterms:replaces rdf:resource="http://www.example.com/plantains#concept"/> <skos:changeNote rdf:parseType="Resource"> <rdf:value>The scope of this concept modified to include plantains also after version 1; 'plantains' added as an altLabel.</rdf:value> <dc:date>2004-11-20</dc:date> </skos:changeNote> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/plantains#concept"> <skos:prefLabel>plantains</skos:prefLabel> <rdfs:isDefinedBy rdf:resource="http://www.example.com/conceptscheme"/> <skos:inScheme rdf:resource="http://www.example.com/conceptscheme/1"/> <dcterms:isReplacedBy rdf:resource="http://www.example.com/bananas#concept"/> </skos:Concept> </rdf:RDF>
Consult the OWL [OWL] and Dublin Core [DCMITERMS] specifications for full usage guidelines with respect to properties in those vocabularies.
This section introduces features of SKOS Core designed to support subject indexing of information resources on the web. Here subject indexing means the association of an information resource with a concept which is a subject of that information resource.
To assert that a concept is the subject of an information resource, use the skos:subject
property, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <foaf:Document rdf:about="http://www.publish.csiro.au/paper/MU00039.htm"> <skos:subject rdf:resource="http://www.example.com/ornithology#concept"/> </foaf:Document> <skos:Concept rdf:about="http://www.example.org/ornithology#concept"> <skos:prefLabel>ornithology</skos:prefLabel> </skos:Concept> </rdf:RDF>
You can use the skos:isSubjectOf
property to make an assertion in the other direction, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <foaf:Document rdf:about="http://www.publish.csiro.au/paper/MU00039.htm"/> <skos:Concept rdf:about="http://www.example.org/ornithology#concept"> <skos:prefLabel>ornithology</skos:prefLabel> <skos:isSubjectOf rdf:resource="http://www.publish.csiro.au/paper/MU00039.htm"/> </skos:Concept> </rdf:RDF>
The properties skos:subject
and skos:isSubjectOf
are each other's inverse.
(?x skos:subject ?y) -> (?y skos:isSubjectOf ?x)
... and vice versa.
The property skos:subject
is a sub-property of dc:subject
.
The following rule applies to the interaction of skos:subject
and skos:broader
:
(?i skos:subject ?x) (?x skos:broader ?y) -> (?i skos:subject ?y)
An information resource may have any number of subjects. To state that one of these subjects is the primary subject of the document, use the skos:primarySubject
property, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <foaf:Document rdf:about="http://www.publish.csiro.au/paper/MU00039.htm"> <skos:primarySubject rdf:resource="http://www.example.com/spottedbowerbird#concept"/> </foaf:Document> <skos:Concept rdf:about="http://www.example.org/spottedbowerbird#concept"> <skos:prefLabel>spotted bowerbird</skos:prefLabel> <skos:altLabel>Chlamydera maculata</skos:altLabel> <foaf:depiction rdf:resource="http://www.example.org/images/spottedbowerbird1.jpg"/> </skos:Concept> </rdf:RDF>
Of course, as with all RDF descriptions, the RDF description of the concept http://www.example.org/spottedbowerbird#concept
and the RDF description of the document http://www.publish.csiro.au/paper/MU00039.htm
need not be within the same RDF document. They are presented here together for ease of interpretation.
The properties skos:primarySubject
and skos:isPrimarySubjectOf
are each other's inverse. Therefore ...
(?x skos:primarySubject ?y) -> (?y skos:isPrimarySubjectOf ?x)
... and vice versa.
An information resource may have only one primary subject assertion per concept scheme.
RDF vocabularies such as SKOS Core can be extended in two ways.
Firstly, any property may be used within an RDF description of a concept or a concept scheme. This means that at any time third parties may define and use new properties for describing concepts or concept schemes. This type of extension is both forwards and backwards compatible.
Secondly, existing classes and properties may be 'refined' by defining sub-classes or sub-properties (via the rdfs:subClassOf
and rdfs:subPropertyOf
properties). This type of extension is also both forwards and backwards compatible.
This section describes how refinement extensions may be defined to deal with more specific labelling scenarios, more specific semantic relation properties, more specific concept types and more specific annotation properties.
SKOS Core includes three labelling properties: skos:prefLabel
, skos:altLabel
and skos:hiddenLabel
. SKOS Core concept descriptions may also re-use the rdfs:label property, which is in fact the super-property of the SKOS Core labelling properties.
rdfs:label | +--skos:prefLabel | +--skos:altLabel | +--skos:hiddenLabel
Applications may demand, however, a richer set of labelling properties with more precise semantics.
For example, you might want to express the fact that one label is the scientific name for a concepts, and another is the common name. To do this, you would first declare two new RDF properties, as illustrated below.
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <rdf:Property rdf:about="http://www.example.com/skos-core-extensions#scientificName"> <rdfs:comment>A scientific name for the concept.</rdfs:comment> <rdfs:subPropertyOf rdf:resource="http://www.w3.org/2004/02/skos/core#prefLabel"/> </rdf:Property> <rdf:Property rdf:about="http://www.example.com/skos-core-extensions#commonName"> <rdfs:comment>A common (non-scientific) name for the concept.</rdfs:comment> <rdfs:subPropertyOf rdf:resource="http://www.w3.org/2004/02/skos/core#altLabel"/> </rdf:Property> </rdf:RDF>
These new properties could then be used as with any other lexical labelling property, for example:
<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:ext="http://www.example.com/skos-core-extensions#"> <skos:Concept rdf:about="http://www.example.com/spottedbowerbird#concept"> <ext:scientificName>Chlamydera maculata</ext:scientificName> <ext:commonName>Spotted bowerbird</ext:commonName> </skos:Concept> </rdf:RDF>
When extending the skos:prefLabel
property, bear in mind that all of the constraints that apply to the use of skos:prefLabel
will apply to the extension.
SKOS Core includes four properties for expressing paradigmatic semantic relationships between concepts: skos:semanticRelation
, skos:broader
, skos:narrower
, skos:related
.
You may, however, require a richer set of properties for expressing relationships between concepts. For example, you might want to express the fact one concept represents something that is a physical part of another concept.
To do this, define two new properties, for example:
<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:owl="http://www.w3.org/2002/07/owl#"> <rdf:Property rdf:about="http://www.example.com/skos-core-extensions#isPhysicalPartOf"> <rdfs:comment>Expresses a physical has-part relationship between two concepts.</rdfs:comment> <rdfs:subPropertyOf rdf:resource="http://www.w3.org/2004/02/skos/core#broader"/> <owl:inverseOf rdf:resource="http://www.example.com/skos-core-extensions#hasPhysicalPart"/> </rdf:Property> <rdf:Property rdf:about="http://www.example.com/skos-core-extensions#hasPhysicalPart"> <rdfs:comment>Expresses a physical is-part-of relationship between two concepts.</rdfs:comment> <rdfs:subPropertyOf rdf:resource="http://www.w3.org/2004/02/skos/core#narrower"/> <owl:inverseOf rdf:resource="http://www.example.com/skos-core-extensions#isPhysicalPartOf"/> </rdf:Property> </rdf:RDF>
Note that these two properties have been declared as each other's inverse via a statement using the owl:inverseOf
property.
Note also that these two properties extend skos:broader
and skos:narrower
respectively. This means that relationships between concepts declared using these properties will be rendered as part of the concept hierarchy by generic SKOS applications. An alternative would be to extend skos:related
instead, in which case the new relationship would be rendered alongside other associative relationships by generic SKOS applications.
Whether you choose to extend skos:semanticRelation
skos:broader
, skos:narrower
or skos:related
will depend on how you want these relationships to be handled by generic SKOS applications.
These two properties can now be used as in e.g.:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:ext="http://www.example.com/skos-core-extensions#"> <skos:Concept rdf:about="http://www.example.com/geography#UK"> <skos:prefLabel>United Kingdom of Great Britain and Northern Ireland</skos:prefLabel> <ext:isPhysicalPartOf rdf:resource="http://www.example.com/geography#Europe"/> </skos:Concept> <skos:Concept rdf:about="http://www.example.com/geography#Europe"> <skos:prefLabel>Europe</skos:prefLabel> <ext:hasPhysicalPart rdf:resource="http://www.example.com/geography#UK"/> </skos:Concept> </rdf:RDF>
N.B. the SKOS Extensions RDF vocabulary [SKOSEXT] has a set of standard semantic relation property extensions, such as 'broader/narrower-instantive' 'broader/narrower-generic' and 'broader/narrower-partitive'.
An example of an extension of skos:Concept
is below:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <rdfs:Class rdf:about="http://www.example.com/skos-core-extensions#BiologicalConcept"> <rdfs:comment>A concept from the domain of biology.</rdfs:comment> <rdfs:subClassOf rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/> </rdfs:Class> </rdf:RDF>
Once this new class has been declared, it can be used as in:
<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:ext="http://www.example.com/skos-core-extensions#"> <ext:BiologicalConcept rdf:about="http://www.example.com/biology#evolution"> <skos:prefLabel>Evolution</skos:prefLabel> <skos:scopeNote>Darwin's theory of evolution by natural selection of inherited characteristics.</skos:scopeNote> </ext:BiologicalConcept> </rdf:RDF>
I.e. you can use the new class ext:BiologicalConcept
exactly as you would normally use skos:Concept
.
An important use case for this type of extension is in the representation of fundamental facets within a concept scheme.
In a concept scheme ordered according to fundamental facets, each fundamental facet contains a homogeneous class of concepts, the members of which share characteristics that distinguish them from members of other classes [AAT]. So, for example, the Art & Architecture Thesaurus [AAT] declares the following fundamental facets:
ASSOCIATED CONCEPTS PHYSICAL ATTRIBUTES STYLES AND PERIODS AGENTS ACTIVITIES MATERIALS OBJECTS
To represent fundamental facets in RDF, declare an extension of skos:Concept
for each facet, for example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <rdfs:Class rdf:about="http://www.example.com/skos-core-extensions#AssociatedConcept"> <rdfs:subClassOf rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/> </rdfs:Class> <rdfs:Class rdf:about="http://www.example.com/skos-core-extensions#PhysicalAttributesConcept"> <rdfs:subClassOf rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/> </rdfs:Class> <rdfs:Class rdf:about="http://www.example.com/skos-core-extensions#StylesAndPeriodsConcept"> <rdfs:subClassOf rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/> </rdfs:Class> <rdfs:Class rdf:about="http://www.example.com/skos-core-extensions#AgentsConcept"> <rdfs:subClassOf rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/> </rdfs:Class> <rdfs:Class rdf:about="http://www.example.com/skos-core-extensions#ActivitiesConcept"> <rdfs:subClassOf rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/> </rdfs:Class> <rdfs:Class rdf:about="http://www.example.com/skos-core-extensions#MaterialsConcept"> <rdfs:subClassOf rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/> </rdfs:Class> <rdfs:Class rdf:about="http://www.example.com/skos-core-extensions#ObjectsConcept"> <rdfs:subClassOf rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/> </rdfs:Class> </rdf:RDF>
Each of these new classes can be used to declare concepts, for example:
<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:ext="http://www.example.com/skos-core-extensions#"> <ext:StylesAndPeriodsConcept rdf:about="http://my.example.org/prehistoric#concept"> <skos:prefLabel>Prehistoric</skos:prefLabel> <skos:scopeNote>Refers to the period antecedent to the first contemporary written accounts of a people. The time span for this period varies according to specific local habitation patterns and in different scholarly disciplines.</skos:scopeNote> </ext:StylesAndPeriodsConcept> </rdf:RDF>
To support stronger validation of your faceted concept scheme, you could also use OWL [OWL] to explicitly declare that a concept may not be a member of more than one fundamental facet, for example:
<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:owl="http://www.w3.org/2002/07/owl#"> <rdfs:Class rdf:about="http://www.example.com/skos-core-extensions#AssociatedConcept"> <owl:disjointWith rdf:resource="http://www.example.com/skos-core-extensions#PhysicalAttributesConcept"/> <owl:disjointWith rdf:resource="http://www.example.com/skos-core-extensions#StylesAndPeriodsConcept"/> <owl:disjointWith rdf:resource="http://www.example.com/skos-core-extensions#AgentsConcept"/> <owl:disjointWith rdf:resource="http://www.example.com/skos-core-extensions#ActivitiesConcept"/> <owl:disjointWith rdf:resource="http://www.example.com/skos-core-extensions#MaterialsConcept"/> <owl:disjointWith rdf:resource="http://www.example.com/skos-core-extensions#ObjectsConcept"/> </rdfs:Class> </rdf:RDF>
A similar declaration must be made for each of the concept classes you intend to use as a fundamental facet.
This example adapted from the AAT [AAT] (@@TODO request permission).
SKOS Core includes eight annotation properties: skos:publicNote
, skos:definition
, skos:example
, skos:scopeNote
, skos:historyNote
, skos:privateNote
, skos:changeNote
and skos:editorialNote
. The basic use of these properties is described in [section basic annotations]. The advanced use of these properties is described in [section advanced annotations].
These properties, as with all SKOS Core properties, can be extended to define more specific note types. So, for example, you might want to have a specific note type for describing the move (relocation) of a concept from one part of the hierarchy to another. To do this, describe a new property e.g.:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <rdf:Property rdf:about="http://www.example.com/skos-core-extensions#relocationNote"> <rdfs:comment>A note about the relocation of the concept within the hierarchy.</rdfs:comment> <rdfs:subPropertyOf rdf:resource="http://www.w3.org/2004/02/skos/core#historyNote"/> </rdf:Property> </rdf:RDF>
This property can now be used in exactly the same way as the built-in SKOS Core note properties.
N.B. this example property is an extension of skos:historyNote, which is an appropriate choice as it represents some sort of historical information about the concept. However, the choice of which SKOS note property to extend is entirely open. Typically, you will want to extend either skos:publicNote
or skos:privateNote
depending on whether you want your note to be published.
If two concepts have different owners, then they must be modelled as distinct resources.
This constraint must be observed even if it looks like the two concepts have the same meaning.
Any party is free, however, to assert a mapping relationship between the two concepts. The SKOS Mapping vocabulary [SKOSMAP] contains a number of RDF properties for expressing mapping relationships between concepts.
In all of the examples in this guide, concepts have been allocated a URI, and that URI has been used to directly identify the concept. RDF natively supports this method of identification.
SKOS Core also supports the method of identifying concepts by reference to a published subject indicator [OASIS]. This means that, for each concept, a document is published on the web explaining the meaning of that concept, and the URI of this document is used to indirectly identify the concept in question. SKOS Core models this relationship between a concept and a published subject indicator document as an inverse functional property. For example:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#"> <skos:Concept> <skos:prefLabel>ornithology</skos:prefLabel> <skos:subjectIndicator rdf:resource="http://www.example.com/psi/ornithology.html"/> </skos:Concept> </rdf:RDF>
The skos:subjectIndicator
property is an owl:InverseFunctionalProperty
, which means that if any two resources have the same value for this property, then they are the same resource [OWL]. This means that the property may be used for example in a subject indexing statement such as:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <foaf:Document rdf:about="http://www.publish.csiro.au/paper/MU00039.htm"> <skos:primarySubject rdf:parseType="Resource"> <skos:subjectIndicator rdf:resource="http://www.example.com/psi/ornithology.html"/> </skos:primarySubject> </foaf:Document> </rdf:RDF>
Bear in mind that, when using inverse functional properties as a basis for identity, you will have to use a reasoner to assert identity (i.e. simple RDF toolkits do not support this, because it is OWL-specific functionality).
@@TODO
The properties skos:broader
and skos:narrower
are each other's inverse.
(?x skos:broader ?y) -> (?y skos:narrower ?x)
... and vice versa.
The property skos:related
is a symmetric property.
(?x skos:related ?y) -> (?y skos:related ?x)
(?x ?p ?c) (?c skos:member ?m) (?p rdf:type skos:CollectableProperty) -> (?x ?p ?m)
(?c skos:memberList ?l) elementOfList(?e,?l) -> (?c skos:member ?e)
... where 'elementOfList' is a builtin function that returns true if the first argument is an element of the RDF list for which the second argument is the head.
(?x rdfs:isDefinedBy ?y) -> (?x skos:inScheme ?y)
The properties skos:subject
and skos:isSubjectOf
are each other's inverse.
(?x skos:subject ?y) -> (?y skos:isSubjectOf ?x)
... and vice versa.
(?i skos:subject ?x) (?x skos:broader ?y) -> (?i skos:subject ?y)
The properties skos:primarySubject
and skos:isPrimarySubjectOf
are each other's inverse. Therefore ...
(?x skos:primarySubject ?y) -> (?y skos:isPrimarySubjectOf ?x)
... and vice versa.
When used with resources of type skos:Concept
, the range of statements involving the rdfs:label
skos:prefLabel
and skos:altLabel
properties and any sub-property thereof should be restricted to RDF plain literals.
A concept must not have more than one preferred lexical label per language (see also multilingual labelling below).
All concepts within the same concept scheme should have different preferred lexical labels within the scope of a particular language (see also multilingual labelling below).
A concept should have no more than one preferred symbolic label.
A concept may have no more than one definition per language.
A concept may have no mote than one scope note per language.
A concept may have no more than one value for the rdfs:isDefinedBy
property.
An information resource may have only one primary subject assertion per concept scheme.
If two concepts have different owners, then they must be modelled as distinct resources.