[Go-essp-tech] [ESGF-Search] Opensearch and XML representation of a search query

Wed Jun 8 07:23:55 MDT 2011

Agreed, Mark. :-)

---
Stephen Pascoe  +44 (0)1235 445980
Centre of Environmental Data Archival
STFC Rutherford Appleton Laboratory, Harwell Oxford, Didcot OX11 0QX, UK

From: Mark Morgan [mailto:momipsl at ipsl.jussieu.fr]
Sent: 08 June 2011 14:07
To: Pascoe, Stephen (STFC,RAL,RALSP)
Cc: Luca.Cinquini at jpl.nasa.gov; chris.a.mattmann at jpl.nasa.gov; go-essp-tech at ucar.edu
Subject: Re: [Go-essp-tech] [ESGF-Search] Opensearch and XML representation of a search query

Hi

Stephen said : "... we end up swimming against the tide ..."

I would underline the importance of not impeding the development process in its early phases.  This is not to denigrate standards such as OpenSearch but simply to underline that from an agile perspective the first few iterations in the SDLC must be upon building momentum ASAP.  This entails placing a premium upon the YAGNI principle (http://en.wikipedia.org/wiki/You_ain't_gonna_need_it).    For me supporting OpenSearch is perhaps an iteration 3/4 task whereby the request/reponse parser/generator are retrofitted with appropriate OpenSearch adaptors.

Having said this if the group decide to support OpenSearch from day one then fair enough.

Mark

On 8 Jun 2011, at 12:53, <stephen.pascoe at stfc.ac.uk<mailto:stephen.pascoe at stfc.ac.uk>> wrote:

Is there more detail on what it means to "federate search with ESIP"?  Is there infrastructure behind the pattern described on the ESIP wiki?

I'm asking because I'm slightly cautions about tying ourselves to an infrastructure that may not meet our needs.  For instance the wiki page suggests ESIP OpenSearch engines will support a single query string plus optional time constraints.  If this is a hard requirement it means we can't use arbitrary OpenSearch extensions.  The time extension that is supported may not meet our needs: I bet it doesn't do 360 day calendars!  Multiple time dimensions anyone?

I've been here before in the context of OGC standards.  We end up swimming against the tide in trying to fit our requirements into what the rest of the community want.  Of course there are many great advantages to sharing standards like this.  I just advocate caution.

Thanks,
Stephen.

---
Stephen Pascoe  +44 (0)1235 445980
Centre of Environmental Data Archival
STFC Rutherford Appleton Laboratory, Harwell Oxford, Didcot OX11 0QX, UK

-----Original Message-----
From: Cinquini, Luca (3880) [mailto:Luca.Cinquini at jpl.nasa.gov]
Sent: 08 June 2011 11:37
To: Mattmann, Chris A (388J)
Cc: Pascoe, Stephen (STFC,RAL,RALSP); go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>
Subject: Re: [Go-essp-tech] [ESGF-Search] Opensearch and XML representation of a search query

Thanks Chris, indeed one of our goals is to federate the ESG search with ESIP...
Luca

On Jun 7, 2011, at 11:18 PM, Mattmann, Chris A (388J) wrote:

Guys you may want to check out the work in ESIP going on with the Federated Search folks:

http://wiki.esipfed.org/index.php/How-To_Guide_for_Implementing_ESIP_Federated_Search_Servers

Just passing it along.

Thanks!

Cheers,
Chris

On Jun 7, 2011, at 7:21 AM, <stephen.pascoe at stfc.ac.uk<mailto:stephen.pascoe at stfc.ac.uk>> <stephen.pascoe at stfc.ac.uk<mailto:stephen.pascoe at stfc.ac.uk>> wrote:

In off-list discussions about QC we've found we need to attach QC documents to data at the simulation level.  This would seem to be semantically similar to selecting all datasets for a given activity/product/institute/model/experiment which could be viewed as a query.

Unfortunately I wasn't on the Search API call yesterday but I hear OpenSearch has been floated as an implementation-neutral interface.  What about using OpenSearch's XML Query syntax for representing this?  E.g.

<Query xmlns="http://a9.com/-/spec/openseaerch/1.1/"
    xmlns:esgf="http://esgf.org/ns/search/"
    role="request"
     esgf:activity="cmip5"
    esgf:product="output"
    esgf:institute="MTEST"
    esgf:model="ECHAM6-MPIOM-TR"
    esgf:experiment="amip"/>

Cheers,
Stephen.

---
Stephen Pascoe  +44 (0)1235 445980
Centre of Environmental Data Archival
STFC Rutherford Appleton Laboratory, Harwell Oxford, Didcot OX11 0QX, UK

--
Scanned by iCritical.

_______________________________________________
GO-ESSP-TECH mailing list
GO-ESSP-TECH at ucar.edu<mailto:GO-ESSP-TECH at ucar.edu>
http://mailman.ucar.edu/mailman/listinfo/go-essp-tech

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann at nasa.gov<mailto:chris.a.mattmann at nasa.gov>
WWW:   http://sunset.usc.edu/~mattmann/
Phone: +1 (818) 354-8810
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

_______________________________________________
GO-ESSP-TECH mailing list
GO-ESSP-TECH at ucar.edu<mailto:GO-ESSP-TECH at ucar.edu>
http://mailman.ucar.edu/mailman/listinfo/go-essp-tech

--
Scanned by iCritical.
_______________________________________________
GO-ESSP-TECH mailing list
GO-ESSP-TECH at ucar.edu<mailto:GO-ESSP-TECH at ucar.edu>
http://mailman.ucar.edu/mailman/listinfo/go-essp-tech

---------------------------------------------------
Mark Morgan
Software Architect / Engineer
Institut Pierre Simon Laplace (IPSL),
Université Pierre Marie Curie,
4 Place Jussieu,
Tour 45-55, Salle #207,
Paris 75005
France.
Tel : +33 (0) 1 44 27 49 10
Email: momipsl at ipsl.jussieu.fr<mailto:momipsl at ipsl.jussieu.fr>
---------------------------------------------------

-- 
Scanned by iCritical.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20110608/b92b2f4a/attachment-0001.html 