1. SRW/U: Re-Introduction SRW is a Web Services based Information Retrieval Protocol Motivations: Create an easy to implement protocol with the power of Z39.50 Need for a generic IR web service Use existing off the shelf solutions where possible Re-evaluate Z39.50 “a good idea at the time” baggage Avoid library-centric preconception More Information: http://www.loc.gov/srw/ http://www.loc.gov/cql/ http://explain.z3950.org/ Email me: azaroth@liv.ac.uk : )azaroth@liv.ac.uk Rob Sanderson (azaroth@liv.ac.uk)

2. SRW/U: Summary SRW is the SOAP binding. (HTTP POST of XML for XML) SRU is the REST binding. (HTTP GET for XML) Current stable version is 1.1, released February 2004. Three Operations Available: Explain Retrieve service description SearchRetrieve Search, sort and retrieve records Scan Retrive ordered list of index terms Rob Sanderson (azaroth@liv.ac.uk)

3. SRW/U: Explain Operation Purpose: Retrieve Service Description Request: Very Simple Not quite so simple as version 1.0 Response: Very Simple Not quite so simple as version 1.0 ZeeRex record wrapped in standard metadata ZeeRex: Z39.50 Explain Explained and Re-Engineered in XML XML service description tailored for Z39.50 and SRW Rob Sanderson (azaroth@liv.ac.uk)

4. SRW/U: SearchRetrieve Operation Purpose: Search, Sort and Retrieve Records Request: Query in CQL (a string) Record Schema Identifier and XPath for sub-record level Sort specification (also a string) Result set manipulation (where to start, time to live etc.) Response: List of Records Result set information (identifier, time to live) Potentially some diagnostics All records are returned in XML. All identifiers are URIs or published aliases. Rob Sanderson (azaroth@liv.ac.uk)

5. SRW/U: Scan Operation Purpose: Retrieve Ordered List of Indexed Terms Request: CQL to determine index and starting point Number of terms Relative location of starting point in term list Response: List of Terms Potentially some diagnostics Term: Value Frequency in database Alternative for display Rob Sanderson (azaroth@liv.ac.uk)

6. CQL: Introduction Purpose: Simple and Intuitive but still Expressive Queries Language Components: Index dc.creator Relation any Term “sanderson denenberg” == SearchClause Boolean and == Triple Relation/Boolean Modifiers Parentheses for precedence Context Sets for disambiguation/extension Rob Sanderson (azaroth@liv.ac.uk)

7. SRW/CQL: Metasearch Requirements Requirements: Result Set Metadata (including Links/Branding) Record Metadata Configurable Authentication Minimal Statefulness Standard, Extensible Query Language Ability to Handle Ranking Algorithms Multiple Resources per Message I'll add: Fairly Easy to Implement and: Builds on Known Specifications Rob Sanderson (azaroth@liv.ac.uk)

8. SRW/CQL: Requirements Met Extensible Metadata: All messages have space for extensions Records and Terms have additional space Authentication handled through this space as tokens All Identifiers are URIs Extensible Query Language: CQL Context sets can be defined by anyone No requirement to register anything Work already begun to facilitate relevance ranking Minimal State Requirements: HTTP, not persistent Z39.50 connections Only state required is for result sets, which aren't mandatory Rob Sanderson (azaroth@liv.ac.uk)

9. SRW/CQL: Requirements Not Met Single Database/Server Model: SRW only queries one database at once and isn't 'expensive' Could be implemented (badly) as an extension Or 'SRW++' which wraps multiple SRW messages Metasearch Model Once More: Rob Sanderson (azaroth@liv.ac.uk) Client MetaSearch Database1 Database2 Database3 Database4 A B

10. SRW++: MetaSearching Protocol Multiple Resource Single Query: Rob Sanderson (azaroth@liv.ac.uk) Client MetaSearch Database1 Database2 Database3 Database4 A AB Here B is acting as A, a MetaSearch Protocol! So A must be at least a superset of B... All requirements for B are requirements for A. Hence SRW++. B

11. SRW++: Requirements Rob Sanderson (azaroth@liv.ac.uk) Database1 Database2 MetaSearch AB Client A[B] Control of MetaSearch Through A: Must at least allow selection of remote resources Must, therefore, advertise available remote resources Must allow selection of combined or separate result sets Fine grained control of remote resource? eg record schema Incremental Updates or Single Response: HTTP is not asynchronous, but can be faked with tokens If not incremental, then no user feedback If incremental, then constantly combining and reranking... Or result sets aren't combined, just republished If not some combination, result set metadata is lost

12. Conclusions Rob Sanderson (azaroth@liv.ac.uk) SRW + CQL: Fits the requirements for protocol B today Built on existing protocols and standards Extensible at many granularities Three primary operations, available via SOAP or REST Several OSS implementations available Right Now SRW++: Extend SRW to handle multiple database searching Enable control of MetaSearcher behaviour Asynchronous/Incremental vs single message NISO Taskgroups to inform the development