Event Recognition in Data Streams

Dr. Manolis Pitsikalis

[email protected]
Spring Semester 2025

1 Introduction
Event recognition systems enable the detection of complex events over data streams that contain
low-level events, such as the timestamped values of a sensor. The architecture of these systems
is briefly described by the following figure.

Figure 1: Architecture of
an event recognition system.

The system in the diagram receives as input a stream of events and has access to a set of event
definitions as well as a set of static knowledge (atemporal knowledge). The system performs
event recognition by applying the definitions of complex events in combination with the static
knowledge over the input stream. The result of this process is the production of an output stream,
which contains the timestamped detections of the complex events. Such a system, for example,
could be applied to monitor the condition of patients through smart sensors.
In your assignment, you are asked to build such an event recognition system in Prolog. This
assignment is organized as follows. Section 2 presents the LDI language as well as its semantics.
Section 3 describes the method for processing data streams and implementation details. Finally,
Section 4 describes the submission process for your assignment.

2 Language
The LDI language is described by the triplet hP es , L, Φi, where P es is defined as the union of
the sets of instantaneous event predicates P e and state event predicates P s ,

L = {and, or, start, end, tnot, ∼> , union, intersection, minus}

is defined as the set of operators of the language, and Φ as the set resulting from the union of
the sets of types Φ• and Φ− . The types in the set Φ• describe instantaneous events (true at time
points), while the types in the set Φ− describe events with duration (true over time intervals).
The language of the assignment has two versions. In the first version, which is mandatory,
the predicates of the language (P es ) have no arguments. In the second version, the predicates
also have arguments. The second version is optional. Implementing the second version gives

1
a +20% bonus to the course grade. The presentation of the assignment below uses the second
version as it is a generalization of the first.

2.1 Grammar
The sets Φ• and Φ− contain all the types of the language. Given a set P es , the types of the LDI
language are defined as follows:

φ := φ• | φ−
φ• := P e (a1 , . . . , ak ) | φ• or φ• | φ• and [[tnot]]φ• ||[start, end]φ−
φ− = P s (a1 , . . . , ak ) | φ• ∼> φ•
| φ− [union, intersection, minus] φ−

where [] denotes the choice of one element (e.g., from [start,end] one may choose only start or
end), [[]] denotes an optional element, and a1 , ..., ak are arguments.

2.2 Semantics
We assume that time is discrete and represented by the natural numbers T = N, which are
ordered by the relation 0 <0 . For the sets of types Φ• and Φ− , we define the model M =
hT, I, V • , V − i, where V • : Φ• → 2T and V − : Φ− → 2I are interpretation functions, and
I = {[ts, te] : ts < te and ts, te ∈ T } ∪ {[ts, ∞) : ts ∈ T } is the set of allowed intervals.
Intervals of the form [ts, te] indicate that an event became true at time ts and stopped being true
at time te, while intervals of the form [ts, ∞) indicate that an event becomes true at time ts and
continues to be true forever.
For easier readability, the following will use the concise forms of bounded quantifiers, that
is,
∀<z
>z1 x (...) corresponds to
2
∀x (x > z1 ∧ x < z2 ) → (...)
and
∃<z
>z1 x (...)
2
corresponds to ∃x (x > z1 ∧ x < z2 ) ∧ (...)
Given a model M , the value of a type ϕ ∈ Φ• at a time t ∈ T (in symbols M, t |= ϕ) is
computed according to the following rules:

• M, t |= P e (a1 , ..., an ) iff t ∈ V • (P e (a1 , ..., an )).

• M, t |= ¬ϕ iff M, t 6|= ϕ.

• M, t |= ϕ [and, or] ψ iff M, t |= ϕ [and, or] M, t |= ψ.

• M, t |= start(ϕ) iff ∃te. M, [t, te] |= ϕ or M, [t, ∞) |= ϕ, where M, [t, te] |= ϕ denotes
the value of a type ϕ ∈ Φ− over an interval [t, te] as defined below.

• M, t |= end(ϕ) iff ∃ts. M, [ts, t] |= ϕ.

Given a model M , the value of a type ϕ ∈ Φ− over an interval [ts, te] ∈ I (in symbols
M, [ts, te] |= ϕ) is computed according to the following rules:

• M, i |= P s (a1 , ..., an ) iff i ∈ V − (P s (a1 , ..., an )).

2
 • M, [ts, te] |= ϕ ∼> ψ iff M, ts |= ϕ and M, te |= ψ ∧ ¬ϕ and ∀<te
>ts t. M, t 6|= ψ ∧ ¬ϕ and
<ts 0 0 <ts 0 0
∀ ts . M, ts |= ϕ → ∃ts0 te . M, te |= ψ ∧ ¬ϕ.
Therefore, ϕ ∼> ψ holds for the non-overlapping maximal intervals that start at the earliest
time ts where ϕ is true and end at the earliest time te where ψ is true and ϕ is not.

• M, [ts, ∞) |= ϕ ∼> ψ iff M, ts |= ϕ and ∀>ts t. M, t 6|= ψ ∧ ¬ϕ and ∀<ts ts0 . M, ts0 |=
0 0
ϕ → ∃<ts
>ts0 te . M, te |= ψ ∧ ¬ϕ.

Therefore, a type ϕ ∼> ψ can hold forever if there is no time after ts at which ψ ∧ ¬ϕ is
satisfied. For simplicity, intervals open to infinity will not be considered further below, as
the semantics are defined similarly.

• M, [ts, te] |= ϕ union ψ iff

– there exists a sequence of size k > 1 of intervals i1 , ..., ik ∈ I where ik = [tsk , tek ],
ts = ts1 and te = tek such that:
1. ∀α ∈ [1, k − 1] : teα ∈ iα+1 , tsα < tsα+1 , teα < teα+1
2. ∀β ∈ [1, k] : M, [tsβ , teβ ] |= ϕ or M, [tsβ , teβ ] |= ψ
3. @iγ = [tsγ , teγ ] ∈ I − {i1 , ..., ik } where M, [tsγ , teγ ] |= ϕ or M, [tsγ , teγ ] |= ψ
and ts1 ∈ iγ or tek ∈ iγ
– or, M, [ts, te] |= ϕ or M, [ts, te] |= ψ and @iγ = [tsγ , teγ ] ∈ I − {[ts, te]} where
M, [tsγ , teγ ] |= ϕ or M, [tsγ , teγ ] |= ψ and ts ∈ iγ or te ∈ iγ .

For a sequence of intervals, conditions (1) and (2) ensure that the intervals where the type
ϕ or the type ψ hold, and which overlap or are adjacent, will be merged, while condition
(3) ensures that the resulting interval is maximal. In the case of a single interval, these
conditions ensure that in the interval [ts, te] the type ϕ or the type ψ holds, and that the
interval [ts, te] is maximal. In simple terms, the temporal union ϕ union ψ holds in the
intervals where at least one of the types ϕ or ψ holds.

• M, [ts, te] |= ϕ minus ψ iff ∃[ts0 , te0 ] ∈ I where M, [ts0 , te0 ] |= ϕ, [ts, te] ⊆ [ts0 , te0 ] (i.e.,
[ts, te] is a subinterval of [ts0 , te0 ]), ∀[tsψ , teψ ] ∈ I where M, [tsψ , teψ ] |= ψ, [ts, te] ∩
[tsψ , teψ ] = ∅ and finally [ts, te] is maximal. In simple terms, the temporal difference of
the types ϕ, ψ holds in the maximal subintervals of the intervals where ϕ holds but ψ does
not.

• M, [ts, te] |= ϕ intersection ψ iff ∃[tsϕ , teϕ ], [tsψ , teψ ] ∈ I where M, [tsϕ , teϕ ] |= ϕ,
M, [tsψ , teψ ] |= ψ and ∃[ts, te] ∈ I where [ts, te] ⊆ [tsϕ , teϕ ], [ts, te] ⊆ [tsψ , teψ ] and
[ts, te] is maximal. In other words, the temporal intersection of two types in Φ− holds in
the intervals where both types hold.

An example of union, intersection, and difference of intervals is shown in the following

figure.

3
 Figure 2: Example of union
(t), intersection (u), and difference (\) of intervals.

3 System Implementation
The system you will implement should support the following. It should read and convert to
executable Prolog code, event definitions written in the LDI language. It should compute a valid
processing order of the user definitions. It should read and gradually load timestamped events
of a specific form from an input file. It should use a temporal query mechanism over windows,
as defined below. Finally, it should write the event detections to an output file. Details are given
below.

3.1 Definitions file

The system you will implement should be able to accept as input a definitions.ldi file with event
definitions written in the following form.

% input event declarations

input_event_declaration(event_name1(arg,...,arg)).
...
input_event_declaration(event_nameK(arg,...,arg)).
% event definitions
event_def event_name1(arg,...,arg) := instant_formula1.
...
event_def event_nameL(arg,...,arg) := instant_formulaL.
% state definitions
state_def state_name1(arg1,...,arg) := interval_formula1.
...
state_def state_nameJ(arg,...,arg) := interval_formulaJ.

In the above template, the file starts with the declaration of input events. For example, such
a declaration could be the following.

% input event declarations

input_event_declaration(turns_on(_Person,_Device)).
input_event_declaration(turns_off(_Person,_Device)).
input_event_declaration(picks(_Person,_Item)).
input_event_declaration(drops(_Person,_Item)).

4
 In this way, we declare to the system that its input will have events of the above form,
e.g. turns-on(bob, stove). Next, the definitions.ldi file has a sequence of instantaneous event
(events) and state event (states) definitions. An event definition consists of the type of definition,
the name of the event being defined, and the description of the conditions under which it holds.
The conditions are written using types Φ• and Φ− of the LDI language for instantaneous events
and state events respectively. For example, a definition of an instantaneous event could be the
following:

event_def picks_and_drops(Person, Item) :=

picks(Person, Item) and drops(Person, Item).

According to the semantics of LDI, picks-and-drops(Person) holds if the events picks(Per-

son,Item) and drops(Person,Item) occur at the same time point. The conditions are written using
types Φ• of the LDI language. Next, a definition of a state event could be the following

state_def powered_on(Device) :=
turns_on(PersonA, Device) �> turns_off(PersonB, Device).

The above holds for the intervals that start when someone turns on a device, and end at the
time someone turns off the device.

3.2 Hierarchies
An event may appear in the definition of another event if it has been defined, or is an input event.
For the correct application of the rules over the input stream and to achieve processing without
unnecessary computations, it is required to find a valid processing order. This requires finding
the dependencies between event definitions. An event A depends on an event B if B appears in
the definition of A. We assume that the user always provides event definitions without cyclic
dependencies. Therefore, since we have no cycles, a valid processing order could be computed
by performing a topological sort on the event definitions. For example, input events have level
0, picks-and-drops has level 1, powered-on has level 1. To perform topological sorting, you
could create a predicate level(EventName, Level) which takes the name of an event and
returns its level.

3.3 Input format

Your system should read and gradually load events from a stream.input file, each time up to the
time point of the current query (defined below). The stream.input should have the following
form.

event(input_event_name1(arg,...,arg),t1).
event(input_event_name2(arg,...,arg),t1).
event(input_event_name1(arg,...,arg),t2).
...

Each line contains a Prolog fact event, with two arguments. The first argument contains an
event, and the second contains a time point. Thus, stream.input contains the sorted input events
which are given as input to your system and have been declared in definitions.ldi.

5
3.4 Temporal window mechanism
Your system should perform recognition of complex events by making temporal queries at spe-
cific time points tq . At each temporal query, your system should: (a) load all input events that
are true at times less than or equal to tq (b) apply all definitions given as input, and (c) print to an
output file the time points or intervals at which instantaneous events or state events occur. The
distance between two consecutive time points tqi and tqi+1 at which queries are made should be
equal to step = tqi+1 − tqi . The step ∈ N+ is a parameter given by the user.
Since it is impossible to continuously load new events into your system's knowledge base1 ,
the temporal queries will be applied over a window of the input event stream. By window, we
mean the set of input events that have occurred in the interval (tq − ω, tq ] where ω ∈ N+ is the
window size and ω ≥ step. The ω is also a parameter that the user must provide. Input events
outside the window should be deleted from the knowledge base.
Your system should implement a mechanism for storing results that span more than one
window, so as to maintain the correctness of its results.

Figure 3: Example of
temporal queries at times tq (left) and tq+1 (right) with ω = step

In the above figure, at the temporal query at time tq , the type a ∼> b holds in the intervals
[t1, t2] and [t3, ∞). As time progresses and we make a new query at time tq+1 , the events that
occurred before tq+1 − ω will be deleted due to the window mechanism. To correctly detect
the interval [t3, t4], the system must have retained all necessary information from the previous
query at time tq , i.e., the interval [t3, ∞).

3.5 Output file

Your system should, for each detection, print a result line to an output file. More specifically, it
should have the following form.

event(output_event_name1(arg,...,arg),t1).
event(output_event_name1(arg,...,arg),t2).
state(output_state_name1(arg,...,arg),[t1,t2]).
event(output_event_name1(arg,...,arg),t3).
state(output_state_name2(arg,...,arg),[t3,inf]).
...

The output does not need to be sorted.

4 Deliverable
The assignment can be implemented either by two people or by one person. You must submit a
zip file with:
1
Memory is not infinite.

6
 • all Prolog files,

• a readme (txt) with execution instructions,

• a bash script that runs an example of your choice,

• and a documentation file describing your implementation.

In the case of a group assignment, the readme must include the names and sdi of both members.
Submission in any case will be done by one person via eclass. The deadline for the assignment
will be the same as the day of the course exam (+10 days late submission without penalty).
In the first lecture after the Easter break (28/4), there will be a continuation of the assignment
presentation, focusing specifically on the code skeleton that will be provided and on which you
should base your implementation. The assignment will also have an oral examination on a date
to be determined.

References
[1] Kafalı Ö, Romero AE, Stathis K. Agent-oriented activity recognition in the event calcu-
lus: An application for diabetic patients. Computational Intelligence. 2017; 33: 899–925.
https://doi.org/10.1111/coin.12121

[2] Manolis Pitsikalis, Alexander Artikis, Richard Dreo, Cyril Ray, Elena Camossi, and Anne-
Laure Jousselme. 2019. Composite Event Recognition for Maritime Monitoring. In Pro-
ceedings of the 13th ACM International Conference on Distributed and Event-based Sys-
tems (DEBS ’19). Association for Computing Machinery, New York, NY, USA, 163–174.
https://doi.org/10.1145/3328905.3329762