[OAI-implementers] Complex objects/embedded metadata/multiple
robert.tansley at hp.com
Tue Jul 26 13:42:09 EDT 2005
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
More information about the OAI-implementers