Re: [galeon] plan for establishing CF-netCDF as an OGC standard

NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.

  • To: "John Graybeal" <graybeal@xxxxxxxxx>
  • Subject: Re: [galeon] plan for establishing CF-netCDF as an OGC standard
  • From: "Ron Lake" <rlake@xxxxxxxxxxxxx>
  • Date: Wed, 15 Jul 2009 15:53:42 -0700
Hi John:


See comments below.


Ron

 

From: John Graybeal [mailto:graybeal@xxxxxxxxx] 
Sent: July 15, 2009 3:29 PM
To: Ron Lake
Cc: Steve Hankin; Ben Domenico; Unidata Techies; Unidata GALEON; Mohan
Ramamurthy; Meg McClellan
Subject: Re: [galeon] plan for establishing CF-netCDF as an OGC standard

 

Ron, I am unfamiliar with GML, and I am not sure I understand what you
are saying.  I think of the encoding for _transport_ as a very different
thing than an encoding for files. If I am not mistaken, the netCDF API
provides an encoding for transport also. No?

 

OK - perhaps I misspoke - I am not that familiar with NetCDF API - often
an API defines just Request/Response and uses something else for the
transport - that is the case for GML/WFS or GML/WCS.  I have just often
observed in OGC a conflict between encodings and API's when we should
focus on the two together.  Sometimes the API folks want to enable many
transport encodings and the encoding people want to support many
request/response API's etc.

 

Which brings me to Steve's email, with which I agree in broad terms. One
thing that CF has that is not explicit/required in the netCDF API
definition is at least the possibility of providing one standard name
for each variable. (More would be better, but one step at a time....)  I
am sure this information makes it across the API when it is provided,
but to be honest, in this day and age spending a lot of time
standardizing the API, while remaining quiet about the semantics of the
transported information, does not seem cost-effective.  I think there
might be some easy strategies for bridging that gap (mostly by insisting
on CF-compliant data on the far side of the interface).

 

John

 

On Jul 15, 2009, at 12:30 PM, Ron Lake wrote:





Hi,

 

I think one needs to standardize BOTH - an access API and an encoding,
AND to do this in a way that they work with one another.  It is for this
reason (as an example) that GML exposes the source data model (as well
as acting as the data encoding for transport) so that WFS can define
requests in a neutral manner.  It should NOT be a matter of ONE or the
OTHER.  You might also look at the work of the XQuery Data Model group.


R

 

From: galeon-bounces@xxxxxxxxxxxxxxxx
[mailto:galeon-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Steve Hankin
Sent: July 15, 2009 12:18 PM
To: Ben Domenico
Cc: Unidata Techies; Unidata GALEON; Mohan Ramamurthy; Meg McClellan
Subject: Re: [galeon] plan for establishing CF-netCDF as an OGC standard

 

Hi Ben,

Firstly -- applause, applause!  This is an important step.  Thanks so
much for leading it.

If it is not too late, however, I'd like to open a discussion on a
rather significant change in the approach.  As outlined at the URL you
provided the approach focuses on "CF-netCDF as an OGC binary encoding
standard".  Wouldn't out outcomes be more powerful and visionary if
instead we focussed on the netCDF API as an OGC standard?  Already today
we see great volumes of GRIB-formatted data that are served as-if NetCDF
through OPeNDAP -- an illustration of how the API as a remote service
becomes a bridge for interoperability.  The vital functionalities of
aggregation, and augmentation via NcML are about exposing *virtual*
files -- again, exposing the API, rather than the binary encoding. 

It is the ability to access remote subsets of a large netCDF virtual
dataset, where we see the greatest power of netCDF as a web service.
While this can be implemented as a "fileout" service (the binary
encoding standard approach) -- and that has been done successfully in
WCS and elsewhere -- it does not seem like the optimal strategy.   It is
the direct connection between data and applications (or intermediate
services) -- i.e. the disappearance of the "physical" (binary) file --
which seems like the service-oriented vision.  This would not eliminate
the ability of the standard to deliver binary netCDF files in the many
cases where that is the desired result.  Simple REST fileout services
are desirable and should perhaps be included as well in this standards
package.   

David Artur (OGC representative) indicated at the meeting where we met
with him in May that there were other examples of standardizing APIs
within OGC.  He also mentioned that with a community-proven
interoperability standard the OGC process can be relatively forgiving
and streamlined (fingers crossed ... lets hope).  As I understand it,
the most recent documents from GALEON allow for an OPeNDAP URL as the
payload of WCS.  So the concept of the API standard -- the reference to
the file, rather than the binary file itself -- has already made its way
into the GALEON work, too.    I imagine there have already been
discussions about this point.  Very interested to hear yours and other's
thoughts.

    - Steve

==========================

Ben Domenico wrote: 

Hello, 

 

At the galeon team wiki site:

 

http://sites.google.com/site/galeonteam/Home/plan-for-cf-netcdf-encoding
-standard

 

I put together a rough draft outline of a plan for establishing
CF-netCDF as an OGC binary encoding standard.  Please note that this is
a strawman.  Comments, suggestions, complaints, etc. are very welcome
and very much encouraged.  It would be good to have the plan and a draft
candidate standard for the core in pretty solid shape by early September
-- 3 weeks before the next OGC TC meeting which starts on September 28.

 

One issue that requires airing early on is the copyright for any
resulting OGC specification documents.  Carl Reed, the OGC TC chair
indicates that the wording normally used in such documents is:

 

        Copyright (c) 2009, <name(s) of organizations here>
        The companies listed above have granted the Open Geospatial
Consortium, Inc. (OGC) a nonexclusive, royalty-free, paid up, worldwide
license to copy and distribute this document and to modify this document
and distribute copies of the modified version.

I'm sending a copy of this to our UCAR legal counsel to make sure we are
not turning over ownership and control of the CF-netCDF itself..

-- Ben

 
 


________________________________



 
 
 
_______________________________________________
galeon mailing list
galeon@xxxxxxxxxxxxxxxx
For list information, to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/ 

_______________________________________________
galeon mailing list
galeon@xxxxxxxxxxxxxxxx
For list information, to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/ 

 


John

 

--------------

John Graybeal   <mailto:graybeal@xxxxxxxxx>  -- 831-775-1956 
Monterey Bay Aquarium Research Institute
Marine Metadata Interoperability Project: http://marinemetadata.org   

 

  • 2009 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the galeon archives: