[Esip-discovery] open search extensions

[Hua, Hook (388C)]

Hi Jeff,

Going back to Chris' rant ("challenge to the community") back in 2008, the original idea was to create simpler services such that more people would actually use it.

I see adhering to the "official" OpenSearch and ESIP Federated OpenSearch specifications is a good way to foster interoperability. Though we know that this may require sacrificing the full potential that these services could provide.

Having said that, in our implementation of OpenSearch here at JPL, we did encounter similar conclusions that you had mentioned. We found the OpenSearch interfaces not expressive enough for more advanced Earth science data queries. So we ended up implementing (1) a formal OpenSearch service adhering to the ESIP Federated OpenSearch 1.0 spec, and (2) informal space-time search services that also include more advanced features such as boolean logic queries, field value constraints, and results sorting.

So the good thing about moving forward together as a community is that we can propose changes to the specifications.

--Hook


________________________________
From: jeff mcwhirter <jeffmc at unavco.org>
Date: Thu, 27 Jan 2011 07:22:40 -0800
To: "Lynnes, Christopher S. (GSFC-6102)" <christopher.s.lynnes at nasa.gov>
Cc: <esip-discovery at lists.esipfed.org>
Subject: Re: [Esip-discovery] open search extensions



Hi Chris,

>     I think on the one hand, some of us don't want to give up the simplicity of the OpenSearch framework, or its basis on a widely used de facto standard.  But on the
Agreed as to simplicity however, if we look at the kind of search
interfaces that are actually in use in the geoinformatics community they
are rarely simple. They aren't complicated by design (well sometimes
:-)) but rather the domain and the end user's needs are complex.
OpenSearch is simple because the domain where it arose from (search
engines, commerce) tends to have simple search needs - mostly text. In
geoinformatics we have complex geospatial, temporal, and metadata
information that should be exposed.
> other hand, for extending our OpenSearch framework, the ability to type additional attributes could be helpful.  Is it possible to fold your ideas into the OpenSearch framework?  For instance, we might establish a convention that the namespace documents that we reference for extended query or response attributes be dereferencible documents in a specific format, with the typing information included therein.
Yes, there could be an extension which is a typed capabilities extension.

I'd suggest before we jump into this lets use the GSAC as a testbed for
these ideas. As I mentioned we have 4 implementations of the API using
capabilities and soon will have a 5th. Perhaps some folks in the
community would like to work with us on this to see how these ideas fit
into their repositories?

Also, we have built a generic repository interface (the GSL) that with
some refactoring we could make even more generic and pull out the
capabilities piece as a stand-alone and resuable library so others could
make use of it.  Likewise, one thing I've thought of doing is a
javascript package that knows how to read and process a capabilities (or
an opensearch capabilities extension) and generate a search interface
directly in the browser.

-Jeff

_______________________________________________
Esip-discovery mailing list
Esip-discovery at lists.esipfed.org
http://www.lists.esipfed.org/mailman/listinfo/esip-discovery

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-discovery/attachments/20110127/4022256d/attachment.html>