SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 113 of 233
-
Geometric functions conformance class STANDARD
-
Conversion functions conformance class BASIC A “GeoPDP” has to implement all functions of conformance class BASIC to be considered
a BASIC GeoXACML conformant PDP implementation. A STANDARD conformant PDP implementation has to implement all functions of conformance class STANDARD in addition to
all functions of conformance class BASIC.
The XACML extension point for function types is shown in the following figure. As the FunctionId attribute is of type anyURI any additional function may simply be used. GeoXACML
does not define any additional or changed XSD schema elements to XACML to stay XACML conformant.
Figure 7-8: Function type extension point of XACML
7.5. Event Information Model
With respect to the OGC baseline, an event is a feature. SensorSA provides a cross-domain application schema for events, called event information model. Although each domain needs to
build their own, well-adapted event model, a cross-domain application schema serves as a common denominator or kind of crystallization point for further extensions.
The event model is organized in a package stereotyped ApplicationSchema. It has dependencies on a number of packages from the ISO 19100 Harmonized Model, as shown in
Figure 7-9.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 114 of 233
Figure 7-9: Event model dependencies on packages from the ISO 19100 Harmonized model
Only one sub-package currently exists in the event model see Figure 7-10.
Figure 7-10: Event model package structure
This package will be explained in the following.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 115 of 233
Figure 7-11: Event type and specializations
Note: The class named AbstractFeature represents the set of all classes with stereotype FeatureType. In an implementation a concrete class representing a feature type from a
domain of discourse will substitute this abstract class. This class is implemented in GML by the element gml:AbstractFeature.
An Event is a feature. It has a required property containing the time when the event happened. The eventTime is modelled as a TM_Primitive from ISO 19108. As such, the value
may be a temporal geometry primitive instant or interval or a temporal topology primitive node or edge. The Event class realizes the getEventTime operation from the EventTimeProvider
interface, which provides access to the value of the eventTime property.
Note: in ISO 19136, a feature is modelled as a gml:AbstractFeature which contains a boundedBy property that can only describe a spatial or spatio-temporal boundary, but not a pure
temporal one. In the case of events, the temporal aspect is of primary interest. This also applies
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 116 of 233
to non-geospatial features, which contain complex temporal properties. Thus, the boundedBy property of gml:AbstractFeature should be modified to support both spatial, temporal and spatio-
temporal bounding extent information.
An event may be related to other features. One to many role properties characterize each EventFeatureRelationship. This primarily supports use cases in which an event object is
exchanged between multiple domains where the relationship target may incorporate a different association role and thus may have a different semantic as property of the event.
Example: an earthquake event may have a relationship to a street feature, indicating that the earthquake affected the street and that it actually destroyed the street. Similarly, a hurricane
event may have a relationship to a butterfly, indicating that the hurricane was causedBy the butterfly and that the hurricane blewAway the butterfly.
An event may also be related to other events via an EventEventRelationship. This type inherits from EventFeatureRelationship and thus has AbstractFeature as target property.
However, a constraint is added to the EventEventRelationship, which requires the target to realize the EventTimeProvider interface. This allows us to establish relationships to features that
can be considered as events, regardless of whether they derive from the Event type defined in this application schema or not.
For further relationships between an Event and another featureevent, we refer to the OGC engineering report OGC 09-032, as mentioned at the beginning of this chapter.
Specializations of the Event type – which itself is neither an abstraction nor a composition
of other events it may nevertheless be related to other events and thus represents a simple event
– can be a ComplexEvent or a DerivedEvent. An abstraction or aggregation of multiple events - its members - is called a ComplexEvent.
The relationship to a member event is modelled through the EventEventRelationship. A ComplexEvent does not necessarily have member events. This situation will likely be the case
when it is known that an event happened and that it was caused by other events but that these causing events cannot be determined at the moment. The ComplexEvent will then be an
abstraction of the happening caused by these unknown events.
This also implies that the event time of a ComplexEvent is - like for a simple Event - assigned by the entity that creates the event object. It can but does not have to be related to the
event times of member events. Note: Because the event time is a genuine property of an event, it shall not be modified
in an event object. This also applies to complex events. Therefore, if the event time of a ComplexEvent object was computed at creation time based upon - for example - the temporal
bounding box of the member events that were available and if later the set of members is modified then the event time of the original event object shall not be modified. Instead a new
complex event object should be created which encompasses the modified set of member events and the new event time. This new event may for example have a relationship to the old event
with a role of supersedes. Otherwise, if a modification of the member set has no implications upon the event time, then a new event object is not necessary.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 117 of 233
If a well-defined procedure was used to detect an event based upon the existence or absence of one or more other events, the resulting event is called DerivedEvent. The procedure may be any
process or algorithm that is capable of detecting an event based upon the existence or absence of information in member events. A DerivedEvent therefore has at least one member. The event
time of a derived event is determined by its procedure.
7.6. Resource Model
