S e n s o r M o d e l
L a n g u a g e O G C
0 7 - 0 0 0
8.6.3.3 CompoundPhenomenon, CompositePhenomenon, PhenomenonSeries
A CompoundPhenomenon has several components, whose count is indicated by the dimension. CompoundPhenomenon is an abstract class. Two concrete specializations are
provided.
A CompositePhenomenon is composed of a set of component phenomena. The components may not be related to each other, though useful compound phenomena would
usually have some semantic coherence. The optional base phenomenon allows for the CompositePhenomenon to be generated by adding components to a base.
A PhenomenonSeries applies one or more constraintLists to the base phenomenon, each providing a set of values for a single secondary axis.
Example: A “radiance spectrum” may be based on “radiance” with a list of “wavelength” intervals specified.
The “base” association indicates a conceptual relationship, which may be useful in classification of observation types. The value of a specialised phenomenon must be
described using a scale units of measure, vocabulary that could also be used for the base.
Example: an application may choose to include observations of “WaterTemperature” when the subject of interest is observations of “Temperature”.
8.7 ObservableProperty
An ObservableProperty is a property of a phenomenon that can be observed and measured e.g. temperature, gravitational force, chemical concentration, orientation,
number-of-individuals, or a characteristic of one or more feature types, the value for which must be estimated by application of some procedure in an observation.
Example: The ObservableProperty element allows one to reference a measurable property of a phenomenon for sensor inputs or actuator outputs, for example.
In ObservableProperty the phenomenon property can only be defined by reference using the definition attribute. The definition attribute value should reference a property defined
within a Phenomenon dictionary or within an ontology. An ObservableProperty can also include a name and a description.
Note: Unlike the simple data types, an ObservableProperty does NOT include properties such as uom or constraints, since these are typically characteristics of the measuring procedure and not properties of the
observable phenomenon itself.
Figure 8.9. Conceptual model of ObservableProperty.
Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved.
53
S e n s o r M o d e l
L a n g u a g e O G C
0 7 - 0 0 0
SensorML Conceptual Models
In SensorML, all components are modeled as processes. This includes components normally viewed as hardware, including transducers, actuators, and processors which are
viewed as process components and sensors and platforms which are modeled as systems. All components are modeled as processes that take input, and which through
the application of an algorithm defined by a method and parameter values, generate output. All such components can therefore participate in process chains. Process chains
are themselves processes with inputs, outputs, and parameters.
Hence, SensorML can be viewed as a specialized process description language with an emphasis on application to sensor data. Process descriptions in SensorML are agnostic of
the development environment in which they might be executed, or the protocol by which data is transported between process execution modules. SensorML does not try to replace
other existing technologies such as BPEL or MATLAB Simulink. It is also conceived that SensorML-defined processes could be imported and executed within other execution
environments, such as BPEL or MATLAB Simulink, as well as within SenosrML- enabled process execution software.
The models for SensorML and SWE Common are presented using Unified Model Language UML static structure diagrams. These UML diagrams represent conceptual
models only and are not intended for automatic encoding within XML Schema.
SensorML models sensor systems as a collection of physical and non-physical processes. It also supports the description of processes that have been applied to an observation i.e.
observation lineage or can be applied on an observation i.e. on-demand processing. In this sense, processes in SensorML are intended as serializations of executable
components. An instance of a process in SensorML should describe the inputs and outputs expected, as well as the parameters and methodology required to create output
values from input values. Process models and chains are expected to be linkable, and these links are expected to be described within a process chain or system.
Issue Name: Use of term “Operation” instead of “Process”. aw, 2006-12-07] Issue Description: It has been recognized that the term “Process” used in
SensorML may be equivalent or similar to the use of the term “Operation” defined in ISO TC211. The issue is whether the term “Process” should be replaced with the
term “Operation” within SensorML.
Resolution: This will be given serious consideration as SensorML moves toward more complete harmonization with ISO standards in future versions.
8.8 ProcessType
Kategori