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

Tue Jun 7 08:44:26 MDT 2011

Luca,

Is there really a requirement that all XML attributes in a namespace are pre-defined?  Use of an XML namespace does not imply an XML schema.  I think this is a fuzzy area.

There is overlap here with the Information Architecture (aka Data Model Group).  In CMIP5 we have defined a set of facets that act as our identifiers (The DRS facets).  There is a good argument for controlling these in some way -- maybe an explicit XML namespace is that way.  Some facets aren't part of the dataset identifier so needn't be pre-defined.

I would prefer as structured a syntax as possible for addressing these sets of datasets  The QC use case needs to be precise about what it is referring to -- more so than the use-case of a user searching for stuff.

Note I'm trying to use one term for these things we call facets.  Let's ditch the attribute/property/component confusion.  I think facet fits.

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

From: Cinquini, Luca (3880) [mailto:Luca.Cinquini at jpl.nasa.gov]
Sent: 07 June 2011 15:31
To: Pascoe, Stephen (STFC,RAL,RALSP)
Cc: go-essp-tech at ucar.edu
Subject: Re: [Go-essp-tech] [ESGF-Search] Opensearch and XML representation of a search query

Hi Stephen,
            you are lucky, the exact query details will be under discussion on Thursday...

That said, I personally do think we should try to express our query service in term of OpenSearch. Wether or not we want to use the OS extensibility mechanism is under discussion...
The query you represent below would be a very good way to advertise the service query syntax, the only drawback is that you would need to upgrade the ESGF schema for every new facet that becomes part of the system. A more dynamic approach would be to encode all terms within the standard "q" parameter, i.e.

http://somehost/search/q="climate activity:cmip5 product:output institute:MTEST model:ECHAM experiment:amip"

versus

http://somehost/search/q=climate&activity=cmip5&product=output&institute=MTEST&model=ECHAM&experiment=AMIP

But we are spoiling all the fun for Thursday...

Luca

On Jun 7, 2011, at 8:21 AM, <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

-- 
Scanned by iCritical.

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