OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: searchRetrieve interoperability demonstration


I want to begin the process of an interoperability demonstration for the OASIS searchRetrieve Standard, required in order to move this to ISO.

 

According to the guidelines, https://www.oasis-open.org/policies-guidelines/interop (Internal TC Interoperability Activities)

"OASIS recognizes that some TCs find value in internally testing specifications through non-promotional, informal, proof-of-concept activities (plug fests, etc.). The results of these activities are primarily intended to benefit further specification development. OASIS TC chairs are asked to notify events@oasis-open.org of intentions to organize an internal TC proof-of-concept, however, formal InterOp Proposals are not required and the InterOp requirements stated in these Guidelines do not apply."

I

hope we can assume that this clause applies in this case.

 

searchRetrieve has several specifications, including  SRU and CQL, and OASIS agreed during the conference call in March that we could limit the demo to SRU and CQL. It was further agreed that the implementations participating need not be fully compliant with the OASIS spec, because the current base of SRU specification are mostly version 1.1 (the OASIS suite includes versions 1.2 and 2.0).

 

I'd like to start the process by simply describing what we can demonstrate.  

 

Brief background.

·         SRU is a client/server protocol.  The client (as suggested via the name SRU which means "Search and rretireive via URL)  may simply consist of a user submitting an SRU-formatted URL.  Or the client may be a user interface (possibly a simple command line client) into which the user inputs  a seach and which then converts the input into an SRU-formatted URL. 

·         SRU is based on the older, Z39.50 protocol.  There is a large base of Z39.50 severs in the world.  SRU is deployed often simply to provide access to Z39.50 servers.  That's because SRU is much friendlier but Z39.50 is where the data is.  CQL is the query language for SRU.  In some cases a client simply provides the user an interface to input a CQL query which it converts to Z39.50. So, interoperability between SRU/CQL and Z39.50 is crucial.

 

we can demonstrate the following:

 

1.       SRU Client/server interoperability. SRU Client at an OASIS Member Institution searching an SRU Server at a remote OASIS Member Institution.

2.       CQL/Z39.50 interperability. CQL Client at one OASIS Member Institution searching a Z39.50 Server at a remote OASIS Member Institution.

 

For (1)   A user (for example, me) at the Library of Congress can search, via direct SRU-URL, an SRU server at OCLC.

 

For example, the following is an SRU URL to seach OCLC's WorldCat Registry of Institutions for 'hopkins':

http://worldcat.org/webservices/registry/search/Institutions?query=local.institutionName=hopkins&recordSchema=info:rfa/rfaRegistry/schemaInfos/adminData

 

 

For (2), using a YAZ client from Index Data (http://www.indexdata.com/yaz) , at the Library of Congress, I can input a CQL query, which will be converted to a Z39.50 query to search a remote Z39.50 database, at an OASIS Member institution.  (I need to research which OASIS Members have Z39.50 servers, but there are some, for example, Johns Hopkins.)

 

 

Ralph, Matthew, do you have any additional suggestions?

 

Chet, how does this all sound, and what's the next step?

 

--Ray

 

 

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]