(This issue emerged out of a discussion on the dc-usage list [1] about
how SKOS concepts might be deployed in DC metadata descriptions, and in
particular about the relationship between what DCMI calls a "Vocabulary
Encoding Scheme" and what SKOS calls a "Concept Scheme". It was
suggested that it would be useful to explore the problem here as some of
the designers of the SKOS model are subscribed to this list.)
The DCQ-RDF proposed recommendation [2] describes a set of conventions
for representing a "qualified DC" metadata description as an RDF graph.
For "encoding schemes", the approach taken is to define an RDFS class
corresponding to the "encoding scheme" - e.g.
http://purl.org/dc/terms/LCSH is the class of LCSH subject headings,
http://purl.org/dc/terms/IMT is the class of Internet Media Types,
http://purl.org/dc/terms/W3CDTF is the class of W3CDTF dates/times,
http://purl.org/dc/terms/DCMIType is the class of DCMI Type terms
and so on.
And (using the qualified name convention as an abbreviation for the URIs
above)
an individual LCSH subject is an instance of the class dcterms:LCSH
an individual Internet Media Type is an instance of the class
dcterms:IMT
an individual W3CDTF date/time is an instance of the class
dcterms:W3CDTF
an individual DCMI Type term (like dcmitype:Collection) is an instance
of the class dcterms:DCMIType (in this latter case, each DCMI Type term
is itself a class)
So, following this convention described in the DCQ-RDF document, the
DCMI Abstract Model [3] states that
- vocabulary encoding scheme URI is "a URI reference that identifies the
class of the value"
- "Each resource may be a member of one or more classes. Note that where
the resource is a value, the class is referred to as a vocabulary
encoding scheme."
(And in fact following these descriptions, I've argued on this list and
elsewhere that since a "value" can be a resource of any type, then a
vocabulary encoding scheme URI can be the URI of any class, i.e. any
class is a potential "vocabulary encoding scheme", not just those
classes that DCMI explicitly types as "encoding schemes".)
And in the DCAM glossary, we have:
====
vocabulary encoding scheme
A vocabulary encoding scheme is a class that indicates that the
value of a property is taken from a controlled vocabulary (or
concept-space), such as the Library of Congress Subject Headings.
vocabulary encoding scheme URI
A vocabulary encoding scheme URI is a URI reference that identifies
a vocabulary encoding scheme. For all DCMI recommended encoding schemes,
the URI reference is constructed by concatenating the name of the
encoding scheme with the http://purl.org/dc/terms/ namespace URI.
====
(With apologies in advance to Alistair, Dan and the other SKOS folks for
any misunderstandings and misrepresentations in the following - please
set me straight on any or all of it!)
The Simple Knowledge Organisation System (SKOS) [4] provides "a model
for expressing the basic structure and content of concept schemes
(thesauri, classification schemes, subject heading lists, taxonomies,
terminologies, glossaries and other types of controlled vocabulary)."
The SKOS Core Vocabulary [5] provides a set of classes and properties
that can be used to express a "concept scheme" as an RDF graph.
SKOS models the content of a concept scheme as a set of resources, where
each resource is an instance of the class skos:Concept. (I'm using
qualified names for brevity again). SKOS also provides a class to
represent concept schemes, i.e. a concept scheme is an instance of the
class skos:ConceptScheme.
Individual concepts (instances of the class skos:Concept) are related to
individual concept schemes (instances of the class skos:ConceptScheme)
using a property skos:inScheme. See [6]. (Other relationships are also
possible e.g. to indicate which are the "top concepts" in a concept
scheme.)
Now then, it seems that if SKOS is widely adopted for the description of
"concept schemes", then it will be useful to be able to reference
concepts within those concept schemes in DC metadata descriptions. e.g.
as values referred to in statements using the dc:subject property (but
quite probably with other properties too).
An SKOS concept is a resource, so it can be a "value" in the terms of
the DCAM, i.e. a statement in a DC metadata description might include a
"value URI" which identifies an SKOS concept, an instance of the class
skos:Concept.
What would be the "vocabulary encoding scheme URI" in such a statement?
The "quick answer" would seem to be, "Oh, the URI of an SKOS concept
scheme, obviously".
However, given the definition of "vocabulary encoding scheme" in the
DCAM, then the "vocabulary encoding scheme URI" is the URI of a class of
which the value is an instance (see the examples of dcterms:LCSH etc
above). In the case of an SKOS concept and an SKOS concept scheme, the
relationship between the two resources is not (or at least not
necessarily?) a relationship of instance/class (i.e. the rdf:type
property) but rather is defined by the skos:inScheme property.
So while an SKOS concept can be used as a "value" in DC metadata, the
corresponding SKOS concept scheme is not a "vocabulary encoding scheme"
(in fact the class (or at least one class) of which an SKOS concept is
an instance is the class skos:Concept, so that class could be the
vocabulary encoding scheme!)
So.....
(a) is this analysis correct please? i.e. is the relationship between a
"value" and a "vocabulary encoding scheme" in the DCAM different from
that between a "concept" and a "concept scheme" in SKOS?
(b) if so, does that mean there is no simple correspondence between a DC
"vocabulary encoding scheme" and an SKOS "concept scheme"?
(c) if so, is that a problem for DC implementers wishing to reference
SKOS concepts as "values"?
(d) if it is a problem, how do we "fix" it?
Cheers
Pete
-------
Pete Johnston
Research Officer (Interoperability)
UKOLN, University of Bath, Bath BA2 7AY, UK
tel: +44 (0)1225 383619 fax: +44 (0)1225 386838
mailto:[log in to unmask]
http://www.ukoln.ac.uk/ukoln/staff/p.johnston/
[1]
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0503&L=dc-usage&T=0&F=&
S=&P=804 (and subsequent messages on that thread)
[2] http://dublincore.org/documents/dcq-rdf-xml/
[3] http://dublincore.org/documents/abstract-model/
[4] http://www.w3.org/2004/02/skos/core/guide/
[5] http://www.w3.org/2004/02/skos/core/spec/
[6] http://www.w3.org/2004/02/skos/core/guide/#secscheme
