[Requests] TML (RFPC 33) Response

Mike Botts mike.botts at nsstc.uah.edu
Wed May 3 15:26:02 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]:

Dr. Mike Botts
Principal Research Scientist
NSSTC/ESSC
University of Alabama in Huntsville
mike.botts at uah.edu

 2. Submission: OGC Request 33: OpenGISR Transducer Markup Language (TML):
Request for Public Comments  


--------

 PART B (General Discussion)
 ------ 
 1. Specification Section number: GENERAL 

 2. Criticality:  

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

First, let me say that I believe wholly in the concepts and general design
of TML and I congratulate Steve Havens and the IRIS team on bringing this
important specification forward. I feel that TML will prove to be an
important complementary specification to the SWE framework. I further
believe that the current version of the TML specification provides a
reasonable and workable model for accomplishing the goals of TML.

My comments and recommendations here deal primarily with the harmonization
of TML with other SWE components. These recommendations may not be critical
or essential to the approval of the current specification as a Version 1.0
standard, assuming we continue to work toward releasing a more harmonized
specification in future versions and build "bridges" between the current TML
specification and other SWE components. We should, however, recognize the
potential for confusion that may exist if our specifications allow different
ways to provide similar information and we should be prepared to better
answer the questions "Which spec do I use when?" and "How do I make these
specifications work together?".

The good news is that the SensorML-TML harmonization efforts that went on
between Summer 2004 and Summer 2005 and the SWE-TML harmonization efforts
that occurred at the beginning of OWS3 (March-July 2005), resulted in
significant advancements that can allow all of these specifications to work
together in a highly complementary environment. These results include:

(a) Refinement of SensorML such that it can better serve as a core framework
from which the TML Transducer and System classes can be derived (as well as
non-TML components).

(b) Development of the SWE Common data definitions that are used throughout
the SWE framework as a common means for describing data components and
specifying parameters. The SWE Common data definitions also provide an
efficient means for supporting large volumes of ascii and binary data within
observations and process descriptions, and can easily be used or adapted in
TML to support data descriptions, as well.

(c) Use of the SWE Common data definitions within the CommonObservation
(derived from om:AbstractObservationType) to provide a means for defining
and efficiently packing data blocks from a wide variety of disparate
sources, including streaming and multiplexed data like that provided through
TML.

While these developments provided a much easier path for greater uniformity
and harmonization of TML within SWE, the current TML encoding does not make
use of these common elements. The comments below describe in more detail,
recommendations for providing greater harmonization of TML with other SWE
components. These include:

(1) With tml:clusterDescr and tml:LogicalDataModel: use or derive from
swe:Encoding and swe:DataGroup i.e. swe:DataDefinition)

(2) Derive tml:Transducer from sml:ProcessModel

(3) Derive TML behavior models using SWE Common Parameters (particularly
swe:Curve)

Of these, perhaps #1 is the most immediately useful and simple. Again, it is
up to the Submission Team, TML RWG, and general membership which if any of
these should be accomplished before or after Version 1.0 of TML. 

--------

 PART B1 (tml:clusterDescr and tml:LogicalDataModel)
 ------ 
 1. Specification Section number: 6.24.5; 7.1; 7.2

 2. Criticality: MAJOR

 3. Comments/justifications for changes: 

Recommend that TML derive from or use the SWE Common data definition schemas
(swe:parameters and swe:data) for defining tml:clusterDescr and
tml:LogicalDataModel. These changes would be relatively simple with minimal
disruption of the rest of TML, but would provide significant benefits in
allowing better coordination of TML with other SWE framework components. SWE
Common parameters and data definitions are utilized throughout the SWE
framework for defining inputs, outputs, parameters, and properties in
SensorML, for defining data components and encodings in Common Observation
(the primary observation definition derived from O&M), for defining tasking
parameters in SPS, and for defining ObservationOffering in SOS.

Benefits:
(a) There would be consistency throughout the SWE Suite of components
(b) Vendor software would only need one parser for dealing with all SWE data
and parameters, including components and encodings (currently need separate
parsers for TML and Common Observation)
(c) TML data streams would be able to easily link into SensorML process
chains

 

 PART B2 (Derive tml:Transducer from sml:ProcessModel)
 ------ 
 1. Specification Section number: 

 2. Criticality: INTERMEDIATE

 3. Comments/justifications for changes: 

Recommend that TML derive transducer from sml:ProcessModel. During OWS3, we
demonstrated through an example schema how tml:transducer could be derived
from SensorML. We feel that such a derivation using the SensorML framework
would provide complementary TML-SensorML schema, and would allow
tml:transducer to be used directly within SensorML sensor descriptions and
process chains.

Benefits:
(a) There would be no need for two definitions of transducers (detectors,
actuators, etc) ... TML would provide the normative specification for
transducer using the SensorML framework 
(b) TML transducers would be easily connected and utilized within SensorML
process chains
(c) There would be no ambiguity from OGC with regard to how to describe a
sensor and the process of measurement


 PART B3 (Derive TML behavior models using SWE Common Parameters
(particularly swe:Curve)
 ------ 
 1. Specification Section number: 

 2. Criticality: INTERMEDIATE

 3. Comments/justifications for changes: 

This is related to B2 .... if B2 is accomplished then B3 would be probably
be accomplished by default. Even if B2 is not accomplished, then B3 would
assist in the use of TML within SensorML process chains. 

Recommend that TML utilize the SWE Common Parameters (Particularly
swe:Curve) for defining the TML behavior models such as calibration, etc. We
have shown that these models can be defined unambiguously using SWE Common
parameters and curves; even in lieu of B2, this would allow those models
defined in TML to be referenced and utilized within SensorML process chains;

Benefits:
(a) There would be consistency throughout the SWE components by using SWE
Common Parameters 
(b) TML models could be easily reference and used in SensorML processes
(c) Vendors would only need to have one parser for all parameter definitions

 

 

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


More information about the Requests mailing list