[Esip-discovery] open search extensions

[Ruth Duerr]

I tried to send this out yesterday - but it bounced due to the size of the diagram (apparently 95KB is the limit).  So... no figure this time...


Ruth

I agree re semantics vs encodings.  We'd also prefer to support a wide variety of encodings and are already supporting a mix of ATOM, RSS, json, etc.  Not as uniformly as I'd like; but, it is still early days...

Where we're headed is towards the concept of facets of information upon which queries can be made.  We are headed down the following path depicted in the diagram (a work in progress) where the results of one Opensearch may lead you down several layers of other OpenSearch queries for not just data but also services.  In all cases the results of an OpenSearch should be in the form of data granule, collection (or data set), service cast, or any of a number of other feed entries...

- Ruth

On Jan 30, 2011, at 5:19 AM, jeff mcwhirter wrote:

> 
>> 
>> 
>> 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?
>> 
> 
> Before we jump into particular encodings I'd like to first nail down the semantics. While in the end *how* a concept is represented is important the more important aspect is *what* that concept is. In the GSAC work (as well as in RAMADDA) we have taken a model/view approach. We provide a number of encodings of information being presented. For example, with the capabilities the GSAC can present them as html:
> http://facility.unavco.org/gsacws/gsacapi/repository/info
> as "capabilities" xml:
> http://facility.unavco.org/gsacws/gsacapi/repository/info?output=xml
> and as an internal java object encoding. We will also be adding json encodings.
> 
> So, I'd suggest that we don't spend too much time on figuring out appropriate encodings before we figure out the underlying semantics of what we are trying to express.
> 
> For example, in our GSAC work we are not purely agnostic in the base middleware. There is an understanding about certain aspects of the underlying repository data model. For example, the browse page:
> http://facility.unavco.org/gsacws/gsacapi/list
> uses some of the capabilities but also has some hard coded knowledge about sites, etc.
> I'd like to move that to be purely capabilities driven. So, for example, some of the browse could be expressed by stating that certain string types capabilities are "browsable"
> 
> Likewise, in the GSAC world resources (i.e., files) are site centric so we include the site capabilities in the resource search form:
> http://facility.unavco.org/gsacws/gsacapi/resource/form
> I'd like to be able to express this in the capabilities as well. 
> 
> -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/20110201/e952350e/attachment.html>