[Esip-discovery] open search extensions

[Lynnes, Christopher S. (GSFC-6102)]

On Jan 27, 2011, at 5:53 PM, Hua, Hook (388C) wrote:

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

However, I like the idea of making the namespace documents dereferencible descriptions of the query/response parameters.  The only question is what form to use to properly type them:  XSD? or maybe RDFS?  Or GSAC?

> 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
> 
> _______________________________________________
> Esip-discovery mailing list
> Esip-discovery at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery

--
Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185