[OAI-implementers] Complex objects/embedded metadata/multiple schemas

[Roy Tennant]

Speaking from the perspective of a nascent service provider, I would  
have to say "the more the merrier" when it comes to exposing metadata  
via OAI-PMH. As a service provider, I can make my own choices as to  
which metadata format I prefer to harvest, and having a much richer  
schema (albeit one that may take some review and post-processing for  
my particular purposes), is still desirable over having no choice at  
all. Having said that, I would say that I would prefer to have the  
metadata exposed as separate descriptive metadata packages if  
possible rather than in a METS wrapper, since as you know the METS  
wrapper adds complexity. Specifically, I mean the data provider might  
offer three different schemas for the metadata:

1) the required simple DC
2) a qualified DC
3) MODS

as an example. This would allow me as a service provider to easily  
consume the metadata without first having to "unpack" and understand  
your particular METS profile. Especially since we are putting the  
metadata into our own METS profile on our end ;-). My two cents, for  
what it's worth.
Roy Tennant

On Jul 26, 2005, at 10:42 AM, Tansley, Robert wrote:

> Hi all,
>
> This issue has been skirted in a few previous mails.  Right now,  
> DSpace
> can expose metadata about complex objects via its OAI-PMH data  
> provider
> interface, either as MPEG-21 DIDL or METS.
>
> One problem of course is that since METS is essentially an envelope  
> for
> other kinds of metadata, it's pretty pointless to just say "I support
> METS".  It's one step further than "I support XML" but to get
> interoperability you need to go quite a bit further.
>
> In other words, as an OAI-PMH service provider (or a tool hoping to do
> some resource harvesting/mirroring) I can't just ask for the metadata
> prefix "mets" and hope to understand what comes out.  E.g. will it  
> have
> qualified DC in it, or MODS?
>
> Perhaps, rather than by namespace/schema, I really need to specify by
> profile (and in the case of DSpace even that's not likely to be  
> uniform
> across the board).  Should I be using a metadataPrefix like
> "mets_dspace" or somesuch?  Just using "mets" might be setting an
> expectation of interoperability/understandability that just isn't  
> there.
> On the other hand, using "mets_dspace" might be removing a possibility
> -- if I expose METS which has qualified Dublin Core in it, a harvester
> might at least be able to extract and use that, even if it doesn't
> understand some of the other metadata embedded in the METS.
>
> Another issue is whether having multiple schemas in harvested  
> records is
> going to cause a problem for harvesters.  Even in the simple case of
> METS with some qualified DC in it, there's the METS and QDC  
> schemas.  I
> don't have enough experience on the harvester/service provider side of
> things to know whether this will cause headaches.
>
> Is this pushing really beyond what OAI-PMH was designed for?
>
> All thoughts/comments welcomed...
>
>  Robert TANSLEY / Digital Media Systems Programme / HP Labs
>   http://www.hpl.hp.com/personal/Robert_Tansley/
>
> _______________________________________________
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
> http://www.openarchives.org/mailman/listinfo/oai-implementers
>
>
>
>