Simple Dublin Core
----------------------------------------------------------------------
Notes from Seattle, 2007:
"Simple DC" is a concept used in a number of ways in a
number of places. Do we address it in reference to OAI?
-- "Simple DC is a description set with one description that
describes a resource with 15 optional property usages"
-- If we say Simple DC is a conforming AP, then folks will
be using it as a model.
-- What goes on a AP for Simple DC? It should include those
properties of the DCMI Profile Model (Application Profile
of Application Profiles).
-- ISSUE: OAI uses value string language. Do we put anything
about value string language in this AP?
-- AGREED: Simple DC includes value string language, and this
is optional.
-- AGREED: Need to include URI in Simple DC AP, not the QName.
-- AGREED: Do not cite our own XML schemas in the AP for Simple DC
-- ISSUE: Documentation mentioning "Simple Dublin Core" should be
revised to point to the Simple DC AP.
----------------------------------------------------------------------
Use of "Simple Dublin Core" in DCMI documentation
http://dublincore.org/documents/dcmes-xml/
This document describes an encoding for the DCMES in XML subject to these restrictions:
* The Dublin Core elements described in the DCMES V1.1 reference can be used
* No other elements can be used
* No element qualifiers can be used
* The resulting RDF/XML cannot be embedded in web pages
http://dublincore.org/documents/usageguide/
The Dublin Core standard includes two levels: Simple and
Qualified. Simple Dublin Core comprises fifteen elements;
Qualified Dublin Core includes three additional elements
(Audience, Provenance and RightsHolder), as well as a group
of element refinements (also called qualifiers) that refine
the semantics of the elements in ways that may be useful in
resource discovery.
http://dublincore.org/documents/usageguide/glossary.shtml
Simple Dublin Core
The fifteen Dublin Core elements used without qualifiers,
that is without element refinement or encoding
schemes. Sometimes referred to as Dublin Core simple.
http://dublincore.org/resources/faq/
"Simple Dublin Core" is Dublin Core metadata that
uses no qualifiers; only the main 15 elements of the
Dublin Core Metadata Element Set are expressed as simple
attribute-value pairs without any "qualifiers" (such as
encoding schemes, enumerated lists of values, or other
processing clues) to provide more detailed information
about a resource.
http://dublincore.org/schemas/xmls/
Simple DC XML schema, version 2002-12-12
This schema defines terms for Simple Dublin Core, i.e. the 15 elements
from the http://purl.org/dc/elements/1.1/ namespace, with no use of
encoding schemes or element refinements.
----------------------------------------------------------------------
2009-05-26 Pete writes about a misconception re: Simple DC
> 3. but, dc elements don't have refinements.
Ah, no, that's not true. (More below).
> (Simple Dublin Core: The fifteen Dublin Core elements used
> without qualifiers, that is without element refinement or
> encoding schemes. Sometimes referred to as Dublin Core
> simple. http://dublincore.org/documents/usageguide/glossary.shtml)
>
> How can dc:title be refined by dcterms:alternative but then
> have no refinements? Isn't that a contradiction?
No, there's no contradiction.
I think the important point here is to maintain the distinction between
(i) the Dublin Core Metadata Element Set i.e. the set of 15 properties
(ii) "Simple Dublin Core", as a "DC Application Profile"
(DCAP), which defines one set of constraints - and only one
of many possible sets of constraints - on the use of those
15 properties to construct a DC description set (containing
a single description).
The former is just a set of properties, which may have
relationships to other properties (through e.g. subproperty
(element refinement) relationships), and to classes (through
domain/range relationships).
Those relationships are specified by assertions made in the
authoritative dsecriptions of those properties provided by
DCMI:
http://dublincore.org/documents/dces/ (or in
machine-readable form http://purl.org/dc/elements/1.1/
(In the case of the DCMES, no domain/range is specified, so
in each case it is the class of all things (rdfs:Resource)).
And these are "global" characteristics of the properties:
they apply wherever the properties are used. Regardless of
what is said in the context of any particular DCAP,
dcterms:alternative is a subproperty (element refinement of)
dc:title.
Beyond the limits imposed by the domain/range
considerations, those global descriptions of those
properties provided by DCMI don't enforce any particular
constraints on thse use of those properties in a description
- they don't tell me whether a statement using dc:title is
required or optional, or a statement using dc:subject should
provide a VES or not, and so on.
"Simple Dublin Core" is a DC application profile which
specifies one "pattern of use", one set of structural
constraints on the use of, those 15 properties in a
description set - a Description Set Profile. It says that
in a description conforming to that DCAP, a statements are
limited to using the 15 DCMES properties; the presence of a
staement using each of the 15 DCMES properties is optional,
and there may be multiple statements using a single
property; only literal values may be used, so no VES URI and
no value URI permitted; and SES are not permitted.
But N.B. that is just my suggested definition for Simple DC! I think
it's consistent with historical usage of the term (and it is a
reasonable fit as a retrospective interpretation of the oai_dc syntax
usued in OAI-PMH - but it is still a retrospective interpretation!)
Unfortunately DCMI doesn't have an authoritative description of Simple
DC as a DCAP at this moment. Tom & Mikael worked on a draft of this some
time ago - though I disagreed with some of it, IIRC! :-) - but that work
has been on the back-burner for a while. I think having this would
clarify some of these issues, but there just hasn't been enough effort
available to take it forward.
So there's no contradiction between, on the one hand, the global
assertion that dcterms:alternative is a refinement of dc:title and, on
the other, some particular DCAP such as "Simple DC" saying that it
supports the use of dc:title, but not dcterms:alternative, in
description sets based on that DCAP.
But I readily admit that DCMI's documentation doesn't make this
distinction clear - and some of the older documents are particularly
muddled. There are several key documents which need to be finalised or
rewritten to really address this, it seems to me.
> In discussing this with you, we had a couple of other questions.
>
> a. Does dcterms:alternative refine dc:title in order to
> achieve dumb-down from dcterms:alternative to dc:title (which
> can be achieve only by qualification, as I read the definition)?
>
> (Dumb-down Principle: The qualification of Dublin Core
> Elements is guided by a rule known colloquially as the
> Dumb-Down Principle. According to this rule, a client should
> be able to ignore any qualifier and use the value as if it
> were unqualified. While this may result in some loss of
> specificity, the remaining term value (minus the qualifier)
> must continue to be generally correct and useful for
> discovery. Qualification is therefore supposed only to
> refine, not extend the semantic scope of an Element.
> http://dublincore.org/documents/usageguide/glossary.shtml)
I think you have to remember that the Usage Guide is really a historical
document which hasn't been aligned with recent developments. It really
reflects a "view" in which the 15 properties of the DCMES were perceived
as the "centre" to which everything else had to be related.
But that isn't the current "view" of the DC properties, and I think it's
significant that "dumb-down" is no longer mentioned in the DCMI Abstract
Model. Rather, the DCAM just specifies how the "historical" types of
relationship mentioned in the Grammatical Principles correspond to the
relationship types defined by RDF, RDF Schema or (for VES) by the DCAM
itself.
And like Simple DC, I don't think "dumb-down" is really well-defined
anywhere :-(
But I think it is usually taken to mean the generation of a "Simple DC"
description set. And that is typically achieved by applying a
combination of
(i) the formal inferencing rules defined by RDF Schema (more on this
below), and
(ii) some additional rules about how to map the components which can
occur in a DC description set in the general case to the subset of
components
The second of these things isn't really well-defined: the text you cite
above suggests I can "ignore qualifiers", so OK, the rule is discard SES
URI and VES URI. But if we accept my definition of Simple DC above,
Simple DC does not support the use of value URIs: what is the rule for
treating a value URI? One option would be to say that a value URI is
mapped to a "value string" - but I don't think that rule is written down
anywhere! :-)
> b. Is it desirable to be able to dumb dcterms:alternative
> down to dc:title?
> An alternative
> relationship between dcterms:alternative and dc:title might
> be a combination of dumb-down and mapping, as follows:
>
> dumb down: dcterms:alternative refines dcterms:title
> mapping: dcterms:title to dc:title
I'm afraid I'm not sure I really grasp the distinction you are making
here: to me, as I've said above, "dumb-down" is just a special case of
"mapping", where the target of the mapping is (usually) "Simple DC".
Or to put it another way, both "dumb-down" and "mapping" (at least
mapping between RDF vocabularies) involves defining and applying some
set of inferencing rules, typically the basic rules defined by RDF
Schema, maybe supplemented by other more complex rules.
DCMI's definition of dcterms:alternative says
dcterms:alternative rdfs:subPropertyOf dcterms:title
dcterms:alternative rdfs:subPropertyOf dc:title
Which means that, following the inferencing rules defined by RDF Schema,
anytime I encounter a triple
doc:D dcterms:alternative "abc"
Then I can infer the following two triples
doc:D dcterms:title "abc"
doc:D dc:title "abc"
i.e. whenever I "say" the first statement, I imply the second two
statements. And that applies for _any_ triple/statement where the
property is used, regardless of the subject/described resource and the
value.
Similarly for the case of dcterms:title, DCMI's definition says
dcterms:title rdfs:subPropertyOf dc:title
So any time I see
doc:D dcterms:title "abc"
I can infer
doc:D dc:title "abc"
> c. Can one map from dc:title to dcterms:title and vice-versa?
As above, if I find
doc:D dcterms:title "abc"
I can infer
doc:D dc:title "abc"
Or to put it another way, one can map from dcterms:title to dc:title.
But not vice versa: I can't map from dc:title to dcterms:title. There's
no basis for doing so in the definitions of the properties. The two
properties aren't equivalents. And the reason for this is that they have
different ranges: for dcterms:title, the range is the class of literals,
but for dc:title the range is the class of all resources. In theory at
least, dc:title could be used with a non-literal value, which the range
of dcterms:title does not support.
> d. I haven't looked into the question of to what extent these
> are issues for the other Simple Dublin Core elements.
I think essentially the same argument applies for all the properties.
I hope this sort of makes sense. Some of it is, as I say, necesaarily
just my own conceptualisation (of things like Simple DC), which does not
(yeet at least) have a formal DCMI endorsement (though I'd argue it's a
reasonable conceptualisation!)
The underlying problem, it seems to me, is that the DCMI Web site has
such a mix of old documents with concepts described in rather loose,
informal (and sometimes contradictory) terms, and newer documents based
on a rather more formal framework. And not all of those "old world"
concepts have been "recast" within the formal framework - though I'd
like to think we are getting there, slowly.
----------------------------------------------------------------------
2009-05-29 Response
I think our experience may be typical for what one finds in
the community: we thought that before reading your
explanation, we understood. But as in the case of the blind
man and the elephant [1], we understood only as much as our
experience allowed. We now have a much better
understanding, but we both agree that it would be really
good to revise those "legacy" (which remain absolutely
essential) documents again so that the entire community can
benefit. In fact, perhaps you would consider making
explanations such as this available to the community, e.g.
in the form of an unofficial FAQ or a blog or ...
> permitted; and SES are not permitted.
** OK. Here is a point where we both said that we were never
quite sure where DCMES left off and a DCAP began, but I
think that it is now clearer and I now see that there is no
contradiction. So, more precise documentation on this point
would be welcome.**
> (ii) some additional rules about how to map the components
> which can occur in a DC description set in the general case
> to the subset of components
**It would also be good to formalize and define this process.**
> I've said above, "dumb-down" is just a special case of
> "mapping", where the target of the mapping is (usually)
> "Simple DC".
**This question is now moot. It was a good question (from
my point of view :)) if one didn't understand that dumb down
is formally a form of mapping.**
> Or to put it another way, one can map from dcterms:title to dc:title.
**Now it is clear! So a rdfs:subPropertyOf predicate
defines a "mapping-to" relation.**
> But not vice versa: I can't map from dc:title to
> dcterms:title. There's no basis for doing so in the
> definitions of the properties. The two properties aren't
> equivalents. And the reason for this is that they have
> different ranges: for dcterms:title, the range is the class
> of literals, but for dc:title the range is the class of all
> resources. In theory at least, dc:title could be used with
> a non-literal value, which the range of dcterms:title does
> not support.
**Yes, now I see how this follows. If "mapping-to" may only
occur in the case of subset relations or identity relations,
then mapping from from dc:title to dcterms:title would not
qualify. But then, "mapping" would also have to be formally
defined.**
> The underlying problem, it seems to me, is that the DCMI
> Web site has such a mix of old documents with concepts
> described in rather loose, informal (and sometimes
> contradictory) terms, and newer documents based on a rather
> more formal framework. And not all of those "old world"
> concepts have been "recast" within the formal framework -
> though I'd like to think we are getting there, slowly.
**We agree. But in so doing, it would be important to not
recast the old world documents in such a way that the
implementations that are based on them are no longer
well-defined.**
[1] http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant
----------------------------------------------------------------------
2007-08-24 Mikael
> Second (and this is my main point here) I guess I do wonder whether it's
> something of a "revision of history too far" to define Simple DC as a
> DSP which
>
> (i) defines Statement Templates which do _not_ reference the
> http://purl.org/elements/1.1/... properties
> (ii) uses both literal and non-literal value surrogates (for different
> Statement Templates referencing different properties)
As I'm sure you can tell, proposing that *was* a conscious decision.
We'll need to think about the consequences, though.
I *do* think we want to do what we have done. I'd not call it
revisionist, but rather an important update.
To revisit the definition of "Simple DC" in the light of the new dcterms
properties, the new DCAM, the domains and ranges, and the DSP model, is,
I think, a good way to highlight the fact that DCMI *has* done all that.
Keeping the old notion of Simple DC leads to the risk of sending a
double message: yes, a number of important things have changed, but
we're not really ready to take the consequences :-)
So I'd advocate using the "Simple DC" term, but of course acknowledge
the existence of a "legacy" term.
Looking forward to other opinions on this matter!
----------------------------------------------------------------------
2007-08-24
> As I'm sure you can tell, proposing that *was* a conscious decision.
Heheh ;-)
> We'll need to think about the consequences, though.
>
> I *do* think we want to do what we have done. I'd not call it
> revisionist, but rather an important update.
>
> To revisit the definition of "Simple DC" in the light of the
> new dcterms properties, the new DCAM, the domains and ranges,
> and the DSP model, is, I think, a good way to highlight the
> fact that DCMI *has* done all that.
>
> Keeping the old notion of Simple DC leads to the risk of
> sending a double message: yes, a number of important things
> have changed, but we're not really ready to take the consequences :-)
Though I think one way of taking the consequences would be to say that
"Simple DC" is indeed a legacy term, but it is one which has an
interpretation which is "out there", and so we can't overnight reuse it
for something else, and this new DSP described here is called something
other than "Simple DC".
> So I'd advocate using the "Simple DC" term, but of course
> acknowledge the existence of a "legacy" term.
>
OK... If we do take the route proposed, I think we (and I suppose I mean
the OAI folk and DCMI between us, but largely us given that we ae making
the changes!) do have to come up with a DSP which we can "retrofit" to
the oai_dc XML format.
Which (I think) means either:
(i) saying oai_dc _is_ a format for this new "Simple DC" DSP, and the
mapping from XML Infoset to DC description set has to be done on an
element-by-element basis (as sketched in my previous message)
(ii) saying that oai_dc is a format for some other DSP (as sketched
towards the end of my previous message) called "the OAI DC DSP" or
whatever, which is different from what DCMI now calls "Simple DC", and
the mapping from XML Infoset to DC description set is more "uniform"
(i.e. doesn't vary with XML element name etc)
I really don't think we can say to the OAI people that the world has
moved on, this is what "Simple DC" means now, and there is no "good fit"
between a DSP and the oai_dc XML format (especially given that OAI-PMH
repositories exposing oai_dc XML instances represent probably the single
largest source of DC metadata on the Web).