DUL:hasConstituent : DUL:Event DUL:hasPart : DUL:Event DUL:hasParticipant : DUL:Object DUL:involvesAgent : DUL:Agent DUL:isEventIncludedIn : DUL:Situation DUL:hasEventDate : date Stream bus:topic : wsnt:Topic[0..1] dc:desciption : string dc:WLWOH VWULQJ Event eventPattern : [0..1] location : geo:Point[0..1] members : rdf:List[0..1] source : Source[0..1] stream : Stream[1..1] endTime : dateTime[1..1] startTime : dateTime[0..1]
message : string Source
geo:Point geo:alt geo:lat geo:long stream location source
Figure 5.1.: Event Model (Class Diagram)
Figure 5.1 shows the event model in a class diagram3. The class “Event”
at bottom left of the figure is the superclass for any event to conform to our model. This class makes use of related work by inheriting from the
3UML-like notation of TopBraid Composer: http://www.topquadrant.com/composer/
5.3. The Model 47
class “DUL:Event” from Dolce Ultralight based on DOLCE [Gangemi et al. 2002]. That class provides a notion of time and helps distinguish events (things that happen) from facts (which are always valid).
In accordance with our requirements some properties are mandatory while the rest are optional. An instance of class Event MUST have (i) a type, (ii) at least one timestamp and (iii) a relevant stream. We describe the event properties in detail as follows.
The type of an event must be specified using rdf:type4. The type must be
the class Event or any subclass. Figure 5.2 shows examples of subclasses. The hierarchy in that figure starts with the universal superclass owl:Thing and shows our Event class with domain-specific subclasses needed to implement our scenarios from Section 2.7.
The event model supports interval-based events as well as point-based events (cf. Section 3.6) by either using just the property :endTime for a point or both :startTime and :endTime for an interval. The property :endTimethus has a cardinality of [1..1] whereas :startTime has a cardinality of [0..1]. Both temporal properties are subproperties of DUL:hasEventDatefrom the super class. We improve the semantics by distinguishing start from end whereas the superclass has an alternative, more difficult way of formulating intervals using subobjects reifying the interval.
The property :stream associates an event with a stream. Streams are used in our system as a unit of organisation for events governing pub- lish/subscribe (cf. Section 3.5) and access control (cf. Section 4.5). Streams themselves are modelled using title, description and a topic needed for topic-based publish/subscribe (cf. Section 3.5).
The first optional property is :location. For for geo-referencing of events (where necessary) we re-use the basic geo vocabulary from the W3C [Brick- ley 2003]. The property may be used to locate events in physical loca- tions on the globe. The property is subproperty of DUL:hasLocation and geo:locationto inherit the semantics from those schemas.
Inter-event relationships may be supported by linking a complex event to the simple events which caused it. Thus, RDF Lists may be used in
:membersto maintain an ordered and complete account of member events.
The linked events are identified by their URI. These linked events could have further member events themselves. This facilitates modelling of compositeevents [Luckham and Schulte 2011]. The :members property is a subproperty of DUL:hasConstituent from the superclass.
The property :eventPattern may be used to link a complex event to the pattern which caused the event to be detected. Direct links to event patterns are provided by RESTful services described in Section 7.4. Using such links can help in recording provenance of derived events.
The source of an event may be specified using the :source property. This is an optional property to record the creator of an event where needed. The property is a subproperty of DUL:involvesAgent. Agents may be human or non-human.
A human readable synopsis of an event may be added using the :message property. This proves useful in scenarios where events are received by human end users. The :message property is a subproperty of dc:title, a popular way of describing things using natural language. Multilingualism is provided by the feature of language tags for string literals in RDF [Klyne and Carroll 2004].
N-ary predicates [Noy and Rector 2006] may be used to maintain event properties which are valid only for a specific event, e.g. a volatile sensor reading such as the temperature measurement belonging to a specific event. For example, instead of plainly stating the disputable fact that “the city of Nice has a temperature in Celsius of 23 degrees” which looks like this:
d b p e d i a : N i c e : c u r T e m p " 23 " .
We can instead state that the city of Nice has said temperature but qual- ified by the conjunction with a given event “e2” in the following n-ary predicate:
5.3. The Model 49
d b p e d i a : N i c e : c u r T e m p [ rdf : v a l u e " 23 " ;
: e v e n t < h t t p :// e v e n t s ... org / ids / e2 # event > ] .
Endowment of further structure for events is left to domain-specific sche- mas. For example the W3C Semantic Sensor Network (SSN) Ontology5
may be added if fine-grained modelling of sensors and pertaining sensor readings is needed.
Listing 5.1 shows several facts about our event model along an example. The listing uses the example of a Facebook event generated by our event adapter described in Section 7.6:
1. The example shows an event using quadruples in TriG syntax [Bizer and Cyganiak 2014]. The graph name (a.k.a context) before the curly braces is used as a unique identifier, e.g. to enable efficient indexing of contiguous triples in the storage backend for historic events. 2. The event in this example has the ID 5534987067802526 as part of its
URI. There is a distinction made between URIs for things and URIs for their information resources, i.e. the event object 553498706780- 2526#eventand the Web document 5534987067802526 describing the event. The two URIs might carry, e.g. a different creation date, which is why it can be important to separate them. The fragment identifier #event is used to differentiate them. See [Berners-Lee 2005] for an in-depth discussion of the matter of disambiguation6.
3. There is an event type hierarchy from which the type Facebook- StatusFeedEventis inherited. This hierarchy can be extended by any user by referencing the RDF type :Event as a super class. See Figure 5.2 for an example hierarchy.
4. The event may link to entities from static Linked Data where further context for the event can be retrieved. In this example the event uses user:linkwhere further context for the event can be retrieved, in this case from the Facebook Graph API7.
5http://www.w3.org/2005/Incubator/ssn/ssnx/ssn
6The issue of HTTP URIs identifying both types of resources became known as the
httpRange-14issue after its issue number in the W3C Technical Architecture Group
5. The event links to a stream which is a URI where current events can be obtained in real-time by dereferencing the link.
6. The namespace event-processing.org is chosen as a generic home for this schema.
1 @ p r e f i x : < h t t p :// e v e n t s . event - p r o c e s s i n g . org / t y p e s / > .
2 @ p r e f i x e : < h t t p :// e v e n t s . event - p r o c e s s i n g . org / ids / > .
3 @ p r e f i x u s e r : < h t t p :// g r a p h . f a c e b o o k . com / s c h e m a / u s e r # > .
4 @ p r e f i x xsd : < h t t p :// www . w3 . org / 2 0 0 1 / X M L S c h e m a # > .
5
6 e : 5 5 3 4 9 8 7 0 6 7 8 0 2 5 2 6 {
7 < h t t p :// e v e n t s . event - p r o c e s s i n g . org / ids / 5 5 3 4 9 8 7 0 6 7 8 0 2 5 2 6 # event >
8 a : F a c e b o o k S t a t u s F e e d E v e n t ;
9 : e n d T i m e " 2012 -03 -28 T06 : 0 4 : 2 6 . 5 2 2 Z "^^ xsd : d a t e T i m e ;
10 : s t a t u s " I b o u g h t s o m e J E A N S t h i s m o r n i n g " ;
11 : s t r e a m < h t t p :// s t r e a m s ... org / ids / F a c e b o o k S t a t u s F e e d # stream > ;
12 u s e r : id " 1 0 0 0 0 0 0 5 8 4 5 5 7 2 6 " ;
13 u s e r : l i n k < h t t p :// g r a p h . f a c e b o o k . com / r o l a n d . s t u e h m e r # > ;
14 u s e r : l o c a t i o n " K a r l s r u h e , G e r m a n y " ;
15 u s e r : n a m e " R o l a n d St ü h m e r " .
16 }
Listing 5.1:Example of an RDF Event (TriG Syntax)
We are re-using and creating domain vocabularies to subclass the class Event. For example in the Facebook case we use the schema from the RDF/Turtle API provided by Facebook [Weaver and Tarjan 2012]. We developed this event model to satisfy requirements of an open platform where data from the Web can be re-used and which is extensible for open participation. Future updates to the event schema can be tracked on-line at [Harth and Stühmer 2011].