SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 123 of 233
be used by client application as navigational means for discovery of and the access to the observations provided by the SOS.
-
An extended approach is to provide a RESTful service as an alternate interface based on a resource model on top of a service instance or by combining several service instances.
Such a RESTful service would then provide a selected view typically just a subset upon the capabilities and operations of the underlying service. This approach has been
implemented for the as a prototype in the SANY project.
The modelling of resources according to this resource model may serve the following purposes in the context of a sensor service network:
-
It may provide a modelling bridge between the Information and the Service Viewpoint in a system design. The modelling of services in terms of the resources and their
representations which they provide to a client may facilitate the understanding of the functionality of the service to a system designer.
-
When specifying a resource- oriented view upon a service in addition to its “specific”
interface and operations, the system designer gains flexibility in mapping the abstract service specification to an implementation specification. For example, the system
designer may then map it to the SANY W3C Web Service platform see section 9.2.1, to a SANY OGC Web Service platform see section 9.2.2, or to a RESTful Web Service
platform see section 9.2.3.
-
The provision of a resource-oriented view upon a service may facilitate the discovery of the se
rvice as the notion of resources may be closer to the “universe of discourse” of the user as it‟s the case for the signatures of specific services. Having this application in
mind, the resource application schema should then be stored as meta-information entries in catalogue systems.
7.7. Meta-information Schema for Discovery
7.7.1 Overview
The discovery of resources is an important consideration in a sensor service network. Several kinds of resources need to be discovered. It is possible to distinguish between two main resource
types which can be described by a meta-information document:
-
services, describing meta-information about available service instances
-
data, describing meta-information about available datasets It is possible to directly search for meta-information describing these two main resource
types in common OGC catalogues. This structure was also used in the default ORCHESTRA meta-information schema. The schema provides general elements for the description of the
above resource types. It is possible to directly re-use this meta-information schema for SANY to create meta-information documents describing resources in the Application Domain of SANY.
However, several extensions of the meta-information schema are needed for the discovery of resources of the Mediation Processing, Acquisition and Sensor Domains. The meta-
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 124 of 233
information schema was especially extended to address the need for sensor observation specific discovery. To achieve this, the OM model see section 7.2 was taken into account.
The following text and UML diagrams are describing the structure and contents of the resulting application schema for meta-information AS-MI. All meta-information types are
prefixed with “MI” for meta-information. The AS-MI contains classes for the two main resource types:
-
MI_Service for the description of services
-
MI_Data for the description of data To address the need for sensor observation specific discovery the data resource type was
refined into several subtypes derived from MI_Data. The following types are reflecting the structure of the OM model:
-
feature of
interests FOI
resource types
can be
described with
MI_Data_FeatureOfInterest,
-
procedure resource types can be described with MI_Data_Procedure, and
-
observed property resource types can be described with MI_Data_ObservedProperty. Besides these OM related types the AS-MI defines a resource type for the description of
sensor networks MI_Data_SensorNetwork. Figure 7-15 provides an illustrative overview of the available resource types. Each resource type is described by means of several mandatory and
optional sections. The mandatory sections for each resource type are listed in the comment boxes that are attached to each resource type box.
Figure 7-15: Meta-information resource types
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 125 of 233
The meta-information schema provides the possibility to create relationships between different resource types. It is possible to link services to a specific data type via the
MI_DataConnector. The data connector can be restricted to specific time-intervals. This ensures that observations can be discovered by time constraints. Conversely, it is also possible to create
links between data resource types and services realised by the MI_ServiceConnector.
Figure 7-16 shows the dependencies between the different resource types.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 126 of 233
Figure 7-16: Dependencies between Resource Types 7.7.2
Generic Meta-information Sections
Each meta-information document describing one resource type consists of several sections. All defined sections are summarised in Figure 7-17. All sections are derived from the class
MI_SectionContentBase.
A particular role is played by the MI_TableOfContents section. It defines the contents of the meta-information document and is mandatory for all resource types see Figure 7-18. Each
meta-information section is described by its name and a description. The combination of all sections described in the table of contents sections builds the meta-information document.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 127 of 233
cd AS-MI-Sections
«Type»
AS-MI Metainformation::MI_MetaMetainformation
+ dateStamp: Date + metainformationResponsible: MI_ResponsibleParty
+ language: CharacterString «Type»
AS-MI Core:: MI_CoreElements
«Type»
AS-MI Discov ery:: MI_Discov eryBasic
«Type»
AS-MI Serv ice Inv ocation:: MI_Serv ice_Inv ocationBasic
+ operation: MI_Operation [1..] + platform: CharacterString
«Type»
AS-MI Serv ice Monitorable::MI_Serv ice_Monitorable
+ monitorableCapabilities: MI_MonitorableCapabilities «Type»
AS-MI Sections:: MI_SectionContentBase
«Type»
AS-MI Sections::MI_Section
+ name: CharacterString + sectionContent: MI_SectionContentBase
+ sectionSchema: CharacterString
«Type»
AS-MI Table of Contents:: MI_TableOfContents
«Type»
AS-MI FeatureOfInterest:: MI_OM_FeatureOfInterest
«Type»
AS-MI Procedure:: MI_OM_Procedure
«Type»
AS-MI Observ edProperty:: MI_OM_Observ edProperty
«Type»
AS-MI Sensor Netw ork:: MI_SensorNetw ork
«Type»
AS-MI Client:: MI_ClientDescription
+ clients: MI_Client [1..] «Type»
AS-MI Serv ice Specific Example:: MI_ExampleServ iceCapabilities
1
Figure 7-17: Defined Meta-information Sections
cd AS-MI-TOC
«Type»
AS-MI Table of Contents::MI_SectionContentToc
+ name: CharacterString + sectionDescription: LocalisedCharacterString [0..]
«Type»
AS-MI Table of Contents:: MI_TableOfContents
+ section: MI_SectionContentToc [1..] «Type»
AS-MI Sections:: MI_SectionContentBase
Figure 7-18: Table of Contents Section
Another important section is the section describing the common core elements MI_CoreElements of the resource. It contains basic information like the ID of the resource, the
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 128 of 233
name of the resource, a description of the resource and basic access to the resource via a URL see Figure 7-19.
Catalogue entries may be time-dependent, i.e. they are only valid for given point or period of time. This may be required for validation and processing purposes. Examples are:
-
A service instance or a procedure may no longer be operational for example, because the underlying sensor is no longer accessible.
-
A service may provide access to different procedures at different times. This permits the deployment of several possibly redundant sensors that are used together to provide an
aggregate measurement. From the perspective of the resource requestor, they are accessible together by means of a single proxy, i.e. a single service instance.
As a consequence, the meta-information entries of the catalogue contain information about the temporal validity of meta-information entries. It is possible to search for a catalogue entry
filtered with the queryables StartDate and EndDate, which correspond to the time interval of the entry see the validation interval as defined in the mandatory core section in Figure 7-19.
cd AS-MI-CoreElements
«Type»
MI_CoreElements
+ description: CharacterString + documentation: OA_URI
+ id: CharacterString [0..1] + language: CharacterString
+ name: CharacterString + validationInterval: MI_ValidationInterval
+ url: OA_URI [0..1] «Type»
MI_SectionContentBase
«Type»
MI_ValidationInterv al
+ startDate: Date + endDate: Date [0..1]
1
Figure 7-19: Core Meta-information Elements
Figure 7-17 shows all available sections of the meta-information schema including the centrals sections “table of contents” and the sections about the core elements. The sections that
deliver the meta-information that is needed for sensor observation-specific discovery are described as follows:
-
The discovery basic section MI_DiscoveryBasic is described below.
-
The meta-meta-information section MI_MetaMetainformation describes meta- information about the meta-information entries themselves. This section includes a
timestamp of the last update of the meta-information document in the catalogue.
-
The service monitorable section MI_Service_Monitorable is a section which can be provided for the description of monitorable services.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 129 of 233
-
The service invocation section MI_Service_InvocationBasic is a section which can be provided for the description of service invocation details. It contains elements to define
the access to the service. Access URLs are given together with operation names and input and output parameters of the available operations.
-
The client description section MI_ClientDescription is a section which can be provided for the description of the clients of services. It contains access information about clients
for the described service resource.
-
The service specific section MI_ExampleServiceCapabilities is a placeholder for a section describing the specific capabilities of a service. The contents of these sections are
usually described in the specification of the described service. An example for the SOS service is given below.
-
The procedure section MI_OM_Procedure is described below.
-
The feature of interest section MI_OM_FeatureOfInterest is described below.
-
The observed property section MI_OM_ObservedProperty is described below.
-
The sensor network section MI_SensorNetwork is described below.
-
The SensorML section MI_SensorML is described below.
cd AS-MI-Discov eryBasic
«Type»
MI_Discov eryBasic
+ freeKeywords: MI_FreeKeywords + spatialReference: MI_SpatialReference [0..1]
+ providerInfo: MI_WhitePageInfo [0..1] + yellowPageInfo: MI_YellowPageInfo [0..1]
+ conformity: CharacterString [0..1] + constraints: CharacterString [0..]
+ lineage: CharacterString [0..1] + time: MI_TemporalReference [0..1]
+ format: CharacterString [0..1]
«Type»
MI_FreeKeyw ords
- keyword: MI_Keywords [1..]
«Type»
MI_Yellow PageInfo
+ business: MI_BusinessClassification [1..] «Type»
MI_BusinessClassification
+ topicCategory: CharacterString «Type»
MI_Keyw ords
+ keywords: CharacterString [1..] «Type»
MI_WhitePageInfo
+ providerName: CharacterString + providerSite: OA_URI [0..1]
+ providerIcon: OA_URI [0..1] + responsibleParty: MI_ResponsibleParty
«Type»
MI_SpatialReference
+ envelope: GM_Envelope [0..1] + place: CharacterString
+ point: GM_Point [0..1] «Type»
MI_SectionContentBase
SWE common provides an EnvelopeType and a
PositionType. For a specific implementation
this can be used as GM_Envelope and
GM_Point.
«Type»
MI_ResponsibleParty
+ responsibleParty: CI_ResponsibleParty «Type»
MI_TemporalReference
+ instant: DateTime + period: TimePeriod [0..1]
SWE common provides a timePair for describing intervals. But since
MI_TemporalReference is not only used for OM types, but also for other
services and data, the defined MI_TemporalReference was used.
0..1
0..1 0..1
1
0..1 1
0..1
1
Figure 7-20: Common Meta-information Elements
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
