[OAI-implementers] Complex objects/embedded metadata/multiple
roy.tennant at ucop.edu
Mon Aug 1 11:23:25 EDT 2005
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
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.
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,
> can expose metadata about complex objects via its OAI-PMH data
> interface, either as MPEG-21 DIDL or METS.
> One problem of course is that since METS is essentially an envelope
> 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
> 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
> 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
> 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
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
More information about the OAI-implementers