In this abstract we present a model for representing heterogeneous event objects in RDF, building on pre-existing work and focusing on structural aspects, which have not been addressed before, such as composite event objects encapsulating other event objects. The model extends the SSN and Event-F ontologies, and is available for download in the ODP portal.
Layered processing of heterogeneous events [
In the terminology of [
In the proposed ODP (core classes and properties illustrated in Fig. 1) we have modelled the EventObject class as a subclass of the dul:InformationObject (similarly as the ssn:SensorOutput). We have aligned our EventObject class to the SSN ontology, by expressing that ssn:SensorOutput is equivalent to SensorOutput in the local namespace, which in turn is a subclass of EventObject. The reason for introducing a new SensorOutput class is to make the ODP more self-contained, but still make the alignment explicit (even without importing the SSN ontology). A SensorOutput is normally a SimpleEventObject, however, when considering more complex sensors, such as human sensors entering information into a system, they can be directly entered into the system as complex event objects. SimpleEventObject may also consist of other kinds of event objects than a SensorOutput, e.g., simulated event objects produced inside a system.
To relate event objects to each other, we introduce a set of object properties (hasSubEventObject and hasDirectSubEventObject, and their inverses). The object properties are modelled in a way that allows us to keep both a hierarchical sub-event object structure through a non-transitive property (hasDirectSubEvent5http://west.uni-koblenz.de/koblenz/fb4/AGStaab/Research/ontologies/events/model.owl 6http://www.loa-cnr.it/ontologies/DUL.owl 7http://spit re-project.eu/ontology/ns/
Object) but (using a reasoner) also allows for directly retrieving all sub-event objects through its transitive superproperty (hasSubEventObject). The properties are aligned to DUL, i.e., sub-properties of dul:hasConstituent (and dul:isConstituentOf). These properties allow us to express event abstraction on the side of the event objects, while a similar structure exists on the side of actual events in DUL, i.e., directly for the dul:Event class using dul:hasConstituent and dul:isConstituentOf. These two parallel structures do not necessarily need to mirror each other, which is actually the main motivation for separating them. For instance, consider a music festival night as an event that occurs in the real world. Intuitively we may, for instance, describe this event as a set of concerts by di erent artists that are held in sequence on the same stage, which could be modelled using Event-F, the dul:Event class and its associated properties for mereological breakdown. However, a system representation of this event, i.e., the event objects, may very well display a completely di erent content and structural breakdown. For instance, we may use sound level sensors to detect that there is some activity on the stage, and make readings every minute, then the music festival night is actually represented by a \loud period" event object in the system, which consists of sub-events that are the individual sound level readings, together with some mechanism detecting that what is heard is actually music. The latter breakdown would then use the properties of the Event Processing ODP, to express the breakdown of the event objects from the system viewpoint. In addition, we also model event objects that are partitioned into components, i.e., whose parts are other event objects. This is modelled in a similar manner, i.e., again with a property structure parallel to Event-F, but this time exploiting the dul:hasPart and dul:hasComponent properties.
Since the notion of event object header and event object body is a
prominent part of some systems (for a more detailed discussion on the aspect, see
[
The actual information content of an EventObject, whether organized into a header and body or not, can then be expressed through properties, such as hasEventObjectAttributeValue (subproperty of dul:hasRegion) and hasEventObjectAttributeDataValue (subproperty of dul:hasDataValue), or through arbitrary properties that the application case requires. To model di erent timestamps of the EventObject, there are a set of subproperties of hasEventObjectAttributeDataValue (in turn subproperty of dul:hasDataValue), grouped under a property called hasEventObjectTime, i.e., the following four OWL datatype properties: hasEventObjectSamplingTime, hasEventObjectApplicationTime, hasEventObjectSystemTime, and hasEventObjectExpirationTime, corresponding to the time points when the event object was sampled (e.g., recorded by a sensor), entered the data stream, arrived in the event processing system via the stream, and any known end time for the event objects validity, respectively. The alignment to Event-F is constructed through a restriction on the EventObject class, expressing that any EventObject describes some \real" event (dul:Event), which then according to the Event-F model has to be a documented event, i.e., a dul:Event involved in some eventf:EventDocumentationSituation. 3
As an example usage of the ODP, we may have sensors measuring the water level and ow in di erent parts of a network of rivers and lakes. That information combined with a weather forecast for rain could be used to derive a ood warning, which would be a complex event object. An RDF le containing an instantiation of the ODP, realizing this small example scenario can be found in the ODP portal8. In this example, a ood warning is an instance of EventObject, which is a composite event object, encapsulating another EventObject, which is a water alert. The water alert, in turn is also composite, encapsulating a water level measurement. The ood warning also refers to a weather event object, but the weather event object is merely referenced (rather than encapsulated). If the ood warning did not encapsulate the triggering event objects, it would still be a complex event object but not a composite event object. Each of the EventObject instances have some data attached, and most of them use the header/body 8http://www.ontologydesignpatterns.org/cp/examples/eventprocessing/eventexample.owl structure described previously. In addition, the example shows how external vocabularies can easily be used for expressing EventObject instances and data. For example, the weather data uses the meteo vocabulary9, and to illustrate the alignment to the SSN ontology the water level measurement EventObject is modelled entirely using classes and properties from the SSN ontology. 4
We propose a novel Event Processing ODP, i.e., a vocabulary for representing
and reasoning over complex and composite event objects, which is needed for
further progress in the area of RDF stream processing. The model is aligned
to important standards, such as the SSN ontology, and compatible with other
event models, such as Event-F, and it is particularly designed so as to be exible
enough to accommodate di erent event object structures, yet generic enough to
allow for expressing generic queries for management of the event objects. For a
complete discussion of bene ts and relations to the underlying requirements, see
the accompanying full paper [
This work was partially supported by European Commission through the SSRA (Smart Space Research and Applications) activity of EIT ICT Labs10, and CENIIT at Linkoping University through the grant 12.10.