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/kml
Simple 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/sfo
OGC 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/bp
Binary XML (BXML) Encoding Specification, OGC 03-002r9 (Craig
Bruce, CubeWerx)
http://portal.opengeospatial.org/files/?artifact_id=13636
Specification 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@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/
_______________________________________________
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