Comments to: SRU/CQL OASIS Proposal

On the day before Christmas SRU Editorial Board sent out a proposal about to standardize a search/retrieve protocol and query-language.

Based on an email discussion in danZIG (indigenous the Danish Z39.50 group - now also deal with other interoperability standards as SRW/SRU and NCIP) and a meeting in S24u4 - Danish Standards committee for Information and Documentation - Technical Interoperability I have some Danish comments.

First we greet the initiative to a broader standardisation of search/retrieve protocol and query-language.

We have noted a change in profiling with the change of "name in front" from SRW to SRU. Notwithstanding the focus on REST web service as SRU involves, we see it as very important to keep the connection to W3C and the SOAP standard. SOAP web service is defined as the Danish e-government basic web service standard - so we need SRW.

CQL can be used both for very simple search and very complicated search. Use of SRW/SRU and CQL for more complicated search reflects a need in library domain - and I think other domains will meet this need over the next years. So we see it as very important that the resulting standard can be used both for simple search and complicated search in same framework.

A standard method to describe the service of a server like Explain and a service to order a list of words are still of great value.


Best regards,

Leif Andresen
Chair danZIG
Chair S24 - Danish Standards committee for Information and Documentation
Member S24u4

*********************************************************
Leif Andresen    *   Email: [log in to unmask]
Library Advisory Officer
Danish National Library Authority
Nyhavn 31 E, DK-1051 Copenhagen K
Phone direct: +45 3373 3354
Phone: +45 3373 3373 *  Telefax: +45 3373 3372
*********************************************************
 

-----Oprindelig meddelelse-----
Fra: SRU (Search and Retrieve Via URL) Implementors [mailto:[log in to unmask]] På vegne af Ray Denenberg, Library of Congress
Sendt: 23. december 2005 20:30
Til: [log in to unmask]
Emne: SRU/CQL OASIS Proposal

The SRU Editoral Board proposes to initiate an effort to standardize a search/retrieve protocol and query-language. The SRU/W/CQL specifications would be the basis for this effort, which might pull together other specifications in this area, including OpenSearch, Google API, and SQI. We propose OASIS (http://www.oasis-open.org) as the standards body.

We would launch the effort by beginning an OASIS discussion list to gauge interest in setting up an OASIS Techical Committee. A discussion list is a preliminary step towards forming a TC but does not constitute a commitment to do so.

OASIS is often used as a neutral ground for merging competing de facto standards into an industry standard. It would fit well with our intent to harmonize the various defacto standards in the field. The OASIS public-list process to discuss the formation of an OASIS TC would be a good exercise to determine if there is sufficient consensus across these different communities that a harmonized standard would actually emerge from an OASIS TC process -- or whether there are intrinsic, insurmountable differences of opinion.

There is some risk: a resultant standard might take the best of OpenSearch, SRU, etc. but  still  not resemble any one of them. On the other hand it might closely resemble SRU.  Most likely, the standardization process will introduce some changes in the specification, especially since the reason for standardization is to raise awareness and usage within new, larger communities who almost certainly have new use cases that need to be supported.

We hope Microsoft, Amazon, etc. will participate in developing a specification that takes the best parts of OpenSearch, SRU, etc. This would be good because (we think) SRU has a very large proportion of those best parts.  The world clearly needs a well-defined, powerful protocol for searching by URL with results returned in XML. SRU clearly has an advantage over OpenSearch because of CQL, and because of the functionality, flexibility, and extensibility that the protocol itself adds. Quite possibly,  SRU can be represented as a sophisticated (and backward
compatible) version of openSearch.

We would start an open list under OASIS auspices that would help determine:
if other parties (A9 etc.) would participate, to what extent the input from other parties might introduce change to the current SRU spec, an estimate of how long it would take to get to a committee draft (the version prior to public comment and a vote of all OASIS members),  and how long to get from committee draft to a standard. For example, the committee draft might take six months and comittee draft to an actual standard, perhaps three months.

We welcome comments on this idea.