[Requests] SensorML (RFPC 31) Response

Mike Botts mike.botts at nsstc.uah.edu
Fri May 5 18:49:30 EDT 2006


Part A is to be completed once per evaluator per comment submission.  Please
iterate over Part B as needed. 

 PART A 
 ------ 
 1. Evaluator: [CONTACT INFORMATION] 

Mike Botts
UAH

 2. Submission: OGC Request 31: OpenGIS® Sensor Model Language (SensorML):
Request for Public Comments  


 PART B 
 ------ 
 1. Specification Section number: [GENERAL] 

 2. Criticality: [Repsonse to Peter Schut' comments] 

 3. Comments/justifications for changes: [COMMENTS, SUGGESTIONS] 

Peter.

Very good comments. Thanks. 

---- response to comment 1 ----

UAH has also been aware of the complementary nature of SensorML and WPS and
had hoped to make comments to the WPS earlier (unfortunately the 30 day
period passed before we were able to). We agree that there is an opportunity
to enable this harmony between SensorML and WPS, and have included this task
in our proposal to OWS4. We are also very excited about the potential for
these two specifications working in harmony. 

We should certainly work more on this, but from our point of view, we see a
simple path for obtaining complementary functionality through two steps:

(a) The wps:describeProcess method of WPS could return a sml:ProcessModel
description instance as its response. A sml:ProcessModel instance can fully
describe a process by providing metadata, a link to a full description of
the algorithm (in MathML if desired), and of course the expected inputs,
outputs, and parameters as you mentioned. The inputs, outputs, and
parameters utilize the SWE Common data model, which provides consistancy
throughout the SWE framework (but we have found that they can equally be
utilized effectively within others specs of OGC, including WCS and GML).

In fact, in some recent work with Northrop Grumman, they have chosen to
utilize SensorML ProcessModel as a means of doing exactly this. They are
looking at having their services return a ProcessModel template, in which
the parameters and inputs can be filled in and returned. The results are
then filled in as the output using the SWE Common data blocks that you
mentioned. The interesting advantage to this idea is that the user then has
a complete record of the information and methodology that went into
providing the result.

(b) By responding to the wps:describeResult in sml:ProcessModel, this also
makes it very easy for us to link to WPS processes as part of a SensorML
process chain (note: this could work anyway, but someone else would be
responsible for wrapping the service in SensorML rather than the service
provider). This provides some very interesting possibilities for processing
that can combine both distributed as well as on-board processing within
chains.

I believe that implementing these steps doesn't require any major changes to
either specification other than perhaps allowing (or requiring) a WPS to
return sml:ProcessModel as its response.

---- response to comment 2 ----

we need to look at BPEL some more, but on our first look, we see that there
is a Web Services profile for BPEL, but haven't found any other profiles;
perhaps it makes since to look at a SensorML profile for BPEL in OWS4;
currently we use a very simple protocol for indicating connections between
process models within a chain; we feel that this is not incompatible with
BPEL, but should examine this more as a mod or extension in the next version
of SensorML

--- response to comment 3 ----

We also feel that the SWE Common data model provides an efficient means of
packing large amounts of data (ascii, binary, or simple MIME) into XML. This
was of course critical for us to deal with the large amounts of data
provided by sensor systems. From the first time I stepped into an OGC TC
(Atlanta), I've proposed such data blocks for GML. In the previous version,
GML did introduce a somewhat similar concept of a tuple data block, but it
is only related to data associated with a CRS (e.g. spatial location data).
In SWE, we generalized the concept more and added the ability to support
various ascii and binary encodings (with robust description). We feel that
the SWE Common data block is not inconsistent with GML and have experimented
with utilizing the SWE Common data model for more robustly providing
properties within valid GML documents. In summary, I agree with your
analysis that there are potentially significant benefits in the future for
some harmonization of GML and SWE Common data model.

--- response to comment 4 ---

The core SensorML specification is nothing more than a framework with which
one can robustly define any process model and process chain. We consider
transducers (detectors, actuators, etc) to be processes that convert a
phenomenon into some digital value. 

Based on over a year of intense harmonization efforts between SensorML and
TML, we have refined SensorML models and schema to be able to serve as a
framework from which TML could derive its transducer profile. The SWE Common
data model likewise is used throughout SensorML and SWE and is capable of
supporting the TML response models. We have in OWS3 demonstrated through
examples that SensorML and SWE Common are capable of serving as a framework
for deriving TML models as well as other process models. In the absence of
specific details of why the current SensorML schema does not suffice to meet
the framework needs of TML, we do not see any reason to hold up SensorML
approval based incomplete harmonization with TML.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mail.opengeospatial.org/mailman/private/requests/attachments/20060505/a2bc8546/attachment.html


More information about the Requests mailing list