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’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.

5 thoughts on “Browser integration of search”

  1. 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)]

  2. 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.

  3. 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

  4. 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=”” template=”{ns:CQL}”]

    so that it could work with any opensearch reader, but those that understand the namespace could use CQL.

Comments are closed.