[OAI-implementers] Qualified Dublin Core

[Timothy W. Cole]

Comments embedded below 

> -----Original Message-----
> From: oai-implementers-bounces at openarchives.org 
> [mailto:oai-implementers-bounces at openarchives.org] On Behalf 
> Of Stephen Crawley
> Sent: Wednesday, August 11, 2004 9:36 PM
> Subject: Re: [OAI-implementers] Qualified Dublin Core 
> 
> Folks,
> 
> A canonical container XSD for qualified DC would be useful, 
> but it doesn't really solve the problem, IMO.
> 
> Why?  Because many (most) DC-based metadata collections use 
> elements and/ or refinements that are not in DCQ.  These can 
> be extensions mandated by some other standard (e.g. AGLS, 
> EdNA, etc) or site-specific extensions. So, while oai schemas 
> for exchanging DCQ, AGLS, EdNA, etc would be useful, the 
> larger problem is how to exchange metadata with an arbitrary 
> metadata schema ... without defining yet another XML schema 
> to transport the records.
> 
> The solution (as we see it) is to use XSD that is 
> *insensitive* to the metadata's schema.  

I'm not sure what is meant here. Seem to be implying a way that I can send
OAI harvesters metadata consisting entirely of elements that have no
community-standard semantic labels, which seems counter-intuitive. Even if
some of my metadata elements make sense only to my local application, don't
I want to label at least those other elements in my record that do
correspond to community-standard semantics with the namespace and element
names of that standard semantic schema(s)?  

> In the simple model, 
> the OAI repository assembles XML records containing whatever 
> elements it is prepared to publish. The OAI client would then 
> sort through the supplied elements, throwing away any that it 
> doesn't want / understand, and massaging others as required.
> Then the client validates the filtered records against its 
> own metadata schema before it decides what to do with them.

I agree with Jeff to this extent, if none of the metadata elements in a
harvested metadata record are labeled with an element name I know prefixed
by a metadata schema namespace I know, I'll have to throw all the elements
away, and the record will therefore be worthless to me.

> The problem of elements meaning different things in different 
> schemas is a bit tricky.  

Yes, an element called <spatial> might mean one thing in metadata schema A
and something quite different in metadata schema B. As a harvester, if I
encounter an element <spatial> that is not tied to the dcterms schema and
namespace (or some other namespace I know) I would always discard it rather
than assume it means the same thing as <dcterms:spatial>. It's not a safe
assumption that just because something is labeled <spatial> in a local
schema it means the same thing as <spatial> in dcterms. That's why XML
namespaces are so handy. The data provider can explicitly and unambiguously
tie an element in his or her record to one specific, community-standard
metadata semantic set.

> However, you can get some traction 
> if each record's metadata schema identifier is included in the record.
>
 
But XML and XML Schema Language already have standard, well-defined
mechanisms (namespaces and the ability to import or include other XSDs
within you XSD) that make it easy to identify the semantic set with which
any given element in a metadata instance is associated. Why not just use
those XML standard approaches?

A problem can occur when semantics overlap such that <spatial> does mean the
same in both schema A and schema B. The most common way around this is to
repeat the element (e.g., include both <A:spatial> and <B:spatial>), which
though perhaps not elegant works just fine. 

In some other instances of overlaps between schemas, the XML schema language
substitutionGroup attribute can also be used to good effect -- though it
requires a slightly more sophisticated algorithm on the part of the
harvester to recognize.

> For info: I've attached the XSD schema that DSTC's MetaSuite 
> system uses for passing metadata records between Broker 
> instances over OAI.  The XSD is not suitable for general use 
> because it contains a lot of MetaSuite specific admin fields. 
>  However, it illustrates the approach. The key bits of the 
> XML schema are the "schema" attribute and the "element"
> element.  The latter represents the element's prefix + name + 
> refinement as the "id" attribute.
> 

Well the schema you attached failed XML well-formedness (apparent typos on
lines 64, 102, and 110, also appear to have left out the attribute name
[i.e., "value"] on lines 110, 111, and 117). There also appears to be a
glitch (at least according to XSV) with complexType definition of
REG:RecordType. So, I'm not sure I exactly understand what you're trying to
do with your schema. But from looking at it and from what you said about in
your note, it seems to me like just another way to do much the same thing
that can be done in a more XML standard way by importing/including other
schemas and namespaces of interest in your local XSD and labeling the
elements in your metadata record instances accordingly. 


> If anyone is interested in developing an OAI spec for 
> schema-independent metadata interchange, please drop me a line.
> 

I'm not sure of the benefit of the approach represented by your schema. You
provide some additional attributes that might be of interest for other
purposes, but for determining whether an element labeled <spatial> in your
metadata record means the same thing as <dcterms:spatial>, I'd rather rely
on conventional XML namespace methods.

Tim Cole
University of Illinois at UC 



> -- Steve
> 
> +----------------------------------+--------------------------
> ----------
> +----------------------------------+----
> | Stephen Crawley                  | MetaSuite Project Leader
> | Level 7, GP South Building (78)  | Distributed Systems 
> Technology CRC
> | Staff House Road                 | Tel   : +61 7 3365 4310
> | The University of Queensland     | Fax   : +61 7 3365 4311
> | Queensland 4072                  | Email : crawley at dstc.edu.au
> | Australia                        | WWW   : http://www.dstc.edu.au
> |                                  | DSTC is the Australian W3C Office
> +----------------------------------+--------------------------
> ----------
> +----------------------------------+----
> 
>