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

[Fabio Simeoni]

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