[OAI-implementers] Qualified Dublin Core

[Timothy W. Cole]

Jeff-

This is partly a matter of striking balance between data provider and
service provider workload.

As another service provider, I would agree that just because an element in a
harvested metadata record is labeled <spatial> in some application-specific
XSD, it doesn't mean that I can assume that the element means the same thing
as <dcterms:spatial>. (See also my own reply to Stephen Crawley.)

However, I disagree that I should treat the contents of an element in a
metadata record that is explicitly labeled <dcterms:spatial> (where dcterms:
is unambiguously the prefix for the appropriate DCMI namespace) as any less
meaningful because it's embedded within a record containing elements from
multiple namespaces, including some with which I may not be familiar. While
arguably the problem can get more complex when dealing with schemas defining
elements with highly complex content models, with dc, dcterms, dcmitypes, I
don't think a lot of ambiguity creeps in just because elements of additional
namespaces are included. The contents of an element labeled
<dcterms:spatial> should still be making the same kind of assertion about
the spatial coverage of the object being described regardless of the
inclusion of sibling elements in other namespaces.

There could of course be some adverse indicators. For instance, I would
prefer that the XSD against which the harvested record validates makes
mention (directly or through indirection) of the dcterms namespace and XSD
(rather than for example allows inclusion by invoking #any or some similar
mechanism). To me that suggests that the data provider really means to be
including dcterms semantics. 

I suppose I might also be wary of <dcterms:spatial> appearing at other than
the first-level of the metadata record XML hierarchy. That could imply the
assertion is not about the primary object being described (which is where
RDF would be helpful, too bad RDF is so antithetical to certain features of
XML Schema Language like xsi:type).

And we can probably argue about whether you risk major problems when you
ignore encoding schemes your application doesn't know about. 

But otherwise, I don't think it's a major leap of faith to take elements
represented as being in namespaces known to me at face value. Certainly I'd
rather harvest the qualified DC based OLAC, NSDL, and CDP formatted records
than settle for their dumbed down simple DC records. I'm confident in those
instances that <dcterms:spatial> means <dcterms:spatial> in spite of the
fact that their records also may include some additional non-DC semantics.

And also I don't think it unreasonably demanding for my application to
inspect XSDs returned in response to ListMetadataFormats verb, even to point
of inspecting one or two levels of imported XSDs to discover namespaces
being invoked of possible interest to me. Of course that gets back to the
balancing act of who should do what between data providers and service
providers. Perhaps in this instance I'm being too liberal in trying to
minimize effort of data providers.

Tim Cole
University of Illinois at UC 


> -----Original Message-----
> From: oai-implementers-bounces at openarchives.org 
> [mailto:oai-implementers-bounces at openarchives.org] On Behalf 
> Of Young,Jeff
> Sent: Thursday, August 12, 2004 8:48 AM
> To: Stephen Crawley; 
> oai-implementers at oaisrv.nsdl.cornell.edu; crawley at piglet.dstc.edu.au
> Subject: RE: [OAI-implementers] Qualified Dublin Core 
> 
> Speaking only for myself as a service provider, I doubt that 
> I will be interested in a generic container of "things". I 
> simply don't have the time or patience to figure out what's 
> what in a blob of data. Including a "schema" attribute and 
> "element" element might help, but the investigation still 
> sounds difficult. In addition, my sense is that taking the 
> easy route and blindly pulling DC and DCQ elements from the 
> blob (or elements from any other namespace) will produce a 
> meaningless jumble 9 times out of 10. I could be wrong, though.
> 
> Jeff
>