[Requests] SensorML (RFPC 31) Response
JGreenwood at seicorp.com
Sat May 6 08:59:45 EDT 2006
Concur. With the caveat that Mike Botts' comments (to the TML document) may help the harmonization efforts.
James F. Greenwood
C4ISR Sys Pgm Mgr
Centreville, VA 20120
From: requests-bounces+jgreenwood=seicorp.com at opengeospatial.org [mailto:requests-bounces+jgreenwood=seicorp.com at opengeospatial.org] On Behalf Of Mike Botts
Sent: Friday, May 05, 2006 6:50 PM
To: requests at opengeospatial.org
Subject: [Requests] SensorML (RFPC 31) Response
Part A is to be completed once per evaluator per comment submission. Please iterate over Part B as needed.
1. Evaluator: [CONTACT INFORMATION]
2. Submission: OGC Request 31: OpenGISÂ® Sensor Model Language (SensorML): Request for Public Comments
1. Specification Section number: [GENERAL]
2. Criticality: [Repsonse to Peter Schut' comments]
3. Comments/justifications for changes: [COMMENTS, SUGGESTIONS]
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...
More information about the Requests