[OAI-implementers] Qualified Dublin Core

Pete Johnston p.johnston at ukoln.ac.uk
Mon Aug 9 12:35:47 EDT 2004

Jeff said:

> The link to http://dublincore.org/schemas/xmls/ refers to a 
> schema at 
> http://dublincore.org/schemas/xmls/qdc/2003/04/02/qualifieddc.
> xsd. If you read the annotation in the schema, though, it says this:
> "Note that this schema does not define a target namespace. 
> The expectation is that the qualifieddc element is assigned 
> to a namespace by an application schema which includes this schema."
> So, since this schema isn't associated with a namespace it 
> must not be appropriate for use by itself, as the note 
> implies. My interpretation, therefore, is that what I really 
> need is some kind of "application schema" that uses this one.

Yes, that is/was the intention. There has been at least one request to
DCMI to provide an "application schema" for "qualified DC" and looking
at the implications of that is, ahem, on my to-do list.

In part the reason for adopting the current approach (I think!) was that
when implementers refer to "qualified DC" they rarely meant an
"application profile" that used _only_ that set of elements, element
refinements and encoding schemes provided by DCMI. More often than not
they meant an application profile that used those elements, element
refinements and encoding schemes provided by DCMI (or some subset of
them), plus a few additional element refinements and encoding schemes
specific to their application. So although DCMI could define "qualified
DC" as the former, it might be turn out to be of limited usefulness in

Even adopting the former definition of "qualified DC", another
consideration is that DCMI regularly adds new terms to the "dcterms"
metadata vocabulary. So unlike the case of "simple DC" (assuming that is
fixed at the 15 elements of the DCMES -  which is another argument, but
let's suppose that's the case!), "qualified DC" is a "moving target".
"Qualified DC" today might permit a new DC element that was not
available last week. 

How should this versioning of the vocabulary be handled in the XML
binding? Should DCMI (or OAI or whoever provides the schemas) expect
that a "qualified DC" application must work on the basis that it must
always expect to encounter new XML elements/complexTypes associated with
the http://purl.org/dc/terms/ namespace, and that documents that were
invalid on Friday afternoon (when they included an XML element
dcterms:widget) become valid on Monday morning (because dcterms:widget
has been added to the schema corresponding to the "dcterms" namespace)? 

Or should implementers be required to update their documents to refer to
a different DCMI-supplied (or OAI-supplied) application schema (e.g. by
using a date-stamped URI) in order to allow the use of new XML elements
in their documents? 

I suspect arguments can be made for either approach, but I'm inclined to
suggest the latter (though I reserve the right to change my mind!) i.e.
I feel uneasy about the (first) scenario where implementers are
validating their XML docs against a schema which is changing without
their knowledge. Anyway, either way, the policy would need to be made
very clear so that users can know what to expect.

The other reason for the current approach is that (to date anyway) DCMI
has regarded its "namespaces" as sets of elements, element refinements,
encoding schemes, and type terms. It hasn't provided URIrefs or
qualified names to identify "application profiles", like "simple DC" and
"qualified DC", so there would probably be some procedural/policy issues
to be addressed there.



More information about the OAI-implementers mailing list