The WNS Model includes two different kinds of notifications. First, the “one-way- communication” provides the user with information without expecting a response.
Second, the “two-way-communication” provides the user with information and expects some kind of asynchronous response. This differentiation implies the differences between
simple and sophisticated WNS. A simple WNS provides the capability to notify a user andor service that a specific event occurred. In addition, the latter is able to receive a
response from the user.
The basis on which notifications will be sent is defined by the service and will be described in its capabilities. The “way-of-notification” palette may include:
• e-mail • HTTP POST: in case of sophisticated clients that act as web services themselves
• SMS • Instant Message
• phone call • letter
• fax Once a client registers itself, along with the method of notification desired, the client
receives a unique RegistrationID that can then be provided as input to other services e.g. SPS or SAS.
The WNS specification document OGC 06-095
was approved for release as an OGC Best Practices Paper in December 2006.
5.4.10 Sensor Web Registry
A Sensor Web Registry is implemented using an OGC Catalog Service backed up by an ebRIMebXML engine. This service provides discovery capability throughout the whole
sensor web infrastructure. Typical requests to this service are ‘GetRecords’ operations containing filtering parameters used to search a database for one or more matching
objects of interest. These objects include SWE services as well as other OGC services, sensor descriptions, process chains and dictionary entries such as phenomena or units,
etc.
In order to be able to insert objects to a Catalog, each object type must be defined by a schema and a CSW harvest profile. This profile shall define what information needs to be
parsed out of the object XML and advertised as searchable content.
The following table shows what data can be mined from different XML documents used through the SWE framework:
40
Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved.
Table 2 - SWE Framework Data Elements
Document Name Searchable SectionsTags
SOS Capabilities OWS common section like any other service
For each observation in the offering list: - observation id, name and description
- observed property association with OM phenomenon object - procedure id association with SensorML sensor object
- feature of interest association with GML feature - time range
- location if fixed - format
SPS Capabilities OWS common section like any other service
For each sensor system in the offering list: - phenomenon urn association with OM phenomenon object
- sensor id association with SensorML sensor object - area of service
SAS Capabilities OWS common section like any other service
For each subscription in the offering list: - alert id, name and description
- observed property association with OM phenomenon object - procedure id association with SensorML sensor object
- feature of interest association with GML feature - time range
- location if fixed - format
SensorML Sensor, System and Process
Most information is contained in the metadata group - description
- identifiers - classifiers
- time, legal and security constraints - characteristics
- capabilities - contacts
- inputs and outputs association with OM phenomenon - taskable parameters association with OM phenomenon
eventually recurse for each sub components
OM Phenomena A phenomenon is intended to be a pure dictionary entry, so it should be parsed
in its entirety, including: - description
- name - base phenomenon association with other OM phenomenon
- constraint phenomenon association with other OM phenomenon - constraint value
- component if composite association with other OM phenomenon
Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved.
41
