[Requests] SensorML (RFPC 31) Response

Schut, Peter SCHUTP at AGR.GC.CA
Mon Apr 10 12:02:05 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] 

Peter Schut,  schutp at agr.gc.ca

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

I have been observing the development of the sensor suite of specifications for some time, and am pleased with how much progress has been made in recent months.  I would like to offer my congratulations to Mike Botts for his leadership in this area.  

 

My observations on SensorML are based on examination of the written specification, and do not reflect any implementation experience.  Comments are as follows:

 

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

 2. Criticality:  STRATEGIC

 3. Comments/justifications for changes: 

There is a startling amount of similarity between portions of SensorML and WPS, even to the point that some identical XML elements such as "Input" and "Output" are found in both schemas.  This is not surprising, since a modeling language for sensor processes should have a lot of similarities with WPS, given that WPS provides a generic mechanism to invoke any kind of process.  Given this similarity, it may be sensible to restructure SensorML as an application schema of WPS.  This approach would help to align SensorML with the other OGC specifications that are expected to build on WPS.  On the other hand, since SensorML is reasonably mature, it might be logical to maintain SensorML as a separate specification, but attempt to bring WPS and SensorML into closer alignment with each other by extracting common components into OWS Common.  The former approach may prove easier to maintain in the long run.

 

 ------ 
 1. Specification Section number: GENERAL 

 2. Criticality:  STRATEGIC

 3. Comments/justifications for changes: 

SensorML includes an explicit service chaining language, which does not conform to the more widely used BPEL approach, but which seems to offer some much desired simplicity.  The costs and benefits of maintaining a separate language to define run-time chaining of services should be assessed by the authors of SensorML.  BPEL seems to be gaining industry endorsement, albeit somewhat slowly, so it may not be worth the effort to maintain a separate approach as currently defined in SensorML unless it brings significant benefits.  Note that WPS can be used to define static service chains, without the use of either BPEL or the SensorML approach.

 

 ------ 
 1. Specification Section number: GENERAL 

 2. Criticality:  STRATEGIC

 3. Comments/justifications for changes: 

SensorML's Data element is interesting in that it allows for extremely efficient encoding of attribute information.  The Geolinked Data Attribute Service (a discussion paper at OGC) uses a somewhat similar light-weight encoding approach, which also relies on a limited amount of XML overhead to retain correspondence between attributes and their definition.  Note that in both cases, this encoding could have been achieved by extending or profiling GML, but GML in and of itself would not bring any added value for these encoding.  For this reason, it is worth considering whether OGC should develop a more generic specification that combines the data encoding approaches of both SensorML and GDAS, perhaps as a part of OWS Common; or if GML should be extended and then profiled to meet these data encoding needs.  Since GML is already such a complicated specification, it is probably easier to maintain GML as a "geography markup language" and create a "georeferenced attribute markup language" which focuses specifically on attributes that are georeferenced.  One way or another, there will be benefits to bringing the attribute encoding portions of GDAS and SensorML together, since they both have some strengths.

 

 ------ 
 1. Specification Section number: GENERAL 

 2. Criticality:  MAJOR

 3. Comments/justifications for changes: 

Blending of TransducerML and SensorML should be completed, as is suggested on page 58 of the draft specification.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mail.opengeospatial.org/mailman/private/requests/attachments/20060410/e519f1aa/attachment.htm


More information about the Requests mailing list