On May 13, 2004, at 10:23 AM, Walter Lewis wrote:

> For how many useful targets would it be possible to define a consistent
> intermediate layer structure that would:
>
>    - handle a SRU/SRW search
>    - transform it into an "native" database search
>    - transform the results into an SRU/SRW friendly result set
>
> and still return them in a reasonable time?
>
> I'm not (necessarily) suggesting a centralized service that would do
> this (a la OCLC) but rather a set of protocols that I could drop into a
> locally managed site for targets that we choose to address in this
> fashion.  Can  the problem be abstracted sufficiently? Can we build in
> alerts to trigger actions when the structure of a given result doesn't
> match the pattern we've been expecting (i.e. site change alert)?

I am not able to answer the question of how many, but the algorithm
Walter outlines is exactly what SRW/U are designed to address.

As you many of you may or many not know, I've been playing with SRU
lately, and I've written the following text briefly describing it:


   SRW and SRU in Five Hundred Words or Less

   Introduction

   Search and Retrieve Web Service (SRW) and Search and Retrieve URL
   Service (SRU) are Web Services-based protocols for querying
   databases and returning search results. SRW and SRU requests and
   results are very similar. The difference between them lies in the
   ways the queries and results are encapsulated and transmitted
   between client and server applications. The canonical URL for SRW
   and SRU is:

     http://www.loc.gov/z3950/agency/zing/srw/


   Basic "operations"

   Both protocols define three and only three basic "operations":
   explain, scan, searchRetrieve:

   * explain - Explain operations are requests sent by clients as a
        way of learning about the server's database. At a minimum,
        responses to explain operations return the location of the
        database, a description of what the database contains, and what
        features of the protocol the server supports.

   * scan - Scan operations are processes for enumerating the terms
        found in the remote database's index. Clients send scan requests
        and servers return lists of terms. The process is akin to
        browsing a back-of-the-book index where a person looks up a term
        in a book index and "scans" the entries surrounding the term.

   * searchRetrieve - SearchRetrieve operations are the heart of the
        matter. They provide the means to query the remote database and
        return search results. Queries must be articulated using the
        Common Query Language (CQL). CQL queries range from simple
        freetext searches to complex Boolean operations with nested
        queries and proximity qualifications. Servers do not have to
        implement every aspect of CQL, but they have to know how to
        return diagnostic messages when something is requested but not
        supported. The results of searchRetrieve operations can be
        returned in any number of formats, as specified via explain
        operations. Examples might include structured but plain text
        streams or data marked up in XML vocabularies such as Dublin
        Core, RDF, MARCXML, etc.


   Differences in operation

   The differences between SRW and SRU lie in the way operations are
   encapsulated and transmitted between client and server as well as
   how results are returned. SRW is essentially as SOAP-ful Web
   service. Operations are encapsulated by clients as SOAP requests
   and sent to the server. Likewise, responses by servers are
   encapsulated using SOAP and returned to clients. Since SOAP is
   used in SRW, HTTP is not a necessary transport protocol.

   On the other hand, SRU is essentially a REST-ful Web Service.
   Operations are encoded as name/value pairs in the query string of
   a URL. As such operations sent by SRU clients can only be
   transmitted via HTTP GET requests. The result of SRU requests are
   XML streams, the same streams returns via SRW requests sans the
   SOAP envelope.


   Summary

   SRW and SRU are "brother and sister" standardized protocols for
   accomplishing the task of querying databases and returning search
   results. If index providers were to expose their services via SRW
   and/or SRU, then access to these services would become more
   ubiquitous.


I have also taken a stab at creating an SRU interface to a union list
of serials. It sport some fun features such as a Did You Mean? function
a la Google, as well as a suggestion function offering alternative
searches to try if you get too many hits. The underlying indexer is
swish-e. The interface to the index is written in Perl. Try searching
for 'computers in librariez' without the quotes:

   http://dewey.library.nd.edu/morgan/sru/search.cgi

P.S. You will need a very modern browser to get human-readable output
from the interface since the raw XML sent to the user agent is expected
to be transformed with XSLT for display.

--
Eric Lease Morgan
University Libraries of Notre Dame