mfoulonn at uiuc.edu
Thu Feb 23 12:47:34 EST 2006
I am not sure about the UK but here the ContentDM software is fairly common
and has integrated in its last version an option to export QDC in OAI,
additionally to the UDC. I think it is using the following schema
http://epubs.cclrc.ac.uk/xsd/qdc.xsd which only includes the DC terms from
the DCMI Website. The OAI registry counts 8 implementations to date but it
still new. Most other QDC as far as I could tell use additional elements or
terminologies I think.
The use of QDC mostly in application profiles is true but certain data
providers are happy to have the possibility of additional refinements.
From: oai-implementers-bounces at openarchives.org
[mailto:oai-implementers-bounces at openarchives.org] On Behalf Of Pete
Sent: Wednesday, February 22, 2006 1:41 PM
To: Young,Jeff (OR)
Cc: oai-implementers at openarchives.org
Subject: Re: [OAI-implementers] DCTerms
I see Rachel has already said pretty much what I was going to say, but
just to expand slightly....
Young,Jeff (OR) wrote:
> I got asked the same thing last week. If you look through the list at
> http://gita.grainger.uiuc.edu/registry/ListSchemas.asp, you will find
> less than a handful of references to http://purl.org/dc/terms/ and there
> is no standard container schema defined for them. The same problem would
> have been the case for Simple DC, except that the OAI specification
> developers went to the trouble of creating one (oai_dc).
> Apparently, there has never been enough interest in DCQ to warrant the
> creation of such a container.
I'd qualify (ho ho!) that slightly by saying it's not so much that there
is no interest in "qualified DC", but rather that the label "qualified
DC" is often used rather loosely to refer to what turn out in practice
to be different permutations of terms - in DCMI parlance, different "DC
DCMI (or indeed another agency) could define a container XML element
which had a content model that permitted as children a set of XML
elements to represent the set of properties owned/defined by DCMI (the
"properties in the dc and dcterms namespaces" - which is not a fixed set
properties, since DCMI occasionally adds new terms to its vocabularies)
But in practice this set is rarely the set of properties that "qualified
DC" applications want to reference. Rather, they want to reference some
subset of this DCMI-owned set of properties, in combination with some
additional set of properties (either drawn from some other "standard"
property set or defined "locally" to meet some application-/context-
If a single (some:qdc) container element was provided, but different
data providers wanted to limit the child elements available to match the
properties used in their own different DCAP, then they each end up
redefining/constraining the content model for that container element.
And conversely, for a service provider consuming the data, they'd have
to expect that a some:qdc container element might contain... well, any
set of child elements at all.
So in terms of validation etc, I'm not sure that a common container XML
element would buy us very much, so (as Rachel said) it's been left to
implementers to provide their own container elements, with the capacity
to provide their own content models, on a per-DCAP basis.
Having said that, I can see that a shared container element could be
used as a "hint" that the record format implemented the DC-XML
guidelines, regardless of what set of actual properties were used in
that particular DCAP. I think a better way of doing this would be to
define a MIME type to identify the DC-XML format, so that it could be
signalled that a metadata record was an instance of that format
independently of the XML Namespace of the "root" element - but AFAIK
OAI-PMH doesn't allow me to associate a MIME type with a metadata
record, so that doesn't help! :-(
Research Officer (Interoperability)
UKOLN, University of Bath, Bath BA2 7AY, UK
tel: +44 (0)1225 383619 fax: +44 (0)1225 386838
mailto:p.johnston at ukoln.ac.uk
OAI-implementers mailing list
List information, archives, preferences and to unsubscribe:
More information about the OAI-implementers