SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 65 of 233
their release, but need to be superseded by updated new event objects, i.e. after release, all properties are fixed.
Nevertheless, there are some event objects that refer to the same logical happening, but differentiate in their property settings. An example would be a
lastEarthquakeEvent object. This event object always refers to the last earthquake, thus some properties, such as epicentre or magnitude change from event object to
event object. Here, every new event object represents an update of all earlier event objects, i.e. though the properties are fixed of each object, they seem to be
dynamically changing.
-
Temporal Properties Each event object may store a temporal property of type time instant or time interval
to represent the time when the happening took place. Still, following the lazy loading pattern, the time might get computed in time when the getEventTime operation is
called.
Event objects might provide any additional temporal property, such as event creation time, event detection time etc. To support distributed systems, each event object shall
reference the temporal reference frame and clock to support proper event sequencing. Event object may represent happenings in the past, ongoing, or simulated in the
future.
-
Spatial and Location Properties Event objects may provide information on spatial extents related to the happening.
Those properties may be of any geometry type and representation, i.e. vector or coverage based. A location identifier may be used instead of a geometry type.
-
Thematic Properties Any domain expert is free to add as many thematic properties as necessary.
The formal definition of the event information model is provided in the Information Viewpoint in section 7.5
6.4.2.3 Event Lifetime
Temporal aspects of events have attracted considerable interest as a research topic over the past few years Allen 1995. The core focus was on representing temporal aspects in
geographic information systems and spatio- temporal data models. SensorSA doesn‟t
contribute to this still ongoing discussion, but defines an event model that acknowledges the temporal aspect of events reifying actions in their respective environment as well as their
causal catenation. SensorSA introduces a three-phases event lifecycle, with creation, update, and deprecation phase of an event.
-
Creation of Events The Sensor Web requires events to be generated from a number of components and
logical entities. Among those components are resource-constrained devices, such as
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 66 of 233
battery-powered sensors, temporarily unavailable components, such as human observers, and high-reliance systems such as emergency warning systems.
Basically, event creation is a two-step process. First, the action that is signified by the event needs to be observed; and second the observation must be transformed to a
structure that can be processed within IT systems.
SensorSA doesn‟t apply any restrictions on the observation process, i.e. the activity can be observed by a sensor, a human, a piece of software that supervises another
piece of soft- or hardware, event processing systems that generate events based on other events, or any other entity that is enabled to execute observations. The second
step is the transformation of the observation to something that can be dealt with within IT systems, i.e. an event object that reifies the observed happening.
-
Update of Events Once generated, events can be updated to allow modifying the event content. The
update of an event may have major effects on events further down the causal chain of related events. Causal chains and updating of events will be further elaborated in
6.4.2.6.
-
Deprecation of Events Events shall not be cancelled, i.e. an event exists and continues to be valid until
declared void or deprecated. SensorSA calls this approach the Reliant Event Model. The rationale behind this approach can be found in the ambiguous semantics of the
term cancellation. Cancelling an event could mean that the signified action never happened e.g. false observation by sensing device, that it had happened but is not
valid any longer e.g. a “fire event” after the fire was extinguished, or that it was once true but was modified based on additional observations e.g. reclassification of a storm
once more observation data were received. The validity of events shall be reflected in the event content model. Events are valid
until they become explicitly deprecated.
6.4.2.4 Event Verbosity Levels
