Abstract 1 Introduction 2 Preliminaries 3 Revisiting the semantics of Complex Event Logic 4 Modelling aggregate functions in CER 5 Aggregation complex event logic 6 Automata model for aggregation in CER 7 Future Work References Appendix A Examples from practice

A Formal Query Language and Automata Model for Aggregation in Complex Event Recognition

Pierre Bourhis ORCID Univ. Lille, CNRS, Centrale Lille, UMR 9189 CRIStAL, INRIA Lille, F-59000 Lille, France Cristian Riveros ORCID Pontificia Universidad Católica de Chile, Santiago, Chile
Millennium Institute for Foundational Research on Data, Santiago, Chile
Amaranta Salas ORCID Pontificia Universidad Católica de Chile, Santiago, Chile
Millennium Institute for Foundational Research on Data, Santiago, Chile
Abstract

Complex Event Recognition (CER) systems are used to identify complex patterns in event streams, such as those found in stock markets, sensor networks, and other similar applications. An important task in such patterns is aggregation, which involves summarizing a set of values into a single value using an algebraic function, such as the maximum, sum, or average, among others. Despite the relevance of this task, query languages in CER typically support aggregation in a restricted syntactic form, and their semantics are generally undefined.

In this work, we present a first step toward formalizing a query language with aggregation for CER. We propose to extend Complex Event Logic (CEL), a formal query language for CER, with aggregation operations. This task requires revisiting the semantics of CEL, using a new semantics based on bags of tuples instead of sets of positions. Then, we present an extension of CEL, called Aggregation CEL (ACEL), which introduces an aggregation operator for any commutative monoid operation. The operator can be freely composed with previous CEL operators, allowing users to define complex queries and patterns. We showcase several queries in practice where ACEL proves to be natural for specifying them. From the computational side, we present a novel automata model, called Aggregation Complex Event Automata (ACEA), that extends the previous proposal of Complex Event Automata (CEA) with aggregation and filtering features. Moreover, we demonstrate that every query in ACEL can be expressed in ACEA, illustrating the effectiveness of our computational model. Finally, we study the expressiveness of ACEA through the lens of ACEL, showing that the automata model is more expressive than ACEL.

Keywords and phrases:
Streams, complex event recognition, query language, aggregation
Copyright and License:
[Uncaptioned image] © Pierre Bourhis, Cristian Riveros, and Amaranta Salas; licensed under Creative Commons License CC-BY 4.0
2012 ACM Subject Classification:
Information systems Stream management
; Theory of computation Database theory ; Theory of computation Database query languages (principles)
Related Version:
Full Version: https://arxiv.org/abs/2601.00967 [8]
Funding:
The work of Bourhis was supported by a French government grant managed by the Agence Nationale de la Recherche under the France 2030 program, reference ANR-23-PECL-0008. The work of Riveros and Salas was supported by ANID Fondecyt Regular project 1230935 and ANID – Millennium Science Initiative Program – Code ICN17_002.
Editors:
Balder ten Cate and Maurice Funk

1 Introduction

Complex Event Recognition (CER) systems are a group of data stream management systems for the detection of special events in real-time, called complex events, that satisfy a pattern, considering their position, the order, and other constraints between them [17, 12]. Some examples of its use are maritime monitoring [26], network intrusion detection [24], industrial control systems [21], and real-time analytics [30]. In the literature, people have proposed multiple systems and query languages based on different formalisms for approaching complex events, such as automata-based, logic-based, tree-based, or a combination of them [17]. Examples of CER systems developed in academic and industrial contexts include SASE [34], EsperTech [1], and CORE [9, 7], among others.

A problem in CER systems is that their query languages, used to declare complex events, are, unfortunately, underspecified with respect to both their syntax and semantics. As observed in previous works [36, 15, 11, 5], CER query languages in systems typically lack a simple, compositional, and denotational semantics. In general, its semantics is defined indirectly through examples [2, 10], or by translation into evaluation models [25, 31, 33]. Recently, this issue in CER systems has been studied more thoroughly, and a query language that has successfully defined the semantics of several CER operators is Complex Event Logic (CEL) [19, 20], alongside a computational model called Complex Event Automata (CEA), which is based on the theory of finite state transducers and symbolic automata.

An open problem in formalizing CER query language is that several interesting queries in practice include aggregation, which previous proposals have not addressed. Aggregation refers to any subprocess in a query that combines and merges several (most often numerical) values into a single one [18], such as taking the average, the sum, or the maximum of a list of values. Examples of CER systems that used aggregation are SASE [14, 35], EsperTech [1], GLORIA [23], GRETA [28], and others [17, 12]. For illustrating a prototypical query with aggregation, consider the following (simplified) query from SASE [35, p. 3]:

ΨQ1: PATTERN seq(JobStart a, Mapper+ b[ ], JobEnd c)
ΨWHERE a.job_id = b[i].job_id and a.job_id = c.job_id
ΨRETURN AVG(b[ ].period), MAX(b[ ].period)

Intuitively, the previous query aims to retrieve the average and maximum periods from a list of running times of mappers. For this, it looks for events from the stream, in the “PATTERN” clause that match the pattern: a JobStart typed event, followed by one or more Mapper events, and finally a JobEnd event. In turn, it uses the “WHERE” clause to ensure that each event matching the pattern has the same id attribute, and finally, it returns the average and maximum of the events that meet the conditions.

Previous proposals for formalizing CER query languages do not include such queries with aggregation, as they must not only detect and retrieve complex events but also produce new events and values. In particular, aggregation queries cannot be defined by logics like CEL or computational models like CEA, or any other formalization of CER as it is currently defined. These issues imply that CER query languages with aggregation are difficult to compare, unclear how to compose queries, and difficult to evaluate (i.e., without knowing the real meaning of a query). Furthermore, computational models for compiling queries with aggregation are not well understood, and systems usually rely on ad-hoc evaluation strategies suitable for specific queries and patterns.

In this work, we propose an extension of the logic CEL, and its corresponding computational model CEA, to express queries with aggregation, which we call Aggregation Complex Event Logic (ACEL) and Aggregation Complex Event Automata (ACEA), respectively. Our main goal is to design a logic and computational model, with a formal semantics that formalizes aggregation in CER and serves as a base for all CER languages.

For extending CEL with aggregation, we need to revisit its semantics. One of the first problems to arise with the current semantics of CEL is that a CEL formula retrieves the positions in the streams that fire the complex events, but it does not allow the creation of new values or events. For this reason, we propose a new, equivalent semantics for CEL that returns events instead of positions. Additionally, since we also need to maintain duplicates for aggregation, we extend the semantics by using bags of events instead of sets. We then prove that the new semantics is equivalent to the previous one. Interestingly, the new semantics enable us to define new relevant operators for CER, such as attribute projection.

To formalize the aggregation in CER, we consider a general setting of aggregation based on aggregate functions [22, 18]; these are functions that go from a bag of values to single values, and they aim to summarize information (like count, sum, etc). By using this general framework of aggregation functions, they support our proposal in providing a general framework for aggregation in CER. Furthermore, we introduce an operator 𝙰𝚐𝚐Y(bX(a)) for variables named X and Y, attributes named a and b, and aggregation function , which takes a bag of events stored in X and -operates it corresponding attribute a, storing the result in another attribute b of an event in another variable Y. We formally define its syntax and semantics in Section 5. An advantage of this definition is that we can compose the 𝙰𝚐𝚐 operator and every other operator in CEL. We show that most CER queries with aggregation from previous works are definable with ACEL.

An advantage of CEL is that one can characterize its expressive power with the so-called Complex Event Automata (CEA); specifically, that for every CEL formula, there exists an equivalent CEA, and vice versa. The practical relevance of this result is that CEL is useful for users to define queries, where CEA is useful for systems to evaluate them. In this work, we aim to achieve an equivalent result, so our next step was to find a machine model that can extend CEA and formally define ACEL. We introduce an automata model with aggregation for ACEL, which we call Aggregation Complex Event Automata (ACEA), an extension of CEA with registers to aggregate values. This extension employs the same concept of operating values in transitions and maintaining registers as cost register automata [4]. Specifically, in each transition, an ACEA takes an event and updates its register with those new values. Then, it performs an operation based on the assignments, checks if it satisfies a predicate, and finally, it creates a new tuple with the aggregated values. One of our main results is that we can compile every ACEL formula into an ACEA, namely, we can prove that the expressive power of ACEL is a subset of ACEA.

Outline.

We present the preliminaries in Section 2. In Section 3, we discuss the necessary changes in CEL semantics and we show a new operator, projection by attribute. In Section 4, we discuss the setting of aggregate functions. In Section 5, we formally introduce ACEL, and we introduce ACEA in Section 6, to study the compilation of CEL formulas into ACEA and its equivalence with CEA. We conclude and discuss future work in Section 7. An extended version with all missing proofs and examples can be found in [8].

2 Preliminaries

Sets, intervals, and mappings.

Given a set A, we denote by 𝒫(A) the set of all finite subsets of A. We denote by the natural numbers. Given n,m with nm, we denote by [n] the set {1,,n} and by [n..m] the interval {n,n+1,,m} over . As usual, we write f:AB to denote a function f from the set A to B where every element in A has an image. A mapping M is a partial function that maps a finite number of elements from A to elements over B. We write M:AB to denote a mapping M from A to B. We denote by 𝖽𝗈𝗆(M) the domain of M (i.e., all aA such that M(a) is defined), and by 𝗂𝗆𝗀(M) the image of M. We will usually use the notation [a1b1,,akbk] to define a mapping M with 𝖽𝗈𝗆(M)={a1,,ak}, 𝗂𝗆𝗀(M)={b1,,bk} and M(ai)=bi for every i[k]. Furthermore, for a map M and a𝖽𝗈𝗆(M) we write [M,ab] to specify a new map M that extends M mapping a to b.

Bags.

A bag or multiset (with own identity) B is a mapping B:IU where I=𝖽𝗈𝗆(B) is a finite set of identifiers (or ids) and U=𝗂𝗆𝗀(B) is the underlying set of the bag. Given any bag B, we refer to these components as I(B) and U(B), respectively. For example, a bag B={{a,a,b}} (where a is repeated twice) can be represented with a mapping B0=[1a,2a,3b] where I(B0)={1,2,3} and U(B0)={a,b}. In general, we will use the standard notation for bags {{a1,,an}} to denote the bag B whose identifiers are I(B)={1,,n} and B(i)=ai for each iI(B). We will use to refer to the union of bags: for every bags A and B, we define the bag C:=AB such that 𝖽𝗈𝗆(C)=(𝖽𝗈𝗆(A)×{0})(𝖽𝗈𝗆(B)×{1}) and C((i,b))=X(i) where X=A if b=0 and X=B, otherwise. In other words, we take the disjoint union of the identifiers mapping every identifier to its corresponding element in A or B. Further, we define 𝒫bags(A) as the set of all finite bags that one can form from a set A.

Computational model.

We assume the model of random access machines (RAM) with uniform cost measure, and addition and subtraction as basic operations [3]. This implies, for example, that the access to a lookup table (i.e., a table indexed by a key) takes constant time. These are common assumptions in the literature of the area [9, 32].

3 Revisiting the semantics of Complex Event Logic

In this section, we revisit the semantics of CEL [20] and present a new semantics based on tuples instead of positions. We then prove the equivalence between the two versions. This new semantics allows, for example, the definition of a new operator for CEL, called attribute-projection, which cannot be defined with the old semantics. Furthermore, the new semantics is crucial to introduce aggregation in CEL in the next section.

Events and streams.

We fix a countably infinite set of attribute names 𝐀 and a countably infinite of data values 𝐃 (e.g. integers, strings). An (untyped) event e is a pair (M,i) such that M:𝐀𝐃 maps attribute names from 𝐀 to data values in 𝐃, and i is the time of the event [16] (we prefer to use discrete time, which is enough for our purposes). Intuitively, M defines the data of the event (i.e., as a tuple). We denote by e(a)𝐃 the value of the attribute a𝐀 assigned by M (i.e., e(a)=M(a)). If e is not defined on attribute a, then we write e(a)=NULL. Furthermore, for the sake of simplification we also denote e(𝗍𝗂𝗆𝖾)=i (note, however, that 𝗍𝗂𝗆𝖾 is not an attribute). We define by 𝖠𝗍𝗍(e) the set of attributes of e, namely, 𝖠𝗍𝗍(e)=𝖽𝗈𝗆(M). We write 𝐄 to denote the set of all events over attributes names 𝐀 and data values 𝐃. We will usually use bold letters a, b, and c to denote attribute names in 𝐀 and (normal) letters a, b, and c to denote data values in 𝐃.

Fix now a finite set of event types 𝐓 and assume that 𝐓𝐃 and NULL𝐃. In this work, we assume the existence of a distinguished attribute 𝗍𝗒𝗉𝖾 that defines the type of an event. Specifically, let 𝗍𝗒𝗉𝖾 be an attribute such that 𝗍𝗒𝗉𝖾𝐀. For every event e, we assume that 𝗍𝗒𝗉𝖾𝖠𝗍𝗍(e) and e(𝗍𝗒𝗉𝖾)𝐓{NULL} is the type of e. Notice that e could be typed (i.e., e(𝗍𝗒𝗉𝖾)𝐓) or untyped in which case we have e(𝗍𝗒𝗉𝖾)=NULL. A schema Σ is a function Σ:𝐓𝒫(𝐀Σ) where 𝐀Σ𝐀 is a finite set of attributes. We say that an event e satisfies the schema Σ if, and only if, e is a typed event and 𝖠𝗍𝗍(e)=Σ(e(𝗍𝗒𝗉𝖾)){𝗍𝗒𝗉𝖾}. In particular, untyped events do not satisfy a schema by definition.

Let Σ:𝐓𝒫(𝐀Σ) be a schema. A stream over a schema Σ is an (arbitrary long) sequence 𝒮=e1e2en of typed events such that, for every i[n], it holds that e satisfies Σ and ei(𝗍𝗂𝗆𝖾)=i. In other words, a stream consists of typed events according to Σ and every time of an event is the position in the stream. Note that we defined the type and time of an event for its later use in the semantics of CEL. The first will allow us to know the attributes of each event when we compile CEL into an automata model, and the second will allow us to differentiate between tuples by adding its origin in the stream [6].

Example 1.

As a running example, consider that we have a stream 𝒮𝖲𝗍𝗈𝖼𝗄𝗌 that is emitting buy and sell events of particular stocks [9]. Here, we assume a schema Σ𝖲𝗍𝗈𝖼𝗄𝗌 with attributes 𝗇𝖺𝗆𝖾 and 𝗉𝗋𝗂𝖼𝖾 that represents the name of the stock (e.g., INTL for intel) and its price (e.g., US$80), respectively. We have two types, called BUY and SELL, and Σ𝖲𝗍𝗈𝖼𝗄𝗌(BUY)=Σ𝖲𝗍𝗈𝖼𝗄𝗌(SELL)={𝗇𝖺𝗆𝖾,𝗉𝗋𝗂𝖼𝖾}. A possible stream 𝒮𝖲𝗍𝗈𝖼𝗄𝗌 could be the following:

Note that each event contains a type (i.e., BUY or SELL), its attributes values (i.e., 𝗇𝖺𝗆𝖾 and 𝗉𝗋𝗂𝖼𝖾) and its time (i.e., the position above the event). Further, each event satisfies Σ𝖲𝗍𝗈𝖼𝗄𝗌.

The notion of a renaming of a event will be useful in this work (e.g., see Section 6). Formally, we define a renaming r as a mapping r:𝐀𝐀. We say that an event e is consistent with a renaming r iff 𝖽𝗈𝗆(r)𝖽𝗈𝗆(e) and, if r(a)=r(b), then e(a)=e(b) for every a,b𝖽𝗈𝗆(r). Given an event e consistent with r, we define the renamed event r(e) such that [r(e)](𝗍𝗂𝗆𝖾)=e(𝗍𝗂𝗆𝖾) and [r(e)](r(a))=e(a) for every attribute a𝖽𝗈𝗆(r). In other words, r renames some attributes a of e to r(a). We define by 𝖱𝖾𝗇 the set of all renamings over 𝐀.

Predicates of events.

A predicate is a possibly infinite set P of events. For instance, P could be the set of all events e such that e(a)20. In our examples, we will use the notation aa where a𝐀, a𝐃, and is a binary relation over 𝐃 to denote the predicate P={ee(a)a}. We say that an event e satisfies predicate P, denoted eP, if, and only if, eP. We generalize this notation from events to a bag of events E such that EP if, and only if, eP for every eE.

In this work, we assume a fix set of predicates 𝐏 that is close under intersection, negation, and renaming, namely, P1P2𝐏, 𝐄P𝐏, and r(P)𝐏 for every P,P1,P2𝐏 and r𝖱𝖾𝗇 where r(P)={r(e)ePe is consistent with r} and 𝐄, the set of all events, is a predicate in 𝐏 that we usually denote by TRUE.

Complex events.

In this work, we will use a slightly different definition of complex event: we will store events inside valuations, instead of storing positions like in [9]. Formally, fix a finite set 𝐗 of variables, which includes all event types (i.e. 𝐓𝐗). Let 𝒮 be a stream of length n. A complex event of 𝒮 is a triple (i,j,μ) where i,j[n], ij, and μ:𝐗𝒫bags(𝐄) is a function from variables to finite bags of events. Intuitively, i and j marks the beginning and end of the interval where the complex event happens, and μ stores the events in the interval [i..j] that fired the complex event. In the following, we will usually denote C to denote a complex event (i,j,μ) of 𝒮 and omit 𝒮 if the stream is clear from the context. We will use 𝗍𝗂𝗆𝖾(C), 𝗌𝗍𝖺𝗋𝗍(C), and 𝖾𝗇𝖽(C) to denote the interval [i..j], the start i, and the end j of C, respectively. Further, by some abuse of notation we will also use C(X) for X𝐗 to denote the bag μ(X) of C.

The following operations on complex events will be useful throughout the paper. We define the union of complex events C1 and C2, denoted by C1C2, as the complex event C such that 𝗌𝗍𝖺𝗋𝗍(C)=𝗆𝗂𝗇{𝗌𝗍𝖺𝗋𝗍(C1),𝗌𝗍𝖺𝗋𝗍(C2)}, 𝖾𝗇𝖽(C)=𝗆𝖺𝗑{𝖾𝗇𝖽(C1),𝖾𝗇𝖽(C2)}, and C(X)=C1(X)C2(X) for every X𝐗. Further, we define the projection over L𝐗 of a complex event C, denoted by πL(C), as the complex event C such that 𝗍𝗂𝗆𝖾(C)=𝗍𝗂𝗆𝖾(C) and C(X)=C(X) whenever XL, and C(X)=, otherwise. Finally, we denote by (i,j,μ) the complex event with the trivial function μ such that μ(X)= for every X𝐗.

A new semantics for CEL.

In this work, we use the Complex Event Logic (CEL) introduced in [20] and implemented in CORE [9] as our basic query language for CER. However, we revisit its semantics in order to extend it with aggregation. In particular, we use the same CEL syntax as in [20] which is given by the following grammar:
φ:=R(event type selection)φ𝖠𝖲X(variable binding)φ𝖥𝖨𝖫𝖳𝖤𝖱X[P](predicate filtering)πL(φ)(variable projection)φ𝖮𝖱φ(disjunction)φ𝖠𝖭𝖣φ(conjunction)φ:φ(contiguous sequencing)φ;φ(non-cont. sequencing)φ(contiguous iteration)φ+(non-cont. iteration)

where R is an event type, X𝐗 is a variable, P𝐏 is a predicate, and L𝐗 is a finite set of variables. Similar to [20, 9], we define the semantics of a CEL formula φ over a stream 𝒮=e1e2en, recursively, as a set of complex events over 𝒮. The main difference is the notion of complex events, that now contains events instead of positions. In Figure 1, we define the semantics of each CEL operator like in [9, 20]. Given a formula φ, the semantics φ(S) defines a set of complex events. Notice that φ(S) has a set-semantics and, instead, complex events store bags of events.

R(𝒮) ={(i,i,μ)i[k]ei(𝗍𝗒𝗉𝖾)=Rμ(R)={{ei}}YX.μ(Y)=}
φ𝖠𝖲X(𝒮) ={CCφ(𝒮).𝗍𝗂𝗆𝖾(C)=𝗍𝗂𝗆𝖾(C)C(X)=YC(Y)ZX.C(Z)=C(Z)}
φ𝖥𝖨𝖫𝖳𝖤𝖱X[P](𝒮) ={CCφ(𝒮)C(X)P}
πL(φ)(𝒮) ={πL(C)Cφ(𝒮)}
φ1𝖮𝖱φ2(𝒮) =φ1(𝒮)φ2(𝒮)
φ1𝖠𝖭𝖣φ2(𝒮) =φ1(𝒮)φ2(𝒮)
φ1:φ2(𝒮) ={C1C2C1φ1(𝒮)C2φ2(𝒮)𝖾𝗇𝖽(C1)+1=𝗌𝗍𝖺𝗋𝗍(C2)}
φ1;φ2(𝒮) ={C1C2C1φ1(𝒮)C2φ2(𝒮)𝖾𝗇𝖽(C1)<𝗌𝗍𝖺𝗋𝗍(C2)}
φ(𝒮) =φ(𝒮)φ:φ(𝒮)
φ+(𝒮) =φ(𝒮)φ;φ+(𝒮)
Figure 1: The semantics of CEL defined over a stream 𝒮=e1e2en where each ei is an event.

Next, we present an example for showing how to use the syntax and semantics of CEL to extract complex events from streams (see also Section 5). In this example, we use conjunction and disjunction in filtering that one can read them as:

φ𝖥𝖨𝖫𝖳𝖤𝖱(X[P1]Y[P2])(φ𝖥𝖨𝖫𝖳𝖤𝖱X[P1])𝖥𝖨𝖫𝖳𝖤𝖱Y[P2]φ𝖥𝖨𝖫𝖳𝖤𝖱(X[P1]Y[P2])(φ𝖥𝖨𝖫𝖳𝖤𝖱X[P1])𝖮𝖱(φ𝖥𝖨𝖫𝖳𝖤𝖱Y[P2])

for every CEL formula φ, variables X,Y𝐗, and predicates P1,P2.

Example 2 (from [9]).

Consider the stream 𝒮𝖲𝗍𝗈𝖼𝗄𝗌 from Example 1. Suppose that we are interested in all triples of SELL events where the first is a sale of Microsoft over US$100, the second is a sale of Intel (of any price), and the third is a sale of Amazon below US$2000. Then, we can specify this pattern by the following CEL formula:

φ2=(SELL𝖠𝖲𝗆𝗌𝖿𝗍;SELL𝖠𝖲𝗂𝗇𝗍𝖾𝗅;SELL𝖠𝖲𝖺𝗆𝗓𝗇)𝖥𝖨𝖫𝖳𝖤𝖱(𝗆𝗌𝖿𝗍[𝗇𝖺𝗆𝖾=𝖬𝖲𝖥𝖳]𝗆𝗌𝖿𝗍[𝗉𝗋𝗂𝖼𝖾>𝟣𝟢𝟢]𝗂𝗇𝗍𝖾𝗅[𝗇𝖺𝗆𝖾=𝖨𝖭𝖳𝖢]𝖺𝗆𝗓𝗇[𝗇𝖺𝗆𝖾=𝖠𝖬𝖹𝖭]𝖺𝗆𝗓𝗇[𝗉𝗋𝗂𝖼𝖾<𝟤𝟢𝟢𝟢]).

Intuitively, the expression (SELL𝖠𝖲𝗆𝗌𝖿𝗍;SELL𝖠𝖲𝗂𝗇𝗍𝖾𝗅;SELL𝖠𝖲𝖺𝗆𝗓𝗇) specifies that we want to see three SELL events that we named by the variables 𝗆𝗌𝖿𝗍, 𝗂𝗇𝗍𝖾𝗅 and 𝖺𝗆𝗓𝗇, respectively. The semicolon operator (;) indicates non-contiguous sequencing among them, namely, there could be more events between them. Finally, the 𝖥𝖨𝖫𝖳𝖤𝖱 clause requires the data of the events to satisfy the necessary restrictions.

As we already mentioned, in this work we change the semantics used in [20, 9] to use events instead of positions, called it here event-based semantics. The old semantics of CEL, called position-based semantics, was obtained by outputting complex events of the form C=(i,j,μ𝗂𝗇𝖽𝖾𝗑) where μ𝗂𝗇𝖽𝖾𝗑 a mapping such that μ𝗂𝗇𝖽𝖾𝗑:𝐗𝒫(). Namely, μ𝗂𝗇𝖽𝖾𝗑 contains the positions of the events that participates in C. One can easily see that the event-based semantics of CEL is equivalent to the position-based semantics where i-th position must be replaced by the i-th event of the stream. In other words, we have the following equivalence.

Theorem 3.

The (old) position-based semantics of CEL is equivalent to the (new) event-based semantics of CEL.

A formalization of the previous statement can be found in [8].

A new operator for projecting attributes.

An advantage of providing a new event-based semantics is that one can extend CEL with new operators, such as aggregation, which we will discuss in the next chapters. More interestingly, we can introduce new natural operators for managing complex events that cannot be defined using the old semantics in [20]. In this work, we use events instead of positions, which makes it possible to extend the CEL syntax with the attribute-projection operator, an operator for projecting tuples within complex events. Formally, we extend the syntax of CEL formulas with the following operator:

φ:=πX(a1,,ak)(φ)(tuple projection)

where φ is an arbitrary CEL formula, X is a variable in 𝐗, and a1,,ak is a list of attributes in 𝐀. Intuitively, it means that it will only consider the attributes in a1,,ak in the events that are in the variable X.

We define the formal semantics of the attribute-projection operator πX(a) recursively as follows. For a list of attributes a1,,ak and an event e, we define πa1,,ak(e) as the new event e such that 𝖠𝗍𝗍(e)=𝖠𝗍𝗍(e){a1,,ak}, e(𝗍𝗂𝗆𝖾)=e(𝗍𝗂𝗆𝖾), and e(ai)=e(ai) whenever ai𝖠𝗍𝗍(e). Let 𝒮=e1e2en where each ei is an event. Then:
πX(a1,,ak)(φ)(𝒮) ={CCφ(𝒮).𝗍𝗂𝗆𝖾(C)=𝗍𝗂𝗆𝖾(C)YX.C(Y)=C(Y)C(X)={{πa1,,ak(e)eC(X)}}}

Intuitively, given a complex event Cφ(𝒮) with C(X)={{e1,,el}}, the projection formula above creates a new complex event C which has the same interval than C and events in variables YX, but it redefines events in X as C(X)={{πa1,,ak(e1),,πa1,,ak(el)}}.

Example 4.

We consider again the setting as in Examples 1 and 2. Now we are interested in getting the price of the sale of Intel, subject to the same constraints. Then, we can write this query by using tuple projection as follows:

φ4=π𝗂𝗇𝗍𝖾𝗅(price)(SELL𝖠𝖲𝗆𝗌𝖿𝗍;SELL𝖠𝖲𝗂𝗇𝗍𝖾𝗅;SELL𝖠𝖲𝖺𝗆𝗓𝗇)𝖥𝖨𝖫𝖳𝖤𝖱(𝗆𝗌𝖿𝗍[𝗇𝖺𝗆𝖾=𝖬𝖲𝖥𝖳]𝗆𝗌𝖿𝗍[𝗉𝗋𝗂𝖼𝖾>𝟣𝟢𝟢]𝗂𝗇𝗍𝖾𝗅[𝗇𝖺𝗆𝖾=𝖨𝖭𝖳𝖢]𝖺𝗆𝗓𝗇[𝗇𝖺𝗆𝖾=𝖠𝖬𝖹𝖭]𝖺𝗆𝗓𝗇[𝗉𝗋𝗂𝖼𝖾<𝟤𝟢𝟢𝟢]).

4 Modelling aggregate functions in CER

Before introducing our logic for aggregation, we present a framework to model aggregate functions in CER based on monoids. Our goal is to present a logic that is as general as possible, encompassing most of the aggregations queries used in practice, such as 𝗌𝗎𝗆, 𝗆𝖺𝗑, 𝖼𝗈𝗎𝗇𝗍, or 𝗋𝖺𝗇𝗀𝖾. In the following, we recall the definitions of monoids and aggregate functions. We end by stating our main assumptions regarding aggregation in CER.

Monoids.

A monoid is an algebraic structure (M,,𝕆) where (M,) forms a semigroup and 𝕆M is an identity element over . Similar to semigroups, we will further assume that is commutative. For example, the natural numbers with addition (,+,0) or with product (,×,1) form commutative monoids. Other examples are ({},𝗆𝗂𝗇,) with 𝗆𝗂𝗇 and (,𝗆𝖺𝗑,0) with 𝗆𝖺𝗑. Given a commutative monoid (M,,𝕆), a finite bag A={{a1,,an}}M and a function f:MM we define the operator: aAf(a)=f(a1)f(an), namely, the generalization of from a binary operator to a set of elements. In particular, if A=, we define aAf(a)=𝕆. In the sequel, we will use (M,,𝕆) or (M,,𝟙) for denoting arbitrary commutative monoid over some set M.

Aggregate functions.

In this work, we consider the most general definition of an aggregate function that can be defined through a monoid (see [22]). Specifically, an aggregate function is a function from a bag of values to values, formally, f:𝒫bags(𝐃)𝐃 for some set of values M. An aggregate function f is self-decomposable if there exists a commutative monoid111In [22], the definition of self-decomposable is not given in terms of a monoid. However, one can easily see that the definition in [22] implies the existence of a monoid. (𝐃,,𝕆) such that f(XY)=f(X)f(Y) for every disjoint bags X,Y𝐃. Examples of functions that are self-decomposable are 𝗌𝗎𝗆, 𝗆𝖺𝗑, 𝗆𝗂𝗇, and 𝖼𝗈𝗎𝗇𝗍. For instance, 𝗌𝗎𝗆(XY) is equal to 0 if XY=, to x if XY={{x}}, and to 𝗌𝗎𝗆(X)+𝗌𝗎𝗆(Y), otherwise. Similarly, 𝖼𝗈𝗎𝗇𝗍(XY) is equal to 0 if XY=, to 1 if XY={{x}}, and to 𝖼𝗈𝗎𝗇𝗍(X)+𝖼𝗈𝗎𝗇𝗍(Y) otherwise. Finally, 𝗆𝗂𝗇(XY) is equal to if XY=, to x if XY={{x}}, and 𝗆𝗂𝗇(𝗆𝗂𝗇(X),𝗆𝗂𝗇(Y)) otherwise.

Unfortunately, in practice not all aggregate function are self-decomposable; however, most of them can still be decomposed before we apply a simple operation. Formally, an aggregate function f is called decomposable if there exist a function g:𝐃𝐃 and a self-decomposable aggregate function h such that f=gh. Furthermore, we assume that g can be computed in constant time (i.e., in the RAM model). This last condition is necessary, as we want g to perform a simple operation (i.e., constant time), as the final step after h has completed the aggregation, and not to be powerful enough to perform the aggregation itself.

Every self-decomposable functions is also decomposable (i.e., where g is the identity function). Other examples of aggregate functions that are decomposable (but not self-decomposable) are 𝖺𝗏𝗀 and 𝗋𝖺𝗇𝗀𝖾. For instance, one can define 𝖺𝗏𝗀 as 𝖺𝗏𝗀(X)=g(h(X)) where h({{x}})=(x,1) and h(XY)=h(X)+h(Y) where + is the standard pointwise sum of pairs, and g((s,c))=s/c. Another example is the 𝗋𝖺𝗇𝗀𝖾 which can be defined as 𝗋𝖺𝗇𝗀𝖾(X)=g(h(X)) such that h(x)=(x,x), h(XY)=(𝗆𝖺𝗑(XY),𝗆𝗂𝗇(XY)), and g((s,c))=sc. In both cases, one can check that h is a self-decomposable function and g can be computed in constant time in the RAM model.

Notice that, although self-decomposable functions can be decomposed through a monoid, they are not entirely specified by it (e.g., 𝖼𝗈𝗎𝗇𝗍). Nevertheless, as the following lemma shows, we can restrict to monoids by first mapping the values to the underlying monoid.

Lemma 5.

f is self-decomposable if, and only if, there exist a commutative monoid (M,,𝕆) and a function f:𝐃M such that f(X)=aXf(a) for every bag X.

Given the previous lemma, we say that f is strong self-decomposable if there exists a pair (M,f) such that M is a commutative monoid and f is the identity function. In other words, f can be directly defined by a commutative monoid. The functions that are strong self-decomposable are 𝗌𝗎𝗆, 𝗆𝗂𝗇, and 𝗆𝖺𝗑. On the other hand, 𝖼𝗈𝗎𝗇𝗍 needs to map each value to 1 before adding them.

For the sake of simplification, in the following we assume that all aggregate functions are strong self-decomposable. In other words, we can directly define the semantics of the aggregate functions through a commutative monoids. We can make this assumption since the functions f and g (i.e., of decomposable aggregate functions) can be computed in constant time when the each data item is read or after the aggregation is done, like, for example, the function f to map a single element to 1 (e.g., 𝖼𝗈𝗎𝗇𝗍), and the final function g to calculate the difference between two elements (e.g., 𝗋𝖺𝗇𝗀𝖾), or divide one by the other (e.g., 𝖺𝗏𝗀). This assumption considerably simplifies our setting, allowing us to focus on the most relevant details of aggregation without discarding relevant aggregate functions from practice.

5 Aggregation complex event logic

In this section, we present our proposal to extend CEL with aggregation. Specifically, we demonstrate how to extend CEL with an operation for aggregations, building upon previous work experience. We provide examples of how this new operator is sufficient to model most queries used in earlier works. We start by introducing the algebraic structure for modelling aggregate functions, which we then use to define the aggregation operator in CEL.

The algebraic structure for aggregation.

Recall that 𝐀 and 𝐃 are our fix sets of attributes names and data values, respectively. We fix an algebraic structure:

𝒟=(𝐃,1,,k,𝕆1,,𝕆k)

over 𝐃 such that each (𝐃,i,𝕆i) forms a commutative monoid for every i[k]. For example, ({},+,𝗆𝗂𝗇,𝗆𝖺𝗑,𝕆,,𝕆) forms such an algebraic structure where we assume that n+= for every n. Without loss of generality, we assume that NULL𝐃 and aiNULL=NULL for every a𝐃 and i[k] (if this is not the case, one can extend 𝒟 with a fresh value NULL). The purpose of NULL is to define the aggregation operator over events e where an attribute is not defined (i.e., e(a)=NULL for some a𝐀).

The single-attribute aggregation operator.

Our goal is to extend the syntax of CEL with an aggregation operator that aggregates values in a single event. For the sake of presentation, we will first introduce the operation for a single attribute to then show how to extend it to multiple attributes.

Specifically, we extend the CEL syntax with the single-attribute aggregation operator, called Aggregation CEL (ACEL), as follows:

φ:=𝙰𝚐𝚐Y[bX(a)](φ)

where φ is an arbitrary CEL formula, X and Y are variables in 𝐗, a and b are attributes names in 𝐀, and is a binary operator from 𝒟 where (𝐃,,𝟙) forms a monoid. Intuitively, the syntax Y[bX(a)] means that the aggregation will create a new event e that will be stored at the variable Y, such that e will have a single attribute b that stores the -aggregation of the a-attribute of events in X. We define the formal semantics of the single aggregation operator 𝙰𝚐𝚐 recursively as follows. Let 𝒮=e1e2en be a stream. Then:

𝙰𝚐𝚐Y[bX(a)](φ)(𝒮)={CCφ(𝒮).𝗍𝗂𝗆𝖾(C)=𝗍𝗂𝗆𝖾(C)ZY.C(Z)=C(Z)C(Y)=C(Y){{ee=[beC(X)e(a)]e(𝗍𝗂𝗆𝖾)=𝖾𝗇𝖽(C)}}}

Intuitively, given a complex event Cφ(𝒮) with C(X)={{e1,,e}}, the aggregation formula above creates a new complex event C which has the same interval and events than C except that Y has an additional event e (i.e., C(Y)=C(Y){{e}}) and e(b)=e1(a)e(a). In case that C(X)=, it will return the identity 𝟙 of . Further, the new event e has e(𝗍𝗂𝗆𝖾)=𝖾𝗇𝖽(C), namely, the last time inside C. Notice that the event e is always well-defined, since we assume that, if a is not defined for some ei, it holds that ei(a)=NULL and then e(a)=NULL.

In the following, we use some special notation for useful functions like 𝗌𝗎𝗆, 𝗆𝖺𝗑, 𝗆𝗂𝗇 instead of . For example, if we use the sum function, we write 𝙰𝚐𝚐Y[b𝗌𝗎𝗆(X(a))](φ). Further, recall that, although we use commutative monoids to define the semantics, this semantics can easily be generalized to decomposable aggregate functions like 𝖼𝗈𝗎𝗇𝗍, 𝖺𝗏𝗀, or 𝗋𝖺𝗇𝗀𝖾. Therefore, without loss of generality, we also write, for example, 𝙰𝚐𝚐Y[b𝖼𝗈𝗎𝗇𝗍(X(a))](φ) although strictly speaking 𝖼𝗈𝗎𝗇𝗍 is not a strong self-decomposable aggregate function.

Example 6.

Consider again the setting as in Examples 1 and 2. Now we are interested in getting the maximum price in a sequence of Intel sales between a Microsoft and an Amazon sale under the same constrains and store it in an attribute MAX in a variable M. Then, we can specify this query by using the aggregation operator as:
φ6=𝙰𝚐𝚐M[MAX𝗆𝖺𝗑(𝗂𝗇𝗍𝖾𝗅(price))([SELL𝖠𝖲𝗆𝗌𝖿𝗍;(SELL𝖠𝖲𝗂𝗇𝗍𝖾𝗅)+;SELL𝖠𝖲𝖺𝗆𝗓𝗇]𝖥𝖨𝖫𝖳𝖤𝖱[𝗆𝗌𝖿𝗍[𝗇𝖺𝗆𝖾=𝖬𝖲𝖥𝖳]𝗆𝗌𝖿𝗍[𝗉𝗋𝗂𝖼𝖾>𝟣𝟢𝟢]𝗂𝗇𝗍𝖾𝗅[𝗇𝖺𝗆𝖾=𝖨𝖭𝖳𝖢]𝖺𝗆𝗓𝗇[𝗇𝖺𝗆𝖾=𝖠𝖬𝖹𝖭]𝖺𝗆𝗓𝗇[𝗉𝗋𝗂𝖼𝖾<𝟤𝟢𝟢𝟢]])

As the reader can check from the semantics of 𝙰𝚐𝚐, the max value in the intel sequence will be stored in a new event at the variable M.

Example 7.

For a second example, suppose that now we are interested in getting the length of a sequence (BUY𝖮𝖱SELL) in a trend between prices 100 and 2000 and store it in an attribute QNT in a variable Q. Further, we want to also check that this length is greater than 5. Then, we can express the query as:

φ7=[𝙰𝚐𝚐M[QNT𝖼𝗈𝗎𝗇𝗍(𝗆(price))([(BUY𝖮𝖱SELL)𝖠𝖲l;(BUY𝖮𝖱SELL)+𝖠𝖲m;(BUY𝖮𝖱SELL)𝖠𝖲h]𝖥𝖨𝖫𝖳𝖤𝖱[𝗅[𝗉𝗋𝗂𝖼𝖾<𝟣𝟢𝟢]𝗆[𝗉𝗋𝗂𝖼𝖾𝟣𝟢𝟢]𝗆[𝗉𝗋𝗂𝖼𝖾𝟤𝟢𝟢𝟢]𝗁[𝗉𝗋𝗂𝖼𝖾>𝟤𝟢𝟢𝟢]])]𝖥𝖨𝖫𝖳𝖤𝖱𝖬[𝖰𝖭𝖳>𝟧]

Notice that, although in the previous example the aggregation was applied over a simple CEL formula (i.e., at the topmost level), in ACEL all operators, including the aggregation operator, can be freely composed. In particular, we can apply a filter (e.g. 𝖥𝖨𝖫𝖳𝖤𝖱𝖬.𝖰𝖭𝖳>𝟧) over an aggregation that was computed.

The multi-attribute aggregation operator.

We present now the generalization of the aggregation operator to multiple attributes. Although this generalized version is more verbose, it is needed in practice for aggregating different sets simultaneously in different attributes. We extend the syntax of CEL with the (multi-attribute) aggregation operator:

φ:=𝙰𝚐𝚐Y[b11X1(a1),,bX(a)](φ)

where φ is an arbitrary CEL formula, X1,,X and Y are variables in 𝐗, a1,,a and b1,,b are attributes names in 𝐀, and 1,, are binary operators from 𝒟. Intuitively, the syntax Y[b11X1(a1),,bX(a)] states that the aggregation will create a new event e with attributes b1,,b that will be stored at the variable Y, such that each attribute bi will store the i-aggregation of the ai-attribute of events in Xi.

Given a stream 𝒮, the formal semantics of the generalization of 𝙰𝚐𝚐 is given as follows:

𝙰𝚐𝚐Y[b11X1(a1),,bX(a)](φ)(𝒮)={CCφ(𝒮).𝗍𝗂𝗆𝖾(C)=𝗍𝗂𝗆𝖾(C)ZY.C(Z)=C(Z)C(Y)=C(Y){{ee=[b11eC(X1)e(a1),,beC(X)e(a)]e(𝗍𝗂𝗆𝖾)=𝖾𝗇𝖽(C)}}}

Intuitively, the general version of 𝙰𝚐𝚐 allows to define several attributes b1,,b by performing aggregation over the attributes a1,,a, respectively. The idea is similar to the single-attribute aggregation operator but with several attributes b1,,b at once.

In Appendix A (see also [8]), we show how to use ACEL to specify some examples from previous academic proposals and real-life systems. In particular, we present examples from the literature where the multi-attribute aggregation operator is required. Similar to the simple-attribute aggregation operator, in ACEL, one can freely compose all operators, including this new aggregation operator. We conclude this section by discussing several relevant design decisions we made in defining the aggregation operator in CEL.

Why this semantics for aggregation in CEL?

There are multiple ways to define a semantics for aggregation in CEL; however, our proposal for CEL and ACEL has some crucial design decisions that need to be justified. Specifically, we propose a semantics that (1) outputs a set of complex events (i.e., no repetitions), (2) each complex event contains bags of events, and (3) each event has a timestamp that defines the time when it arrives or was created. Indeed, we could consider other alternatives, such as a semantics that outputs bags of complex events, sets inside a complex event, or events without a timestamp, or any combination of these alternatives. In the following, we discuss why we proposed a semantics based on (1), (2), and (3), and what the consequences are of taking other alternatives.

For (1), if we choose a semantics based on bags of complex events, independent of the other choices, we will get a semantics that outputs duplicated results depending on how we specify the query. For example, assume a bag-based semantics and a user writes the query:

φ1=πX(A𝖠𝖲X;B+;A𝖠𝖲X)

over a stream 𝒮1=A1B2B3A4 where A and B are the types of the events (i.e., the data in the attributes is not relevant). If we evaluate φ1 over 𝒮1 with a bag-based semantics, we will have the same result (1,4) multiple times (potentially exponentially many times) depending on how many B were captured for each result. Instead, a set-based semantics ensures that each complex event appears only once, no matter how the query is specified.

For (2), if we choose that each variable inside a complex event maps to a set of events, instead of a bag of events, we could get some answers that do not consider some results as they will be taken as repeated elements. For example, if we consider a query:

φ2=𝙰𝚐𝚐Y(b𝗌𝗎𝗆(X(a)))[(𝙰𝚐𝚐X(a𝗌𝗎𝗆(A(value)))[B:A])]

and a stream 𝒮2=B1A2[a:3]A3[a:5]B4A5[a:2]A6[a:4]A7[a:2], first we will get two matches (one from B1A2A3 and the other from B4A5A6A7), then we will make the aggregation in each of them, but the result of each aggregation is the same (i.e., 8), they come from different values and they will not be saved as two different values, so finally the outer aggregation will be applied over one element and not two.

Finally, for (3), if we consider that each event that arrives or is created does not have a timestamp (i.e., a mark of origin), then we can still lose some information during aggregation (even if we used bags inside complex events to store events). For example, consider the query

φ3=(𝙰𝚐𝚐Y(b𝗌𝗎𝗆(X(a)))(X);ψ1)𝖮𝖱(ψ2;𝙰𝚐𝚐Y(b𝗌𝗎𝗆(W(a)))(W))

for some subformulas ψ1 and ψ2. For formula φ3 over some stream, the results of the aggregation in the left and right parts of the disjunction (i.e., 𝖮𝖱) could be equal, and it will be impossible to differentiate which part the aggregation is coming from when we apply the 𝖮𝖱 operator. Instead, by assuming that each event has a timestamp (even those created through aggregation), for φ3, there will be at least two outputs, and we can differentiate the position where the aggregation was performed.

It is important to note that another semantics for CEL and the aggregation operator is possible, and our argument above does not invalidate them. However, there could be consequences for the query language with unintuitive behavior for the users. In this work, we have chosen to focus on a semantics based on (1), (2), and (3), studying its properties, and reserve the study of other variants of the logic for future work.

Expressive power of ACEL.

When introducing a new operator, such as aggregation, one wants it to model only what it is meant to; however, combining it with other operators can lead to unexpected properties that can be expressed. In particular, combining the aggregate operator with filters is very powerful, as it allows one to check equivalence between events. For example, consider the following query with aggregation and filtering:

πX,Y(𝙰𝚐𝚐Z(b1𝗌𝗎𝗆(X(a)),b2𝗌𝗎𝗆(Y(a)))(R𝖠𝖲X;T𝖠𝖲Y)𝖥𝖨𝖫𝖳𝖤𝖱[Z(b1=b2)])

Intuitively, the previous query checks that an event of type T (naming it Y) happens after an event of type R (naming it X) and 𝗌𝗎𝗆 the values of attribute a in both events separately, saving those values in attributes b1 and b2 of variable Z in one event. Then, the query filters it by checking if the values of attributes b1 and b2 are equal, as they correspond to the same event. Finally, it projects variables X and Y. One can see that the query correlates events from different types only using aggregation and filter operators over single events, as it generates two new variables in an event with the aggregation, that come from two different events, and then it uses filter which only is applied to a single event.

This unexpected behaviour of combining aggregation with filtering is an interesting side effect that could lead to a better understanding of aggregation in CER. Note that observing this interaction between aggregates, filters, and other operators will not be possible without having a concrete and formal semantics of the query language.

6 Automata model for aggregation in CER

Here we present an automata model for aggregation that extends complex event automata with registers similar to the model of cost register automata [4]. We start by recalling the model of complex event automata (CEA) to provide then the necessary definitions for introducing our new automata model for aggregation.

CEA.

A Complex Event Automaton (CEA) [20, 9] is a tuple 𝒜=(Q,Δ,q0,F) where Q is a finite set of states, ΔQ×𝐏×𝒫(𝐗)×Q is a finite transition relation, q0Q is the initial state, and FQ is the set of final states. A run of 𝒜 over stream 𝒮=e1en from positions i to j is a sequence of transition:

ρ:=qiPi/Liqi+1Pi+1/Li+1Pj/Ljqj+1

such that qi=q0 is the initial state of 𝒜 and for every k[i..j] it holds that (qk,Pk,Lk,qk+1)Δ and ekPk. A run ρ is accepting if qj+1F. An accepting run ρ of 𝒜 over 𝒮 from i to j naturally defines the complex event Cρ:=(i,j,μρ) such that μρ(X)={ekikjXLk} for every X𝐗. If position i and j are clear from the context, we say that ρ is a run of 𝒜 over 𝒮. Finally, we define the semantics of 𝒜 over a stream 𝒮 as: 𝒜(𝒮):={Cρρ is an accepting run of 𝒜 over S}.

CEA was crucial to capture the expressiveness of CEL, compile queries from CEL into CEA, and efficiently evaluate them. Unfortunately, one can easily notice that CEA are not useful for our ACEL semantics, since there is no way to remember the values of the attributes that we have seen to do the aggregation. In other words, there is no mechanism for aggregating values and producing new events as in the new semantics of ACEL. We will show how to overcome these shortcomings in the next definitions.

Expressions.

Recall that 𝐀 is a fixed set of attributes and 𝐃 a fix set of data values. Further, recall that in Section 5 we fix an algebraic structure of the form () over 𝐃 such that each (𝐃,i,𝕆i) forms a commutative monoid for every i[k]. We define an (𝒟,𝐀)-expression e (or just expression) as a syntactical formula over 𝒟 and 𝐀 generated by the grammar:

α:=daαiαi[k]

where d𝐃 and a𝐀. We define the set of all (𝒟,𝐀)-expressions by 𝖤𝗑𝗉𝗋(𝒟,𝐀). For any expression α𝖤𝗑𝗉𝗋(𝒟,𝐀) we denote by 𝖠𝗍𝗍(α) the set of all attributes in α. Given an event e:𝐀𝐃 and an expression α such that 𝖠𝗍𝗍(α)𝖠𝗍𝗍(e), we define the semantics of α over e, denoted by α(e), as the value in 𝐃 of evaluating α by replacing every a𝐀 by e(a).

Example 8.

Let 𝒟=(𝐃,𝗆𝗂𝗇,𝗆𝖺𝗑,+,,0,0), the expressions α=a+b and β=𝗆𝗂𝗇(a,b)+𝗆𝖺𝗑(b,c), and an event e where e(a)=4, e(b)=2 and e(c)=5. Then the result of each expression α and β over the event e are α(e)=6 and β(e)=7, respectively.

Assignments.

An (𝒟,𝐀)-assignment (or just assignment when 𝒟 and 𝐀 are clear from the context) is a program that assigns attributes in 𝐀 to expressions in 𝖤𝗑𝗉𝗋(𝒟,𝐀). Formally, an assignment is defined as a mapping σ:𝐀𝖤𝗑𝗉𝗋(𝒟,𝐀). Similar to expressions, we define 𝖠𝗍𝗍𝗂𝗇(σ)=a𝖽𝗈𝗆(σ)𝖠𝗍𝗍(σ(a)) to be all the attributes used in expressions of σ, and 𝖠𝗍𝗍𝗈𝗎𝗍(σ)=𝖽𝗈𝗆(σ) all the attributes that are assigned. Given an event e:𝐀𝐃 and an (𝒟,𝐀)-assignment σ such that 𝖠𝗍𝗍𝗂𝗇(σ)𝖠𝗍𝗍(e), the semantics of an assignment σ over e is an event e:=σ(e):𝐀𝐃 such that 𝖠𝗍𝗍(e)=𝖠𝗍𝗍𝗈𝗎𝗍(σ) and e(a)=σ(a)(e) for every a𝖠𝗍𝗍𝗈𝗎𝗍(σ). In other words, σ(e) is the result of applying the assignment σ with the values in the event e. We denote the set of all (𝒟,𝐀)-assignments by 𝖠𝗌𝗀(𝒟,𝐀).

Example 9.

Consider again the setting of Example 8 and the assignment σ defined as: σ:a𝗆𝖺𝗑(a+b,c). Here, we think σ as a program where the left side of is updated with the right side, namely, σ(a)=𝗆𝖺𝗑(a+b,c). Then, [σ(e)](a)=6.

Finally, we recall the notion of renamings (Section 3) and define updates of events that will be useful for our automata model. So, remember that a renaming r is defined as r:𝐀𝐀, which maps each attribute to a new attribute. We can note that a renaming is also a particular case of an assignment r:𝐀𝖤𝗑𝗉𝗋(𝒟,𝐀) such that r(a)𝐀. Also, recall that we define by 𝖱𝖾𝗇 the set of all tuple renaming over 𝐀. Given events e and e, we define the update of e by e, denoted by ee, as a new event such that 𝖠𝗍𝗍(ee)=𝖠𝗍𝗍(e)𝖠𝗍𝗍(e) and [ee](a)=e(a) if a𝖠𝗍𝗍(e), and [ee](a)=e(a) otherwise.

Aggregation Complex Event Automata.

We are ready to define the model of CEA with aggregation. An Aggregation Complex Event Automaton (ACEA) is a tuple 𝒜=(Q,Δ,q0,F) where Q is a finite set of states, q0Q is the initial state, FQ are the final states, and:

ΔQ×𝖠𝗌𝗀(𝒟,𝐀)×𝐏×{λ:𝐗𝒫bags(𝖱𝖾𝗇)}×Q

is a finite transition relation where {λ:𝐗𝒫bags(𝖱𝖾𝗇)} is the set of all mappings λ that maps a variable X to a finite bag of renamings {{r1,,rk}}. A transition (p,σ,P,λ,q)Δ specifies that 𝒜 can move from state p to state q after reading an event, by updating some internal registers with σ and checking a condition (over the registers) with P. Similar to CEA, λ will be in charge of creating the outputs of the complex event where the renamings λ(X)={{r1,,rk}} will create k new tuples in the variable X coming from the values stored in the internal registers. We assume that the renamings in λ for a transition of the form (p,σ,P,λ,q)Δ are consistent with σ, namely, 𝖠𝗍𝗍𝗂𝗇(λ(X))𝖽𝗈𝗆(σ) for every X𝖽𝗈𝗆(λ).

A pair (q,ν) is a configuration of 𝒜 where qQ and ν:𝐀𝐃 is an event which represents the current values of the attributes. For the sake of simplification, in ACEA, we use attributes as “registers” for storing temporary values. For this reason, the configuration (q,ν) represents that the automata is in the state q and the registers 𝖽𝗈𝗆(ν) (i.e., a subset of attributes) store the current computed values.

Let 𝒮=e1en be a stream. A run of 𝒜 over stream S from positions i to j is a sequence of configurations and transitions:

ρ:=(qi,νi)σi,Pi/λi(qi+1,νi+1)σi+1,Pi+1/λi+1σj,Pj/λj(qj+1,νj+1)

such that qi is the initial state q0, νi is the empty event (i.e., 𝖽𝗈𝗆(νi)=), and for every k[i..j], (qk,σk,Pk,λk,qk+1)Δ, (qk+1,νk+1) is a configuration of 𝒜 with νk+1:=σk(ekνk), and νk+1Pk. Also, it must hold that 𝖠𝗍𝗍𝗂𝗇(σk)𝖽𝗈𝗆(ekνk). Intuitively, the new values νk+1 are produced by first updating νk by the new event ek (i.e., ekνk) and then operate ekνk by the assignment σk. After the new values νk+1 are computed, we check if they satisfy the predicate Pk of the transition.

Similar to CEA, a run ρ is accepting if qj+1F. An accepting run ρ like () of 𝒜 over 𝒮 from i to j defines the complex event Cρ:=(i,j,μρ) such that:

μρ(X)={{ek[i..j]rλk(X)e=r(νk+1)e(𝗍𝗂𝗆𝖾)=k}}

for every X𝐗. Finally, we define the semantics of 𝒜 over a stream 𝒮 as:

𝒜(𝒮):={Cρρ is an accepting run of 𝒜 over S}.
Figure 2: An ACEA 𝒜 representing the given query in Example 6 where P1:=n=𝖬𝖲𝖥𝖳p>𝟣𝟢𝟢, P2:=n=𝖨𝖭𝖳𝖢 and P3:=n=𝖠𝖬𝖹𝖭p<𝟤𝟢𝟢𝟢. Further, λ1(𝗆𝗌𝖿𝗍)=λ2(𝗂𝗇𝗍𝖾𝗅)=λ3(𝖺𝗆𝗓𝗇)={{[𝗇𝖺𝗆𝖾n,𝗉𝗋𝗂𝖼𝖾p]}}, and λ3(𝖬)={{[𝖬𝖠𝖷m]}}.
Example 10.

Consider the ACEL query from Example 6. We can obtain the same result with the ACEA 𝒜 in Figure 2 where P1:=n=𝖬𝖲𝖥𝖳p>𝟣𝟢𝟢, P2:=n=𝖨𝖭𝖳𝖢 and P3:=n=𝖠𝖬𝖹𝖭p<𝟤𝟢𝟢𝟢. Further, λ1(𝗆𝗌𝖿𝗍)=λ2(𝗂𝗇𝗍𝖾𝗅)=λ3(𝖺𝗆𝗓𝗇)={{[𝗇𝖺𝗆𝖾n,𝗉𝗋𝗂𝖼𝖾p]}}, and λ3(𝖬)={{[𝖬𝖠𝖷m]}}. Intuitively, in the first transition, 𝒜 initializes a register m (i.e., an attribute) with 0 and checks that the price and name attributes satisfy the predicate P1, by storing the name in n and the price in p. Then, it waits in q2 maintaining the registers. After, in the next transition it updates the maximum value in m with the new price and again checks that the name satisfies P2. Then, in the loop of q3, it repeats the same as the previous transition or it maintains the registers. Finally, in the last transition, it maintains the maximum value in m and verifies that the attributes name and price satisfy P3. The mappings λ1, λ2, and λ3 are in charge of outputting the events in variables 𝗆𝗌𝖿𝗍, 𝗂𝗇𝗍𝖾𝗅, and 𝖺𝗆𝗓𝗇, respectively. Further, λ3 is in charge of producing the final event in variable M that contains the max-aggregate of Intel’s prices.

A first natural question to answer is whether the expressive power of the new model ACEA includes queries defined by CEA or not. Similar to the question of ACEL versus CEL, CEA outputs complex events with positions, where our new model outputs complex events with events among other new features. Below, we show that a ACEA can define every CEA by mapping the positions of the stream to the events.

Theorem 11.

ACEA can define the same as CEA over streams over a schema Σ, namely, for every CEA 𝒜 there exists an ACEA 𝒜 such that 𝒜(𝒮)=𝒜(𝒮) for every 𝒮 over Σ.

Equivalence with ACEL.

The first main goal of this paper is to provide a query language with a formal and denotational semantics for performing aggregation in CER. The second main goal is to provide a computational model to compile queries from this language. In the following result, we show that ACEA is a computational model to fulfill this goal. Specifically, we show that every formula φ in ACEL can be compiled into a ACEA, proving that the model has all the feature to perform complex event extraction and aggregation.

Theorem 12.

Let Σ be a schema. For every ACEL formula φ, there exists an ACEA 𝒜φ such that φ(𝒮)=𝒜φ(𝒮) for every stream 𝒮 over Σ.

We present the proof in [8]. It goes by induction over the formula showing how to compile each operator into an ACEA. The standard CEL operators follow a similar construction to that in [20] (except the AND operator), but here we also have to make sure that the registers are correctly maintained to produce the output.

It is important to remark that ACEA is a hybrid automata model that needs to perform computation (i.e., for the aggregation), check filters (i.e., for the predicates), and produce outputs (i.e., events). Therefore, in designing the model, we seek an equilibrium that fulfills all these goals and, simultaneously, is as simple as possible. This simplicity could be helpful for understanding its expressiveness and designing efficient evaluation algorithms.

Despite its simplicity, ACEA has more expressive power than ACEL, namely, there are queries that can be defined with ACEA but not with ACEL. For example, consider the monoid of natural numbers (,+,0) (i.e., 𝗌𝗎𝗆). Given a stream R[a:1]n-timesR[a:1], one can define an ACEA with one register that always doubles the current value and outputs its content in an event [b:2n]. Intuitively, ACEL with (,+,0) cannot specify this query since it can only produce values that grow linearly with respect to the sum of all values in the stream. Even if we restrict the use of registers in a copyless manner (see copyless cost register automaton in [4]), one can design ACEA that cannot be specified by ACEL. For instance, given the previous stream, one can code an ACEA that produces a complex event with the sequence of events: [b:1][b:2][b:n] (i.e., by adding in a register the input values and outputting its content in each transition). Given that in ACEL, each value of an event can contribute to a finite number of new events, one cannot specify this in ACEL. Therefore, ACEA is more expressive than ACEL, and it is an interesting open problem to characterize ACEL in terms of restrictions over ACEA. We leave this problem for future work.

7 Future Work

This paper provides logical foundations for aggregation in CER but leaves several open problems for future work. One relevant open problem is to better understand the equivalence between ACEL and ACEA, namely, which ACEA can be written in ACEL. Another interesting question is to understand the expressive power of aggregation combined with filters and other operators (see Section 5). Finally, a crucial line of research for making ACEL work in practice is to study how to evaluate ACEL queries efficiently, finding enumeration algorithms that, given an ACEA and a stream, run with constant update time and constant delay enumeration.

References

  • [1] Esper Enterprise Edition Website. https://www.espertech.com/, 2025. [Accessed 23-06-2025].
  • [2] Asaf Adi and Opher Etzion. Amit-the situation manager. The VLDB journal, 13:177–203, 2004.
  • [3] Alfred V Aho and John E Hopcroft. The design and analysis of computer algorithms. Pearson Education India, 1974.
  • [4] Rajeev Alur, Loris D’Antoni, Jyotirmoy V. Deshmukh, Mukund Raghothaman, and Yifei Yuan. Regular functions and cost register automata. In LICS, pages 13–22, 2013. doi:10.1109/LICS.2013.65.
  • [5] Alexander Artikis, Alessandro Margara, Martín Ugarte, Stijn Vansummeren, and Matthias Weidlich. Complex event recognition languages: Tutorial. In DEBS, pages 7–10. ACM, 2017. doi:10.1145/3093742.3095106.
  • [6] Mikołaj Bojańczyk. Transducers with origin information. In ICALP, pages 26–37, 2014.
  • [7] Kyle Bossonney, Nicolás Buzeta, Vicente Calisto, Juan-Eduardo López, Cristian Riveros, and Stijn Vansummeren. CORE+: A complex event recognition engine in C++. In SIGMOD demo, pages 47–50, 2025. doi:10.1145/3722212.3725090.
  • [8] Pierre Bourhis, Cristian Riveros, and Amaranta Salas. A formal query language and automata model for aggregation in complex event recognition. CoRR, abs/2601.00967, 2026.
  • [9] Marco Bucchi, Alejandro Grez, Andrés Quintana, Cristian Riveros, and Stijn Vansummeren. CORE: a complex event recognition engine. VLDB, 15(9):1951–1964, 2022. doi:10.14778/3538598.3538615.
  • [10] Gianpaolo Cugola and Alessandro Margara. Raced: an adaptive middleware for complex event detection. In ARM, pages 1–6, 2009.
  • [11] Gianpaolo Cugola and Alessandro Margara. TESLA: a formally defined event specification language. In DEBS, pages 50–61. ACM, 2010. doi:10.1145/1827418.1827427.
  • [12] Gianpaolo Cugola and Alessandro Margara. Processing flows of information: From data stream to complex event processing. ACM Computing Surveys (CSUR), 44(3):1–62, 2012. doi:10.1145/2187671.2187677.
  • [13] Alan J. Demers, Johannes Gehrke, Biswanath Panda, Mirek Riedewald, Varun Sharma, and Walker M. White. Cayuga: A general purpose event monitoring system. In CIDR, pages 412–422, 2007. URL: http://cidrdb.org/cidr2007/papers/cidr07p47.pdf.
  • [14] Yanlei Diao, Neil Immerman, and Daniel Gyllstrom. SASE+: An agile language for kleene closure over event streams. UMass Technical Report, 2007.
  • [15] Antony Galton and Juan Carlos Augusto. Two approaches to event definition. In DEXA, pages 547–556, 2002. doi:10.1007/3-540-46146-9_54.
  • [16] Julián García and Cristian Riveros. Complex event recognition under time constraints: Towards a formal framework for efficient query evaluation. Proc. ACM Manag. Data, 3(2):94:1–94:17, 2025. doi:10.1145/3725231.
  • [17] Nikos Giatrakos, Elias Alevizos, Alexander Artikis, Antonios Deligiannakis, and Minos Garofalakis. Complex event recognition in the big data era: a survey. The VLDB Journal, 29:313–352, 2020. doi:10.1007/S00778-019-00557-W.
  • [18] Michel Grabisch, Jean-Luc Marichal, Radko Mesiar, and Endre Pap. Aggregation functions, volume 127. Cambridge University Press, 2009.
  • [19] Alejandro Grez, Cristian Riveros, and Martín Ugarte. A formal framework for complex event processing. In ICDT, volume 127, pages 5:1–5:18, 2019. doi:10.4230/LIPIcs.ICDT.2019.5.
  • [20] Alejandro Grez, Cristian Riveros, Martín Ugarte, and Stijn Vansummeren. A formal framework for complex event recognition. ACM TODS, 46(4):16:1–16:49, 2021. doi:10.1145/3485463.
  • [21] Mikell P Groover. Automation, production systems, and computer-integrated manufacturing. Pearson Education India, 2016.
  • [22] Paulo Jesus, Carlos Baquero, and Paulo Sérgio Almeida. A survey of distributed data aggregation algorithms. IEEE Communications Surveys & Tutorials, 17(1):381–404, 2014. doi:10.1109/COMST.2014.2354398.
  • [23] Lei Ma, Chuan Lei, Olga Poppe, and Elke A Rundensteiner. Gloria: Graph-based sharing optimizer for event trend aggregation. In SIGMOD, pages 1122–1135, 2022. doi:10.1145/3514221.3526145.
  • [24] Biswanath Mukherjee, L Todd Heberlein, and Karl N Levitt. Network intrusion detection. IEEE network, 8(3):26–41, 1994. doi:10.1109/65.283931.
  • [25] Peter R Pietzuch, Brian Shand, and Jean Bacon. A framework for event composition in distributed systems. In Middleware, pages 62–82. Springer, 2003. doi:10.1007/3-540-44892-6_4.
  • [26] Manolis Pitsikalis, Alexander Artikis, Richard Dreo, Cyril Ray, Elena Camossi, and Anne-Laure Jousselme. Composite event recognition for maritime monitoring. In DEBS, pages 163–174, 2019. doi:10.1145/3328905.3329762.
  • [27] Olga Poppe, Chuan Lei, Lei Ma, Allison Rozet, and Elke A Rundensteiner. To share, or not to share online event trend aggregation over bursty event streams. In SIGMOD, pages 1452–1464, 2021. doi:10.1145/3448016.3452785.
  • [28] Olga Poppe, Chuan Lei, Elke A. Rundensteiner, and David Maier. GRETA: graph-based real-time event trend aggregation. VLDB, 11(1):80–92, 2017. doi:10.14778/3151113.3151120.
  • [29] Olga Poppe, Chuan Lei, Elke A Rundensteiner, and David Maier. Event trend aggregation under rich event matching semantics. In SIGMOD, pages 555–572, 2019. doi:10.1145/3299869.3319862.
  • [30] BS Sahay and Jayanthi Ranjan. Real time business intelligence in supply chain analytics. Information Management & Computer Security, 16(1):28–48, 2008. doi:10.1108/09685220810862733.
  • [31] Nicholas Poul Schultz-Møller, Matteo Migliavacca, and Peter Pietzuch. Distributed complex event processing with query rewriting. In DEBS, pages 1–12, 2009.
  • [32] Luc Segoufin. Enumerating with constant delay the answers to a query. In ICDT, pages 10–20, 2013. doi:10.1145/2448496.2448498.
  • [33] Walker White, Mirek Riedewald, Johannes Gehrke, and Alan Demers. What is “next” in event processing? In PODS, pages 263–272, 2007. doi:10.1145/1265530.1265567.
  • [34] Eugene Wu, Yanlei Diao, and Shariq Rizvi. High-performance complex event processing over streams. In SIGMOD, pages 407–418, 2006. doi:10.1145/1142473.1142520.
  • [35] Haopeng Zhang, Yanlei Diao, and Neil Immerman. On complexity and optimization of expensive queries in complex event processing. In SIGMOD, 2014.
  • [36] Detlef Zimmer and Rainer Unland. On the semantics of complex events in active database management systems. In ICDE, pages 392–399, 1999. doi:10.1109/ICDE.1999.754955.

Appendix A Examples from practice

In the following, we present several queries obtained from the literature and show how to model them with ACEL. Given the operators introduced in the previous sections, recall that we define ACEL as any formula φ that uses the standard operators of CEL (Section 2), the aggregation operator 𝙰𝚐𝚐 (Section 5), or a combination of them. We start this section by introducing some new operators and predicates that work as syntax sugar for ACEL to define practical queries. Then we present three queries with aggregation obtained from three different CER proposals and specify them by using ACEL.

A.1 Useful operators in ACEL for specifying real-life queries

To specify CER queries in practice, the following operator will be useful. Let R be any event type. We define the ACEL formula 𝙽𝙴𝚇𝚃(R) with CEL such that:

𝙽𝙴𝚇𝚃(R)πR((X+:R)𝖥𝖨𝖫𝖳𝖤𝖱X[𝗍𝗒𝗉𝖾R])𝖮𝖱R

where we assume that R can also be used as a variable name (i.e., R𝐗). In other words, 𝙽𝙴𝚇𝚃(R) finds the first event of R-type in an interval and discard all other events in between. As an example, one can use this operator to succinctly define the CEL query S:𝙽𝙴𝚇𝚃(R) that finds all S-events directly followed by an R event. We define this operator for its later use in examples appearing from other systems.

Let a be an attribute. We also define some auxiliary predicates that will be use with the 𝖥𝖨𝖫𝖳𝖤𝖱 operator to correlate two or more events. Recall that we define a predicate P as a possibly infinite subset of events and we generalize P from events to a multiset of events E𝐄 such that EP if, and only if, eP for every eE. For specifying queries in practice, we need some special multisets predicates that cannot be defined directly as a generalization of normal predicates. Formally, a multiset predicate P is a subset of multisets of events, namely, P𝒫bags(𝐄). For example, the generalization of an (event) predicate to multisets of events is a multiset predicate. These multisets predicates defined below will allow us to (1) ensure that the pattern has the same value at attribute a, (2) the value of an attribute is increasing, or (3) the value of an attribute is decreasing, respectively. More specifically, we define the following three multiset predicates. For a multiset of events E and two events e1,e2E, let 𝖲𝗎𝖼𝖼E(e1,e2) be the logical formula that checks if e2 is the successor of e1 in E, formally, e1(𝗍𝗂𝗆𝖾)<e2(𝗍𝗂𝗆𝖾) and there does not exist e3E such that e1(𝗍𝗂𝗆𝖾)<e3(𝗍𝗂𝗆𝖾) and e3(𝗍𝗂𝗆𝖾)<e2(𝗍𝗂𝗆𝖾).

  1. 1.

    We define the auxiliary predicate [a] as:

    [a]:={E𝒫bags(𝐄)e1,e2E.e1(a)=e2(a)}
  2. 2.

    We define the auxiliary predicate [𝗂𝗇𝖼𝗋𝖾𝖺𝗌𝗂𝗇𝗀(a)] as:

    [𝗂𝗇𝖼𝗋𝖾𝖺𝗌𝗂𝗇𝗀(a)]:={E𝒫bags(𝐄)e1,e2E.𝖲𝗎𝖼𝖼E(e1,e2)e1(a)<e2(a)}
  3. 3.

    Finally, we define the auxiliary predicate [𝖽𝖾𝖼𝗋𝖾𝖺𝗌𝗂𝗇𝗀(a)] as:

    [𝖽𝖾𝖼𝗋𝖾𝖺𝗌𝗂𝗇𝗀(a)]:={E𝒫bags(𝐄)e1,e2E.𝖲𝗎𝖼𝖼E(e1,e2)e1(a)>e2(a)}

Following ACEL syntax and semantics, we use the above predicates with variables in 𝐗. For example, we write φ𝖥𝖨𝖫𝖳𝖤𝖱X[a] to define that all events in variable X must satisfy [a]. Similar as for standard predicates, we use conjunction and disjunction in 𝖥𝖨𝖫𝖳𝖤𝖱 as a syntax sugar for composing filters or using 𝖮𝖱, respectively.

In the following we provide several examples from previous literature and how we can specify them by using ACEL.

Example 13.

We use as an example an adaptation of a query extracted from ESPER’s documentation [1], which says:

“This example statement demonstrates the idea by selecting a total price per customer over pairs of events (ServiceOrder followed by a ProductOrder event for the same customer id within 1 minute), occurring in the last 2 hours, in which the sum of price is greater than 100, and using a where clause to filter on name.”

The difference between this example and the original one is that we do not consider group-by, window and slide operators and a slightly different filter. The query in ESPER’s query language is the following:

Q13: SELECT a.custId, sum(a.price + b.price) FROM PATTERN [every a=ServiceOrder -> b=ProductOrder(custId = a.custId)] WHERE a.name in (b.name) HAVING sum(a.price + b.price) > 100

We can define Q2 by using ACEL as follows:

φ13=[𝙰𝚐𝚐Y(e𝗌𝗎𝗆(X(price)))([(𝖲𝖾𝗋𝗏𝗂𝖼𝖾𝖮𝗋𝖽𝖾𝗋𝖠𝖲a;𝖯𝗋𝗈𝖽𝗎𝖼𝗍𝖮𝗋𝖽𝖾𝗋𝖠𝖲b)+𝖠𝖲X]𝖥𝖨𝖫𝖳𝖤𝖱(X[𝗇𝖺𝗆𝖾])X[𝖼𝗎𝗌𝗍𝖨𝖽])]𝖥𝖨𝖫𝖳𝖤𝖱Y[𝖾>100]
Example 14.

We use as an example an adaptation of query “q3” extracted from HAMLET’s paper [27, p. 1], which says

“All events in a trip must have the same driver and rider identifiers as required by the predicate [driver, rider] (…). Query q3 tracks riders who cancel their accepted requests while the drivers were stuck in slow-moving traffic. All three queries contain the expensive Kleene sub-pattern T+ that matches arbitrarily long event trends.”

The difference between this example and the original one is that this does not considers within, slide and group-by operators.

Q14: RETURN T.district, COUNT(*), SUM(T.duration) PATTERN SEQ(Request R, Travel T+, Cancel C) WHERE [driver, rider]

A formula equivalent to the previous query in CEL with aggregation could be the following:

φ14=𝙰𝚐𝚐Y[e𝗌𝗎𝗆(T(𝖽𝗎𝗋𝖺𝗍𝗂𝗈𝗇)),f𝖼𝗈𝗎𝗇𝗍(C(𝖽𝗋𝗂𝗏𝖾𝗋))][((𝖱𝖾𝗊𝗎𝖾𝗌𝗍𝖠𝖲R;𝖳𝗋𝖺𝗏𝖾𝗅𝖠𝖲T+;𝖢𝖺𝗇𝖼𝖾𝗅𝖠𝖲C)𝖠𝖲X)+]𝖥𝖨𝖫𝖳𝖤𝖱X[𝖽𝗋𝗂𝗏𝖾𝗋]X[𝗋𝗂𝖽𝖾𝗋]
Example 15.

We use as an example an adaptation of the query “q1” extracted from COGRA’s paper [29, p. 1], which says:

“Query q1 detects minimal and maximal heartbeat during passive physical activities (e.g., reading, watching TV). Query q1 consumes a stream of heart rate measurements of intensive care patients. Each event carries a time stamp in seconds, a patient identifier, an activity identifier, and a heart rate. For each patient, q1 detects contiguously increasing heart rate measurements during a time window of 10 minutes that slides every 30 seconds. No measurements may be skipped in between matched events per patient, as expressed by the contiguous semantics.”

The difference between this example and the original one is that this version does not considers within, group-by, and slide operators. The query is:

Q15: RETURN patient, MIN(M.rate), MAX(M.rate) PATTERN Measurement M+ SEMANTICS contiguous WHERE [patient] AND M.rate < NEXT(M).rate AND M.activity = passive

An ACEL formula equivalent to the previous query could be the following:

φ15=𝙰𝚐𝚐Y[e𝗆𝗂𝗇(M(𝗋𝖺𝗍𝖾)),f𝗆𝖺𝗑(M(𝗋𝖺𝗍𝖾))][(𝖬𝖾𝖺𝗌𝗎𝗋𝖾𝗆𝖾𝗇𝗍𝖠𝖲M)𝖥𝖨𝖫𝖳𝖤𝖱M[𝗉𝖺𝗍𝗂𝖾𝗇𝗍]M[𝗂𝗇𝖼𝗋𝖾𝖺𝗌𝗂𝗇𝗀(𝗋𝖺𝗍𝖾)]M.𝖺𝖼𝗍𝗂𝗏𝗂𝗍𝗒=“passive”]

One can check that formula φ3 specifies the same query as Q3 with the difference is that φ3 has a formal and denotational semantics.

More examples can be found in [8]. Finally, it is important to note that we also consider examples of other proposals (e.g., CAYUGA [13]) that use aggregation; however, their query languages are procedural, and they do not adapt to the concept of declarative aggregation that we use in this work.