Browser integration of search

Interesting post on the Amazon Web Services Blog:

Microsoft's IE blog is reporting on the behind the scenes efforts which lead up to the recent announcement that IE7 will support A9.com's OpenSearch interface. You can read even more about this on the A9 blog. [Amazon Web Services Blog: Behind the Scenes at Microsoft, A9, and Amazon]
And the IE Blog's view of why this is important:
It's been a lot of fun working with A9. But, this is just the beginning. The OpenSearch spec occupies a special place because it intersects 3 important communities - browser, search and RSS. We want to hear from all of you. My dream is that OpenSearch is adopted by all the browsers and millions of sites (Internet and Intranets) and that a significant percentage of these sites also expose RSS. [IEBlog : IE7 and OpenSearch: Behind the scenes]
I suggest that it is time for SRU/Metasearch/NISO/somebody to come out with some simple explanatory materials explaining the relationship between MXG, SRU, SRW, and Z39.50; a routemap for the future suggesting who should adopt what and what should go away; and materials explaining the relationship between a hopefully reduced set of these acronyms and OpenSearch.

Comments: 5

Sep 17, 2005
Michael Fagan

I for one would like to see some harmonization between OpenSearch and SRU. I haven't looked at SRU much (yet), but aside from that, an SRU response could be specified in an OpenSearch Description document I believe.

[not speaking for employer (A9)]

Sep 19, 2005
Bill Oldroyd

Our SRU/Z39.50 gateway also provides an OpenSearch interface.

OpenSearch is obviously a much simpler interface which provides an entry route to records in our traditional OPAC. An issue with OpenSearch is composing a suitable presentation of the catalogue record within the limited metadata fields provided by OpenSearch.

SRU returns more detailed records. This provides a standard interface across a range of catalogues separate from the traditional OPAC and shows detail in the catalogue records. I suspect the catalogue user appreciates this detail as it allows the representation of more complex metadata.

I can see it would be useful if OpenSearch handles SRU. The recordSchema parameter could be used to request records in the OpenSearch
format. This should also be a trivial development for most SRU implementations.

Bill

Sep 19, 2005
Dan Rehak

I did an exploration of the relationship between SQI, SRW/SRU, OpenSearch, OAI-PMH and the Google search API earlier this year in thinking about how to create a search interface for CORDRA.



See
http://cordra.org/cordra/docs/info/searchspecs/v1p00/info-searchspecs-v1p00.php


or

http://hdl.handle.net/2000.01/7BD1A39662B54C1691365ADE01366A0A




Dan

Sep 25, 2005
Rick Silterra

People from a9 can comment on this, but it seems to me that the metadata returned by an opensearch request can always be expanded by adding a new namespace, and you could get as much detail as you wanted by adding in, for instance, the
mods namespace. On the other hand, the syntax of an opensearch is also expandable, by using new keywords. But there is no search language like CQL
Rick

Oct 28, 2005
Michael Fagan

Yes, Rick, you're correct. The OpenSearch 1.1 specifications are all completely extensible via namespaces.

And no, the actual {searchTerms} parameter doesn't specify the type of searchterms (eg CQL. Perhaps a future version will.

One possibility would be to do something like
[Url type="application/atom+xml" xmlns:ns="http://example.com/ns" template="http://example.com/search?q={ns:CQL}"]
or
template="http://example.com/search?q={searchTerms?}&cql={ns:CQL?}"
so that it could work with any opensearch reader, but those that understand the namespace could use CQL.