Hi Ben and GALEON,
I would vote for the OGC GALEON Network option, for the following motivations:
1) In my opinion, GALEON phase 1 was a success because, among the other results, it
established a Community of people who have been working on OGC OWS for accessing and
dispatching Fluid Earth Sciences (FES) datasets. Actually, we have already started a
"network" and it would be a pity not to continue it.
2) The established Community is composed of both OGC and non-OGC members. Naturally, the most active ones are OGC members, but the contributions coming from the others are extremely valuable, as well.
3) From my perspective, this Community needs a permanent testing framework where to experiment interoperability solutions and analyze OWS opportunities for FES applications.
4) The interaction with the GSN would be much easier and direct.
For the GML role in GALEON, we do think that GML would play a relevant role in
order to facilitate FES and GIS interoperability. That mainly stems from our
conviction that XML-based languages provide the right semistructured approach
to model, formalize and exchange geospatial data and knowledge in a Web
Services framework. Indeed, the ncML-GML is a mediation markup language between
ncML and GML. It was successfully tested in the GEALEON Phase 1. As Ben
mentioned, we want to continue its enhancement and testing in the GALEON Phase
2. Moreover, working on a common Reference Framework for these technologies
would be important for our Community. This could be the framework where to
develop and coordinate the ncML-GML and CSML efforts, which seem to be
complementary.
---Stefano
Ron,
A key conclusion of GALEON Phase 1 is that GML is irrelevant and
should be abandoned as soon as possible..... JUST KIDDING, JUST KIDDING!!!
Seriously though -- and others should chime in with additions or
modifications to the following comments which reflect my views on
the three main areas where GALEON is now and will be (in Phase 2)
involved with GML.
The earliest development in this area and perhaps furthest along is
the ncML-GML work being spearheaded at the University of Florence
CNR/IMAA. It is based on the earlier development of the ncML
(netCDF Markup Language). My personal way of characterizing
ncML-GML is that it combines the disciplinary semantics (what do the
numbers in the dataset represent?) of ncML with the spatio-temporal
(the where and when of the numbers in the dataset) semantics in GML.
A complementary approach being developed by the UK BADC/NERC group
is the (Climate Science Modelling Language). Here again I'll offer
my oversimplified characterization of the main difference between
CSML and ncML-GML, namely, that the the disciplinary semantics and
spatio-temporal semantics are more tightly coupled in CSML whereas
they are loosely coupled in ncML-GML.
The two initiatives above have been underway for some time now, but
are not at a point where we could submit them as finished products
of GALEON Phase 1. The development and coordination of the two
efforts will be one of the most important facets of GALEON Phase
2. While it's a bit out of date, I put together a brief description
of various means (both implicit and explicit) of representing netCDF
semantics (including ncML-GML and CSML) along with a very simple set
of examples at:
<http://www.unidata.ucar.edu/projects/THREDDS/GALEON/NetCDFandStandards.htm>http://www.unidata.ucar.edu/projects/THREDDS/GALEON/NetCDFandStandards.htm
for what it's worth.
A third key area for GALEON related to GML is in the very initial
stages. This involves determining the relationships (if any) among
various types of GALEON netCDF datasets (especially the sort of 5D
datasets output from numerical weather and climate forecast models),
ncML-GML, CSML, and GMLJ2 (GML JPEG2000). We had a few preliminary
discussions at the Bonn TC meeting on this GALEON/GMLJP2 topic and
my opinion is that we learned enough to become convinced that the
topic area needs much more study. Unfortunately I don't think all
the knowledgable players will be at the Huntsville meetings, but we
will target this as a goal for GALEON Phase 2.
I hope others will correct anything I've misrepresented or add some
of the important aspects I may have left out.
-- Ben
From gerry.creager@xxxxxxxx Sun 26 Feb 10:36:23 2006 -0600
Received: from smtp-relay.tamu.edu (smtp-relay.tamu.edu [165.91.22.120])
by unidata.ucar.edu (UCAR/Unidata) with ESMTP id k1QGadO7012668;
Sun, 26 Feb 2006 09:36:39 -0700 (MST)
Organization: UCAR/Unidata
Keywords: 200602261636.k1QGadO7012668
Received: from [192.168.1.60] (n5jxs.dsl.tamu.edu [165.91.8.82])
(authenticated bits=0)
by smtp-relay.tamu.edu (8.13.4/8.13.3) with ESMTP id k1QGagsO023158
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sun, 26 Feb 2006 10:36:44 -0600 (CST)
(envelope-from gerry.creager@xxxxxxxx)
Message-ID: <4401D907.9050909@xxxxxxxx>
Date: Sun, 26 Feb 2006 10:36:23 -0600
From: Gerry Creager N5JXS <gerry.creager@xxxxxxxx>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ben@xxxxxxxxxxxxxxxx
CC: Ron Lake <rlake@xxxxxxxxxxxxx>,
GALEON email list <galeon@xxxxxxxxxxxxxxxx>
Subject: Re: Thoughts on GALEON Phase 2
References: <4E1D53230994FD45A119B5090DFBF4605BD1CE@andalusia.Galdos.local>
<f90afa860602241906i4d99e50cg4407f7b3160ea550@xxxxxxxxxxxxxx>
In-Reply-To: <f90afa860602241906i4d99e50cg4407f7b3160ea550@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (smtp-relay.tamu.edu: 165.91.8.82 is authenticated by a
trusted mechanism)
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on
laraine.unidata.ucar.edu
X-Spam-Level:
X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL
autolearn=no version=3.0.1
Sender: owner-galeon@xxxxxxxxxxxxxxxx
Precedence: bulk
I'd like to offer the thought that we need to consider SensorML, as well as
GML, or potentially ESML, to allow description of datasets and sensors involved
in this work.
Gerry
Ben Domenico wrote:
Ron,
A key conclusion of GALEON Phase 1 is that GML is irrelevant and should
be abandoned as soon as possible..... JUST KIDDING, JUST KIDDING!!!
Seriously though -- and others should chime in with additions or
modifications to the following comments which reflect my views on the
three main areas where GALEON is now and will be (in Phase 2) involved
with GML.
The earliest development in this area and perhaps furthest along is the
ncML-GML work being spearheaded at the University of Florence CNR/IMAA.
It is based on the earlier development of the ncML (netCDF Markup
Language). My personal way of characterizing ncML-GML is that it
combines the disciplinary semantics (what do the numbers in the dataset
represent?) of ncML with the spatio-temporal (the where and when of the
numbers in the dataset) semantics in GML.
A complementary approach being developed by the UK BADC/NERC group is
the (Climate Science Modelling Language). Here again I'll offer my
oversimplified characterization of the main difference between CSML and
ncML-GML, namely, that the the disciplinary semantics and
spatio-temporal semantics are more tightly coupled in CSML whereas they
are loosely coupled in ncML-GML.
The two initiatives above have been underway for some time now, but are
not at a point where we could submit them as finished products of GALEON
Phase 1. The development and coordination of the two efforts will be
one of the most important facets of GALEON Phase 2. While it's a bit
out of date, I put together a brief description of various means (both
implicit and explicit) of representing netCDF semantics (including
ncML-GML and CSML) along with a very simple set of examples at:
http://www.unidata.ucar.edu/projects/THREDDS/GALEON/NetCDFandStandards.htm
for what it's worth.
A third key area for GALEON related to GML is in the very initial
stages. This involves determining the relationships (if any) among
various types of GALEON netCDF datasets (especially the sort of 5D
datasets output from numerical weather and climate forecast models),
ncML-GML, CSML, and GMLJ2 (GML JPEG2000). We had a few preliminary
discussions at the Bonn TC meeting on this GALEON/GMLJP2 topic and my
opinion is that we learned enough to become convinced that the topic
area needs much more study. Unfortunately I don't think all the
knowledgable players will be at the Huntsville meetings, but we will
target this as a goal for GALEON Phase 2.
I hope others will correct anything I've misrepresented or add some of
the important aspects I may have left out.
-- Ben