[Web4lib] Re: OpenSearch, Koha, and Library Catalogs [SRW/U]

Ross Singer ross.singer at library.gatech.edu
Mon Jul 25 12:27:31 EDT 2005


Mike Taylor wrote:

>>Imagine a larger result set, with multiple "types" of results (some
>>monographs, some electronic, some other types) where your metadata
>>results might vary?
>>    
>>
>
>Yes.  I still don't understand the problem.
>  
>
If all cataloging departments followed the exact same rules this 
wouldn't be a problem.  I think to create a simple interface that can 
account for how all the metadata could be returned is a bit optimistic.

Note:  I really want this to become an overly cynical position and to be 
proven that it's much simpler than I currently feel it is.

>  
>
>>OpenSearch requires a "title" and "url" for each result and an
>>option description.
>>    
>>
>
>You can easily do that with SRU.
>
>  
>
Aren't you limited to the formats that the SRW/U in question will return 
the results in?  You are requiring the client to transform this.

>>The other thing I note is that SRU requires an SRW/U server --
>>which, frankly, probably means only bibliographic data will be
>>searched.
>>    
>>
>
>??!!
>
>What is an "SRW/U" server?  And SRU server can be any program the
>responds to SRU requests -- for example the 136-line SRU server on the
>	http://sru.miketaylor.org.uk/
>web-site.  So, sorry, I am still not understanding what the problem
>is.
>
>And I don't _at all_ understand what makes you think that SRU is
>limited to bibliographic data.  It absolutely isn't.  There are
>_already_ SRU profiles for:
>* thesaurus navigation -- http://zthes.z3950.org/srw/current.html
>* collectable card games -- http://srw.cheshire3.org/contextSets/ccg/
>* musical manuscript -- http://www.ceridwen.com/srw/music-contextset.html
>* service registries -- http://srw.cheshire3.org/profiles/ZeeRex/
>and who knows what else is in development?
>
>  
>
While I agree that SRW/U is good for more than bibliographic data (and 
that's why I stated "frankly, /probably means/ only bibliographic data 
will be searched"), I have yet to see it widely implemented.

You have to understand, I /love/ SRW/U.  It has made my life a lot 
easier.  None of my developer friends outside of libraries have ever 
heard of it, though.  Should they?  Maybe.   However, until it's in the 
common parlance, it's hard to wait around for the "outside world" to 
adopt it in order to expose our resources.

>>Also, I want to reiterate the fact that our OpenSearch
>>implementation /is merely transforming queries to and from our SRU
>>implementation/.  A9 does not support SRU, so what do we do?
>>Boycott them?  Or adapt our services to work with them?
>>    
>>
>
>No, sure, absolutely.  The point I am _not_ missing (:-) is your need
>to provide an OpenSearch interface for the benefit of the specific
>client (A9) that uses it.  What I am still not getting is why you seem
>to think SRU is unsuitable in other contexts.
>  
>
Again, I think it goes back to a particular use case.  OpenSearch, by 
definition, requires a title and url formatted a particular way.  SRU 
requires me to know what to do with whatever metadata schema might be 
coming from the originating server.

I think my point is that these two technologies aren't incompatible, 
and, in fact, can serve two different purposes.  I honestly believe it 
is much easier to create a "generic" opensearch client that can point at 
any opensearch server and always display the same way than it is for 
SRW/U.  This doesn't exclude SRW/U from searching across 
databases/resources/collections in the background, it also doesn't 
exclude SRU being the URL sent in an OpenSearch result set (I'm talking 
hypothetically here).  The OpenSearch server, can, in fact, be  (and in 
our case, is) an SRU client.

The other nice part (although I'm not going to call it an "advantage", 
SRU has infinitely more "advantages" than OpenSearch) is that OpenSearch 
is served via RSS, which there is a rich infrastructure for, already, a 
lot of possibilities on how to integrate it into existing 
applications/sites.

I guess what it boils down to is:  I am not endorsing OpenSearch over 
SRU (which I think has been mistaken).  In fact, I feel the opposite.  
SRU is a /much/ better technology for searching.  However, I feel that 
OpenSearch /at times/ can be a better (and easier) way to integrate 
those search results into an application/web presence.

-Ross.



More information about the Web4lib mailing list