Temporal conditions and relationships between events play an important role in querying events. Temporal conditions are specified in the where-clause of an XChangeEQ event query —just like conditions on event data— and make use of the event identifiers for referring to events.
Example The event query in the following rule involves temporal conditions. It detects situa- tions where a customer first buys stocks and then (re)sells them again at a lower price within a short time, here less than 1 hour. The query illustrates that typical applications require both qual- itative conditions (b before s) and metric (or quantitative) conditions ({b,s} within 1 hour). In addition, the query also includes a data condition for the price (var P1 > var P2).
DETECT e a r l y R e s e l l W i t h L o s s { c u s t o m e r { var C } , s t o c k { var S } } ON and { event b : buy {{ c u s t o m e r { var C } , s t o c k { var S } , p r i c e { var P1 } }} , event s : s e l l {{ c u s t o m e r { var C } , s t o c k { var S } , p r i c e { var P2 } }}
} where { b b e f o r e s , { b , s } w i t h i n 1 hour , var P1 > var P2 }
END
As we can see in this example, the approach XChangeEQ uses for querying events can be considered as loosely inspired by event calculus. The use of an event identifier event i: is somewhat reminiscent of the happens predicate found in some variants such as [Kow92] of the event calculus [KS86]. Like an event identifier, the happens predicate reifies an event so that conditions on its occurrence time (and other conditions) can be expressed elsewhere in the logical formula. Note however that event calculus and XChangeEQare otherwise very different and serve
different purposes. In Chapter 17 we will give examples why this reification and the separation of the dimension that it achieves is considered better than, e.g., composition operators that include temporal conditions (such a sequence).
In principle, various external calendar and time reasoning systems could be used to specify and evaluate temporal conditions. The declarative semantics of XChangeEQ are organized in such a way that embedding an external temporal reasoner is simple. Its operational semantics for the evaluation of event queries however require deeper knowledge about temporal conditions for garbage collection and some optimizations. In the example above, using the condition b before sallows (1) to completely avoid evaluating the sell query until a buy event is received and (2) to use the values for variables C and S obtained from buy events when evaluating the sell query. Further, the condition {b,s} within 1 hour allows to garbage collect stored buy events after one hour has elapsed. We now discuss first the core temporal conditions supported by the current operational semantics of XChangeEQ. We then discuss further temporal conditions that might be desirable but would require at least an extension on the notion of temporal relevance that is used for garbage collection (cf. Chapter 15).
Qualitative Temporal Relations Since the occurrence times of events in XChangeEQ are time intervals, Allen’s thirteen relations [All83] are the natural candidate to express qualitative temporal conditions. XChangeEQ supports all thirteen relations, however they are not of equal importance for querying events. Of primary interest in querying events are:
• i beforej to express that eventiends before eventj starts, i.e., the ending timeend(i) of iis lower than the beginning time begin(j) ofj: end(i)< begin(j),
• i containsj to express that the time interval of eventi contains the time interval of event j, i.e., begin(j)< begin(i) andend(i)< begin(j).
• i overlaps j to express that event i starts before event j and overlaps j, i.e., begin(i) < begin(j) andbegin(j)< end(i) andend(i)< end(j).
Their inverses are available for convenience and named after, during, andoverlapped-by, respectively.
The other seven temporal relations can be considered less important since they require at least two endpoints of the time intervals to be exactly equal. Generally in event processing, two different events (or their begins or ends) rarely happen at the exactly same time and if so only accidentally. Nonetheless, XChangeEQ supports these relations:
• i meetsj expresses that the end time ofiis the same as the beginning time ofj: end(i) = begin(j).
• i starts j expresses that i and j begin at the same time and i ends earlier: begin(i) = begin(j) andend(i)< end(j).
• ifinishesj expresses thatiandjend at the same time andistarts later: end(i) =end(j) andbegin(i)> begin(j).
• iequalsjexpresses that the time intervals foriandjare exactly equal: begin(i) =begin(j) andend(i) =end(j).
The respective inverses of the first three relations are named met-by, started-by, and finished-byin XChangeEQ. The inverse of equalsis of course againequalsitself.
Metric Temporal Relations Qualitative conditions express only conditions that constrain the relative positions of occurrence time intervals on the time axis. Complex event queries however also often require conditions that affect the duration of or between events. Since these conditions involve actual values (lengths of time), they are called metric or quantitative.
The metric condition{i1, ...in } within d(i1, . . .inevent identifiers,n≥0,da duration)
limits the overall duration of a set i1, . . .in of events. All events must “fit” into a time interval
of length d. More formally: max{end(i1), . . . end(in)} −min{begin(i1), . . . end(in)} ≤ d. The
durationdis specified as described previously in Section 6.7. This metric condition is particularly useful for garbage collecting events (cf. Chapter 15)
XChangeEQ also supports a constraint that requires a given duration to separate two events. It is written{i, j} d apart(i, j event identifiers,da duration). Formally it means that either end(i)−begin(j)≥dor end(j)−begin(i)≥d.
Further Temporal Conditions XChangeEQ can easily be extended to accommodate further temporal conditions. In principle, various external calendar and time reasoning systems could also be included. The following gives a flavor of conditions that might be desirable in XChangeEQ in addition to the currently supported conditions discussed above.
Qualitative conditions may also refer to a fixed time point or interval on the time axis instead of an event identifier. For example, the following event query would detect only sell events that happen before 9am on September 18, 2006:
event s : s e l l {{ }}
where {
s b e f o r e d a t e t i m e ( " 20 0 6 - 0 9 - 18 T09 : 0 0 " ) }
Note that there is an important difference between timer events used in queries and references to time as part of where-conditions. Timer events have to happen for the event query to yield an answer i.e., they are waited for. Time references in conditions can be in the future and only restrict the possible answers to an event query. The following two event queries are therefore fundamentally different. To illustrate this, consider the following query where the date 9am on September 18, 2006 is used as a timer event:
and { event s : s e l l {{ }} , event t : t i m e r : d a t e t i m e {{ d a t e { " 2 0 0 6 - 0 9 - 1 8 " } , t i m e { " 9 : 0 0 " } }} } where { s b e f o r e t }
All answers to this event query on the are detected at the same time (2006-09-18T09:00). In contrast, the answers to the event query further up occur at different times (whenever a sell event is received).
Interesting in temporal conditions are in particular also periodic time intervals. For example an application might have a variant of the early resell complex event from earlier where the buy and sell events must happen on the same trading day (instead of within one hour). This might be specified as follows using an external calendar system such as CaTTS to define the concept of trading day:
DETECT s a m e D a y R e s e l l W i t h L o s s { c u s t o m e r { var C } , s t o c k { var S } } ON and { event b : buy {{ c u s t o m e r { var C } , s t o c k { var S } , p r i c e { var P1 } }} , event s : s e l l {{ c u s t o m e r { var C } , s t o c k { var S } , p r i c e { var P2 } }}
} where { { b , s } in c a t t s : t r a d i n g D a y () , b b e f o r e s , var P1 > var P2 }
END
Other Event Relationships The language design of XChangeEQ allows easy extension to accommodate other conditions on events such as causal or spatial relationships. This is the power of the separation of the four dimensions of XChangeEQ. One could for example have conditions such asi causes j for a causal relationship ori colocated-with j for a spatial relationship. These relationships have been discussed in Chapter 5.