NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
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
galeon archives: