EVENT LIFETIME CALCULATION BASED ON TEMPORAL
RELATIONSHIPS
Karen Walzer, Thomas Heinze and Anja Klein
SAP Research, CEC Dresden, Chemnitzer Strasse, Dresden, Germany
Keywords:
Rete algorithm, Rule-based systems, Event processing, Garbage collection.
Abstract:
In the last decade, the detection and processing of complex events has increasingly gained importance, since it
allows an immediate reaction to changes to instantly adapt business processes to varying situations. However,
currently there is a discrepancy in tools available for modelling constraints on business processes, mainly
rule-based systems, and those providing complex event processing.
This paper deals with the challenge of identifying unneeded events in rule-based systems in order to delete
them to save memory to enable event processing. We adapt an existing approach of lifetime calculation to
suit interval-based semantics for event timestamps. In a subsequent validation of our concepts, we were able
to demonstrate that they lead to improved event processing capabilities compared to a traditional rule-based
system.
1 INTRODUCTION
Whereas rule-based systems are currently used to
model integrity constraints and conditions on business
processes, they are not used to define and detect com-
plex events. Instead complex event processing sys-
tems are used for this purpose. As a result, it is prefer-
able that rule-based systems used to define business
processes also facilitate the definition and processing
of complex events.
An event represents a change in state of a certain
object of the world, it is an “occurrence of signifi-
cance in a system” (Luckham, 2002). Complex event
processing performs a set of operations on event data
in order to detect certain logical, temporal or causal
combinations of single events in this data. The com-
plex events of interest are defined in a description lan-
guage and detected by a pattern matching mechanism
such as finite state automata (S´anchez et al., 2005).
On an occurrence of a specified event pattern, an ac-
tion such as the creation of a complex event is per-
formed. Rule-based systems (RBS) describe knowl-
edge in the form of facts and if-then rules. A rule
expresses that if a condition is satisfied, then an ac-
tion is executed. The Rete algorithm (Forgy, 1982)
The research leading to these results has received fund-
ing from the European Community’s Seventh Framework
Programme (FP7/2007-2013) under grant agreement n
224282.
is commonly used in rule-based systems to perform
pattern matching, matching a set of facts against a set
of rules. It does not delete events or partial results
and has no means of determining when events can be
discarded besides a manual deletion. Since events are
not manually deleted, this is unsuitable for complex
event processing. This paper addresses this problem
by making the following contributions:
We define when an event can be considered as be-
ing unneeded and how this influences its lifetime.
We extend an existing lifetime calculation (Teo-
dosiu and Pollak, 1992) to suit interval-based
timestamp semantics.
The next section presents our approach to deter-
mine the lifetime of an event by its constraint satisfi-
ability. After this, related work is outlined. In Sect.
4, we discuss our evaluation. Finally Sect. 5 summa-
rizes our work.
2 LIFETIME CALCULATION
In this section, after giving same basic definitions,
the our temporal operators and the lifetime calcula-
tion (Teodosiu and Pollak, 1992) we base our work
on are briefly introduced. Then, our extension of this
calculation for interval-based timestamp semantics is
described.
269
Walzer K., Heinze T. and Klein A. (2009).
EVENT LIFETIME CALCULATION BASED ON TEMPORAL RELATIONSHIPS.
In Proceedings of the International Conference on Knowledge Engineering and Ontology Development, pages 269-274
DOI: 10.5220/0002305502690274
Copyright
c
SciTePress
2.1 Definitions
We will define the terms event, instantaneous and
complex event, needed and unneeded event in the fol-
lowing as a foundation of our work.
Let D be a set of atomic values where atomic
values are primitive or complex data types, such as
strings or records. Let T = (T;) be an ordered time
domain. Then, let I := {[t
s
,t
e
] T × T|t
s
t
e
} be a
set of time intervals with t
s
as start and t
e
as the end
time-point of the interval. Then, let a set of events
be defined as E := {(k
1
, .., k
n
,t
s
,t
e
)|k
i
D, [t
s
,t
e
] I}.
That means we use interval-based timestamp seman-
tics for events. Events can have a duration. In con-
trast, when using time-point semantics eventsonly oc-
cur in a time-point.
Instantaneous events are events with a duration
of zero, i.e. t
s
= t
e
. Complex events are ab-
stractions of single or complex events. Let C :=
{(e
1
, .., e
n
, e
n+1
, )|e
i
E, C E be the set of complex
events. They can have a duration greater zero, i.e.
t
s
t
e
. We define an event to be needed as long as it
can contribute to any matches in the future. All other
events are unneeded. An event’s lifetime τ states the
time that an event is needed. An event only needs to
be stored for its lifetime. If it is stored longer, it does
not contribute to any further matches, but just blocks
memory.
2.2 Temporal Operators in Rete
We base our temporal operators on the work of Allen
(Allen, 1983) who defined thirteen possible opera-
tors to describe the relationships between two time
intervals. We enhanced these operators by allowing
an operator-specific number of parameters denoting
quantitative time constraints. Table 1 states the op-
erators for events e
i
and e
j
(first column) and their
possible parameter constellations (top) with the inter-
pretation of the parameters (table entries). The func-
tion d(t
1
, t
2
) = t
2
t
1
denotes the difference of two
timestamps t
1
and t
2
.
2.3 Teodosiu and Pollak’s Calculation
Teodosiu and Pollak (Teodosiu and Pollak, 1992) al-
low the specification of time intervals [α, β] that de-
fine the time an event should occur with respect to
another event. For instance, e
2
in [e
1
+ α, e
1
+ β] de-
notes that event e
2
should occur between α and β time
units after event e
1
. Negative values for α or β denote
that an event should occur a specified amount of time
units before the other event. By calculating the depen-
dency matrix of an event’s temporal constraints, it is
possible to determine its lifetime. They define a tem-
poral distance d
e
i
,e
j
as the range of possible values
for the difference t
e
j
t
e
i
between the absolute arrival
times of two events e
i
and e
j
. These intervals can be
entered in a matrix whose closure leads to a temporal
dependency matrix D
0
R
2
n×n
which can be used to
calculate an event’s lifetime.
2.4 Extension to Intervals
Since we use interval-based semantics for event
timestamp definition, we distinguish two cases ac-
cording to what information is available to us: 1) ei-
ther events arrive at their start time-point, e.g. repre-
senting the initiation of processes of a certain duration
or 2) they arrive at their end time-point in our RBS. In
the first case, they can be discarded once they do not
meet their start time-point constraints. In the second
case, constraints concerning its end time-point need
to be considered .
Next, we provide the calculations of an event’s
lifetime for Allen’s operators for each of these two
cases.
2.4.1 Bounds for Allen’s Operators
Allen’s operators define constraints on the relation of
the start and end time-points of two events. We de-
fine d
ls
e
i
,e
j
to be a lower bound on an event start time-
point, d
us
e
i
,e
j
an upper bound on a start time-point, d
le
e
i
,e
j
a lower bound on an end time-point, and d
ue
e
i
,e
j
an up-
per bound on an end time-point. In the following, we
explain how the upper and lower bounds can be deter-
mined for the relative temporal operators.
Events Arriving at their Start Time-point. Using
the operators, the upper bounds d
ue
e
i
,e
j
of the temporal
distance of an event e
i
s start time-point used in an
operator with event e
j
, both events arriving at their
start time-points, can be estimated as follows based
on their temporal constraints:
d
us
e
i
,e
j
=
0 if t
s
e
i
= t
s
e
j
if t
s
e
i
> t
s
e
j
otherwise
(1)
That means, if the start time t
s
e
i
of an event e
i
is de-
fined to be greater than the start time t
s
e
j
of e
j
as e. g.
for the during operator, then event e
j
should have al-
ready be arrived at an indeterminate time-point in the
past to lead to a match with e
i
. Thus, the upper bound
of e
i
, e
j
is , after matching with all existing events,
event e
i
does not have to be kept, since no future
matches can take place. If both events e
i
and e
j
are
KEOD 2009 - International Conference on Knowledge Engineering and Ontology Development
270
Table 1: Allen’s operators (Ops) and their parametrization (P).
Ops \ P Allen’s Definition a a, b a1, a2, b1, b2
meets d(t
e
e
i
,t
s
e
j
) = 0 0 < d(t
e
e
i
,t
s
e
j
) a - -
d(t
s
e
i
,t
s
e
j
) > 0
met-by d(t
e
e
j
,t
s
e
i
) = 0 0 < d(t
e
e
j
,t
s
e
i
) a - -
d(t
s
e
j
,t
s
e
i
) > 0
equals d(t
s
e
i
,t
s
e
j
) = 0 |d(t
s
e
i
,t
s
e
j
)| a |d(t
s
e
i
,t
s
e
j
)| a -
d(t
e
e
i
,t
e
e
j
) = 0 d(t
e
e
i
,t
e
e
j
) a d(t
e
e
i
,t
e
e
j
) b
before 0 < d(t
e
e
i
,t
s
e
j
) d(t
e
e
i
,t
s
e
j
) = a a d(t
e
e
i
,t
s
e
j
) b -
after 0 < d(t
e
e
j
,t
s
e
i
) d(t
e
e
j
,t
s
e
i
) = a a d(t
e
e
j
,t
s
e
i
) b -
during 0 < d(t
s
e
j
,t
s
e
i
) d(t
s
e
j
,t
s
e
i
) = a d(t
s
e
j
,t
s
e
i
) = a a1 d(t
s
e
j
,t
s
e
i
) a2
0 < d(t
e
e
i
,t
s
e
j
) d(t
e
e
i
,t
s
e
j
) = a d(t
e
e
i
,t
s
e
j
) = b b1 d(t
e
e
i
,t
s
e
j
) b2
contains 0 < d(t
s
e
i
,t
s
e
j
) d(t
s
e
i
,t
s
e
j
) = a d(t
s
e
i
,t
s
e
j
) = a a1 d(t
s
e
i
,t
s
e
j
) a2
0 < d(t
e
e
j
,t
s
e
i
) d(t
e
e
j
,t
s
e
i
) = a d(t
e
e
j
,t
s
e
i
) = b b1 d(t
e
e
j
,t
s
e
i
) b2
overlaps 0 < d(t
s
e
i
,t
s
e
j
) d(t
s
e
i
,t
s
e
j
) = a d(t
s
e
i
,t
s
e
j
) = a a1 d(t
s
e
i
,t
s
e
j
) a2
0 < d(t
e
e
i
,t
e
e
j
) d(t
e
e
i
,t
e
e
j
) = a d(t
e
e
i
,t
e
e
j
) = b b1 d(t
e
e
i
,t
e
e
j
) b2
overlapped- d(t
s
e
i
,t
s
e
j
) = 0 d(t
s
e
i
,t
s
e
j
) = a d(t
s
e
i
,t
s
e
j
) = a a1 d(t
s
e
i
,t
s
e
j
) a2
by d(t
e
e
i
,t
e
e
j
) = 0 d(t
e
e
i
,t
e
e
j
) = a d(t
e
e
i
,t
e
e
j
) = b b1 d(t
e
e
i
,t
e
e
j
) b2
starts d(t
s
e
i
,t
s
e
j
) = 0 d(t
s
e
i
,t
s
e
j
) = 0 d(t
s
e
i
,t
s
e
j
) = 0 d(t
s
e
i
,t
s
e
j
) a1
0 < d(t
e
e
i
,t
e
e
j
) d(t
e
e
i
,t
e
e
j
) = a a d(t
e
e
i
,t
e
e
j
) b b1 d(t
e
e
i
,t
e
e
j
) b2
started-by d(t
s
e
i
,t
s
e
j
) = 0 d(t
s
e
i
,t
s
e
j
) = 0 d(t
s
e
i
,t
s
e
j
) = 0 d(t
s
e
i
,t
s
e
j
) a1
0 < d(t
e
e
j
,t
e
e
i
) d(t
e
e
j
,t
e
e
i
) = a a d(t
e
e
j
,t
e
e
i
) b b1 d(t
e
e
j
,t
e
e
i
) b2
finishes d(t
e
e
i
,t
e
e
j
) = 0 d(t
e
e
i
,t
e
e
j
) = 0 d(t
e
e
i
,t
e
e
j
) = 0 a1 d(t
s
e
j
,t
s
e
i
) a2
0 < d(t
s
e
j
,t
s
e
i
) d(t
s
e
j
,t
s
e
i
) = a a d(t
s
e
j
,t
s
e
i
) b d(t
e
e
i
,t
e
e
j
) b1
finished-by d(t
e
e
i
,t
e
e
j
) = 0 d(t
e
e
i
,t
e
e
j
) = 0 d(t
e
e
i
,t
e
e
j
) = 0 a1 d(t
s
e
i
,t
s
e
j
) a2
0 < d(t
s
e
i
,t
s
e
j
) d(t
s
e
i
,t
s
e
j
) = a a d(t
s
e
i
,t
s
e
j
) b d(t
e
e
i
,t
e
e
j
) b1
required to have identical start times as e. g. for the
starts operator, they should arrive at the same time
unit, thus their upper bound is zero. Events have to
be kept for one time unit to ensure that all possible
matches take place, then they can be discarded. If the
start time t
s
e
i
of e
i
is required to be less than that of e
j
as e.g. for the containing operator, event e
i
has to be
kept, because matches with e
j
can still take place. In
this case it needs to be determined, if an event can be
discarded considering its end time-point. The upper
bounds d
ue
e
i
,e
j
of an event e
i
s end time-point used in
an operator with event e
j
, both events arriving at their
start time-points, can be estimated as follows:
d
ue
e
i
,e
j
=
0 if t
e
e
i
= t
e
e
j
t
e
e
i
= t
s
e
j
t
e
e
j
= t
s
e
i
(t
e
e
i
t
e
e
j
t
s
e
j
t
e
e
i
)
if t
e
e
i
> t
e
e
j
otherwise
(2)
Analogous to the calculation for start time-points, the
upper bound of events is zero if they need to have
equal end time-points as e.g. the nishes operator.
However, events also have an upper bound of zero
when their end time-points are required to be identical
with the start time-points of their matching partners as
e.g. for the meets operator. The same applies when
the start time-points of events are required to be equal
to the end time-points of matching partners as e. g.
for the met-by operator. Moreover, the upper bound
of an event’s end time-point is also zero, if its end
time-point is less than the matching event’s end time-
point, but it is greater than the matching event’s start
time-point as e. g. for the during operator. All these
three calculations leading to an upper bound of zero
can be explained by the fact that events are ordered
by their start timestamp. Thus in all three cases all
matching events should arrive at the same time unit
as the event ends or have already arrived before the
event’s end time-point. An upper bound of oc-
curs if the end time-point of an event is greater than
the end time-point of a matching event as e.g. for
the before operator, i.e. all matching events arrived at
some time in the past. Otherwise the upper bound is
infinite.
For eight of Allen’s operators, a restriction on the
start time-point is given, the events can be instantly
deleted after matching or be deleted after one time
unit. The other five operators do not set any restric-
tions on an event’s end time-point and hence result in
an unlimited upper bound, since any of the events e
j
EVENT LIFETIME CALCULATION BASED ON TEMPORAL RELATIONSHIPS
271
occurring after e
i
could lead to a match. The lower
bounds match the upper bounds.
For all operators with an unlimited upper bound
on an event’sstart time-point, the bounds on end time-
points of the event can be used. Only for the before
operator no bounds can be determined using a combi-
nation of bounds on start and end time-points.
Events Arriving at their End Time-point. When
events arrive at their end time-points, these time-
points need to be considered for lifetime calculation.
In this case, the upper bound d
ue
e
i
,e
j
of an event e
i
s end
time-point with respect to an event e
j
, both events ar-
riving at their end time-points, can be estimated as
follows:
d
ue
e
i
,e
j
=
0 if t
e
e
i
= t
e
e
j
if t
e
e
i
> t
e
e
j
otherwise
(3)
Similar to the upper bounds of the start timestamps,
if the end timestamp t
e
e
i
of event e
i
is greater than the
end timestamp t
e
e
j
of event e
j
as e.g. for the after
operator, the upper bound is , all matching events
should have already arrived and the event could there-
fore be discarded. If the end time-points of two events
are required to be equal, the upper bound is zero as
e. g. for the finishes operator, events can be discarded
after one time unit, since all matching events should
arrive simultaneously. However, if none of these two
conditions applies as e. g. for the meets operator, no
other restriction can be made, since it is always pos-
sible that events with a higher end time-point arrive
later which fulfil all start time-point constraints. As
a result, there is a much higher number of operators
for which no upper bound can be defined compared
to events arriving at their start time-point. One way to
deal with this problem is the definition of a maximum
event lifetime.
2.4.2 Bounds on Parametrized Operators
Previously, we introduced bounds for Allen’s original
qualitative operators. Now, the bounds for our quan-
titative operators are stated in Table 2. The opera-
tors are given with their parameters, the bounds and
their reasons. The lifetimes of events e
n+1
or tuples
(e
1
, ..., e
n
) can be calculated analogous to the method
suggested by Teodosiu and Pollak. Again, a distinc-
tion has to be made for events arriving at their start
time-point and those arriving at their end time-point.
In the first case, the lower and upper bounds for
temporal distances d
ls
e
i
,e
j
, d
us
e
i
,e
j
based on the operators
an event is used in can be calculated for Allen’s oper-
ators as described earlier or by taking the end bounds
from Table 2 for the parameterized operators. These
bounds are then used to calculate an event’s upper
bounds based on all its relationships. Whenever no
bound is defined on an event’s start time-point, the
bounds on its end time-point can be used.
In the second case, lower and upper bounds for
temporal distances d
le
e
i
,e
j
, d
ue
e
i
,e
j
can be calculated for
Allen’s operators as described earlier or by taking the
end bounds from Table 2 for parameterized operators.
From these times, the lifetime can be determined for
all events or tuples as suggested by Teodosiu.
The constraints an event has to fulfil depend on
the complex event definitions it occurs in. The cal-
culation of an event’s lifetime is done based on these
constraints. Therefore, the lifetime calculation can be
done only once, when a rule defining a complex event
is added to an RBS or updated in an RBS, e. g. during
initialisation phase of an RBS, and then be stored to
avoid recalculation. Thereby the lifetime of an event
and the lifetime of a tuple arriving at a node can be
stored locally at this node. Then, a garbage collection
mechanism can access this time whenever needed in
order to discard unneeded events from this node.
3 RELATED WORK
Next, we describe ideas of garbage collection and rel-
ative constraints in the Rete algorithm.
Berstel (Berstel, 2002) described the adaptations
of the Rete algorithm used in ILOG JRules. He used
time-point semantics and before and after operators
are incorporated into Rete. The event concept is simi-
lar to ours, but distinguishes itself by using time-point
instead of interval-based semantics.
TPS (Maloof and Kochut, 1993) is a traditional
production system based on the Rete algorithm which
is extended with temporal knowledge by storing past
and developing events in a temporal database. An
interval-based timestamp semantics is used. The sys-
tem supports detection of events occurring during, be-
fore or after other events. However, operator seman-
tics as well as conceptual details remain unclear.
HALO (Herzeel et al., 2007) is a logic-based
pointcut language based on an extension of the Rete
algorithm. A garbage collection mechanism deals
with facts that are relevant only for a single time step
or a certain time. Facts that are irrelevant from the
start are not dealt with. The garbage collection is
performed as part of a node’s functionality, not by
a separate mechanism. However, the paper does not
explain in detail, how this garbage collection mecha-
nism works or how it is determined if an element can
be removed, just an example is given.
KEOD 2009 - International Conference on Knowledge Engineering and Ontology Development
272
Table 2: Lower and upper bounds of an event based on its usage within a parameterized operator.
Start bounds End bounds
Operator d
ls
e
i
,e
j
d
us
e
i
,e
j
d
le
e
i
,e
j
d
ue
e
i
,e
j
Reason
e
i
is equal to e
j
(a)
a a a a |d(t
s
e
i
,t
s
e
j
)| a
|d(t
e
e
i
,t
e
e
j
)| a
e
i
is equal to e
j
(a, b)
a a b b |d(t
s
e
i
,t
s
e
j
)| a
|d(t
e
e
i
,t
e
e
j
)| b
e
i
starts e
j
(a)
0 0 a a d(t
s
e
i
,t
s
e
j
) = 0
|d(t
e
e
i
,t
e
e
j
)| = a
e
i
starts e
j
(a, b)
0 0 b b d(t
s
e
i
,t
s
e
j
) = 0
a d(t
e
e
i
,t
e
e
j
) b
e
i
starts e
j
(a
1
, b
1
, b
2
)
a
1
a
1
b
2
b
2
d(t
s
e
i
,t
s
e
j
) a
1
b
1
d(t
e
e
i
,t
e
e
j
) b
2
e
i
during e
j
(a)
a a a a d(t
s
e
i
,t
s
e
j
) = a
|d(t
e
e
i
,t
e
e
j
)| = a
e
i
during e
j
(a, b)
a a b b d(t
s
e
i
,t
s
e
j
) = a
a d(t
e
e
i
,t
e
e
j
) = b
e
i
during e
j
(a
1
, a
2
, b
1
, b
2
)
a
2
a
2
b
2
b
2
a
1
d(t
e
e
i
,t
e
e
j
) a
2
b
1
d(t
e
e
i
,t
e
e
j
) b
2
e
i
finishes e
j
(a)
a a 0 0 d(t
s
e
i
,t
s
e
j
) = a
|d(t
e
e
i
,t
e
e
j
)| = 0
e
i
finishes e
j
(a, b)
b b 0 0 a d(t
s
e
i
,t
s
e
j
) b
d(t
e
e
i
,t
e
e
j
) = 0
e
i
finishes e
j
(a
1
, b
1
, b
2
)
b
2
b
2
a
1
a
1
b
1
d(t
e
e
i
,t
e
e
j
) b
2
d(t
e
e
i
,t
e
e
j
) a
1
e
i
overlaps e
j
(a)
a a a a d(t
s
e
i
,t
s
e
j
) = a
|d(t
e
e
i
,t
e
e
j
)| = a
e
i
overlaps e
j
(a, b)
a a b b d(t
s
e
i
,t
s
e
j
) = a
d(t
e
e
i
,t
e
e
j
) = b
e
i
overlaps e
j
(a
1
, b
1
, b
2
)
a
2
a
2
b
2
b
2
a
1
d(t
e
e
i
,t
e
e
j
) a
2
b
1
d(t
e
e
i
,t
e
e
j
) b
2
e
i
meets e
j
(a) t
e
e
i
t
s
e
i
a a |d(t
e
e
i
,t
s
e
j
)| a
e
i
before e
j
(a) a a d(t
e
e
i
,t
s
e
j
) = a
e
i
before e
j
(a, b) b b a d(t
e
e
i
,t
s
e
j
) b
4 EVALUATION
We realized our proposed concepts for relative tem-
poral constraints and garbage collection in Rete as an
extension of the rule-based system JBoss Drools (Red
Hat, Inc., 2007) version 4.0.3.
In our non-functional validation, we studied re-
sponse times and memory usage of our system using
our operators with and without garbage collection as
well as a work-around without garbage collection us-
ing selections instead of our operators. We conducted
all our experiments on a Dual Core AMD Opteron
CPU (2.4 GHz) with 3.6 GB RAM running Linux
2.6.22. Here, we will show the results for the after
operator exemplary.
We used two events of type EventA and EventB
with attributes x, start and end denoting an event
identifier and an event’s start and end time-point. All
events have a duration of two. All attributes have in-
teger values. We used a rule that reacts to all events
of type EventB that occur between 1 and 2 time units
after an event of type EventA.
For the memory tests, we inserted an EventA and
20.000 EventB at each time unit observing 20 time-
points ( Figure 1 (a)). Then, we waited ve seconds
and advised the Java garbage collector explicitly to
become active to ensure deterministic results. We no-
tice that the memory requirements are lower when
using the garbage collection compared to not using
garbage collection.
EVENT LIFETIME CALCULATION BASED ON TEMPORAL RELATIONSHIPS
273
0
50
100
150
200
250
0 5 10 15 20
Memory consumption in MB
Time
Work-around After operator w/ GC After operator w/o GC
(a) Memory consumption
0
100
200
300
400
500
600
700
800
900
0 100 200 300 400 500 600
Response time per iteration in msec
Iteration
After operator w/o GC After operator w/ GC Work-around
(b) Response times per iteration
Figure 1: Comparison of memory consumption and re-
sponse times per iteration for detection of the after operator;
w/ GC with garbage collection, w/o GC – without garbage
collection.
We measured response time of our system analo-
gous using the same rule as above. We advanced the
time of our pseudo clock 5 times counting 100 itera-
tions each time, inserting 1.000 events of each type in
each iteration. Then, we divided the resulting time by
the number of iterations performed at this measure-
ment to determine the average response time (Figure1
(b)). We notice that using garbage collection leads
to a constant response time whereas otherwise a con-
tinuously increasing response time can be observed,
since the number of events increases over time.
5 CONCLUSIONS
We presented a method of determining if events can
still contribute to future matches based on the satis-
fiability of their temporal constraints. Our proposed
method leads to an exact calculation, improved mem-
ory consumption and response time. Nevertheless,
improvements are still possible. For instance, node
sharing could be studied which implies that a node
condition occurs in several rules, thus having differ-
ent temporal constraints.
REFERENCES
Allen, J. F. (1983). Maintaining Knowledge about Temporal
Intervals. Communications of the ACM Press, 26:832–
843.
Berstel, B. (2002). Extending the RETE Algorithm for
Event Management. In TIME ’02, page 49, Washing-
ton, DC, USA. IEEE Computer Society.
Forgy, C. (1982). Rete: A Fast Algorithm for the Many
Patterns/Many Objects Match Problem. Artificial In-
telligence, 19(1):17–37.
Herzeel, C., Gybels, K., and Costanza, P. (2007). Escaping
with Future Variables in HALO. In Sokolsky, O. and
Tasiran, S., editors, RV ’07, volume 4839 of LNCS,
pages 51–62. Springer.
Luckham, D. (2002). The Power of Events: An Introduc-
tion to Complex Event Processing in Distributed En-
terprise Systems. Addison Wesley Professional.
Maloof, M. A. and Kochut, K. (1993). Modifying Rete to
Reason Temporally. In ICTAI, pages 472–473.
Red Hat, Inc. (2007). JBoss Drools. Online.
http://labs.jboss.com/drools/.
S´anchez, C., Slanina, M., Sipma, H. B., and Manna, Z.
(2005). Expressive Completeness of an Event-Pattern
Reactive Programming Language. In FORTE, pages
529–532.
Teodosiu, D. and Pollak, G. (1992). Discarding Unused
Temporal Information in a Production System. In
CIKM ’92, pages 177–184.
KEOD 2009 - International Conference on Knowledge Engineering and Ontology Development
274