Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document defines the Simple Knowledge Organization System (SKOS), a common data model for sharing and linking knowledge organization systems via the Semantic Web.
Many knowledge organization systems, such as thesauri, taxonomies, classification schemes and subject heading systems, share a similar structure, and are used in similar applications. SKOS captures much of this similarity and makes it explicit, to enable data and technology sharing across diverse applications.
The SKOS data model provides a standard, low-cost migration path for porting existing knowledge organization systems to the Semantic Web. SKOS also provides a light weight, intuitive language for developing and sharing new knowledge organization systems. It may be used on its own, or in combination with formal knowledge representation languages such as the Web Ontology language (OWL).
This document is the normative specification of the Simple Knowledge Organization System. It is intended for readers who are involved in the design and implementation of information systems, and who already have a good understanding of Semantic Web technology, especially RDF and OWL.
For an informative guide to using SKOS, see the upcoming SKOS Primer.
Using SKOS, conceptual resources can be identified using URIs, labeled with lexical strings in one or more natural languages, documented with various types of note, linked to each other and organized into informal hierarchies and association networks, aggregated into concept schemes, and mapped to conceptual resources in other schemes. In addition, labels can be related to each other, and conceptual resources can be grouped into labeled and/or ordered collections.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is a W3C First Public Working Draft published by the Semantic Web Deployment Working Group, part of the W3C Semantic Web Activity. This is a substantial update to and replacement for the previous SKOS Core Vocabulary Specification W3C Working Draft dated 2 November 2005.
The Working Group solicits review and feedback on this draft specification. All comments are welcome and may be sent to public-swd-wg@w3.org; please include the text "SKOS comment" in the subject line. All messages received at this address are viewable in a public archive. Certain open issues are indicated with Editors' notes to particularly draw the attention of readers.
Editors' note: Anything marked in the document with an "@@" indicates something still to be done or fixed. For example, "@@TODO" indicates an outstanding task, "@@REF" indicates a reference that needs to be properly cited.
The Working Group intends to advance the SKOS Reference to W3C Recommendation after further review and comment. Per W3C Process, a future Last Call Working Draft will signal the Working Group's belief that it has met its design objectives for SKOS and has resolved all open issues.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Quick Access Panel [hide]
Classes
Properties
Sections
Appendices
The Simple Knowledge Organization System is a data sharing standard, bridging several different fields of knowledge, technology and practice.
In the library and information sciences, a long and distinguished heritage is devoted to developing tools for organizing large collections of objects such as books or museum artifacts. These tools are known generally as "knowledge organization systems" (KOS) or sometimes "controlled structured vocabularies", although no widely agreed definitions exist for these terms. The situation is complicated because several similar yet distinct traditions have emerged over time, each supported by a distinct community of practice and set of agreed standards. Different families of knowledge organization systems, including "thesauri", "classification schemes", "subject heading systems", and "taxonomies" are widely recognized and applied in both modern and traditional information systems. In practice it can be hard to draw an absolute distinction between "thesauri" and "classification schemes" or "taxonomies", although some properties can be used to broadly characterize these different families (see e.g. [@@REF-BS8723-X]). The important thing for SKOS is that, in addition to their unique features, each of these families shares much in common, and can often be applied in similar ways.
@@TODO insert an example of an extract from a thesaurus and an extract from a classification scheme or taxonomy, ideally with similar concepts in each extract, to illustrate common aspects of structure and possibility for similar applications.
In recent years, the W3C's Semantic Web Activity [@@REF-SW] has stimulated a new field of integrative research and technology development, at the boundaries between database systems, formal logic and the World Wide Web. This work has led to the development of foundational standards for the Semantic Web. The Resource Description Framework (RDF) provides a common data abstraction and syntax for the Web [@@REF-RDF-PRIMER]. The RDF Vocabulary Description language (RDFS) and the Web Ontology language (OWL) together provide a common data modeling (schema) language for data in the Web [@@REF-RDFS] [@@REF-OWL-GUIDE]. The SPARQL Query language and Protocol provide a standard means for interacting with data in the Web [@@REF-SPARQL]. @@TODO add remark about GRDDL & RDFa?
These technologies are being applied across a diverse set of applications, because many applications require a common framework for publishing, sharing, exchanging and integrating ("joining up") data from different sources. This ability to "join up" data from different sources is motivating many projects, as different communities seek to exploit the hidden value in data previously spread across isolated sources.
One facet of the Semantic Web vision is the hope that Semantic Web technology could be used to better organize the vast amounts of unstructured (i.e. human-readable) information in the Web, providing new routes to discovering and sharing that information. RDFS and OWL are formally defined knowledge representation languages, providing ways of expressing meaning that are amenable to computation; meaning that complements and gives structure to information already present in the Web [@@REF-RDF-PRIMER] [@@REF-OWL-GUIDE]. They go a long way towards supporting that vision, but the story doesn't end there. To actually apply these technologies over large bodies of information requires the construction of detailed "maps" of particular domains of knowledge, in addition to the accurate description (i.e. annotation or cataloging) of information resources on a large scale, much of which cannot be done automatically. The accumulated experience and best practices in the library and information sciences regarding the organization of information and knowledge is obviously complementary and applicable to this vision, as are the many existing knowledge organization systems already developed and in use, such as the Library of Congress Subject Headings or the United Nations Food and Agriculture Organization's Agrovoc Thesaurus.
The Simple Knowledge Organization System therefore aims to provide a bridge between different communities of practice within the library and information sciences involved in the design and application of knowledge organization systems. In addition, SKOS aims to provide a bridge between these communities and the Semantic Web, by transferring existing models of knowledge organization to the Semantic Web technology context, and by providing a low-cost migration path for porting existing knowledge organization systems to RDF.
Looking to the future, SKOS occupies a position between the exploitation and analysis of unstructured information, the large and socially-mediated organization of information on an informal level, and the formal representation of knowledge. It is hoped that, by making the accumulated experience and wisdom of knowledge organization in the library and information sciences accessible, applicable within and transferable to the technological context of the Semantic Web, in a way that is complementary to existing Semantic Web technology (and in particular formal systems of knowledge representation such as OWL), SKOS will not only enable many new and valuable applications, but will also lead to new, integrative lines of research and development in both technology and practice.
The Simple Knowledge Organization System is a common data model for knowledge organization systems such as thesauri, classification schemes, subject heading systems and taxonomies. Using SKOS, a knowledge organization system can be expressed as data. It can then be exchanged between computer applications and published in a machine-readable format in the Web.
The SKOS data model is formally defined in this specification as an OWL Full ontology. SKOS data are expressed as RDF triples, and may be encoded using any concrete RDF syntax (such as RDF/XML or Turtle). For more on the relationships between SKOS, RDF and OWL, see the next sub-section below.
The SKOS data model views a knowledge organization system as a concept scheme comprising a set of conceptual resources. These concept schemes and conceptual resources are identified by URIs, enabling anyone to refer to them unambiguously from any context, and making them a part of the World Wide Web. See section 3 for more on conceptual resources, and section 4 for more on concept schemes.
Conceptual resources can be labeled with any number of lexical (UNICODE) strings, such as "romantic love" or "れんあい", in any given natural language, such as English or Japanese Hiragana. One of these labels in any given language can be indicated as the "preferred" label for that language, and the others as "alternate" labels. Labels may also be "hidden", which is useful e.g. where a knowledge organization system is being queried via a text index. See section 5 for more on the SKOS lexical labeling properties.
Conceptual resources can be documented with any number of notes of various types. The SKOS data model provides a basic set of documentation properties, supporting scope notes, definitions and editorial notes, among others. This set is not meant to be exhaustive, but rather to provide a framework that can be extended by third parties to provide support for more specific types of note. See section 6 for more on the SKOS documentation properties, and appendix F for guidance on best practices for extending SKOS.
Conceptual resources can be linked to other conceptual resources (within the same concept scheme) via semantic relation properties. The SKOS data model provides support for hierarchical and associative links between conceptual resources. Again, as with any part of the SKOS data model, these can be extended by third parties to provide support for more specific needs. See section 7 for more on the SKOS semantic relation properties.
Using the more advanced parts of the SKOS data model, lexical labels (i.e. UNICODE strings) can be linked to each other via n-ary label relations. The SKOS data model only provides a general framework for defining label relations, which is intended as a common extension point for third parties to provide support for specific label relation scenarios, such as acronym, abbreviation or transliteration relations. See section 8 for more on SKOS label relations.
Conceptual resources can be grouped into collections, which can be labeled and/or ordered. This part of the SKOS data model is intended to provide support for node labels within thesauri, and for situations where the ordering of a set of concepts is meaningful or provides some useful information. See section 9 for more on SKOS concept collections.
Conceptual resources can also be mapped to other conceptual resources in different concept schemes. The SKOS data model provides support for three basic types of mapping link: hierarchical, associative and exact. See section 10 for more on SKOS concept mapping.
Editors' note: There are a number of additional features which currently have an uncertain status within the SKOS data model, including symbolic labeling properties and subject indexing properties. These are presented in section 11.
As mentioned above, the SKOS data model is formally defined as an OWL Full ontology. I.e. SKOS is itself an OWL Full ontology. The "elements" of the SKOS data model are classes and properties, and the structure and integrity of the data model is defined by the logical characteristics of and interdependencies between those classes and properties. This is perhaps one of the most powerful and yet confusing aspects of SKOS, because SKOS can, in more advanced applications, also be used side-by-side with OWL to express and exchange knowledge about a domain. However, SKOS is not a formal knowledge representation language.
To understand this distinction, consider that the "knowledge" made explicit in a formal ontology is expressed as sets of axioms and facts. A thesaurus or classification scheme is of a completely different nature, and does not assert any axioms or facts. Rather, a thesaurus or classification scheme identifies and describes, through natural language and other informal means, a set of distinct "ideas" or "meanings", which are sometimes conveniently referred to as "concepts". These "concepts" may also be arranged and organized into various structures, most commonly hierarchies and association networks. These structures, however, do not have any formal semantics, and cannot be reliably interpreted as either formal axioms or facts about the world. Indeed they were never intended to be so, for they serve only to provide a convenient and intuitive "map" of some subject domain, which can then be used as an aid to organizing and finding objects, such as documents, which are relevant to that domain.
To make the "knowledge" embedded in a thesaurus or classification scheme explicit in any formal sense requires that the thesaurus or classification scheme be re-engineered as a formal ontology. In other words, some person has to do the work of transforming the structure and intellectual content of a thesaurus or classification scheme into a set of formal axioms and facts. This work of transformation is both intellectually demanding and time consuming, and therefore costly. Much can be gained from using thesauri etc. "as-is", as informal, convenient structures for navigation within a subject domain. Using them "as-is" does not require any re-engineering, and is therefore much less costly.
Because OWL is a formal ontology language, it does not by itself provide a natural or suitable data model for expressing a thesaurus or classification scheme. I.e. it is appropriate (if one has the time, effort and need) to manually re-engineer a thesaurus or classification scheme as a formal OWL ontology, transforming the "concepts" of the thesaurus into the classes, properties and individuals of the ontology, and transforming the informal hierarchies and association networks of the thesaurus into axioms or facts of the ontology. However, it is not appropriate to express the "concepts" of a thesaurus or classification scheme directly as classes of an ontology, nor to express the informal (broader/narrower) hierarchy of a thesaurus directly as a set of class subsumption axioms. The reason for this is that, because a thesaurus or classification scheme has not been developed with formal semantics in mind, but rather as an informal or semi-formal aid to navigation and information retrieval, expressing a thesaurus hierarchy directly as a set of ontology classes with subsumption axioms typically leads to a number of inappropriate or nonsensical conclusions.
OWL does, however, provide a powerful data modeling language. We can, therefore, use OWL to construct a data model which is appropriate to the level of formality in a thesaurus or classification scheme. This is exactly what SKOS does. Taking this approach, the "concepts" of a thesaurus or classification scheme are modeled as individuals in the SKOS data model, and the informal descriptions about and links between those "concepts" as given by the thesaurus or classification scheme are modeled as facts about those individuals, never as class or property axioms. Note that these "facts" are facts about the thesaurus or classification scheme itself, such as "concept X has preferred label 'Y' and is part of thesaurus Z"; these are not facts about the way the world is arranged, as are typically expressed in a formal ontology.
SKOS data are then expressed as RDF triples. For example, the RDF graph below expresses some facts about a thesaurus.
<A> rdf:type skos:Concept ; skos:prefLabel "love"@en ; skos:prefLabel "adoration"@en ; skos:broader <B> ; skos:inScheme <C> . <B> rdf:type skos:Concept ; skos:prefLabel "emotion"@en ; skos:altLabel "feeling"@en ; skos:inScheme <C> . <C> rdf:type skos:ConceptScheme ; dc:title "My First Thesaurus" ; skos:hasTopConcept <B> .
This point is vital to understanding the formal definition of the SKOS data model, and how it may be implemented in software systems. This point is also vital to more advanced applications of SKOS, especially where SKOS and OWL are used in combination as part of a hybrid formal/semi-formal design.
From a users point of view, however, the distinction between a formal
knowledge representation system and an informal or semi-formal knowledge
organization system may naturally become blurred, and can often be ignored
without any serious repercussions. In other words, it may not be relevant to
a user that <A>
and <B>
in the graph
below are individuals (instances of skos:Concept
), and
<C>
and <D>
are classes (instances of
owl:Class
) .
<A> rdf:type skos:Concept ; skos:prefLabel "love"@en ; skos:broader <B> . <B> rdf:type skos:Concept ; skos:prefLabel "emotion"@en . <C> rdf:type owl:Class ; rdfs:label "mammals"@en ; rdfs:subClassOf <D> . <D> rdf:type owl:Class ; rdfs:label "animals"@en .
An information system that has any awareness of the SKOS data model will, however, need to appreciate the distinction.
Under the RDF and OWL Full semantics, the formal meaning (interpretation) of an RDF graph is a truth value [@@REF-RDF-SEMANTICS] [@@REF-OWL-SEMANTICS]. I.e. an RDF graph is interpreted as either true or false.
In general, an RDF graph is said to be inconsistent if it cannot possibly be true. In other words, an RDF graph is inconsistent if it contains a contradiction.
Using the RDF and RDFS vocabularies alone, it is virtually impossible to make a contradictory statement. When the OWL vocabulary is used as well, there are many ways to state a contradiction. For example, consider the RDF graph below.
<Foo> rdf:type owl:Class . <Bar> rdf:type owl:Class . <Foo> owl:disjointWith <Bar> . <foobar> rdf:type <Foo> , <Bar> .
The graph states that <Foo>
and
<Bar>
are both classes, and that they are disjoint, i.e.
that they do not have any members in common. This is contradicted by the
statement that <foobar>
has type both
<Foo>
and <Bar>
. There is no OWL Full
interpretation which can satisfy this graph, and therefore this graph is
not OWL Full consistent.
When OWL Full is used as a knowledge representation language, the notion of inconsistency is useful because it reveals contradictions within the axioms and facts that are asserted in an ontology. By resolving these inconsistencies, we learn more about a domain of knowledge, and come to a better model of that domain from which interesting and valid inferences can be drawn.
When OWL Full is used as a data modeling (i.e. schema) language, the notion of inconsistency is again useful, but in a different way. Here we are not concerned with the logical consistency of human knowledge itself. We are simply interested in formally defining a data model, so that we can establish with certainty whether or not some given data conforms to or "fits" with the given data model. If the data is inconsistent with respect to the data model, then it does not "fit".
Here, we are not concerned with whether or not some given data has any correspondence with the "real world", i.e. whether it is true or false in any absolute sense. We are simply interested in whether or not the data fits the data model, because interoperability within a given class of applications depends on data conforming to a common data model.
Another way to express this view is via the notion of integrity. Integrity conditions are statements within the formal definition of a data model, which are used to establish whether or not given data is consistent with respect to the data model.
For example, the statement that <Foo>
and
<Bar>
are disjoint classes can be viewed as an integrity
condition on a data model. Given this condition, the data below is then not
(OWL Full) consistent.
<foobar> rdf:type <Foo> , <Bar> .
The definition of the SKOS data model given in this document contains a limited number of statements that are intended as integrity conditions. These integrity conditions are included to promote interoperability, by defining the circumstances under which data is not consistent with respect to the SKOS data model. Tools can then be implemented which "check" whether some or all of these integrity conditions are met for given data, and therefore whether the data "fits" the SKOS data model.
These integrity conditions are part of the formal definition of the SKOS data model, however they are presented separately from other parts of the formal definition because they serve a different purpose. Integrity conditions serve primarily to establish whether given data is consistent with the SKOS data model. All other statements within the definition of the SKOS data model serve only to support logical inferences (see also the next sub-section).
Integrity conditions are defined for the SKOS data model in a way that is independent of strategies for their implementation, in so far as that is possible. This is because there are several different ways in which a procedure to find inconsistencies with the SKOS data model could be implemented. For example, inconsistencies could be found using an OWL reasoner. Alternatively, some inconsistencies could be found by searching for specific patterns within the data, or by a hybrid strategy (draw inferences using an RDFS or OWL reasoner, then search for patterns in the inferred graph).
The integrity conditions on the SKOS data model are fewer than might be expected, especially for those used to working within the "closed world" of database systems. See also the next sub-section, and the notes in sections 3-11 below.
This document defines the SKOS data model as an OWL Full ontology. There are other, alternate ways in which the SKOS data model could have been defined, for example as an entity-relationship model, or a UML class model. Although OWL Full as a data modeling language appears intuitively similar in many ways to these other modeling approaches, there is an important fundamental distinction.
RDF and OWL Full are designed for systems in which data may be widely distributed (e.g. the Web). As such a system becomes larger, it becomes both impractical and virtually impossible to "know" where all of the data in the system is located. Therefore, one cannot generally assume that data obtained from such a system is "complete". I.e. if some data appears to be "missing", one has to assume, in general, that the data might exist somewhere else in the system. This assumption, roughly speaking, is known as the "open world" assumption. @@TODO add reference to formal definition of OWA
This means in practice that, for a data model defined as an OWL Full ontology, some definitions can have an unexpected meaning. No conclusions can be drawn from "missing" data, and removing something will never make the remaining data inconsistent.
For example, in section 7 below, the
property skos:semanticRelation
is defined to have domain and
range skos:Concept
. These statements are not
integrity conditions. I.e. the graph below is perfectly
consistent with the SKOS data model, despite the fact that
<A>
and <B>
have not been explicitly
declared as instances of skos:Concept
.
<A> skos:semanticRelation <B> .
In fact, the domain and range definitions give license to inferences. In this case, the graph above (RDFS and OWL Full) entails the following graph. I.e. the following graph can be deduced or inferred.
<A> rdf:type skos:Concept . <B> rdf:type skos:Concept .
In the SKOS data model, most statements of definition are
not integrity conditions, but are statements of logical
dependency between different elements of the data model, which under the
open-world assumption give license to a number of simple inferences. For
example, in section 7 below,
skos:broader
and skos:narrower
are defined as
inverse properties. This statement means that
<A> skos:narrower <B> .
entails
<B> skos:broader <A> .
Both of these two graphs are, by themselves, consistent with the SKOS data model.
Knowledge organization systems such as thesauri and classification schemes are applied in a wide range of situations, and an individual knowledge organization system can be used in many different information systems. By defining the SKOS data model as an OWL Full ontology, the Semantic Web can then be used as a medium for publishing, exchanging, sharing and "joining up" data involving these knowledge organization systems. For this reason, for the expressiveness of OWL Full as a data modeling language, and for the possibility of then using thesauri, classification schemes etc. side-by-side with formal ontologies, OWL Full has been used to define the SKOS data model. The "open world" assumption is therefore a fundamental premise of the SKOS data model, and should be borne in mind when reading this document.
See also [@@REF-RDF-PRIMER] and [@@OWL-GUIDE].
This document formally defines the Simple Knowledge Organization System data model as an OWL Full ontology. The "elements" of the SKOS data model are OWL classes and properties, and a Uniform Resource Identifier (URI) is provided for each of these classes and properties so that they may be used unambiguously in the Web. This set of URIs comprises the SKOS vocabulary.
The complete SKOS vocabulary is given in section 2 below. Sections 3 to 11 then formally define the SKOS data model. The definition of the data model is broken down into a number of sections purely for convenience. Each of these sections 3 to 11 follows a common layout:
Most of the class and property definitions and integrity conditions stated in this document could be stated as RDF triples, using the RDF, RDFS and OWL vocabularies. However, a small number cannot, either because of limitations in the expressiveness of OWL Full or lack of standard URI for some class. To improve the overall readability of this document, rather than mix RDF triples and other notations, the formal definitions and integrity conditions are stated throughout using prose.
The style of this prose generally follows the style used in [@@REF-RDFS], and should be clear to a reader with a working knowledge of RDF and OWL.
So, for example, "ex:Foo
is an instance of
owl:Class
" means
ex:Foo rdf:type owl:Class .
"ex:p
and ex:q
are each instances of
owl:ObjectProperty
" means
ex:p rdf:type owl:ObjectProperty . ex:q rdf:type owl:ObjectProperty .
"ex:p
is a sub-property of ex:q
" means
ex:p rdfs:subPropertyOf ex:q .
"the rdfs:range
of ex:p
is the class
ex:Foo
" means
ex:p rdfs:range ex:Foo .
etc.
Where some formal aspects of the SKOS data model cannot be stated as RDF triples using either RDF, RDFS or OWL vocabularies, it should be clear to a reader with a basic understanding of the RDF and OWL semantics how these statements might be translated into formal conditions on the interpretation of an RDF vocabulary.
For example, from section 5, "A resource has
no more than one value of skos:prefLabel
per language" means for
any resource x, no two members of the set { y | <x,y> is in
IEXT(I(skos:prefLabel
)) } share the same language tag (where I
and IEXT are functions as defined in [@@REF-RDF-SEMANTICS]).
Editors' note: The Working Group is considering alternate ways of presenting the formal class and property definitions and integrity conditions given in this specification. This is recorded as ISSUE-67 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group, starting the subject line with "Comment: ISSUE-67"
Full URIs are cited in the text of this document in monospace font,
enclosed by angle brackets. For example,
<http://example.org/ns/example>
. Relative URIs are cited
in the same way, and are relative to the base URI
<http://example.org/ns/>
. For example,
<example>
and
<http://example.org/ns/example>
are the same URI.
URIs are also cited in the text of this document in an abbreviated form. Abbreviated URIs are cited in monospace font without angle brackets, and should be expanded using the table of abbreviations below.
URI | Abbreviation |
---|---|
http://www.w3.org/2004/02/skos/core# | skos: |
http://www.w3.org/1999/02/22-rdf-syntax-ns# | rdf: |
http://www.w3.org/2000/01/rdf-schema# | rdfs: |
http://www.w3.org/2002/07/owl# | owl: |
So, for example, skos:Concept
is an abbreviation of
<http://www.w3.org/2004/02/skos/core#Concept>
.
Examples of RDF graphs are given using the Terse RDF Triple language (Turtle) [@@REF-TURTLE]. All examples assume that they are preceded by the following prefix and URI base directives:
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@base <http://example.org/ns/> .
Therefore, the example given below
Example 1 |
---|
<MyConcept> rdf:type skos:Concept .
|
is equivalent to the following Turtle document
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@base <http://example.org/ns/> . <MyConcept> rdf:type skos:Concept .
which is equivalent to the following RDF/XML document [@@REF-RDF/XML]
<?xml version="1.0" encoding="UTF-8"?> <rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:skos="http://www.w3.org/2004/02/skos/core#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xml:base="http://example.org/ns/"> <skos:Concept rdf:about="MyConcept"/> </rdf:RDF>
which is equivalent to the following N-TRIPLES document [@@REF-N-TRIPLES]
<http://example.org/ns/MyConcept> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2004/02/skos/core#Concept> .
Note the use in Turtle of the ";" and "," characters to abbreviate multiple triples with the same subject or predicate.
This specification does not define a formal notion of conformance.
However, an RDF graph will be inconsistent with the SKOS data model if that graph and the SKOS data model (as defined formally below) together lead to a logical contradiction.
Appendix B below gives some rules of thumb for avoiding inconsistency with the SKOS data model when constructing RDF graphs.
The SKOS vocabulary is a set of URIs, given in the left-hand column in the table below.
See also the quick reference table in Appendix A.
The class skos:Concept
is the class of SKOS conceptual
resources.
A conceptual resource can be viewed as an idea or notion; a unit of thought. However, what constitutes a "unit of thought" is subjective, and this definition is meant to be suggestive, rather than restrictive.
The notion of a conceptual resource is useful when describing the conceptual or intellectual structure of a knowledge organization system, and when referring to specific ideas or meanings established within a KOS.
Note that, because SKOS is designed to be a vehicle for representing semi-formal KOS, such as thesauri and classification schemes, a certain amount of flexibility has been built in to the formal definition of this class. See also the notes below.
See the upcoming SKOS Primer for more examples of identifying and describing conceptual resources.
skos:Concept |
S1 | skos:Concept is an instance of
owl:Class . |
The graph below states that <MyConcept>
is a conceptual
resource (i.e. an instance of skos:Concept
). This graph is
consistent with the SKOS data model.
Example 2 |
---|
<MyConcept> rdf:type skos:Concept .
|
This specification does not make any statement about the formal relationship between the class of SKOS conceptual resources and the class of OWL classes. The decision not to make any such statement has been made to allow applications the freedom to explore different design patterns for working with SKOS in combination with OWL.
For example, in the graph below, <MyConcept>
is an
instance of skos:Concept
and an instance of
owl:Class
.
Example 3 |
---|
<MyConcept> rdf:type skos:Concept , owl:Class .
|
This example is consistent with the SKOS data model.
However, note that it is not compatible with OWL DL, because
the URI <MyConcept>
has been used to denote both a class
and an individual. To work within the OWL DL language, take care
not to use the same URI to denote both an OWL class and a
SKOS conceptual resource.
Similarly, this specification does not make any statement about the formal relationship between the class of SKOS conceptual resources and the class of OWL object properties.
For example, in the graph below, <MyConcept>
is an
instance of skos:Concept
and an instance of
owl:ObjectProperty
.
Example 4 |
---|
<MyConcept> rdf:type skos:Concept , owl:ObjectProperty .
|
This example is consistent with the SKOS data model.
However, it is not compatible with OWL DL, because the URI
<MyConcept>
has been used to denote both an object
property and an individual.
For more information on recommended design patterns for working with SKOS in combination with OWL, see appendix D.
A SKOS concept scheme can be viewed as an aggregation of one or more conceptual resources. Semantic relationships (links) between those conceptual resources may also be viewed as part of a concept scheme. This definition is, however, meant to be suggestive rather than restrictive, and there is a certain amount of flexibility in the formal semantics stated below (see also the notes below).
The notion of a concept scheme is useful when dealing with data from an unknown source, and when dealing with data that describes two or more different knowledge organization systems.
See the upcoming SKOS Primer for more examples of identifying and describing concept schemes.
skos:ConceptScheme |
skos:inScheme |
skos:hasTopConcept |
S2 | skos:ConceptScheme is an instance of
owl:Class . |
S3 | skos:inScheme and skos:hasTopConcept are
each instances of owl:ObjectProperty . |
S4 | The rdfs:range of skos:inScheme is the
class skos:ConceptScheme . |
S5 | The rdfs:domain of skos:hasTopConcept is
the class skos:ConceptScheme . |
S6 | The rdfs:range of skos:hasTopConcept is
the class skos:Concept . |
S7 | skos:ConceptScheme is disjoint with
skos:Concept . |
The graph below describes a concept scheme with two conceptual resources, one of which is a top-level concept in that scheme, and is consistent with the SKOS data model.
Example 5 |
---|
<MyScheme> rdf:type skos:ConceptScheme ;
skos:hasTopConcept <MyConcept> . <MyConcept> skos:inScheme <MyScheme> . <AnotherConcept> skos:inScheme <MyScheme> . |
The notion of an individual SKOS concept scheme corresponds roughly to the notion of an individual thesaurus, classification scheme, subject heading system or other knowledge organization system.
However, in most current information systems, a thesaurus or classification scheme is treated as a closed system — conceptual units defined within that system cannot take part in other systems (although they can be mapped to units in other systems).
Although SKOS does take a similar approach, there are no conditions preventing a conceptual resource from taking part in zero, one, or more than one concept scheme.
So, for example, in the graph below the conceptual resource
<MyConcept>
takes part in two different concept schemes
— this is consistent with the SKOS data model.
Example 6 |
---|
<MyScheme> rdf:type skos:ConceptScheme .
<AnotherScheme> rdf:type skos:ConceptScheme ; owl:differentFrom <MyScheme> . <MyConcept> skos:inScheme <MyScheme> , <AnotherScheme> . |
This flexibility is desirable because it allows, for example, new concept schemes to be described by linking two or more existing concept schemes together.
Also, note that there is no way to close the boundary of a concept scheme.
So, while it is possible using skos:inScheme
to say that
conceptual resources X, Y and Z take part in concept scheme A, there is no
way to say that only X, Y and Z take part in A.
Therefore, while SKOS can be used to describe a concept scheme, SKOS does not provide any mechanism to completely define a concept scheme.
This specification does not make any statement about the formal relationship between the class of SKOS concept schemes and the class of OWL ontologies. The decision not to make any such statement has been made to allow different design patterns to be explored for using SKOS in combination with OWL [@@REF-OWL].
For example, in the graph below, <MyScheme>
is both a
concept scheme and an OWL ontology. This is consistent with
the SKOS data model.
Example 7 |
---|
<MyScheme> rdf:type skos:ConceptScheme , owl:Ontology .
<MyConcept> skos:inScheme <MyScheme> . |
In the example below, owl:imports
has been used to state that
one concept scheme logically imports another concept scheme, according to the
semantics and processing rules defined for importing OWL ontologies [@@REF].
Again, this is consistent with the SKOS data model.
Example 8 |
---|
<MyScheme> rdf:type skos:ConceptScheme .
<AnotherScheme> rdf:type skos:ConceptScheme . <MyScheme> owl:imports <AnotherScheme> . |
Note, however, that there is no logical dependency between
skos:inScheme
and owl:imports
. Therefore, the
entailment illustrated below is not supported by the SKOS
data model.
Example 9 |
---|
<MyConcept> skos:inScheme <MyScheme> .
<AnotherScheme> owl:imports <MyScheme> . does not entail
<MyConcept> skos:inScheme <AnotherScheme> .
|
For more information on recommended patterns for working with SKOS in combination with OWL, see appendix D.
This specification does not make any statement about the formal relationship between the class of SKOS concept schemes and the class of named RDF Graphs. The decision not to make any such statement has been made to allow different design patterns to be explored for using SKOS with query languages such as SPARQL [@@REF].
For more information about patterns for using SKOS with SPARQL, see appendix E.
The property skos:hasTopConcept
is, by convention, used to
link a concept scheme to the conceptual resource(s) which are topmost in the
hierarchical relations for that scheme. However, note that there are no
integrity conditions enforcing this convention. Therefore, the graph below,
whilst not adhering to the usage convention for
skos:hasTopConcept
, is nevertheless consistent
with the SKOS data model.
Example 10 |
---|
<MyScheme> skos:hasTopConcept <MyConcept> .
<MyConcept> skos:inScheme <MyScheme> ; skos:broader <AnotherConcept> . <AnotherConcept> skos:inScheme <MyScheme> . |
A lexical label is a string of UNICODE characters, such as "romantic love" or "れんあい", in a given natural language, such as English or Japanese Hiragana.
The Simple Knowledge Organization System provides some basic vocabulary for associating lexical labels with resources of any type. In particular, SKOS enables a distinction to be made between the "preferred", "alternate" and "hidden" lexical labels for any given resource.
The "preferred" and "alternate" labels are useful when generating or creating human-readable representations of a knowledge organization system. These labels provide the strongest clues as to the meaning of a conceptual resource.
The "hidden" labels are useful when a user is interacting with a knowledge organization system via a text-based search function. The user may, for example, enter mis-spelled words when trying to find a relevant concept. If the mis-spelled query can be matched against a "hidden" label, the user will be able to find the relevant concept, but the "hidden" label won't otherwise be visible to the user (so further mistakes aren't encouraged).
Formally, a lexical label is an RDF plain literal [@@REF-RDF-CONCEPTS]. An RDF plain literal is composed of a lexical form, which is a string of UNICODE characters, and an optional language tag, which is a string of characters conforming to the syntax defined by [@@BCP47].
See the @@Primer for more examples of labeling conceptual resources.
skos:prefLabel |
skos:altLabel |
skos:hiddenLabel |
S8 |
skos:prefLabel ,
skos:altLabel and skos:hiddenLabel are each
instances of owl:DatatypeProperty . |
S9 | The rdfs:range of skos:prefLabel ,
skos:altLabel and skos:hiddenLabel is the
class of RDF plain literals. |
S10 | skos:prefLabel , skos:altLabel and
skos:hiddenLabel are pairwise disjoint properties. |
S11 | A resource has no more than one value of
skos:prefLabel per language. |
N.B. the conditions above assume that each distinct language tag allowed by [BCP 47] denotes a different "language". E.g. "en", "en-GB" and "en-US" denote three different languages (English, British English and US English respectively). E.g. "ja", "ja-Hani", "ja-Hira", "ja-Kana" and "ja-Latn" denote five different languages (Japanese, Japanese Kanji, Japanese Hiragana, Japanese Katakana and Japanese Rōmaji respectively).
The following graph is consistent, and illustrates the provision of lexical labels in two different languages (French and English).
Example 11 |
---|
<MyResource>
skos:prefLabel "animals"@en ; skos:altLabel "fauna"@en ; skos:hiddenLabel "aminals"@en ; skos:prefLabel "animaux"@fr ; skos:altLabel "faune"@fr . |
The following graph is consistent, and illustrates the provision of lexical labels in four different languages (Japanese Kanji, Japanese Hiragana, Japanese Katakana and Japanese Rōmaji).
Example 12 |
---|
<AnotherResource>
skos:prefLabel "東"@ja-Hani ; skos:prefLabel "ひがし"@ja-Hira ; skos:altLabel "あずま"@ja-Hira ; skos:prefLabel "ヒガシ"@ja-Kana ; skos:altLabel "アズマ"@ja-Kana ; skos:prefLabel "higashi"@ja-Latn ; skos:altLabel "azuma"@ja-Latn . |
The following graph is not consistent with the SKOS data model, because two different preferred lexical labels have been given for the same language.
Example 13 |
---|
<FooResource> skos:prefLabel "foo"@en ; skos:prefLabel "bar"@en
.
|
The following graph is not consistent with the SKOS data model, because there is a "clash" between the preferred and alternate lexical labels.
Example 14 |
---|
<FooResource> skos:prefLabel "foo"@en ; skos:altLabel "foo"@en
.
|
The following graph is not consistent with the SKOS data model, because there is a "clash" between alternate and hidden lexical labels.
Example 15 |
---|
<FooResource> skos:altLabel "foo"@en ; skos:hiddenLabel
"foo"@en .
|
The following graph is not consistent with the SKOS data model, because there is a "clash" between preferred and hidden lexical labels.
Example 16 |
---|
<FooResource> skos:prefLabel "foo"@en ; skos:hiddenLabel
"foo"@en .
|
Note that no domain is stated for
skos:prefLabel
, skos:altLabel
and
skos:hiddenLabel
. Thus, the effective domain of these properties
is the class of all resources (rdfs:Resource
).
Therefore, using the properties skos:prefLabel
,
skos:altLabel
and skos:hiddenLabel
to label
any type of resource is consistent with the SKOS
data model.
For example, in the graph below, skos:prefLabel
,
skos:altLabel
and skos:hiddenLabel
have been used
to label a resource of type owl:Class
— this is
consistent with the SKOS data model.
Example 17 |
---|
<MyClass> rdf:type owl:Class ;
skos:prefLabel "animals"@en ; skos:altLabel "fauna"@en ; skos:hiddenLabel "aminals"@en ; skos:prefLabel "animaux"@fr ; skos:altLabel "faune"@fr . |
This example is, however, incompatible with OWL DL, because a datatype
property has been used to make assertions about a class. To work within the
OWL DL language, treat skos:prefLabel
,
skos:altLabel
and skos:hiddenLabel
as annotation
properties.
For more information on recommended best practice for using SKOS in combination with OWL, see appendix D.
Note that the range of skos:prefLabel
,
skos:altLabel
and skos:hiddenLabel
is the class of
RDF plain literals [@@REF-RDF-CONCEPTS].
By convention, RDF plain literals are always used in the object position
of a triple, where the predicate is one of skos:prefLabel
,
skos:altLabel
or skos:hiddenLabel
. However, there
is nothing in the RDF or OWL Full semantics which prevents the use of a URI
or a blank node to denote an RDF plain literal. Therefore, although the graph
below does not adhere to the usage convention stated above, it is
consistent with the SKOS data model.
Example 18 |
---|
<FooResource> skos:prefLabel <bar> .
|
In the graph below, a resource has two alternate lexical labels, but no preferred lexical label. This is consistent with the SKOS data model, and there are no additional entailments which follow from the semantics. However, note that many applications will require a preferred lexical label in order to generate an optimum human-readable display.
Example 19 |
---|
<FooResource> skos:altLabel "foo"@en , "bar"@en .
|
Note how "language" has been defined for the conditions above. Each different language tag permissible by [@@BCP 47] is taken to denote a different "language". Therefore the graph below is consistent with the SKOS data model, because "en", "en-US" and "en-GB" are taken to denote different languages.
Example 20 |
---|
<FooResource> skos:prefLabel "color"@en , "color"@en-US ,
"color"@en-GB .
|
In the graph below, there is no "clash" between the lexical labeling properties, again because "en" and "en-GB" are taken to denote different languages, and therefore the graph is consistent.
Example 21 |
---|
<FooResource> skos:prefLabel "foo"@en ; skos:altLabel
"foo"@en-GB .
|
Notes are used to provide information relating to conceptual resources. There is no restriction on the nature of this information. For example, it could be plain text, hypertext, or an image; it could be a definition, information about the scope of a conceptual resource, editorial information, or any other type of information.
There are 7 properties in SKOS for associating notes with conceptual resources, defined formally in this section. For more information on the recommended usage of each of the SKOS documentation properties, see the @@Primer.
These 7 properties are not intended to cover every situation, but rather to be useful in some of the most common situations, and to provide a set of extension points for defining more specific types of note. For more information on recommended best practice for extending SKOS, see appendix F.
Three different usage patterns are recommended in the @@Primer for the SKOS documentation properties — "documentation as an RDF literal", "documentation as a related resource description" and "documentation as a document reference". The formal semantics stated in this section are intended to accommodate all three design patterns. See also the notes below.
skos:note |
skos:changeNote |
skos:definition |
skos:editorialNote |
skos:example |
skos:historyNote |
skos:scopeNote |
S12 |
skos:note , skos:changeNote ,
skos:definition , skos:editorialNote ,
skos:example , skos:historyNote and
skos:scopeNote are each instances of
owl:ObjectProperty . |
S13 | skos:changeNote , skos:definition ,
skos:editorialNote , skos:example ,
skos:historyNote and skos:scopeNote are
each sub-properties of skos:note . |
The graph below gives a consistent example of the "documentation as an RDF literal" pattern.
Example 22 |
---|
<MyResource> skos:note "foo bar"@en .
|
The graph below gives a consistent example of the "documentation as a related resource description" pattern.
Example 23 |
---|
<MyResource> skos:note [ rdf:value "foo bar"@en ] .
|
The graph below gives a consistent example of the "documentation as a document reference" pattern.
Example 24 |
---|
<MyResource> skos:note <MyNote> .
|
Note that no domain is stated for the SKOS documentation
properties. Thus, the effective domain for these properties is the class of
all resources (rdfs:Resource
). Therefore, using the SKOS
documentation properties to provide information on any type of
resource is consistent with the SKOS data model.
For example, in the graph below, skos:definition
has been
used to provide a plain text definition for a resource of type
owl:Class
— this is consistent with the SKOS data model.
Example 25 |
---|
<Protein> rdf:type owl:Class ;
skos:definition """A physical entity consisting of a sequence of amino-acids; a protein monomer; a single polypeptide chain. An example is the EGFR protein."""@en . |
This example is, however, incompatible with OWL DL, because an object property has been used to make an assertion about a class. To use graphs like this and work within the OWL DL language, treat the SKOS documentation properties as annotation properties. For more on recommended best practice for using SKOS in combination with OWL, see appendix D.
Note that the basis for the SKOS data model is the RDF-compatible
model-theoretic semantics for OWL Full [@@REF-OWL-SEMANTICS]. Under the OWL
Full semantics, the class of OWL datatype properties is a sub-class of the
class of OWL object properties [@@REF-OWL-REFERENCE]. Therefore, stating that
the SKOS documentation properties are all instances of
owl:ObjectProperty
is the most general statement that can be
made, and is consistent with all three usage patterns described in the
@@Primer.
Note also that no range is stated for the SKOS documentation properties,
and thus the range of these properties is effectively the class of all
resources (rdfs:Resource
). Under the RDF and OWL Full semantics,
everything is a resource, including RDF plain literals.
SKOS semantic relations are links between conceptual resources, where the link is inherent in the meaning of the linked conceptual resources.
The Simple Knowledge Organization System distinguishes between two basic categories of semantic relation: hierarchical and associative. A hierarchical link between two conceptual resources indicates that one is in some way more general ("broader") than the other ("narrower"). An associative link between two conceptual resources indicates that the two are inherently "related", but that one is not in any way more general than the other.
The properties skos:broader
and skos:narrower
are used to assert a hierarchical link between two conceptual resources.
Note that the properties skos:broader
and
skos:narrower
are not defined as a transitive
properties. Applications may wish to make use of the transitive closure of
skos:broader
(or skos:narrower
), for instance to
improve search recall through query expansion. For these purposes, transitive
super-properties skos:broaderTransitive
and
skos:narrowerTransitive
are provided.
By convention, skos:broader
and skos:narrower
are only used to assert an immediate (i.e. direct)
hierarchical link between two conceptual resources.
By convention, the properties skos:broaderTransitive
and
skos:narrowerTransitive
are not used to make
assertions. Rather, these properties are used to draw inferences about the
transitive closure of the hierarchical relation, which is useful e.g. when
implementing a simple query expansion algorithm in a search application.
The property skos:related
is used to assert an associative
link between two conceptual resources.
For more examples of stating hierarchical and associative links, see the @@Primer.
skos:semanticRelation |
skos:broader |
skos:narrower |
skos:related |
skos:broaderTransitive |
skos:narrowerTransitive |
S14 |
skos:semanticRelation ,
skos:broader , skos:narrower ,
skos:related , skos:broaderTransitive and
skos:narrowerTransitive are each instances of
owl:ObjectProperty . |
S15 | The rdfs:domain of skos:semanticRelation
is the class skos:Concept . |
S16 | The rdfs:range of skos:semanticRelation
is the class skos:Concept . |
S17 | skos:broaderTransitive ,
skos:narrowerTransitive and skos:related
are each sub-properties of skos:semanticRelation . |
S18 | skos:broader is a sub-property of
skos:broaderTransitive , and skos:narrower
is a sub-property of skos:narrowerTransitive . |
S19 | skos:related is an instance of
owl:SymmetricProperty . |
S20 | skos:broader , skos:narrower and
skos:related are each not instances of
owl:TransitiveProperty . |
S21 | skos:broaderTransitive and
skos:narrowerTransitive are each instances of
owl:TransitiveProperty . |
S22 | skos:narrower is the owl:inverseOf the
property skos:broader . |
S23 | skos:narrowerTransitive is the
owl:inverseOf the property
skos:broaderTransitive . |
S24 | skos:related is disjoint with the property
skos:broaderTransitive . |
The graph below asserts a hierarchical link between <A>
and <B>
, and an associative link between
<A>
and <C>
, and is
consistent with the SKOS data model.
Example 26 |
---|
<A> skos:broader <B> ; skos:related <C> .
|
The graph below is not consistent with the SKOS data model, because there is a "clash" between associative links and hierarchical links.
Example 27 |
---|
<A> skos:broader <B> ; skos:related <B> .
|
The graph below is not consistent with the SKOS data model, again because there is a "clash" between associative links and hierarchical links.
Example 28 |
---|
<A> skos:broader <B> ; skos:related <C> .
<B> skos:broader <C> . |
In the example above, the "clash" is not immediately obvious. The "clash" becomes apparent when inferences are drawn, based on the class and property definitions above, giving the following graph.
Example 29 |
---|
<A> skos:broaderTransitive <C> ; skos:related <C>
.
|
The graph below is not consistent with the SKOS data model, again because there is a "clash" between associative links and hierarchical links, which can be inferred from the class and property definitions given above.
Example 30 |
---|
<A> skos:narrower <B> ; skos:related <C> .
<B> skos:narrower <C> . |
The diagram below illustrates informally the sub-property relationships between the SKOS semantic relation properties.
skos:semanticRelation | +— skos:related | +— skos:broaderTransitive | | | +— skos:broader | +— skos:narrowerTransitive | +— skos:narrower
Note that the domain and range of skos:semanticRelation
is
the class skos:Concept
. Because skos:broader
,
skos:narrower
and skos:related
are each
sub-properties of skos:semanticRelation
, the graph in example 30
above entails that <A>
, <B>
and
<C>
are each instances of skos:Concept
.
skos:related
is a symmetric property. The example below
illustrates an entailment which follows from this condition.
Example 31 |
---|
<A> skos:related <B> .
entails
<B> skos:related <A> .
|
Note that, although skos:related
is a symmetric property,
this condition does not place any restrictions on
sub-properties of skos:related
. I.e. sub-properties of
skos:related
could be symmetric, not symmetric or antisymmetric,
and still be consistent with the SKOS data model.
To illustrate this point, in the example below, two new properties which
are not symmetric are declared as sub-properties of
skos:related
. The example, which is consistent
with the SKOS data model, also shows some of the entailments which follow.
Example 32 |
---|
<cause> rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf skos:related . <effect> rdf:type owl:ObjectProperty ; rdfs:subPropertyOf skos:related ; owl:inverseOf <cause> . <A> <cause> <B> . entails
<A> skos:related <B> .
<B> <effect> <A> ; skos:related <A> . |
See also appendix F for best practice recommendations on extending SKOS.
Note that skos:related
is not a transitive
property. Therefore, the SKOS data model does not support an
entailment as illustrated in the example below.
Example 33 |
---|
<A> skos:related <B> .
<B> skos:related <C> . does not entail
<A> skos:related <C> .
|
Note that this specification does not state that skos:related
is a reflexive property, neither does it
state that skos:related
is an irreflexive property.
Because skos:related
is not defined as an
irreflexive property, the graph below is consistent with the
SKOS data model.
Example 34 |
---|
<A> skos:related <A> .
|
Editors' note: The Working Group has noted that, for many applications, it might be more useful to define skos:related as an irreflexive property, which would mean that the example above was made inconsistent with the SKOS data model. This is recorded as ISSUE-68 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group, starting the subject line with "Comment: ISSUE-68".
Note that skos:broader
is not a transitive
property. Similarly, skos:narrower
is not a
transitive property. Therefore, the SKOS data model does not
support an entailment as illustrated in the example below.
Example 35 |
---|
<A> skos:broader <B> .
<B> skos:broader <C> . does not entail
<A> skos:broader <C> .
|
However, skos:broader
is a sub-property of
skos:broaderTransitive
, which is a transitive
property. Similarly, skos:narrower
is a sub-property of
skos:narrowerTransitive
, which is a transitive
property. Therefore the SKOS data model does support the
entailment illustrated below.
Example 36 |
---|
<A> skos:broader <B> .
<B> skos:broader <C> . entails
<A> skos:broaderTransitive <C> .
|
Note especially that, by convention, skos:broader
and
skos:narrower
are only used to assert immediate
(i.e. direct) hierarchical links between two conceptual resources. By
convention, skos:broaderTransitive
and
skos:narrowerTransitive
are not used to make
assertions, but are instead used only to draw inferences.
This pattern allows the information about direct hierarchical links to be preserved, which is necessary for many tasks (e.g. building various types of visual representation of a knowledge organization system), whilst also providing a mechanism for conveniently querying the transitive closure of those hierarchical links, which is useful in other situations (e.g. simple query expansion algorithms).
Note also that a sub-property of a transitive property is not necessarily transitive.
See also the note on alternate paths below.
Editors' note: At the time of writing, this pattern is under discussion by the Working Group, and represents a proposed partial resolution to ISSUE-44 in the Working Group's issue process. In particular, alternate names (URIs) have been suggested for the transitive variants of the hierarchical link properties: skos:broaderAncestor (instead of skos:broaderTransitive) and skos:narrowerDescendant (instead of skos:narrowerTransitive). The Working Group invites comments on this pattern and on the naming of the properties. Comments should be sent in an email to the SWD Working Group, starting the subject line with "Comment: ISSUE-44".
Note that this specification does not state that skos:broader
is a reflexive property, neither does it
state that skos:broader
is an irreflexive property.
Because skos:broader
is not defined as
irreflexive, the graph below is consistent with the SKOS
data model.
Example 37 |
---|
<A> skos:broader <A> .
|
Editors' note: The Working Group has noted that, for many applications, it might be more useful to define skos:broader as an irreflexive property, which would mean that the example above was made inconsistent with the SKOS data model. This is recorded as ISSUE-69 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group, starting the subject line with "Comment: ISSUE-69".
In the graph below, a cycle has been stated in the hierarchical relation.
Note that this graph is consistent with the SKOS data model.
I.e. there is no condition requiring that
skos:broaderTransitive
be irreflexive.
Example 38 |
---|
<A> skos:broader <B> .
<B> skos:broader <A> . |
Editors' note: The Working Group has noted that, for many applications, it might be more useful to define skos:broaderTransitive as an irreflexive property, which would mean that the example above was made inconsistent with the SKOS data model (i.e. cycles in the hierarchical relation are inconsistent with the SKOS data model). This is recorded as ISSUE-70 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group, starting the subject line with "Comment: ISSUE-70".
In the graph below, there are two alternate paths from A to C in the hierarchical relation.
Example 39 |
---|
<A> skos:broader <B> , <C> .
<B> skos:broader <C> . |
In the graph below, there are two alternate paths from A to D in the hierarchical relation.
Example 40 |
---|
<A> skos:broader <B,> <C> .
<B> skos:broader <D> . <C> skos:broader <D> . |
This is a pattern which arises naturally in "poly-hierarchical" knowledge organization systems.
Both of these graphs are consistent with the SKOS data model. I.e. there is no condition requiring that there be only one path between any two nodes in the hierarchical relation.
This specification treats the hierarchical and associative relations as fundamentally distinct in nature, and that therefore a "clash" between hierarchical and associative links is not consistent with the SKOS data model. The examples above illustrate some situations in which a "clash" is seen to arise.
This position follows the usual definitions given to hierarchical and associative relations in thesaurus standards [@@REF-ISO2788] [@@REF-BS8273-2], and supports common practice in many existing knowledge organization systems.
Note that this specification takes the stronger position that, not only
are the immediate (i.e. direct) hierarchical and associative links disjoint,
but associative links are also disjoint with indirect hierarchical
links. This is captured formally in the integrity condition asserting that
skos:related
and skos:broaderTransitive
are
disjoint properties.
SKOS label relations are n-ary relations between lexical labels.
SKOS provides some general vocabulary for describing label relations. This vocabulary is intended primarily as an extension point for more specific vocabulary describing various sub-types of label relation, such as transliteration relations, acronym relations, abbreviation relations etc. Defining vocabulary for each of these sub-types of label relation is beyond the scope of SKOS. See also appendix F for best practice recommendations for extending SKOS.
skos:LabelRelation |
skos:labelRelated |
skos:seeLabelRelation |
Editors' note: The Working Group is considering alternate URIs for the vocabulary defined in this section, which might be more intuitive. In particular, skos:relatedLabel has been offered as an alternate to skos:labelRelated. This is recorded as ISSUE-81 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group mailing list (public-swd-wg@w3.org), starting the subject line with "Comment: ISSUE-81".
S25 | skos:LabelRelation is an instance of
owl:Class . |
S26 | skos:labelRelated is an instance of
owl:DatatypeProperty . |
S27 | skos:seeLabelRelation is an instance of
owl:ObjectProperty . |
S28 | The rdfs:domain of skos:labelRelated is
the class skos:LabelRelation . |
S29 | The rdfs:range of skos:labelRelated is
the class of RDF plain literals. |
S30 | The rdfs:range of skos:seeLabelRelation
is the class skos:LabelRelation . |
S31 | skos:LabelRelation is disjoint with each of
skos:Concept and skos:ConceptScheme . |
The graph below illustrates a resource <MyResource>
which is linked to a label relation between three literals. This graph is
consistent with the SKOS data model.
Example 41 |
---|
<MyResource> skos:seeLabelRelation [ skos:labelRelated "foo"@en
, "bar"@en , "baz"@en ] .
|
The SKOS label relations vocabulary provides a basis for defining label relations of any arity. However, most label relations are typically binary. In the graph below, a specific sub-type of binary label relation is defined by extending SKOS.
Example 42 |
---|
<AcronymRelation> rdfs:subClassOf skos:LabelRelation .
<fullForm> rdfs:subPropertyOf skos:labelRelated . <acronymForm> rdfs:subPropertyOf skos:labelRelated . <FAOAcronymRelation> rdf:type <AcronymRelation> ; <fullForm> "Food and Agriculture Organization"@en ; <acronymForm> "FAO"@en . |
See also appendix F for best practice recommendations for extending SKOS.
There are no integrity conditions on the SKOS label relations vocabulary. This means that there does not necessarily have to be any correspondence whatsoever between the lexical labels of a resource, and the labels involved in an associated label relation. The example below, which is consistent with the SKOS data model, illustrates this.
Example 43 |
---|
<FooResource>
skos:prefLabel "foo"@en ; skos:altLabel "bar"@en ; skos:seeLabelRelation [ skos:labelRelated "baz"@en , "quux"@en ] . |
SKOS concept collections are labeled and/or ordered groups of conceptual resources.
Collections are useful where a group of conceptual resources shares something in common, and it is convenient to group them under a common label, or where some conceptual resources can be placed in a meaningful order.
skos:Collection |
skos:OrderedCollection |
skos:member |
skos:memberList |
S32 | skos:Collection and
skos:OrderedCollection are each instances of
owl:Class . |
S33 | skos:OrderedCollection is a sub-class of
skos:Collection . |
S34 | skos:member and skos:memberList are each
instances of owl:ObjectProperty . |
S35 | The rdfs:domain of skos:member is the
class skos:Collection . |
S36 | The rdfs:domain of skos:memberList is the
class skos:OrderedCollection . |
S37 | The rdfs:range of skos:memberList is the
class rdf:List . |
S38 | skos:memberList is an instance of
owl:FunctionalProperty . |
S39 | For any resource, every item in the list given as the value of the
skos:memberList property is also a value of the
skos:member property. |
S40 | skos:Collection is disjoint with each of
skos:Concept , skos:ConceptScheme and
skos:LabelRelation . |
The graph below illustrates a SKOS collection, and is consistent with the SKOS data model.
Example 44 |
---|
<MyCollection> rdf:type skos:Collection ;
skos:member <X> , <Y> , <Z> . |
The graph below illustrates an ordered SKOS collection, and is consistent with the SKOS data model.
Example 45 |
---|
<MyOrderedCollection> rdf:type skos:OrderedCollection ;
skos:memberList ( <X> <Y> <Z> ) . |
Statement S39 defines the logical relationship between the
skos:memberList
and skos:member
properties. This
relationship means, in practice, that a collection can be inferred from an
ordered collection. This is illustrated in the example below.
Example 46 |
---|
<MyOrderedCollection> rdf:type skos:OrderedCollection ;
skos:memberList ( <X> <Y> <Z> ) . entails
<MyOrderedCollection> rdf:type skos:Collection ;
skos:member <X> , <Y> , <Z> . |
Note that SKOS does not provide any way to explicitly state that a collection is not ordered.
Note that skos:memberList
is a functional property, i.e. it
does not have more than one value. This is intended to capture within the
SKOS data model that it doesn't make sense for an ordered collection to have
more than one member list. Unfortunately, there is no way to use this
condition as an integrity constraint without explicitly stating that two
lists are different objects. In other words, although the graph below is
consistent with the SKOS data model, it entails nonsense (a
list with two first elements and a forked tail).
Example 47 |
---|
<FooOrderedCollection>
skos:memberList ( <A> <B> ) , ( <X> <Y> ) . entails
<FooOrderedCollection>
skos:memberList [ rdf:first <A> , <X> ; rdf:rest [ rdf:first <B> ; rdf:rest rdf:nil ] , [ rdf:first <Y> ; rdf:rest rdf:nil ] . |
In the example below, a collection is nested within another collection.
Example 48 |
---|
<MyCollection> rdf:type skos:Collection ;
skos:member <A> , <B> , <MyNestedCollection> . <MyNestedCollection> rdf:type skos:Collection ; skos:member <X> , <Y> , <Z> . |
This example is consistent with the SKOS data model.
In the SKOS data model, skos:Concept
and
skos:Collection
are disjoint classes. The domain and range of
the SKOS semantic relation properties is skos:Concept
.
Therefore, if any of the SKOS semantic relation properties (e.g.
skos:narrower
) are used to link to or from a collection, the
graph will not be consistent with the SKOS data model.
This is illustrated in the example below, which is not consistent with the SKOS data model.
Example 49 |
---|
<A> skos:narrower <B> .
<B> rdf:type skos:Collection . |
Similarly, the graph below is not consistent with the SKOS data model.
Example 50 |
---|
<A> skos:broader <B> .
<B> rdf:type skos:Collection . |
Similarly, the graph below is not consistent with the SKOS data model.
Example 51 |
---|
<A> skos:related <B> .
<B> rdf:type skos:Collection . |
However, the graph below is consistent with the SKOS data model.
Example 52 |
---|
<A> skos:narrower <B> , <C> , <D> .
<FooCollection> rdfs:label "Foo Collection"@en ; skos:member <B> , <C> , <D> . |
This means that, for thesauri and other knowledge organization systems where "node labels" are used within the systematic display for that thesaurus, the appropriate SKOS representation requires careful consideration. Furthermore, where "node labels" are used in the systematic display, it may not always be possible to fully reconstruct the systematic display from a SKOS representation alone. Fully representing all of the information represented in a systematic display of a thesaurus or other knowledge organization system, including details of layout and presentation, is beyond the scope of SKOS.
SKOS concept mapping relations are links between conceptual resources in different concept schemes, where the links are inherent in the meaning of the linked conceptual resources.
The property skos:exactMatch
is used to indicate that two
conceptual resources in different concept schemes are sufficiently similar
that they can be used interchangeably in an information retrieval
application.
The properties skos:broadMatch
and
skos:narrowMatch
are used to state a hierarchical mapping link
between two conceptual resources in different concept schemes.
The property skos:relatedMatch
is used to state an
associative mapping link between two conceptual resources in different
concept schemes.
These concept mapping relations mirror semantic relations, and the data
model defined below is similar (with the exception of
skos:exactMatch
) to the data model defined in section 7 above. A distinct vocabulary is
provided for concept mapping relations, to provide a convenient way to
differentiate links within a concept scheme from links
between concept schemes. However, this pattern of usage is not a
formal requirement of the SKOS data model, and relies on informal definitions
of best practice. See also the @@PRIMER and the notes
below.
Editors' note: There is an ongoing discussion within the Working Group as to whether it is necessary to have separate vocabulary for mapping relations which "mirror" semantic relations, or whether semantic relations alone could be used both to state links within and to state links between concept schemes. A separate, parallel vocabulary for concept mapping provides a convenient way to differentiate links within a scheme from links between schemes. However, there are other mechanisms for making such a differentiation that do not require a separate vocabulary. With a separate vocabulary for mapping relations, a number of interactions between the mapping and semantic relation vocabularies then have to be considered. Many of these interactions have not yet been considered by the Working Group, and the model presented in this section reflects this state of affairs. The model is essentially underspecified, which leads to a number of potentially counter-intuitive results (see the notes below). This is recorded as ISSUE-71 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group mailing list (public-swd-wg@w3.org), starting the subject line with "Comment: ISSUE-71".
skos:mappingRelation |
skos:exactMatch |
skos:broadMatch |
skos:narrowMatch |
skos:relatedMatch |
S41 | skos:mappingRelation , skos:exactMatch ,
skos:broadMatch , skos:narrowMatch and
skos:relatedMatch are each instances of
owl:ObjectProperty . |
S42 | skos:exactMatch , skos:broadMatch ,
skos:narrowMatch and skos:relatedMatch are
each sub-properties of skos:mappingRelation . |
S43 | The rdfs:domain of skos:mappingRelation
is the class skos:Concept . |
S44 | The rdfs:range of skos:mappingRelation is
the class skos:Concept |
S45 | skos:narrowMatch is the owl:inverseOf the
property skos:broadMatch . |
S46 | skos:relatedMatch is an instance of
owl:SymmetricProperty . |
S47 | skos:exactMatch is an instance of
owl:SymmetricProperty . |
S48 | skos:relatedMatch is disjoint with the property
skos:broadMatch . |
The graph below asserts a hierarchical mapping link between
<A>
and <B>
, and an associative mapping
link between <A>
and <C>
, and is
consistent with the SKOS data model.
Example 53 |
---|
<A> skos:broadMatch <B> ; skos:relatedMatch <C>
.
|
The graph below is not consistent with the SKOS data
model, because there is a "clash" between skos:relatedMatch
and
skos:broadMatch
.
Example 54 |
---|
<A> skos:broadMatch <B> ; skos:relatedMatch <B>
.
|
The graph below is not consistent with the SKOS data
model, again because there is a "clash" between
skos:relatedMatch
and skos:broadMatch
, which can be
inferred from the statements that skos:broadMatch
and
skos:narrowMatch
are inverse properties (S45), and that
skos:relatedMatch
is a symmetric property (S46).
Example 55 |
---|
<A> skos:narrowMatch <B> ; skos:relatedMatch <B>
.
|
None of the SKOS concept mapping properties are defined in this specification as transitive properties. Therefore, entailments as illustrated in examples 56-58 below are not supported by the SKOS data model.
Example 56 |
---|
<A> skos:exactMatch <B> .
<B> skos:exactMatch <C> . does not entail
<A> skos:exactMatch <C> .
|
Example 57 |
---|
<A> skos:broadMatch <B> .
<B> skos:broadMatch <C> . does not entail
<A> skos:broadMatch <C> .
|
Example 58 |
---|
<A> skos:relatedMatch <B> .
<B> skos:relatedMatch <C> . does not entail
<A> skos:relatedMatch <C> .
|
Editors' note: The Working Group has recognized that it might be reasonable and useful to define skos:exactMatch as a transitive property. This is recorded as ISSUE-72 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group mailing list (public-swd-wg@w3.org), starting the subject line with "Comment: ISSUE-72".
This specification defines none of the SKOS concept mapping properties as reflexive, neither are they defined as irreflexive.
Because skos:exactMatch
, skos:broadMatch
and
skos:relatedMatch
are not defined as
irreflexive properties, the graph below is consistent with
the SKOS data model.
Example 59 |
---|
<A> skos:exactMatch <A> .
<B> skos:broadMatch <B> . <C> skos:relatedMatch <C> . |
This specification does not state that the property
skos:exactMatch
is disjoint with any of the other concept
mapping properties. Therefore the graph below is consistent
with the SKOS data model.
Example 60 |
---|
<A> skos:exactMatch <B> ; skos:broadMatch <B> ;
skos:exactMatch <C> ; skos:relatedMatch <C> . |
Editors' note: Intuitively, an exact mapping link asserts something fundamentally different from a hierarchical or associative mapping link. Therefore, it might be reasonable and useful to define skos:exactMatch as disjoint with skos:broadMatch (or skos:broader), and disjoint with skos:relatedMatch (or skos:related). This is recorded as ISSUE-73 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group mailing list (public-swd-wg@w3.org), starting the subject line with "Comment: ISSUE-73".
There are no integrity conditions preventing either cycles or alternate paths in the hierarchical mapping relation.
In the graph below there are two cycles involving
skos:broadMatch
. This graph is consistent with
the SKOS data model.
Example 61 |
---|
<A> skos:broadMatch <B> .
<B> skos:broadMatch <A> . <X> skos:broadMatch <Y> . <Y> skos:broadMatch <Z> . <Z> skos:broadMatch <X> . |
In the graph below there are two alternate paths involving
skos:broadMatch
. This graph is consistent with
the SKOS data model.
Example 62 |
---|
<A> skos:broadMatch <B> .
<B> skos:broadMatch <C> . <A> skos:broadMatch <C> . |
There are no definitions within the SKOS data model supporting property
chain inclusions involving the skos:exactMatch
property.
Accordingly, the entailments illustrated below are not
supported by the SKOS data model.
Example 63 |
---|
<A> skos:exactMatch <B> .
<B> skos:broadMatch <C> . does not entail
<A> skos:broadMatch <C> .
|
Example 64 |
---|
<A> skos:exactMatch <B> .
<B> skos:relatedMatch <C> . does not entail
<A> skos:relatedMatch <C> .
|
Example 65 |
---|
<A> skos:exactMatch <B> .
<B> skos:broader <C> . does not entail
<A> skos:broader <C> .
|
Example 66 |
---|
<A> skos:exactMatch <B> .
<B> skos:related <C> . does not entail
<A> skos:related <C> .
|
Editors' note: Whether any property chain inclusions could reasonably be defined for skos:exactMatch is under discussion within the Working Group. This is recorded as ISSUE-75 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group mailing list (public-swd-wg@w3.org), starting the subject line with "Comment: ISSUE-75".
By convention, the SKOS semantic relation properties are only used to state links between conceptual resources within the same concept scheme, and the SKOS concept mapping properties are only used to state links between conceptual resources in different concept schemes.
However, note that there are no integrity constraints
preventing the SKOS semantic relation properties, skos:broader
,
skos:narrower
and skos:related
being used to link
conceptual resources between different concept schemes.
Therefore the graph below is consistent with the SKOS data model.
Example 67 |
---|
<A> skos:broader <B> ; skos:related <C> .
<A> skos:inScheme <MyScheme> . <B> skos:inScheme <AnotherScheme> . <C> skos:inScheme <AnotherScheme> . <MyScheme> owl:differentFrom <AnotherScheme> . |
Neither are there any integrity constraints preventing the SKOS concept mapping relation properties being used to link conceptual resources within the same concept scheme.
Therefore, the graph below is consistent with the SKOS data model.
Example 68 |
---|
<A> skos:broadMatch <B> ; skos:relatedMatch <C>
.
<A> skos:inScheme <MyScheme> . <B> skos:inScheme <MyScheme> . <C> skos:inScheme <MyScheme> . |
Editorial note: These usage conventions, and any corresponding integrity conditions (or lack thereof) are under discussion within the Working Group. This is recorded as ISSUE-74 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group mailing list (public-swd-wg@w3.org), starting the subject line with "Comment: ISSUE-74".
There are no integrity conditions on the interaction between the semantic relation properties and the concept mapping properties.
Therefore, the graph below is consistent with the SKOS data model.
Example 69 |
---|
<A> skos:broader <B> ; skos:relatedMatch <B> .
<C> skos:relatedMatch <D> ; skos:broader <D> . <E> skos:exactMatch <F> ; skos:broader <F> . |
Furthermore, there are no logical dependencies between the semantic relation properties and concept mapping properties. Accordingly, examples 70-73 below illustrate entailments which do not hold for these properties.
Example 70 |
---|
<A> skos:exactMatch <B> .
<B> skos:related <C> . does not entail
<A> skos:related <C> .
|
Example 71 |
---|
<A> skos:exactMatch <B> .
<B> skos:broader <C> . does not entail
<A> skos:broader <C> .
|
Example 72 |
---|
<A> skos:broadMatch <B> .
does not entail
<A> skos:broader <B> .
|
Example 73 |
---|
<A> skos:relatedMatch <B> .
does not entail
<A> skos:related <B> .
|
Editors' note: See also the editors' note at the beginning of this section concerning ISSUE-71 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group mailing list (public-swd-wg@w3.org), starting the subject line with "Comment: ISSUE-71".
OWL provides three properties which might, at first glance, appear similar
to skos:exactMatch. owl:sameAs
is used to link to individuals in
an ontology, and indicates that they are the same individual (i.e. the same
resource). owl:equivalentClass
is used to link two classes in an
ontology, and indicates that those classes have the same class extension.
owl:equivalentProperty
is used to link two properties in an
ontology and indicates that both properties have the same property
extension.
skos:exactMatch
is used to link two SKOS conceptual
resources. It is typically used to indicate that two conceptual resources are
sufficiently similar that they can be used interchangeably in an information
retrieval application.
owl:sameAs
, owl:equivalentClass
or
owl:equivalentProperty
would typically be inappropriate for
linking conceptual resources in different concept schemes, because the formal
consequences that follow would typically be undesirable.
The example below illustrates an entailment that would follow from using
owl:sameAs
in this way.
Example 74 |
---|
<A> rdf:type skos:Concept ;
skos:prefLabel "foo"@en ; skos:inScheme <MyScheme> . <B> rdf:type skos:Concept ; skos:prefLabel "bar"@en ; skos:inScheme <AnotherScheme> . <A> owl:sameAs <B> . entails
<A>
skos:prefLabel "foo"@en ; skos:prefLabel "bar"@en ; skos:inScheme <MyScheme> ; skos:inScheme <AnotherScheme> . <B> skos:prefLabel "foo"@en ; skos:prefLabel "bar"@en ; skos:inScheme <MyScheme> ; skos:inScheme <AnotherScheme> . |
In this example, using owl:sameAs
to link two conceptual
resources in different concept schemes does actually lead to an inconsistency
with the SKOS data model, because both <A>
and
<B>
now have two preferred lexical labels in the same
language. This will not always be the case, however. Generally speaking,
using owl:sameAs
in this way will lead to inappropriate
inferences, which may sometimes but not always be detectable by checking
consistency with the SKOS data model.
In the Simple Knowledge Organization System, while two conceptual resources may be viewed as sharing very similar if not identical "meaning", it does not necessarily follow that they are the same resource (individual).
This section describes some other parts of the SKOS data model.
Editors' note: Previous drafts of the SKOS specification included the properties skos:prefSymbol and skos:altSymbol as "symbolic labeling properties". These features are considered to be at risk by the Working Group. This is recorded as ISSUE-76 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group mailing list (public-swd-wg@w3.org), starting the subject line with "Comment: ISSUE-76".
Editors' note: Previous drafts of the SKOS specification included the properties skos:subject, skos:isSubjectOf, skos:primarySubject and skos:isPrimarySubjectOf as "subject indexing properties". These features are considered to be at risk by the Working Group. This is recorded as ISSUE-77 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group mailing list (public-swd-wg@w3.org), starting the subject line with "Comment: ISSUE-77".
Editors' note: Previous drafts of the SKOS specification included the property skos:subjectIndicator, which was intended as a bridge between SKOS and topic maps. This feature is considered to be at risk by the Working Group. This is recorded as ISSUE-78 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group mailing list (public-swd-wg@w3.org), starting the subject line with "Comment: ISSUE-78".
Editors' note: There is currently no explicit support in the SKOS data model or definition of best practice for providing "notations", which are codes used in some thesauri and classification schemes. This is recorded as ISSUE-79 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group mailing list (public-swd-wg@w3.org), starting the subject line with "Comment: ISSUE-79".
@@TODO
skos:Concept | |
---|---|
URI: | http://www.w3.org/2004/02/skos/core#Concept |
Super-classes: | rdfs:Resource owl:Thing |
Disjoint classes: | rdfs:Literal rdf:List skos:ConceptScheme skos:Collection skos:LabelRelation |
Definition: | Section 3 (Conceptual Resources) |
skos:ConceptScheme | |
URI: | http://www.w3.org/2004/02/skos/core#ConceptScheme |
Super-classes: |
rdfs:Resource owl:Thing |
Disjoint classes: | rdfs:Literal rdf:List skos:Concept skos:Collection skos:LabelRelation |
Definition: | Section 4 (Concept Schemes) |
skos:LabelRelation | |
URI: | http://www.w3.org/2004/02/skos/core#LabelRelation |
Super-classes: | rdfs:Resource owl:Thing |
Disjoint classes: | rdfs:Literal rdf:List skos:Concept skos:ConceptScheme skos:Collection |
Definition: | |
skos:Collection | |
URI: | http://www.w3.org/2004/02/skos/core#Collection |
Super-classes: | rdfs:Resource owl:Thing |
Disjoint classes: | rdfs:Literal rdf:List skos:Concept skos:ConceptScheme skos:LabelRelation |
Definition: | Section 9 (Concept Collections) |
skos:OrderedCollection | |
URI: | http://www.w3.org/2004/02/skos/core#OrderedCollection
|
Super-classes: | skos:Collection |
Disjoint classes: | rdfs:Literal rdf:List skos:Concept skos:ConceptScheme skos:LabelRelation |
Definition: | Section 9 (Concept Collections) |
skos:inScheme | |
---|---|
URI: | http://www.w3.org/2004/02/skos/core#inScheme |
Super-properties: | (none) |
Disjoint properties: | (none) |
Domain: | rdfs:Resource |
Range: | skos:ConceptScheme |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Antisymmetric Irreflexive |
Definition: | Section 4 (Concept Schemes) |
skos:hasTopConcept | |
URI: | http://www.w3.org/2004/02/skos/core#hasTopConcept |
Super-properties: | (none) |
Disjoint properties: | (none) |
Domain: | skos:ConceptScheme |
Range: | skos:Concept |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Antisymmetric Irreflexive |
Definition: | Section 4 (Concept Schemes) |
skos:prefLabel | |
URI: | http://www.w3.org/2004/02/skos/core#prefLabel |
Super-properties: | rdfs:label |
Disjoint properties: | skos:altLabel skos:hiddenLabel |
Domain: | rdfs:Resource |
Range: | The class of RDF plain literals |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 5 (Lexical Labels) |
skos:altLabel | |
URI: | http://www.w3.org/2004/02/skos/core#altLabel |
Super-properties: | rdfs:label |
Disjoint properties: | skos:prefLabel skos:hiddenLabel |
Domain: | rdfs:Resource |
Range: | The class of RDF plain literals |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 5 (Lexical Labels) |
URI: | http://www.w3.org/2004/02/skos/core#hiddenLabel |
Super-properties: | rdfs:label |
Disjoint properties: | skos:prefLabel skos:altLabel |
Domain: | rdfs:Resource |
Range: | The class of RDF plain literals |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 5 (Lexical Labels) |
skos:note | |
URI: | http://www.w3.org/2004/02/skos/core#note |
Super-properties: | (none) |
Disjoint properties: | (none) |
Domain: | rdfs:Resource |
Range: | rdfs:Resource |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 6 (Documentation Properties) |
skos:changeNote | |
URI: | http://www.w3.org/2004/02/skos/core#changeNote |
Super-properties: | skos:note |
Disjoint properties: | (none) |
Domain: | rdfs:Resource |
Range: | rdfs:Resource |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 6 (Documentation Properties) |
skos:definition | |
URI: | http://www.w3.org/2004/02/skos/core#definition |
Super-properties: | skos:note |
Disjoint properties: | (none) |
Domain: | rdfs:Resource |
Range: | rdfs:Resource |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 6 (Documentation Properties) |
skos:editorialNote | |
URI: | http://www.w3.org/2004/02/skos/core#editorialNote |
Super-properties: | skos:note |
Disjoint properties: | (none) |
Domain: | rdfs:Resource |
Range: | rdfs:Resource |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 6 (Documentation Properties) |
skos:example | |
URI: | http://www.w3.org/2004/02/skos/core#example |
Super-properties: | skos:note |
Disjoint properties: | (none) |
Domain: | rdfs:Resource |
Range: | rdfs:Resource |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 6 (Documentation Properties) |
skos:historyNote | |
URI: | http://www.w3.org/2004/02/skos/core#historyNote |
Super-properties: | skos:note |
Disjoint properties: | (none) |
Domain: | rdfs:Resource |
Range: | rdfs:Resource |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 6 (Documentation Properties) |
skos:scopeNote | |
URI: | http://www.w3.org/2004/02/skos/core#scopeNote |
Super-properties: | skos:note |
Disjoint properties: | (none) |
Domain: | rdfs:Resource |
Range: | rdfs:Resource |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 6 (Documentation Properties) |
skos:semanticRelation | |
URI: | http://www.w3.org/2004/02/skos/core#semanticRelation
|
Super-properties: | (none) |
Disjoint properties: | (none) |
Domain: | skos:Concept |
Range: | skos:Concept |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Symmetric Not reflexive Not irreflexive |
Definition: | Section 7 (Semantic Relations) |
skos:broader | |
URI: | http://www.w3.org/2004/02/skos/core#broader |
Super-properties: | skos:broaderTransitive |
Disjoint properties: | skos:related |
Domain: | skos:Concept |
Range: | skos:Concept |
Inverse of: | skos:narrower |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 7 (Semantic Relations) |
skos:narrower | |
URI: | http://www.w3.org/2004/02/skos/core#narrower |
Super-properties: | skos:narrowerTransitive |
Disjoint properties: | skos:related |
Domain: | skos:Concept |
Range: | skos:Concept |
Inverse of: | skos:broader |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 7 (Semantic Relations) |
skos:related | |
URI: | http://www.w3.org/2004/02/skos/core#related |
Super-properties: | skos:semanticRelation |
Disjoint properties: | skos:broaderTransitive skos:narrowerTransitive |
Domain: | skos:Concept |
Range: | skos:Concept |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Symmetric Not reflexive Not irreflexive |
Definition: | Section 7 (Semantic Relations) |
skos:broaderTransitive | |
URI: | http://www.w3.org/2004/02/skos/core#broaderTransitive
|
Super-properties: | skos:semanticRelation |
Disjoint properties: | skos:related |
Domain: | skos:Concept |
Range: | skos:Concept |
Inverse of: | skos:narrowerTransitive |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 7 (Semantic Relations) |
skos:narrowerTransitive | |
URI: | http://www.w3.org/2004/02/skos/core#narrowerTransitive
|
Super-properties: | skos:semanticRelation |
Disjoint properties: | skos:related |
Domain: | skos:Concept |
Range: | skos:Concept |
Inverse of: | skos:broaderTransitive |
Other characteristics: | Transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 7 (Semantic Relations) |
skos:labelRelated | |
URI: | http://www.w3.org/2004/02/skos/core#labelRelated |
Super-properties: | (none) |
Disjoint properties: | (none) |
Domain: | skos:LabelRelation |
Range: | The class of RDF plain literals |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Antisymmetric Irreflexive |
Definition: | Section 8 (Label Relations) |
skos:seeLabelRelation | |
URI: | http://www.w3.org/2004/02/skos/core#seeLabelRelation
|
Super-properties: | (none) |
Disjoint properties: | (none) |
Domain: | rdfs:Resource |
Range: | skos:LabelRelation |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 8 (Label Relations) |
skos:member | |
URI: | http://www.w3.org/2004/02/skos/core#member |
Super-properties: | (none) |
Disjoint properties: | skos:memberList |
Domain: | skos:Collection |
Range: | rdfs:Resource |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Antisymmetric Irreflexive |
Definition: | Section 9 (Concept Collections) |
skos:memberList | |
URI: | http://www.w3.org/2004/02/skos/core#memberList |
Super-properties: | (none) |
Disjoint properties: | skos:member |
Domain: | skos:OrderedCollection |
Range: | rdf:List |
Inverse of: | (none) |
Other characteristics: | Not transitive Functional Not inverse functional Antisymmetric Irreflexive |
Definition: | Section 9 (Concept Collections) |
skos:mappingRelation | |
URI: | http://www.w3.org/2004/02/skos/core#mappingRelation
|
Super-properties: | (none) |
Disjoint properties: | (none) |
Domain: | skos:Concept |
Range: | skos:Concept |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Symmetric Not reflexive Not irreflexive |
Definition: | Section 10 (Concept Mapping Relations) |
skos:broadMatch | |
URI: | http://www.w3.org/2004/02/skos/core#broadMatch |
Super-properties: | skos:mappingRelation |
Disjoint properties: | skos:relatedMatch |
Domain: | skos:Concept |
Range: | skos:Concept |
Inverse of: | skos:narrowMatch |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 10 (Concept Mapping Relations) |
skos:narrowMatch | |
URI: | http://www.w3.org/2004/02/skos/core#narrowMatch |
Super-properties: | skos:mappingRelation |
Disjoint properties: | skos:relatedMatch |
Domain: | skos:Concept |
Range: | skos:Concept |
Inverse of: | skos:broadMatch |
Other characteristics: | Not transitive Not functional Not inverse functional Not symmetric Not antisymmetric Not reflexive Not irreflexive |
Definition: | Section 10 (Concept Mapping Relations) |
skos:relatedMatch | |
URI: | http://www.w3.org/2004/02/skos/core#relatedMatch |
Super-properties: | skos:mappingRelation |
Disjoint properties: | skos:broadMatch skos:narrowMatch |
Domain: | skos:Concept |
Range: | skos:Concept |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Symmetric Not reflexive Not irreflexive |
Definition: | Section 10 (Concept Mapping Relations) |
skos:exactMatch | |
URI: | http://www.w3.org/2004/02/skos/core#exactMatch |
Super-properties: | skos:mappingRelation |
Disjoint properties: | (none) |
Domain: | skos:Concept |
Range: | skos:Concept |
Inverse of: | (none) |
Other characteristics: | Not transitive Not functional Not inverse functional Symmetric Not reflexive Not irreflexive |
Definition: | Section 10 (Concept Mapping Relations) |
@@TODO. Consider whether this section is appropriately named, or should be moved to the primer, or if indeed it is necessary at all.
The OWL Reference [@@REF-OWL-REFERENCE] includes a section called Rules of Thumb. OWL-DL ontologies form a subset of RDF graphs — not all RDF graphs correspond to legal OWL-DL ontologies. The appendix provides an informal characterization of the conditions for RDF graphs to be OWL-DL.
This section is intended to play a similar role. However, there are some
key differences here. SKOS provides a data model and vocabulary for
describing concept schemes. The collection of SKOS concept schemes are not
characterized in the same way as OWL-DL ontologies: we do not have conditions
for an RDF graph being a "valid" SKOS concept scheme. There are, however,
constraints on the vocabulary expressed as a combination of type assertions
(e.g. skos:ConceptScheme
is an instance of
owl:Class
) and additional constraints expressed in prose.
This appendix provides an informal characterization of the constraints. It is not intended to replace the formal characterization given above — the idea is that if you stick to the guidelines below, you are more likely to produce SKOS concept schemes that are interoperable.
In general, it is best to avoid stating triples where a URI from the SKOS vocabulary is in the subject position. By doing so, you may alter the semantics of the SKOS vocabulary and introduce unwanted side effects. This may then compromise the interoperability of vocabularies. If you really want to alter the behavior of the "built-in" vocabulary, consider introducing a subclass or sub-property.
The properties skos:prefLabel
, skos:altLabel
and
skos:hiddenLabel
are pairwise disjoint. Thus a resource should
not have the same literal given as, for example, a
skos:prefLabel
and a skos:hiddenLabel
. Each
resource should only have one skos:prefLabel
per language.
The transitive closure of skos:broader
is disjoint from
skos:related
. If resources A
and B
are
related via skos:related
, there must not be a chain of
skos:broader
relationships from A
to
B
. The same holds of skos:narrower
.
The SKOS data model expressed as RDF triples (in so far as possible) is given in the following resource:
@@TODO this section describes some patterns for working with SKOS in combination with OWL for more advanced applications.
Editors' note: Recommended patterns for using SKOS and OWL in combination are being developed by the Working Group. This is recorded as ISSUE-80 in the Working Group's issue process. Comments on this issue are invited, and should be sent in an email to the SWD Working Group mailing list (public-swd-wg@w3.org), starting the subject line with "Comment: ISSUE-80".
This section describes some patterns for using the SPARQL query language [@@REF-SPARQL-QUERY] to implement some common operations required by applications that use SKOS data. All of these patterns are consistent with the SKOS data model.
In this pattern, the URI of a SKOS concept scheme is also treated as the URI of a named RDF graph. SPARQL's support for specifying and querying the RDF dataset can then be used to establish the "containment" of a particular semantic relationship between two conceptual resources.
For example, given the data below
# Named graph: http://example.org/ns/MyScheme @prefix skos: <http://www.w3.org/2004/02/skos/core#> . @base <http://example.org/ns/> . <A> skos:inScheme <MyScheme> ; skos:broader <B> . <B> skos:inScheme <MyScheme> ; skos:narrower <A> .
the following SPARQL query establishes whether or not a hierarchical link
between <A>
and <B>
is "contained" in
<MyScheme>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#> BASE <http://example.org/ns/> ASK FROM NAMED <MyScheme> WHERE { <A> skos:broader <B> }
Note, however, that this pattern would not be appropriate if different named RDF graphs were used to express different "states" or "versions" of a concept scheme; or if a concept scheme were viewed as having alternate expressions, as an RDF graph and an HTML document for example (in which case separate URIs might be required for the concept scheme, the RDF graph, and the HTML document).
@@TODO more patterns?
@@TODO how to extend SKOS with some examples
@@TODO how to define sub-properties and sub-classes of SKOS
@@TODO how to define new properties and classes which "plug in" to SKOS properties and classes, e.g. as domain/range etc.
@@TODO extensions which require mapping rules to dumb down, e.g. labels as classes
—- Change Log —- $Log: Overview.html,v $ Revision 1.11 2018/10/09 13:19:24 denis fix validation of xhtml documents Revision 1.10 2017/10/02 10:36:35 denis add fixup.js to old specs Revision 1.9 2008/01/25 18:03:28 swick W3C /+First Public+/ Working Draft Revision 1.8 2008/01/25 01:50:01 swick Remove one more reference to not-yet-published Primer. Revision 1.7 2008/01/25 01:48:59 swick More SOTD boilerplate. Remove @@LINK and @@TODO local refs for link checker. Remove link to not-yet-published Primer. Revision 1.6 2008/01/25 01:29:38 swick Demote synopsis section to placate pubrules Revision 1.5 2008/01/24 21:21:30 swick comment-out previous version section; apparently pubrules doesn't require this Revision 1.4 2008/01/24 21:19:13 swick Fix title metadata to be pubrules compliant (match the H1) Revision 1.3 2008/01/24 21:17:23 swick fixup SOTD Revision 1.2 2008/01/24 21:01:21 swick Fix title page material Revision 1.1 2008/01/24 19:26:50 swick Copied from /2006/07/SWD/SKOS/reference/20080118.html Revision 1.5 2008/01/22 16:58:43 ajm65 Did numbering for tables, examples and formal definitions. Revision 1.4 2008/01/18 14:30:07 ajm65 Fixed minor capitalization inconsitency. Revision 1.3 2008/01/18 14:21:18 ajm65 Minor editorial and stylistic changes only. Revision 1.2 2008/01/18 12:19:24 ajm65 Fixed CVS log only. Revision 1.1 2008/01/18 12:18:08 ajm65 Initial, corresponding to master rev 1.33