[OAI-implementers] on the extensibility of OAI-PMH

[herbert van de sompel]

Fabio,

I guess you may want to look at complex object formats such as MPEG-21 DIDL and 
METS, which natively allow you to "wrap" lots of things.

See, for example, http://www.dlib.org/dlib/december04/vandesompel/12vandesompel.html

herbert

Fabio Simeoni wrote:

> Herbert,
> 
> the 'additional' stuff is indeed about items, not their metadata (so outside
> the <about> container). 
> Defining a new metadata format does not seem satisfactory, because it either
> 
> 1) freezes the format of both 'normal' and 'additional' stuff, and I am
> after a general, application-independent mechanism.
> 2) does not mandate either (is a container) but consumes the possibility of
> specifying precise formats for 'normal' and 'additional' stuff.
> 
> To rephrase, a harvester may want any combination of formats for both
> metadata and extra stuff and I'm after mechanism that does not rely on the
> standardisation of specific combinations of 'normal' and 'additional' stuff
> (say DC&add1, MARC&add2, DC&add3, MARC&add1, ....). I'd rather having the
> two parts to be standardised separately and combined on a per-request basis.
> 
> 
> cheers,
> 
> fabio
> 
> ##############################################
> Fabio Simeoni 
> Research Fellow
> Department of Computer & Information Sciences
> University of Strathclyde, Glasgow
> 
> TEL: +44 141 548 (3590)
> FAX: +44 141 548 (4523)
> 
> -----Original Message-----
> From: herbert van de sompel [mailto:herbertv at lanl.gov] 
> Sent: 06 May 2005 18:29
> To: Fabio Simeoni
> Cc: oai-implementers at openarchives.org; 'Steve Neely'
> Subject: Re: [OAI-implementers] on the extensibility of OAI-PMH
> 
> Fabio Simeoni wrote:
> 
>>Hi,
>>
>>a 3rd party would like to consider extensions of the oai:recordType 
>>component of the protocol's schema in order to disclose per-record 
>>information other than and in addition to descriptive metadata (say 
>>contained in a <foo> element following the <metadata> element). The 
>>extra information is optional, in that standard OAI requests simply do 
>>not trigger its generation; accordingly, the party would very much 
>>like this kind of extension to be backword-compatible, so that a 
>>single implementation of the extended server would equally serve old and
> 
> new clients of the protocol.
> 
>>Conceptually such an extension *is* backword-compatible but the 
>>protocol's schema does not cater for it (why?). The 3rd party must 
>>either extend within the OAI namespace, which it does not own 
>>(apparently a bad practice even when technically harmless) or else 
>>extend into a new namespace and accept to break all namespace-aware 
>>old clients. Is this correct and, in case, is there a way around it? 
>>Or must the 3rd party admit that standard and extended implementations 
>>of the protol must live (and be maintained) side by side at two different
> 
> URLs?
> 
> 
> Fabio,
> 
> I am not sure I understand your question correctly, but assuming I do, here
> are the ways to achieve what I think you want to achieve without having to
> extend the protocol:
> 
> (*) Introduce an extra harvestable metadata format - <bar> - that
> encapsulates the "normal" one and the "additional" one (note that using XML
> Schema, the nature of the additional one can be defined in an open-ended
> manner : any namespace ...)
> 
> <metadata>
> <bar>
> <dc/>
> <foo/>
> </bar>
> </metadata>
> 
> (*) If the "additional" stuff is metadata about the "normal" stuff then put
> it in an "about" container
> 
> cheers
> 
> herbert
> --
> Herbert Van de Sompel
> Digital Library Research & Prototyping
> Los Alamos National Laboratory, Research Library
> http://public.lanl.gov/herbertv/ tel. +1 505 667 1267
> 
> 
> _______________________________________________
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
> http://www.openarchives.org/mailman/listinfo/oai-implementers
> 
> 

-- 
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/
tel. +1 505 667 1267