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/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
--
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
