cni, 4th april 2006 slide 1

CNI, 4th April 2006 Slide 1

Key Standards Update:Key Standards Update:SRU (“Technical” Details)SRU (“Technical” Details)

Dr. Robert SandersonDept. of Computer ScienceUniversity of Liverpool

[email protected]

http://www.csc.liv.ac.uk/~azaroth/http://www.loc.gov/standards/sru/http://srw.cheshire3.org/


OverviewOverview

Aims and Motivations

Other Protocols: OAI, OpenSearch

Response Format Additions

Sort

Proximity

Extensions, Diagnostics


OverviewOverview

Overall aims/goals for the changes towards SRU 1.2

Reduce protocol complexity without losing important

features

Allow easier/deeper integration with other protocols

Correct past mistakes (mea culpa!)

Improve visibility, understanding and implementations

Escape the “library ghetto”

... Profit!


Ease of IntegrationEase of Integration

Other protocols to interoperate with:

Open Archives Initiative (OAI-PMH)

OpenSearch

OpenURL

“Web 2.0” / “Library 2.0” enabling techniques

(Should change name to “OpenSRU 2.0” ??)


Ease of Integration: OAIEase of Integration: OAI

Formalize a profile to allow OAI to be implemented over

SRU

rec.identifier Search by

identifier

rec.lastModificationDate Search by

modification time

rec.collectionIdentifier Search by 'set'

Plus extension to allow OAI header information to be

returned

(record is in which sets, etc)


Ease of Integration: Ease of Integration: OpenSearchOpenSearch

SRU compatible profile of OpenSearch

OpenSearch allows the server to pick the names of

parameters ... Pick names that match SRU's

parameters

Allow query extensions to build CQL from OpenSearch's

parameters.

x-dc-title=Lord of the Rings&x-dc-creator=Tolkien

Unaware SRU and OS servers will just ignore.


Response Format Response Format AdditionsAdditions

Allow record Identifier (metadata level) to be returned in the

record structure

Allow the full base URL to be returned in the response

(within echoedRequest)

<record> <recordSchema>info:srw/schema/1/dc-v1.1</recordSchema> <recordPacking>xml</recordPacking> <recordIdentifier>info:pmid/15411833</recordIdentifier> <recordData> ... </recordData></record>

<echoedRequest> <baseUrl>http://srw.cheshire3.org/services/spy</baseUrl> <version>1.2</version> ...</echoedRequest>


SortSort

Sort has been a bugbear since version 1.0

Extend CQL to include sorting specification

Allow use of indexes with modifiers to specify

semantics

(Previously XPath expressions)

CQL parsers can be used to parse both, reducing

workload

(assuming that an existing CQL parser is used)

Enhances independence of CQL as query language

Example: dc.title any fish sortBy dc.date/ascending

dc.creator


ProximityProximity

One of the most complicated parts of SRU/CQL

No easy solution, but some improvements...

Recommendations for how to extend proximity

modifiers

-- Use a new context set for modifiers

Explainable server defaults for proximity modifiers

Improved documentation

Agreement to not agree on anything further until the

OASIS

Technical Committee to include other interested

parties


Extensions, DiagnosticsExtensions, Diagnostics

Issue: Number of matching records may be unknown or

approximate, no way to notify this condition

New diagnostics:

Number of records approximate

Number of records truncated

Request Extension:

Approximate record count is acceptable


Extra Term InformationExtra Term Information

Issue: Desirable to return sub-query level detailsEg: How many records matched in one part of the

query

Details to return need to be extensible

Solution: Add extraTermInfo into the XCQL

representation to be returned in the response

Some general extensions will be defined, but allows

implementors to include any information they think

appropriate

Needs a parameter to request that the details be

returned

(like all SRU extensions)


Thank you!Thank you!

Questions?

cni, 4th april 2006 slide 1

Documents