SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 130 of 233
The optional section MI_Discovery_Basic further details common information that may be useful for the description of the meta-information about different kinds of resources see Figure
7-20. It includes spatial references to define the location of the described resource. The discovery basic section also contains a temporal reference. It is possible to define a
time stamp or a time interval. The defined temporal types of SWE common are not used, because the meta-information schema and especially the discovery basic section is common and not
exclusively tied to the description of sensor observation meta-information. However, for the implementation of a specific catalogue containing OM resources the usage of SWE common
types for spatial and temporal reference is possible. The discovery basic section also defines free keywords to be used as matching constraints in catalogue search operations as well as white page
information containing detailed contact information about the resource provider and yellow page information for the classification of the meta-information document. The white page information
part uses well known types defined by ISO19115.
7.7.3 Meta-information Sections Related to Observation Discovery
The sections
MI_OM_FeatureOfInterest, MI_OM_ObservedProperty
and MI_OM_Procedure represent the OM model types. These sections can be used to define meta-
information that describes observations see Figure 7-21, Figure 7-23 and Figure 7-22. For the description of the meta-information of observations there is no need for a complete mapping of
the OM elements. Instead a well defined list of available types describing the OM types is needed. The feature of interest section is mandatory for the creation of a meta-information
document of the resource type feature of interest. It includes a feature of interest type defined with a URN, which shall be defined in a list of available features of interest and a spatial
reference which provides information about the location of the feature of interest.
class AS-MI-OM-FeatureOfInterest
«type»
AS-MI FeatureOfInterest::MI_OM_FeatureOfInterest
+ spatialReference: MI_SpatialReference [0..1] + featureOfInterestType: OA_URN [1..]
+ feautreOfInterestId: CharacterString «type»
AS-MI Sections:: MI_SectionContentBase
Figure 7-21: Feature of Interest Section
The procedure section is mandatory for the creation of a meta-information document of the resource type procedure. It includes a procedure type defined via a URN, which shall be
defined in a list of available procedures. Like the feature of interest section it is also possible to define an area of interest of the procedure via the spatial reference attribute. Additionally the
procedure section contains information about the procedure input, procedure output, accuracy,
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 131 of 233
process and responsible party which describes the meta-information for information fusion processes of procedures see section 10.6.3.
class AS-MI-OM-Procedure
«type»
AS-MI Procedure::MI_OM_Procedure
+ procedureTy pe: OA_URN + spatialReference: MI_SpatialReference [0..1]
+ procedureInput: MI_OM_ObservedProperty + responsibleParty: MI_ResponsibleParty
+ accuracy: DQ_ Element [0..1] + process: OA _URN [0..]
+ procedureOutput: MI_OM_ObservedProperty + procedureId: CharacterString
«type»
AS-MI Sections:: MI_SectionContentBase
Figure 7-22: Procedure Section
The observed property section is mandatory for the creation of the resource type observed property. It includes an observed property type defined via a URN, which shall be defined in a
list of available observed properties see section 6.5.2. Additionally the section contains a placeholder for a more detailed description of the observed properties. This element can be used
if there is a need for a registry containing observed properties.
Figure 7-23: Observed Property Section
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 132 of 233
The section MI_SensorML see Figure 7-24 provides the possibility to include a SensorML document that contains detailed information about a procedure which, according to
the OM model, represents a sensor see section 7.2. Using this section the creation of a catalogue as sensor registry is possible.
cd AS-MI-SensorML
«Type»
AS-MI SensorML:: MI_SensorML
+ sensorML: SensorML «Type»
AS-MI Sections:: MI_SectionContentBase
Figure 7-24: SensorML Section
For each service type there is a need to define a section that defines the specific capabilities of a service. As an example the section MI_SOS_Capabilities defines the capabilities of an SOS
service see Figure 7-25. The same structure shall be used for the creation of specific sections for other services.
Figure 7-25: Example Section describing Specific Capabilities of a Service
Instances of the OGC Sensor Observation Service SOS see section 8.2.2 provide offerings as a means to combine observations that share common characteristics. For each
offering a bounding box and a time interval is provided. This principle is currently under discussion in the OGC Sensor Web Enablement Working Group. Therefore the section
describing the SOS capabilities in the meta-information schema assumes an SOS having a single offering and provides a single time interval and bounding box. The MI_SOS_Capabilities type
will be adapted to the result of the ongoing discussion.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 133 of 233
It is also possible to include original OGC capabilities in a meta-information document. An example including the capabilities of an SOS is defined in the section
MI_OGC_SOS_Capabilities see Figure 7-26
cd AS-MI-OGCSOSCapabilities
«Type»
AS-MI Sections:: MI_SectionContentBase
«Type»
AS-MI OGC SOS Capabilities:: MI_OGC_SOS_Capabilities
+ sosCapabilities: Capabilities
Figure 7-26: Example Section including original OGC SOS Capabilities
There is a placeholder in the section MI_SensorNetwork to define meta-information about sensor networks see section 5.4. From the modelling point of view, a sensor network is at
present simply represented by a container of a set of sensors.
class AS-MI-SensorNetw ork
«type»
AS-MI Sensor Netw ork::MI_SensorNetw ork
+ procedureConnector: MI_ProcedureConnector «type»
AS-MI Sections:: MI_SectionContentBase
«type»
AS-MI Sensor Netw ork::MI_ProcedureConnector
+ connectorType: MI_ConnectorEnumeration
constraints
{connectorType is restricted to dataProcedure} «enumeration»
AS-MI::MI_ConnectorEnumeration
dataFeatureOfInterest dataPro cedure
service dataObservedProperty
dataSensorNetwork da ta
1 0..
Figure 7-27: Sensor Network Section
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 134 of 233
The sections described above can be used for the discovery of different resource types in a catalogue. For the discovery of sensor observations there is a need for links between the different
resource types. Figure 7-28 shows the MI_Service section that describes common meta- information about a service. Using a so-called data connector, resources information about
services may be connected to different data resource types such as features of interest, procedures or observed properties. As a consequence, a query for services may include search
criteria for these resources. The following describes an example workflow for the discovery of SOSs providing observations yielded by a specific procedure:
1. Search in the catalogue for the specific procedure type. The catalogue will return a MI_Data_Procedure type document.
2. Search in the catalogue for SOSs which are connected to the MI_Data_Procedure type document. The MI_Data_Procedure instance is identified via its ID. The
catalogue will return MI_Service documents describing SOSs which use the specific procedure type.
3. The MI_Service document provides access information about the SOS. The access to the observations of the procedures is achieved via the means of the SOS.
Figure 7-28: Service Description Section
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 135 of 233
Figure 7-29 shows the OA_MI_Data section that describes a data resource. In analogy to the section about services, resource information of type service can be connected to data.
class AS-MI-Data
«type»
AS-MI Data::MI_DataDescription
+ serviceConnector: MI_ServiceConnector [0..] + dataType: Charac terString [1..]
«type»
AS-MI Sections:: MI_SectionContentBase
«enumeration»
AS-MI::MI_ConnectorEnumeration
dataFeatureOfInterest dataPro cedure
service dataObservedProperty
dataSensorNetwork da ta
«type»
AS-MI Data::MI_Serv iceConnector
+ connectorType: MI_ConnectorEnumeration
constraints
{connectorType is restricted to service} 1
0..
Figure 7-29: Data Description Section
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 136 of 233
8. Service Viewpoint
8.1. Overview
The service viewpoint of the SensorSA specifies the interface and service types that aim at improving the syntactic and semantic interoperability between services, source systems and
applications. These interface and service types principally cover all of the functional domains as illustrated in Figure 6-1 and described in section 6.2.
The services are described according to the service description framework of the RM-OA, 2007 and are structured as follows:
-
Section 8.2 focuses on the services of the acquisition domain on the basis of the services of the OGC Sensor Web Enablement initiative.
-
Section 8.3 focuses on the services that support the abstract access control pattern as introduced in section 6.8.2.
-
Section 8.4 provides the descriptions of the remaining architecture services of the mediation, processing and application domain.
Note: Services of the sensor domain are out of scope of the current version of the SensorSA. The user domain is not specified on an abstract level in the SensorSA. Instead,
implementations of user-oriented services in a Web-based environment may be found in the Service Support Environment ESA SSE, 2007.
8.2. Services of the OGC Sensor Web Enablement
8.2.1 Overview
Service and Interface Type
Name Overview Description
Reference
Sensor Observation
Service Provides access to observations from sensors and sensor
systems that is consistent for all sensor systems including remote, in-situ, fixed and mobile sensors.
section 8.2.2
Sensor Planning Service
Provides an interface to task any kind of sensor to retrieve collection assets.
section 8.2.3 Sensor Alert
Service Provides means to register for and receive sensor alert
messages. section 8.2.4
Web Notification Service
Provides means by which a client may conduct asynchronous dialogues with one or more other services
using a range of communication protocols. section 8.2.5
Table 8-1: Sensor Web Enablement Services
