VIATRA/CEP/Semantics

Event representation semantics

Depending on whether events have a length attribute in the time dimension (i.e. a duration) associated with them, we distinguish between two fundamental event representation semantics:

• Point and
• Interval semantics.

In point-like representation, events are depicted as points on the time line, with no duration; i.e. only the occurrence of the event can be detected. In contrast, the interval semantics-based representation depicts both the appearance and the disappearance of an event and hence, assigning a duration attribute to it.

The VIATRA-CEP framework, and the VEPL language in particular, uses point semantics to represent simple atomic events. Although, in the special case of Query result change event patterns, both point and interval semantics can be used and that in a very intuitive way: via the optional queryResultType attribute of Query result change event patterns.

Setting the queryResultType to NEW_MATCH_FOUND or EXISTING_MATCH_LOST, one can define an event pattern on the appearance or the disappearance of a graph pattern, respectively.

• If there are event patterns defined for both ends, interval semantics is used, essentially.
• If the optional parameter is not used, point semantics is used.
• If only one of the NEW_MATCH_FOUND and EXISTING_MATCH_LOST values is used, so-called quasi-point semantics is used. In this case the runtime watches both ends of the interval, but only triggers actions on the appropriate end.

Event processing semantics (a.k.a. Event contexts)

Observed events can be combined into complex event patterns in multiple combinations. The set of rules defining how the observed events build up complex event patterns is called the event context. The event context is an engine-level setting in VIATRA-CEP. VIATRA-CEP supports the following event contexts.

• Chronicle
• Immediate
• Strict immediate

The following figure from Carlson's event detection algebra shows how the chronicle and two other currently not supported (recent, unrestricted) contexts work.

Taking the example on the top of the figure (three occurrences of event A and two of event B), the next three rows show all the matched instances for the event pattern "A is followed by B". The most commonly used and natural context of the three is the chronicle, which is the default for VIATRA-CEP.

The chronicle context allows unlimited "noise" on the event stream. If the event sequence in the previous example (AAABB) would change to AxxAxAxxBxB, where 'Xs are events differing from A and B, the chronicle context would yield the same result. In some cases this is not acceptable. The immediate contexts support these cases. In both cases, if an event is observed on the event stream which does not add information to an event pattern, that pattern is reset. (On the level of the internal runtime model, this means the lack of triggering a token fire and the corresponding automaton being reset.) The difference between the normal and strict immediate context is the number of partially matched complex event patterns they allow: the normal case allows tracking multiple partial matches (as long as there are no non-interesting events on the event stream); while the strict immediate strategy allows tracking only one pattern.

TODO: example like above (AAABB)

Complex event operator semantics

Timewindow

• Active/Passive
• Within/Holds-For