SRWU ReIntroduction SRW is a Web Services based

SRW/U: Re-Introduction SRW is a Web Services based Information Retrieval Protocol Motivations: Create an easy to implement protocol with the power of Z 39. 50 Need for a generic IR web service Use existing off the shelf solutions where possible Re-evaluate Z 39. 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. z 3950. org/ Email me: azaroth@liv. ac. uk : ) Rob Sanderson (azaroth@liv. ac. uk)

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 Search. Retrieve Search, sort and retrieve records Scan Retrive ordered list of index terms Rob Sanderson (azaroth@liv. ac. uk)

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 Zee. Rex record wrapped in standard metadata Zee. Rex: Z 39. 50 Explained and Re-Engineered in XML service description tailored for Z 39. 50 and SRW Rob Sanderson (azaroth@liv. ac. uk)

SRW/U: Search. Retrieve 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)

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)

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

SRW/CQL: Metasearch 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)

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 Z 39. 50 connections Only state required is for result sets, which aren't mandatory Rob Sanderson (azaroth@liv. ac. uk)

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)

SRW++: Meta. Searching Protocol Multiple Resource Single Query: AB Client A Database 1 Database 2 Meta. Search Database 3 B Database 4 Here B is acting as A, a Meta. Search Protocol! So A must be at least a superset of B. . . All requirements for B are requirements for A. Hence SRW++. Rob Sanderson (azaroth@liv. ac. uk)

SRW++: Requirements A[B] Client Database 1 Database 2 Control of Meta. Search 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 Rob Sanderson (azaroth@liv. ac. uk)

Conclusions 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 Meta. Searcher behaviour Asynchronous/Incremental vs single message NISO Taskgroups to inform the development Rob Sanderson (azaroth@liv. ac. uk)