[Esip-discovery] open search extensions

[jeff mcwhirter]

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




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