[OAI-implementers] points to ponder

[Simeon Warner]

I think that they key to extension of OAI-PMH in experiments or in
production systems is that extension shouldn't derail the continuing
movement to expose metadata with OAI. We would loose a great deal if this
aggregate "collection" became fragmented due to interoperability problems.

This means that extensions mustn't break existing functionality so that
any ordinary harvester may continue oblivious to the extension if the
baseURL is public in the normal way. Hussein's point that research should
be advertised as such (and shouldn't necessarily be judged by the "who is
using it" criterion) and Jeff's point about marking the baseURL in an
obvious way sound sensible.

We also shouldn't forget to do experiments with the big metadata
collection that OAI already allows us access too...

my 2c,
Simeon


On Wed, 14 May 2003, Andy Powell wrote:
> On Tue, 13 May 2003, Young,Jeff wrote:
> 
> > My general solution has been to add '/extension' to the baseURL for any
> > application-type verbs. Whether this enough to differentiate it from OAI-PMH
> > proper may be debatable.
> >
> > I've encountered three cases so far:
> >
> > verb=GetMetadata&metadataPrefix=oai_dc&identifier=oai:xyz:123 - to return
> > the content of the <DEFANGED_metadata> element without the OAI wrapper.
> >
> > verb=Redirect&identifier=oai:xyz:123 - to look up the first dc:identifier in
> > the record and perform an HTTP redirect to it. (This is in relation to
> > another upcoming paper that Thom and I are doing with Andy Powell.)
> >
> > verb=FRBRRedirect&identifier=OPAC_ID&isbn=ISBN - to support bookmarklets
> > that direct users from a web page containing an ISBN (such as Amazon) to
> > their local library's OPAC. (See http://alcme.oclc.org/bookmarks/ for the
> > prototype).
> 
> Provided these extension 'verbs' are supported at a different baseURL,
> then I don't see any problem at all - because you haven't touched the
> protocol at all.  What you done is extended a bit of software that
> supports OAI-PMH to all support some additional requests at a different
> URL (at least, I assume that's what you've done!).
> 
> I'm not quite clear Where the original question was coming from, but, for
> example, I think it would be much more questionable to invent a record
> format called 'fullText' and to then use the protocol to exchange
> 'resources' (as opposed to 'records').  At that point, one would be using
> the 'protocol for metadata harvesting' to do something other than
> 'harvesting metadata'.
> 
> At the moment, the protocol 'does exactly what it says on the tin' (sorry,
> that's a quote from a UK TV advert for wood stain) and it does it in
> pretty much the simplest way possible given the required functionality.
> That makes it pretty easy to explain to people what it does, why it does
> it and what it doesn't do.  I have a concern that 'extending' the use of
> the protocol may actually make it harder to sell to people (depending on
> what we mean by extending - and I may be barking up the wrong tree
> here!).
> 
> > > should i use a completely new vocabulary for random access to a
> > > repository/database/component or are words like "GetRecord" and
> > > "ListRecords" ok? can the parameters be the same or are
> > > "identifier" and
> > > "set" reserved for OAI-PMH? is the record format strictly for
> > > OAI-PMH only?
> 
> One thing I have been wondering about is whether the use of
> oai-identifiers is restricted in some way to the use of the OAI-PMH, or
> whether they can be used as identifiers for metadata records (or 'items')
> in other contexts?
> 
> Andy
> --
> Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
> http://www.ukoln.ac.uk/ukoln/staff/a.powell       +44 1225 383933
> Resource Discovery Network http://www.rdn.ac.uk/