Event Properties Event Model

SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 64 of 233 GFM defined in ISO 19109. Here, features are entities that have a set of properties defining their characteristics. All events have one characteristic in common: The time the happening of interest took place. Some happenings last for a period of time, e.g. a sandstorm. SensorSA adopts the definition by Allen and Ferguson that events are temporally anti-homogeneous Allen Ferguson 1994. Thus, an event that happened over an interval of time did not happen during that interval, because the event would not have been completed yet. The event time equals the time of completion of the interval. This aspect needs to be considered for the modelling of event types. Further on, the event model shall allow multiple events generated for a single happening of interest. Those events might represent different aspects of the happening, with only the time being shared across them. We will elaborate the lifetime of events in more detail in the following sections, before the event model aspects inheritance, constraints, properties and associations will be discussed in more detail. Before we address the lifetime of an event, we define further: - A notification is a message that transports one or more events. The notification might be identical to the event object, if a single event object gets transported without any further packaging into a message container. Note 1: An alert is a notification. The terms notification and alert are used synonymously throughout this document. Note 2: Some use cases describe the dispatch of “alarms”. The SensorSA specification does not differentiate types of event notifications. Thus, an “alarm” is simply an event notification and shall not be used in architectural discussions, as its semantics differ considerably across applications. The term is better used in its verb- form, e.g. “…a notification will be sent to alarm the user…”.

6.4.2.2 Event Properties

SensorSA follows the General Feature Model defined in ISO 19109 to define the property types operations, attributes, and association roles of the feature type event type. However, the SensorSA uses the RDF terminology, as defined by the W3C W3C, 2004 because it doesnt differentiate between attribute and association roles, but calls both property types properties, which is more appropriate for the event model: - Operations SensorSA defines a single mandatory operation to retrieve the event time: getEventTime . It returns a time instant or time interval. An event type might encode the time when the happening took place as a property, or the time gets computed on the fly once the getEventTime operation is called. Event types may provide additional optional operations. - Fixed and Dynamic Properties Event objects have fixed and dynamic properties. Fixed properties cannot be modified once the value has been set. An example of a fixed property is the temporal or spatio- temporal characteristic of the event object. Event objects cannot be modified after 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