OpenSearch is not for describing web services
OpenSearch is a collection of specifications that describe how search results can be shared between search engines and meta-search engines. A recent discussion thread on the GeoRSS mailing list brought about a debate over whether OpenSearch’s Geo extension is better than OGC’s Catalogue Service and vice verse.
OpenSearch was founded by A9 Inc., a subsidiary of Amazon.com. It’s a widely adopted specification on the Web today. Popular web search engines implement OpenSearch protocols and service descriptions. Modern browsers like IE7 and Mozilla Firefox have built-in support for OpenSearch extensions. For example, when you enter the string (e.g., “sea”) in the Firefox’s Search Engine toolbar, the toolbar will automatically display a list of possible matching keywords (e.g., “sears”, “search engines”, “sears.com” and “seattle times”). This feature is built-on the OpenSearch specification.
Some people see OpenSearch to be a direct competitor of other Web service description languages and specifications, including CSW, OWL-S and WSDL. I would agree with this thinking only if OpenSearch were designed to solve problems that others are trying to solve. In reality, this is not the case.
I see OpenSearch as a complementary technology to other web service techonlogies. The design of OpenSearch is aimed to solve the problem of sharing search results and the description of search services on the Web. One could argue that all services on the Web can be modeled as a kind of search service — finding things in CSW is a kind of search, finding where is the closest gas station is a kind of search, etc. But, in order for programs to discover and reason about these services, we need expressive service description languages.
OpenSearch is not designed for describing services so that they can be reasoned about. If someone is forced to develop service discovery programs based on OpenSearch, I suspect it will be difficult for the programs to reason about service properties because the specification offers limited vocabularies for describing what a service can do and can’t do. Furthermore, interpreting an OpenSearch service’s properties requires a great deal of offline decision-making from the developers. To automate this process within software programs, I believe RDF-based service description languages are more suited.
Good point - people do have the habit of seeing that new tool over there and trying to shove it into their particular problem.
One possible point of overlap is that while OpenSearch is for search and aggregation - it can perhaps inform or guide discussions on lightweight, common filtering and querying mechanisms for more complex catalog and discovery services.
This is especially useful for clients that then want to easily build interfaces to complex specs without necessarily having to understand and flex all the complex corners that original spec addressed.
Comment by Andrew Turner — October 17, 2007 @ 7:29 am
OpenSearch Geo could be a nice simplified replacement for WFS filters and for CSW queries. Replace OWS-L? No. Replace WSDL? I haven’t read any such suggestion, and WSDL doesn’t matter on the Web anyway.
Comment by Sean Gillies — October 17, 2007 @ 10:02 am
Yes, exactly right!
Comment by DeWitt Clinton — October 17, 2007 @ 12:19 pm