[Esip-discovery] open search extensions

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

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

On Jan 25, 2011, at 12:04 AM, jeff mcwhirter wrote:

> 
> Hi all,
> I'd like to open up a discussion of the Open Search efforts within 
> ESDSWG/ESIP. I am fairly new to this community so please forgive me if 
> some of these issues and ideas have been discussed already.
> 
> At UNAVCO we have a NASA ROSES grant (GSAC) where we are working on 
> defining a common web service and html API for querying geodesy data 
> repositories.  We currently have 3 implementations of these GSAC 
> repositories running at UNAVCO, Scripp's SOPAC and (soon) NASA's CDDIS 
> sites. We also have a 4th implementation of a federated repository that 
> can search across multiple external repositories and will soon have a 
> 5th implementation in a  stand-alone repository for 3rd party sites. 
> Here is UNAVCO's implementation:
> http://facility.unavco.org/gsacws/gsacapi/site/form
> 
> As part of this work we have developed a facility for repositories to 
> describe their query capabilities. This is similar to the Open Search 
> initiative but it is a more flexible and richer mechanism. You can see 
> the auto-generated API documentation here:
> http://facility.unavco.org/gsacws/gsacapi/repository/info
> and a write up on this here:
> http://facility.unavco.org/data/gsacws/development/capabilities.html
> 
> It should be noted that the above site form as well as the resource 
> query forms:
> http://facility.unavco.org/gsacws/gsacapi/resource/form
> are completely generated via reading the declarative specification of 
> the capabilities of the underlying repository.
> 
> The basic idea is that a data repository describes a query end point URL 
> and a set of possible URL arguments. The key differentiation between 
> this approach and Open Search is the introduction of a type mechanism. 
> As described in the above documentation each search parameter has a type 
> associated with it. Based on the type a front-end can assemble the 
> appropriate search interface. So, for example, our site searches have 
> parameters such as  site code (string), name (string), type 
> (enumeration), bounds (spatial bounds), etc.
> 
> As we describe in the write up, while Open Search has the ability to 
> have extensions these are still essentially hard-coded and front ends 
> need to have explicit knowledge of those extensions to produce search 
> interfaces. With the capabilities/type approach the only "hard-coding" 
> required of a front end is for the front end to understand the type 
> system. This provides much greater flexibility in defining what can be 
> searched for. For example, in our resource (i.e., file) search interface 
> there are actually 2 different dates that can be searched for - the data 
> date and the archive publish date.
> 
> What this has enabled us to do is to develop a generic layer called the 
> GSAC Service Layer (GSL). The GSL (a Java servlet) reads a set of 
> capabilities from an underyling repository implementation and generates 
> the appropriate interfaces. Likewise, in our implementation of a 
> federated search repository the system reads the capabilities from a set 
> of external repositories and merges those capabilities together.
> 
> While the goal of having open search interfaces is important the 
> text-search oriented focus of the Open Search spec is perhaps too 
> limited for the complexities inherent within geoscience data systems.
> 
> While our major focus has been on development we'd like to see if some 
> of these ideas can gain traction in the broader ESIP/ESDWSG communities 
> and would welcome discussion and feedback.
> 
> Thanks,
> -Jeff
> 
> _______________________________________________
> Esip-discovery mailing list
> Esip-discovery at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery

Christopher Lynnes     
Goddard Earth Sciences Data and Information Center, NASA/GSFC
301-614-5185