DC Vocabulary Encoding Schemes and SKOS Concept Schemes

Dear all,

Pete Johnston has started a thread on DC-ARCHITECTURE about
possible inconsistencies between SKOS and Dublin Core.  The 
thread starts at [1].  Anyone is welcome to join the list [2]
and participate in the discussion.

Tom

[1] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A1=ind0503&L=dc-architecture&T=0&F=&S=&P=170
[2] http://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=dc-architecture&T=O



On Tue, Mar 08, 2005 at 08:45:51PM -0000, Pete Johnston wrote:
> X-Mailer: Microsoft Outlook, Build 10.0.2627
> Date:         Tue, 8 Mar 2005 20:45:51 -0000
> Sender: DCMI Architecture Group <DC-ARCHITECTURE@JISCMAIL.AC.UK>
> From: Pete Johnston <p.johnston@UKOLN.AC.UK>
> Subject: DC Vocabulary Encoding Schemes and SKOS Concept Schemes
> To: DC-ARCHITECTURE@JISCMAIL.AC.UK
> 
> (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:p.johnston@ukoln.ac.uk
> 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

-- 
Dr. Thomas Baker                        Thomas.Baker@izb.fraunhofer.de
Institutszentrum Schloss Birlinghoven         mobile +49-160-9664-2129
Fraunhofer-Gesellschaft                          work +49-30-8109-9027
53754 Sankt Augustin, Germany                    fax +49-2241-144-2352
Personal email: thbaker79@alumni.amherst.edu

Received on Wednesday, 9 March 2005 14:05:32 UTC