=Paper=
{{Paper
|id=Vol-2052/paper20
|storemode=property
|title=Towards A Simple Event Calculus for Run-Time Reasoning
|pdfUrl=https://ceur-ws.org/Vol-2052/paper20.pdf
|volume=Vol-2052
|authors=Christos Vlassopoulos,Alexander Artikis
|dblpUrl=https://dblp.org/rec/conf/commonsense/VlassopoulosA17
}}
==Towards A Simple Event Calculus for Run-Time Reasoning==
https://ceur-ws.org/Vol-2052/paper20.pdf
Towards A Simple Event Calculus for Run-Time Reasoning
Christos Vlassopoulos1,2 and Alexander Artikis3,1
1
Institute of Informatics and Telecommunications, NCSR “Demokritos”, Athens, Greece
2
Department of Informatics and Telecommunications, National and Kapodistrian University of Athens, Greece
3
Department of Maritime Studies, University of Piraeus, Greece
Abstract re-computations. A set of interval manipulation constructs
simplify CE definitions and improve reasoning efficiency.
The Event Calculus for Run-Time reasoning (RTEC) is An indexing mechanism makes RTEC robust to SDEs that
a logic programming implementation of the Event Calcu-
are irrelevant to the CEs we want to recognise and so RTEC
lus, designed to compute continuous narrative assimilation
queries on data streams. RTEC has been used for complex can operate without SDE filtering modules. Finally, a ‘win-
event recognition in various applications domains, such as dowing’ mechanism supports real-time CE recognition.
maritime monitoring, city transport management and human RTEC has been used for CE recognition in various ap-
activity recognition. The construction of the complex event plications domains, including human activity recognition
definitions has proven a time-consuming process, since it re- from video content, city transport management, and mar-
quires several interactions with domain experts (e.g. transport itime monitoring (Patroumpas et al. 2017). The construction
engineers). To address this issue, we present a simple lan- of CE definitions was performed manually, since annotated
guage for RTEC, with the aim of supporting people who are data were insufficient for employing machine learning tech-
not familiar with the Event Calculus or (logic) programming. niques. This was a time-consuming process that required
A compiler translates, in a process transparent to the user, a
several interactions with domain experts. To address this is-
specification in the simple language to an RTEC event de-
scription that may be subsequently used for continuous query sue, we have been developing a simpler language for RTEC,
computation. with the aim of supporting people who are not familiar with
the Event Calculus or (logic) programming. A compiler
translates, in a process transparent to the user, a specifica-
Introduction tion in the simpler language to an RTEC event description
Today’s organisations need to act upon high-velocity data that may be subsequently used for query computation.
streams in order to capitalise on opportunities and detect The remainder of the paper is structured as follows. First,
threats. Towards this, event recognition systems have been we present RTEC. Then, we discuss the simple language
particularly helpful, as they support the detection of ‘com- and illustrate its use through various examples. In the sec-
plex events’ (CE) of special significance, given streams of tion that follows, we describe the functionality of the com-
‘simple, derived events’ (SDE) arriving from various types piler that translates the statements of the simple language to
of sensor (Artikis et al. 2012). The ‘definition’ of a CE RTEC. Subsequently, we present the empirical evaluation of
imposes temporal and, possibly, atemporal constraints on our approach, and briefly discuss related and further work.
its subevents, i.e. SDEs or other CEs. In the maritime do-
main, for example, CE recognition systems have been used RTEC
to make sense of position streams emitted from thousands of The Event Calculus for Run-Time reasoning (RTEC) is
vessels, in order to detect, in real-time, suspicious and illegal a logic programming implementation of the Event Calcu-
activity that may have dire effects in the maritime ecosystem lus, designed to compute continuous narrative assimilation
and passenger safety. queries on data streams for complex event (CE) recognition.
Several CE recognition frameworks have been proposed, The time model is linear and includes integer time-points.
supporting data streams by means of various optimisation Following Prolog, variables start with an upper-case letter,
techniques (Cugola and Margara 2012; Bicocchi et al. 2014). while predicates and constants start with a lower-case let-
One such framework is the Event Calculus for Run-Time ter. Where F is a fluent—a property that is allowed to have
reasoning (RTEC), a logic programming implementation of different values at different points in time—the term F = V
the Event Calculus (Kowalski and Sergot 1986), designed to denotes that fluent F has value V . Boolean fluents are a
compute continuous narrative assimilation queries on data special case in which the possible values are true and false.
streams (Artikis, Sergot, and Paliouras 2015). RTEC in- Informally, F = V holds at a particular time-point if F = V
cludes novel implementation techniques for efficient CE has been initiated by an event at some earlier time-point, and
recognition. A form of caching stores the results of sub- not terminated by another event in the meantime.
computations in the computer memory to avoid unnecessary An event description in RTEC includes rules that define
Predicate Meaning
happensAt(E, T ) Event E occurs at time T
holdsAt(F = V, T ) The value of fluent F is V at time T
holdsFor(F = V, I) I is the list of the maximal intervals for which F = V holds continuously
initiatedAt(F = V, T ) At time T a period of time for which F = V is initiated
terminatedAt(F = V, T ) At time T a period of time for which F = V is terminated
union all(L, I ) I is the list of maximal intervals produced by the union of the lists of maximal
intervals of list L
intersect all(L, I ) I is the list of maximal intervals produced by the intersection of the lists of maximal
intervals of list L
relative complement all (I 0 , L, I ) I is the list of maximal intervals produced by the relative complement of the list of
maximal intervals I 0 with respect to every list of maximal intervals of list L
Table 1: Main predicates of RTEC.
the event instances with the use of the happensAt predi- • a possibly empty set of happensAt predicates expressing
cate, the effects of events with the use of the initiatedAt constraints on the (non-)occurrence of events;
and terminatedAt predicates, and the values of the fluents • a possibly empty set of holdsAt predicates expressing con-
with the use of the holdsAt and holdsFor predicates, as well straints on fluents; and
as other, possibly atemporal, constraints. Table 1 sum- • a possibly empty set of atemporal constraints.
marises the main predicates of RTEC. The code is available Consider the following example from human activity
at https://github.com/aartikis/RTEC. We rep- recognition on video content:
resent instantaneous SDEs and CEs by means of happensAt, initiatedAt(moving(P1 , P2 ) = true, T ) :−
while durative CEs are represented as fluents. The major- happensAt(start(walking(P1 ) = true), T ),
ity of CEs are durative and, therefore, in CE recognition the holdsAt(walking(P2 ) = true, T ),
task generally is to compute the maximal intervals for which holdsAt(close(P1 , P2 ) = true, T ).
a fluent expressing a CE has a particular value continuously.
Below, we discuss the representation of fluents, and present initiatedAt(moving(P1 , P2 ) = true, T ) :−
the way we compute their maximal intervals. happensAt(start(walking(P2 ) = true), T ),
holdsAt(walking(P1 ) = true, T ),
Fluents holdsAt(close(P1 , P2 ) = true, T ).
holdsFor(F = V, I) represents that I is the list of the max- initiatedAt(moving(P1 , P2 ) = true, T ) :−
happensAt(start(close(P1 , P2 ) = true), T ), (1)
imal intervals for which fluent F has value V continuously.
holdsAt(F = V, T ) represents that fluent F has value V at a holdsAt(walking(P1 ) = true, T ),
particular time-point T . holdsAt and holdsFor are defined in holdsAt(walking(P2 ) = true, T ).
such a way that, for any fluent F , holdsAt(F = V, T ) if and terminatedAt(moving(P1 , P2 ) = true, T ) :−
only if time-point T belongs to one of the maximal intervals happensAt(end(walking(P1 ) = true), T ).
of I for which holdsFor(F = V, I). Fluents in RTEC are terminatedAt(moving(P1 , P2 ) = true, T ) :−
of two kinds: simple and statically determined. We assume, happensAt(end(walking(P2 ) = true), T ).
without loss of generality, that these types are disjoint.
terminatedAt(moving(P1 , P2 ) = true, T ) :−
Simple fluents For a simple fluent F , F = V holds at a happensAt(end(close(P1 , P2 ) = true), T ).
time-point T if F = V has been initiated by an event at some walking is a durative SDE detected on video frames. (Re-
time-point earlier than T , and has not been terminated at call that SDEs are given as input to RTEC.) start(F = V )
some other time-point in the meantime. This is an imple- (resp. end(F = V )) is a built-in RTEC event taking place
mentation of the law of inertia. The time-points at which at each starting (ending) point of each maximal interval for
F = V is initiated are computed with the use of initiatedAt which F = V holds continuously. close(A, B ) = true when
rules, which have the following form (terminatedAt are de- the distance between tracked entities (people and/or objects)
fined similarly): A and B does not exceed some threshold of pixel positions.
initiatedAt(F = V, T ) :− The above formalisation states that P1 is moving with P2
happensAt(E, T ), when they are walking close to each other.
conditions[T ] Note that in this formulation of the Event Calculus,
terminatedAt(F = V, T ) does not necessarily imply that
The conditions[T ] set includes further constraints on time- F = V at T . Similarly, initiatedAt(F = V, T ) does not nec-
point T , expressed as follows: essarily imply that F 6= V at T .
I1 I1 I1
I2 I2 I2
time time time
(a) Union. (b) Intersection. (c) Relative Complement.
Figure 1: A visual illustration of the three interval manipulation constructs of RTEC. In this example, there are two input fluent
streams, I1 and I2 . The output of each interval manipulation construct is colored light blue.
To compute holdsFor(moving(P1 , P2 ) = true, I), fluent:
that is, to compute the maximal intervals for which holdsFor(moving(P1 , P2 ) = true, I ) :−
moving(P1 , P2 ) = true holds continuously, we find all holdsFor(walking(P1 ) = true, I1 ),
time-points Ts at which moving(P1 , P2 ) = true is initiated, holdsFor(walking(P2 ) = true, I2 ), (5)
and then, for each Ts , we compute the first time-point Te holdsFor(close(P1 , P2 ) = true, I3 ),
after Ts at which moving(P1 , P2 ) = true is ‘broken’. The intersect all([I1 , I2 , I3 ], I ).
time-points at which F = V is broken are computed as
follows: According to the above rule, the list I of maximal intervals
broken(F = V, Ts , T ) :− during which P1 is moving with P2 is computed by deter-
(2) mining the list I1 of maximal intervals during which P1 is
terminatedAt(F = V, Te ), Ts < Te ≤ T.
walking, the list I2 of maximal intervals during which P2 is
broken(F = V1 , Ts , T ) :− walking, the list I3 of maximal intervals during which P1 is
initiatedAt(F = V2 , Te ), Ts < Te ≤ T, (3) close to P2 , and then calculating the list I representing the
V1 6= V2 . intersections of the maximal intervals in I1 , I2 and I3 .
According to rule (3), if F = V2 is initiated at Te then effec- RTEC provides three interval manipulation constructs:
tively F = V1 is terminated at time Te , for all other possible union all, intersect all and relative complement all. These
values V1 of F . Rule (3) ensures, therefore, that a fluent are illustrated in Figure 1. The interval manipulation con-
cannot have more than one value at any time. We do not structs of RTEC support the following type of definition:
insist that a fluent must have a value at every time-point. In for all time-points T , F = V holds at T if and only if some
RTEC there is a difference between initiating a Boolean flu- Boolean combination of fluent-value pairs holds at T . For a
ent F = false and terminating F = true: the first implies, but wide range of fluents, this is a much more concise definition
is not implied by, the second. than the traditional style of Event Calculus representation,
Consider another example, this time from city transport i.e. identifying the various conditions under which the fluent
management. In this application domain, transport officials is initiated and terminated so that maximal intervals can then
are interested in computing the maximal intervals for which be computed using the domain-independent holdsFor. Com-
passenger density in buses and trams is high. This may indi- pare, e.g. the statically determined and simple fluent repre-
cate low passenger satisfaction, among others. Consider the sentations of moving in rules (5) and (1) respectively.
formalisation below:
Semantics
initiatedAt(passenger density(ID, VT ) = Val , T ) :− CE definitions in RTEC are (locally) stratified logic pro-
happensAt(passenger density change(ID, VT , Val ), T ). grams (Przymusinski 1987). We restrict attention to hierar-
(4) chical definitions, those where it is possible to define a func-
passenger density change is an SDE determined from sen- tion level that maps all fluent-values F = V and all events to
sor data. ID concerns the vehicle of type VT (bus, tram) the non-negative integers as follows. Events and statically
on which the sensors (video cameras, microphones) are determined fluent-values F = V of level 0 are those whose
happensAt and holdsFor definitions do not depend on any
mounted, while the value Val may be low , medium or high.
other events or fluents. In CE recognition, they represent the
Statically determined fluents In addition to the domain- input SDEs. There are no fluent-values F = V of simple flu-
independent definition of holdsFor, an event description may ents F in level 0. Events and simple fluent-values of level
include domain-specific holdsFor rules, used to define the n are defined in terms of at least one event or fluent-value
values of a fluent F in terms of the values of other fluents. of level n−1 and a possibly empty set of events and fluent-
We call such a fluent F statically determined. holdsFor rules values from levels lower than n−1. Statically determined
of this kind make use of interval manipulation constructs— fluent-values of level n are defined in terms of at least one
see the last three items of Table 1. Consider, e.g. moving fluent-value of level n−1 and a possibly empty set of fluent-
as in rules (1) but defined instead as a statically determined values from levels lower than n−1. Note that fluent-values
F = Vi and F = Vj for Vi 6=Vj could be mapped to different In addition to ‘happensAt’, ‘holdsAt’ is also omitted from
levels. For simplicity however, and without loss of general- the above statements, since after the first condition, con-
ity, a fluent F itself is either simple or statically determined straints on fluents are expected (recall that walking and
but not both. close are fluents). If more constraints on events were re-
quired, then these would have to be prefixed by ‘happens’.
A Simple Language The value of true Boolean fluents can also be omitted. To
Addressing an event recognition problem in RTEC requires make the above formalisation even more succinct, the last
knowledge of Prolog, familiarisation with the Event Calcu- three statements may be replaced by the following one:
lus in general, as well as understanding and memorisation terminate moving(P1 , P2 ) iff
of the syntactical details of RTEC in particular. In this sec- end walking(P1 ) or
tion, we present a simple Event Calculus dialect with a high- (8)
end walking(P2 ) or
level notation, abstracting away from technical details. This end close(P1 , P2 ).
simplified Event Calculus (SimplEC) aims at supporting do-
main experts, such as city transport engineers and maritime In datasets used for human activity recognition, there is
patrol officials, that are not familiar with (logic) program- no explicit information that a tracked entity is a person or an
ming. SimplEC is designed to resemble simple statements inanimate object. Therefore, in the activity definitions we try
in English, with some pseudo-code and mathematical ele- to deduce whether a tracked entity is a person or an object
ments. It does not contain obscure symbols like :-, or \+. given, among others, the detected SDEs. We defined the
Instead, it contains simple words like if, or, not, as well as the fluent person(P ) to have value true if P has been walking,
comma operator that indicates conjunction. There are also active, running or moving abruptly since P ‘appeared’, that
a few special tokens, like initiate that stem from the Event is, since P was first tracked:
Calculus. In what follows, we illustrate the use of SimplEC
initiate person(P ) iff
through a series of examples from three real-world applica-
tions. A full account of the SimplEC statements for all these (start walking(P ) or
start active(P ) or
applications, as well as the grammar of SimplEC, is avail-
start running(P ) or
able at the GitHub repository of RTEC. (9)
start abrupt(P )),
Recall the formalisation of passenger density from city
not disappear (P ).
transport management—see rule (4). This may be expressed
in SimplEC as follows: terminate person(P ) iff
disappear (P ).
initiate passenger density(ID, VT ) = Val iff
(6)
passenger density change(ID, VT , Val ). The value of person(P ) is time-dependent because the iden-
‘happensAt’ may be omitted since the first condition of an tifier P of a tracked entity that ‘disappears’ (is no longer
initiate statement is always an event. Moreover, in the ab- tracked) at some point may be used later to refer to another
sence of long-term temporal relations, the variables express- entity that ‘appears’ (becomes tracked), and that other entity
ing time-points may be omitted, and ‘initiatedAt’ may be may not necessarily be a person. Note that disappear is an
simply written as initiate. event; however, we did not have to use the ‘happens’ prefix
The definition of moving in human activity recognition, in the initiate statement. The compiler of SimplEC may de-
given by rule-set (1), may be written in SimplEC as follows: duce that disappear is an event since it is used as the first
condition of the ‘terminate’ statement.
initiate moving(P1 , P2 ) if The compiled RTEC rules are the following:
start walking(P1 ),
walking(P2 ), initiatedAt(person(P ) = true, T ) :−
close(P1 , P2 ). happensAt(start(walking(P ) = true), T ),
initiate moving(P1 , P2 ) if not happensAt(disappear (P ), T ).
start walking(P2 ), initiatedAt(person(P ) = true, T ) :−
walking(P1 ), happensAt(start(active(P ) = true), T ),
close(P1 , P2 ). not happensAt(disappear (P ), T ).
initiate moving(P1 , P2 ) if initiatedAt(person(P ) = true, T ) :−
(7) (10)
start close(P1 , P2 ), happensAt(start(running(P ) = true), T ),
walking(P1 ), not happensAt(disappear (P ), T ).
walking(P2 ). initiatedAt(person(P ) = true, T ) :−
terminate moving(P1 , P2 ) if happensAt(start(abrupt(P ) = true), T ),
end walking(P1 ). not happensAt(disappear (P ), T ).
terminate moving(P1 , P2 ) if terminatedAt(person(P ) = true, T ) :−
end walking(P2 ). happensAt(disappear (P ), T ).
terminate moving(P1 , P2 ) if In SimplEC, statically determined fluents are defined via
end close(P1 , P2 ). statements that begin with the fluent itself. The body of
the statement consists of a number of conjunctions, dis- Unlike the specifications that we have seen so far, the
junctions, and negations of other fluents, expressing, respec- activity of interest here is defined as a derived event.
tively, the intersect all, union all and relative complement all speedChange(Vessel ) is an SDE detected from vessel po-
interval manipulation constructs of RTEC (see Figure 1). sition signals. velocity and coord are fluents indicating,
As an illustration, consider the statement below expressing respectively, the speed and coordinates of a vessel. These
moving, from the domain of activity recognition, as a stati- are also given as input to RTEC. nearPorts(Lon, Lat) is
cally determined fluent: an atemporal predicate that becomes true when the point
(Lon, Lat) is close to a port. headingToVessels(Vessel )
moving(P1 , P2 ) iff is a fluent that becomes true whenever a Vessel ’s direction
walking(P1 ), of movement is towards at least one other vessel. According
(11)
walking(P2 ), to rule (14), a ‘fast approach’ movement is recognised when
close(P1 , P2 ). a Vessel changes its speed at open sea, the new speed is
Recall that the corresponding definition in RTEC is given above 20 knots, and there is at least one other nearby vessel
by rule (5). Note that the above statement does not include towards which it is heading. The value of 20 knots was cho-
‘holdsFor’ and the corresponding variables for intervals. sen by domain experts. More details about the application of
Another example illustrating the compactness of the stat- RTEC to maritime monitoring may be found at (Patroumpas
ically determined fluent definitions is again taken from ac- et al. 2017).
tivity recognition. In this domain, fighting between two per- In addition to fluents, SimplEC supports derived events.
sons may be defined in the following way: Rule (14) e.g. may be expressed as follows:
happens fastApproach(Vessel ) iff
fighting(P1 , P2 ) iff
speedChange(Vessel ),
(abrupt(P1 ) or abrupt(P2 )),
(12) velocity(Vessel ) > 20 knots,
close(P1 , P2 ), (15)
coord (Vessel ) =(Lon, Lat),
not (inactive(P1 ) or inactive(P2 )).
not nearPorts(Lon, Lat),
This statement declares that when two persons stand close headingToVessels(Vessel ).
to each other and at least one of them appears to be moving Similar to initiate and terminate statements, the first condi-
abruptly while none of them is inactive, then a fight is in- tion of a happens statement is expected to be an event, while
ferred to be taking place. Translating this statement into the the remaining ones concern fluents unless otherwise indi-
RTEC syntax yields the following rule: cated. In this example, the user has to declare separately
holdsFor(fighting(P1 , P2 ) = true, I ) :− that nearPorts is an atemporal predicate. We should also
holdsFor(abrupt(P1 ) = true, I1 ), like to note, in this example, the ability to condense arith-
holdsFor(abrupt(P2 ) = true, I2 ), metic comparisons, such as that of lines 3 and 4 of rule (14).
union all([I1 , I2 ], I3 ),
holdsFor(close(P1 , P2 ) = true, I4 ), Compiler
(13) The compiler of SimplEC parses a set of statements in
intersect all([I3 , I4 ], I5 ),
holdsFor(inactive(P1 ) = true, I6 ), the simple language and, based on its grammar, translates
holdsFor(inactive(P2 ) = true, I7 ), the statements to rules in the RTEC format. Moreover, it
union all([I6 , I7 ], I8 ), constructs the declarations required for computing narra-
relative complement all(I5 , [I8 ], I ). tive assimilation queries. The declarations distinguish, for
the benefit of RTEC, between simple and statically deter-
Rule (13) takes many more keystrokes to complete and re- mined fluents, and between input and output entities (events
quires the application of quite a few interval manipulation and fluents). In SimplEC statement (11), for instance,
constructs, compared to statement (12). SimplEC here helps the compiler will detect three statically determined fluents,
building a shorter and more natural-looking statement. namely moving( , ), walking( ), and close( , ), of which
RTEC has also been used for maritime monitoring. In moving( , ) is an output entity, as it appears in the head of
this domain, maritime patrol officers are interested in detect- the statement, and the other two are input entities, as they do
ing various types of illegal, suspicious or dangerous activity, not appear to be defined by other, simpler entities. Subse-
such as when a vessel is rapidly moving towards some other quently, the compiler will generate the RTEC rule (5), along
vessel(s). Such a behaviour could indicate a vessel pursuit or with the following declarations:
even imminent collision. Consider the formalisation below:
sDFluent(moving( , )).
happensAt(fastApproach(Vessel ), T ) :− sDFluent(walking( )).
happensAt(speedChange(Vessel ), T ), sDFluent(close( , )).
holdsAt(velocity(Vessel ) = Speed , T ), (16)
outputEntity(moving( , )).
Speed > 20 knots, inputEntity(walking( )).
holdsAt(coord (Vessel ) =(Lon, Lat), T ), inputEntity(close( , )).
not nearPorts(Lon, Lat), See the GitHub repository of RTEC for example decla-
holdsAt(headingToVessels(Vessel ) = true, T ). ration files. The declarations also express the ‘caching hi-
(14) erarchy’, that is, the order in which fluents and events are
Figure 2: Dependency graph of the city transport management event description.
processed. RTEC performs bottom-up processing whereby straightforward statements. To test the extent to which this
fluents and events of level 1 of a hierarchy are processed conciseness is achieved by our proposed language, we com-
first, subsequently moving to levels 2, 3, etc. The computed pared the RTEC code with its respective SimplEC code in
intervals of each level are cached. This way, fluent and event terms of length and simplicity in three application domains
intervals of some level n may be simply fetched from mem- already discussed in this paper: Human activity recognition,
ory when required in the processing of fluents and events of city transport management and maritime monitoring. Figure
some higher level m. 3 illustrates the comparison.
To aid the user, the compiler may display the dependency Figure 3a depicts the code size in bytes needed to con-
graph of the event description. This is a directed graph struct equivalent formalisations in RTEC and SimplEC. In
where each vertex corresponds to a fluent or event, and for human activity recognition, the event descriptions along
each pair of vertices (i, j) there is an edge from i to j if with the entity declarations of RTEC result in 7,406 bytes
i appears in the body of a statement defining j. Figure 2 of code. The same information can be described in our pro-
shows the dependency graph of an event description for city posed language using only 2,780 bytes, which corresponds
transport management. In this figure, we can observe the to a 62.5% reduction. In city transport management, the
way in which the events and fluents affect each other. In the achieved reduction is approximately 50%, while in maritime
leftmost part of the figure there are vertices with no incom- monitoring it is approximately 60%. In Figure 3b we focus
ing edges. These correspond to input events and fluents that the comparison on the lines of code needed in each case.
form the narrative upon which all complex activities will be As far as the human activity recognition application is con-
recognised. In this domain, the input entities include infor- cerned, 130 RTEC rules were needed in order to describe
mation about the acceleration and deceleration of transport the problem. This number is brought down to just 38 using
vehicles, changes in internal temperature, noise level or pas- SimplEC, which corresponds to a 70.8% reduction. Simi-
senger density, as well as the time of arrival at a stop. larly, for city transport management, rules were reduced by
On the right of the bottom layer, there are two other lay- approximately 72%, while in maritime monitoring they were
ers of events and fluents that have both incoming and out- reduced by 77%. Finally, apart from the metrics that have to
going edges. These are output entities that also contribute do with the brevity of the event descriptions, there are met-
to the definition of other output entities. On these layers rics that concern the simplicity of a dialect. One such metric
we combine information from the bottom layer and produce is the amount of unique domain-independent keywords and
higher-level information. For instance, we can recognise predicates. The application of this metric to the three do-
complex activities such as driving style and quality, vehicle mains is shown in Figure 3c.
punctuality and the passengers’ comfort level. In the right-
most part of the figure, there is one last layer with no out- The significant difference in code size, lines of code and
going edges. These are the complex activities of the highest number of unique domain-independent predicates is mainly
level—consider, for instance, passenger satisfaction. caused by the fact that there are several keywords, condi-
tions and facts in the RTEC code, which are automatically
inferred and generated internally by the SimplEC compiler
Empirical Evaluation and, therefore, need not be included in the SimplEC state-
SimplEC has been designed and implemented with a view to ment set, thus paving the way for fewer, shorter and more
making the event descriptions of RTEC concise and Prolog- compact statements. These automatically inferred objects
independent. A SimplEC user with little or no programming include the interval manipulation constructs and the entity
skills should be able to define events and the effects thereof declarations, among others. For instance, SimplEC state-
within a particular domain, by writing short, simple and ment (11) yields RTEC rule (5), along with the declarations
(a) Code size. (b) Lines of code. (c) Unique keywords.
Figure 3: Comparison between RTEC and SimplEC in three real-world applications: Human Activity Recognition (HAR),
City Transport Management (CTM) and Maritime Monitoring (MM). Dark blue bars correspond to RTEC while dark red ones
correspond to SimplEC.
shown in (16). Consequently, a user of SimplEC does not References
have to keep many special terms and domain-independent
predicates in mind, thus making it easier to focus on the do- [Artikis and Sergot 2010] Artikis, A., and Sergot, M. J.
main formalisation. 2010. Executable specification of open multi-agent systems.
Logic Journal of the IGPL 18(1):31–65.
[Artikis et al. 2012] Artikis, A.; Skarlatidis, A.; Portet, F.;
Related and Further Work and Paliouras, G. 2012. Logic-based event recognition.
Knowledge Eng. Review 27(4):469–506.
RTEC has a formal, declarative semantics as opposed to
most complex event processing languages, several data [Artikis, Sergot, and Paliouras 2015] Artikis, A.; Sergot,
stream processing and event query languages, and most M. J.; and Paliouras, G. 2015. An event calculus for event
commercial production rule systems (Cugola and Margara recognition. IEEE Trans. Knowl. Data Eng. 27(4):895–908.
2012). Moreover, RTEC supports atemporal reasoning and [Bicocchi et al. 2014] Bicocchi, N.; Vassev, E.; Zambonelli,
reasoning over background knowledge, and explicitly rep- F.; and Hinchey, M. 2014. Reasoning on data streams:
resents intervals, thus avoiding the related logical problems An approach to adaptation in pervasive systems. In Nature
(Paschke 2005). Concerning the Event Calculus literature of Computation and Communication - International Confer-
(e.g. (Chittaro and Montanari 1996; Cervesato and Monta- ence, ICTCC, 23–32.
nari 2000; Miller and Shanahan 2002; Paschke and Bichler [Cervesato and Montanari 2000] Cervesato, I., and Monta-
2008; Artikis and Sergot 2010; Montali et al. 2013)), a key nari, A. 2000. A calculus of macro-events: Progress report.
feature of RTEC is that it includes a windowing technique In Seventh International Workshop on Temporal Represen-
(Artikis, Sergot, and Paliouras 2015). In contrast, no Event tation and Reasoning, TIME, 47–58.
Calculus system ‘forgets’ or represents concisely the data
stream history. [Chittaro and Montanari 1996] Chittaro, L., and Montanari,
We presented our efforts towards a simple language for A. 1996. Efficient temporal reasoning in the cached event
RTEC. We observed, using real-world applications, that calculus. Computational Intelligence 12(3):359–382.
SimplEC helps in writing much more succinct event de- [Cugola and Margara 2012] Cugola, G., and Margara, A.
scriptions. However, the simple language must be evalu- 2012. Processing flows of information: From data stream
ated by people that are not familiar with the Event Calculus. to complex event processing. ACM Computing Surveys
Towards this, we will make use of the domain experts of 44(3):15.
the datAcron project1 , where RTEC is used as the complex [Kowalski and Sergot 1986] Kowalski, R. A., and Sergot,
event recognition engine for maritime and aviation monitor- M. J. 1986. A logic-based calculus of events. New Gen-
ing. We are also working towards constructing simpler and eration Comput. 4(1):67–95.
more orderly dependency graphs.
[Miller and Shanahan 2002] Miller, R., and Shanahan, M.
2002. Some alternative formulations of the event calculus.
Acknowledgements In Computational Logic: Logic Programming and Beyond,
LNAI 2408. 452–490.
This work is funded by the H2020 project datAcron [Montali et al. 2013] Montali, M.; Maggi, F. M.; Chesani, F.;
(687591). Mello, P.; and van der Aalst, W. M. P. 2013. Monitor-
ing business constraints with the event calculus. ACM TIST
1
http://datacron-project.eu 5(1):17:1–17:30.
[Paschke and Bichler 2008] Paschke, A., and Bichler, M.
2008. Knowledge representation concepts for automated
SLA management. Decision Support Systems 46(1).
[Paschke 2005] Paschke, A. 2005. ECA-RuleML: An ap-
proach combining ECA rules with temporal interval-based
KR event/action logics and transactional update logics.
Technical report, CoRR abs/cs/0610167.
[Patroumpas et al. 2017] Patroumpas, K.; Alevizos, E.; Ar-
tikis, A.; Vodas, M.; Pelekis, N.; and Theodoridis, Y. 2017.
Online event recognition from moving vessel trajectories.
GeoInformatica 21(2):389–427.
[Przymusinski 1987] Przymusinski, T. 1987. On the declar-
ative semantics of stratified deductive databases and logic
programs. In Foundations of Deductive Databases and
Logic Programming. Morgan.