[OAI-implementers] DCTerms

[Pete Johnston]

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 
application profiles".

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- 
specific requirements).

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! :-(

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 at ukoln.ac.uk
http://www.ukoln.ac.uk/ukoln/staff/p.johnston/