112
Copyright © 2010 Open Geospatial Consortium, Inc.
Figure 39: Overview of the timeline of selected bindings and specifications
As shown in the figure the first binding technology that influenced the OGC eventing specifications was WS-N from OASIS. It was used in the SES to define the common
communication methods like Notify and Subscribe. Due to the experience made with the SES it was also selected to be used in the SWES specification for the notification
handling.
The SWES specification has the goal to define standard behavior and operations across SWE service specifications similar to the OWS common specification. As said above it is
used in the 2.0 versions of the SPS and the SOS. The SWES specification is currently reviewing the comments received in the RFC phase and - once all comments have been
processed - will move forward to vote for adoption as an OGC Standard.
For the development of the Event Architecture also WS-E and ATOM were considered, besides WS-N. Web Services Eventing WS-E from the W3C has a similar scope as
WS-N but differs in some aspects. In general it is a bit simpler and lighter. It is currently proposed as W3C standard but not released yet.
Under the term ATOM three specifications are listed. The first is the Atom Syndication Format ASF which is an XML based format for the description of lists of related
information feeds. The Atom Publishing Protocol AtomPub is used for editing and publishing web resources encoded as ATOM feeds. PubSubHubBub PSHB is a protocol
that extends ATOM feeds to support push based communication via feeds instead of pulling requesting information updates. AtomPub and PSHB can be considered to
enable a RESTful implementation of the Event Architecture and a possible OGC Event Service.
Copyright © 2010 Open Geospatial Consortium, Inc.
113 Both the latest WS-Eventing and Atom specifications need to be investigated in detail
and the results incorporated in a further revision of the OGC Event Architecture.
12.2 Information models
12.2.1 Introduction
In this section various information models are described that can be used for the encoding of events.
12.2.2 Timeline
The following figure Figure 40 shows the relations and the timeline of multiple information models. These include information models developed by the OGC like the
Geography Markup Language GML, Observations and Measurements OM and SWE Common but also external information models like the Aeronautical Information
Exchange Model AIXM, the Weather Information Exchange Model WXXM and the Common Alerting Protocol CAP. Please note that not all relations between GML and
other models are included in the figure for readability reasons. The relations shall be interpreted to be transitive, for instance AIXM 5.1 is also using GML 3.2.1 because it is
based on AIXM 5.0 which uses GML 3.2.1 directly.
Figure 40: Overview of the timeline and relations of selected information models
114
Copyright © 2010 Open Geospatial Consortium, Inc.
12.2.3 GML
The Geography Markup Language is widely used for the encoding of geographical features. It defines the encoding of a wide range of properties like the geometry,
reference system information, temporal properties and other data types. GML therefore provides the baseline for other information models like OM. In fact, OM is a GML
application schema, meaning that it is encoded following encoding rules defined by GML. The standard output of Web Feature Services is usually encoded in GML.
GML does not define data types itself for encoding events. A given application schema has to define the encoding of its events. This can but does not have to leverage the Event
Model that was first described in OWS-6 Event Architecture ER 09-032. Note that the encoding of an event shall
– according to the Event Architecture – provide the information to determine the time when the event happened, that is the event time.
12.2.4 Event Model Revision
Based upon the OGC Event Definition developed in OWS-6, the first version of a GML Application Schema for events - the Event Model - was developed. This model defines
the structure of basic event types. In addition, some special events with common purpose are provided. The Event Model was first documented in the
OWS-6 SWE Event Architecture Engineering Report
OGC 09-032. In OWS-7, the following improvements to the model were identified:
Each event shall have an optional spatialExtent property. This property shall be populated with the geometry that best describes the spatial boundary of the event.
Of course, the property can only have a value if the event has a spatial context and if that context can be expressed as a geometry.
An event shall support the addition of a number of soft-typed properties. These named value attributes support the inclusion of any property that is defined
through an extension, added ad hoc or used for testing purposes. The name of such an attribute shall be well-defined, ideally via a unique URL, so that clients
can unambiguously identify the purpose of a given soft-typed property.
The target property of the EventEventRelationship shall not be constrained to be a GML AbstractFeature. It shall be possible to point to any existing type. This for
example supports use cases in which the members of a DerivedEvent are CAP alerts.
This change required that the EventEventRelationship type does not derive from the EventFeatureRelationship type. Both types could derive from a common
relationship type that defines the role property. This change has not been required yet.
Figure 41 shows the revised model that incorporates these changes.
