NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
John,Interoperability is a sort of elusive goal in a data format, and that's actually what we're talking about here. In my estimate, the interoperabile element of CF-NetCDF is in its very standard format, rather than in the variable names that are invoked inside a given file.
Where we need to focus the semantic effort, in my mind, is in identifying candidate vocabularies, and performing mappings among them... then make these vocabularies easily discoverable so that new users can readily find them, learn the nature of their content, extend them, as an observationalist is unlikely to be able to find a "one size fits all" vocabulary and will have to customize it somewhat, and then create a straightforward method to map the new, personalized vocabulary as much as possible.
Semantic processes, like natural language, have to allow for growth... and mutation. We see new words added to the authoritative dictionaries of natural language regularly. We can hardly expect the language of observation to cooperate and simply sit still.
I think we need to have an OGC session soon... Boston? I can host it in the University Working Group... where we have a near pure discussion of what you've raised here.
Gerry John Graybeal wrote:
Well said, Gerry and everyone to date.Another question mark comes from the semantic realm. At present, netCDF/CF doesn't specify an interoperable way to specify the semantics of its parameter vocabularies, though this has been discussed. Then, its standard names have in the past been driven by the needs of the participants, principally modelers, and while the names are becoming more observational, there is a long path yet to travel. The semantic elements will represent one of those areas that will have to be aligned as this idea moves forward.It is an exciting notion, and I look forward to the OGC community's reaction to it. In that regard, I would be delicate in describing SensorML/O&M (which are XML) as "for text data" -- many binary data streams can be described just fine using the SWE XML specifications.John On May 11, 2009, at 1:33 PM, Gerald Creager wrote:Steve,In my experience, the fact has always been that OGC working groups were dominated by the folks who had a particular interest in some aspect of the topic thereof, championed it, and shepherded it along its way.Even in some of our rather broad groups, now, (SensorML/SWE), although there's broad agreement that there's benefit in ocean observations, the key focus remains based on the satellite (imagery) origins of SensorML. I view the new Meteorological working group as a healthy start, however. I can see membership in that WG from both atmosphere and ocean scientists seeking to gain interoperability. And with a cohesive base, we can help drive other changes (CRS, datum agreement, acceptable units, etc.), consistent with the needs of the Atmo/Ocean community specifically.This isn't a slight on OGC, its makeup, nor its members. It's recognition of reality, and that reality includes the fact that discipline science is becoming more vocal in the need for interoperability. Recall that essentially, the origins of OGC reside in GIS. GIS interoperability took years to actually realize, and is still mutating. AND, GIS is, in reality, 2D-based, although a lot of folk have started realizing that 2D maps don't well serve a 3D world... and things are changing.I think David captured the essence of getting things moving. Count my voice in, too. gerry Steve Hankin wrote:Hi Ben,Publicly adding my voice to the chorus of endorsements for this idea ... or at least for some serious exploration of it. Worth mentioning also the context: that David Arctur suggested this goal might be accomplished by spinning up a new working group (say, "Fluid Earth Systems"?). David's outlooked seemed radical to me in the sense that he seemed to imply there was in fact not such a coordinated OGC outlook on interoperability. The apparent outlook, he seemed to be saying, was merely a reflection of who was strongly participating in the process. I wonder if a part of the significance of creating a new OGC working group might be to recruit additional membership from within our own FES community and thereby to grow a more sizable OGC subcommunity that shares our view that a 3D space-time, continuous coordinate system framework needs to lie at the foundation of interoperability.- Steve Ben Domenico wrote:Hi,At the US IOOS (Intgrated Oceans Observing System) DMAC (Data Management and Communications Subsystem) Steering Team meetings last week, a topic with important GALEON implications came up. Please note up front that this is all very tentative at the moment and very much in the "investigation" stage. But, with the next OGC Technical Committee meeting coming up in June, we should begin considering the pros and cons and other implications.David Arctur of the OGC suggested that we submit the CF-netCDF directly as an OGC standard. As I understood his suggestion, the general idea would be that CF and netCDF would be for binary data what GML and XML is for text data. To me this was a very innovative (if not radical) suggestion and questions arise whether this would involve the file format, the API, ncML, ncML-GML, CSML and possibly other facets related to CF-netCDF. In spite of the question marks, I think this is really worth some careful thought. Since the concept was so new to me, I asked David if there were any precedents that might serve as a template for how we might proceed. In response, he sent a list (appended below without any implied endorsement) which includes specification examples for file formats and for the APIs.Fascinating idea. . -- Ben =============================================Geographic Objects (GO-1) - this is a fine-grained API pushed by a federal agency, very little uptake, but it's an API that became an OGC standard.http://www.opengeospatial.org/standards/go KML 2.2 - see what they did. http://www.opengeospatial.org/standards/kmlSimple Feature Access, Part 1: Common Architecture - this is an interface with different platform-specific encodings (COM, CORBA) and SQL access (see next two references for the most used platforms)http://www.opengeospatial.org/standards/sfa Simple Feature Access, Part 2: SQL Option http://www.opengeospatial.org/standards/sfs Simple Features for OLE/COM http://www.opengeospatial.org/standards/sfoOGC Reference Model (ORM) -- this is the roadmap for OGC standards evolution and maturation; in your proposal for CF/netCDF describe how it fits in the roadmap. http://www.opengeospatial.org/standards/orm (pdf & doc downloads from this page)Best Practices - index page (includes next two references below) http://www.opengeospatial.org/standards/bpBinary XML (BXML) Encoding Specification, OGC 03-002r9 (Craig Bruce, CubeWerx)http://portal.opengeospatial.org/files/?artifact_id=13636Specification Best Practices, OGC 06-135r1 (Carl Reed) - This document describes a variety of Best Practices and Specification development guidance that the Members have discussed and approved over the years. These Best Practices have not been captured in other formal OGC documents other than meeting notes.http://portal.opengeospatial.org/files/?artifact_id=17566------------------------------------------------------------------------_______________________________________________ galeon mailing list galeon@xxxxxxxxxxxxxxxxFor list information, to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/------------------------------------------------------------------------ _______________________________________________ galeon mailing list galeon@xxxxxxxxxxxxxxxxFor list information, to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/_______________________________________________ galeon mailing list galeon@xxxxxxxxxxxxxxxxFor 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
-- Gerry Creager -- gerry.creager@xxxxxxxx Texas Mesonet -- AATLT, Texas A&M University Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.862.3983 Office: 1700 Research Parkway Ste 160, TAMU, College Station, TX 77843
galeon archives: