hickey at oclc.org
Tue Dec 7 15:51:46 EST 2004
I was talking to someone at Google the other day about a possible
service we could put up for them. How to do it? HTTP-Get with a simple
URL is what they were looking for.
From: oai-implementers-bounces at openarchives.org
[mailto:oai-implementers-bounces at openarchives.org] On Behalf Of Roy
Sent: Tuesday, December 07, 2004 2:46 PM
To: oai-implementers at openarchives.org
Subject: Re: [OAI-implementers] SOAP-PMH
But are we losing track of the fact that OAI-PMH is a _harvesting_
protocol and NOT a _searching_ protocol? Are potential SOAP users of
OAI data providers clear that the only thing they may be able to do is
request 85,000 records in order to get the ten they are really after
(the "professor's list of publications" example below)? The Google API,
for example, is searching of course, not harvesting. There is a
On Dec 7, 2004, at 11:36 AM, Joachim Wackerow wrote:
> Just to clarify:
> There is indeed an HTTP based approach of SOAP, it is called "The SOAP
> HTTP Binding". Here is an complete request example from the chapter
> "SOAP HTTP GET Usage" of the W3C SOAP Primer .
> GET /travelcompany.example.org/reservations?code=FT35ZBQ HTTP/1.1
> Host: travelcompany.example.org
> Accept: text/html;q=0.5, application/soap+xml
> The answer is in an SOAP envelope, a specific client is needed (as
> with OAI-PMH?).
> For example Fedora (Open-Source Digital Repository Management System)
> is using such an approach in the Fedora-API-A-LITE .
> Regarding the question on advantages of SOAP see the interesting
> discussion threads two years ago on "OAI-PMH & SOAP":
> A person of the Inktomi company is speaking for SOAP, see:
> I think some of his arguments are still important. Here are some
> snippets of his arguments:
> "With a SOAP
> interface, it would be fairly easy to build a harvester for
> our search engine. It would be a very nice sample program for our
> indexing interface. But with a one-of-a-kind XML protocol, it isn't
> worth the trouble.
> I believe that not using SOAP is a serious mistake. It means that
> OAI will remain a niche protocol, with few implementations, few
> users, and little positive effect.
> With SOAP, you get scaling support, test suites, development tools,
> supported libraries, directory service, etc. A custom protocol can
> never catch up. And implementors have much better things to do
> with their time than re-invent RPC."
> "I want that library information to be easily available to all,
> not just people willing to run a library-only protocol."
> "With a SOAP protocol, any scripted web page can make a call to OAI.
> Servers like DP9 and the repository explorer become very easy to
> write. A professor's list of publications could be built from
> the eprint data."
> "OAI is already using an XML RPC. Switching from a non-standard XML
> RPC to a standard one should be an obvious decision."
> As fare as I know: Google is investing in SOAP  but not OAI-PMH.
> Regards, Achim
>  W3C SOAP Primer
>  Fedora-API-A-LITE
>  Google Web APIs
> Young,Jeff wrote:
> > It's not a question of SOAP vs. OAI, it's a question of SOAP vs.
> > OAI could, in theory, operate using either transport mechanism.
> > Currently, the OAI protocol is based on the REST model, but some
> > prefer the SOAP model (although I can't imagine why. ;-))
> > In general, REST refers to the use of HTTP URL requests that produce
> > some form of HTTP response. This approach is so familiar to us with
> > browsing that we don't even realize it is a convention for providing
> > lightweight web service like OAI and RSS.
> > SOAP, OTOH, generally requires intelligent clients (compared to web
> > browsers) that can encode requests in SOAP wrappers and decode the
> > responses.
> > Jeff
OAI-implementers mailing list
List information, archives, preferences and to unsubscribe:
More information about the OAI-implementers