1 Introduction
Complex Event Recognition (CER) is a key ingredient of many contemporary Big Data applications that require the processing of event streams in order to obtain timely insights and implement reactive and proactive measures. Examples of such applications include the recognition of: attacks in computer networks [9, 8]; human activities in video content [17]; traffic incidents in smart cities [5]; and opportunities in the stock market [18], among others.
To support the abovementioned application scenarios, numerous CER systems and languages have been proposed in the literature—see e.g., the surveys [11, 4] and the references therein. As noted by Cugola and Margara [11], however, the literature focuses mostly on the practical system aspects of CER, resulting in many heterogeneous implementations with sometimes fundamentally different capabilities. As a result, little work has been done on the formal foundations of CER. Consequently, and in contrast to the situation for relational databases, we currently lack a common understanding of the tradeoffs between expressiveness and complexity in the design of CER languages, as well as an established theory for optimizing CER queries. In fact, it is rare to even find a formal definition of a CER language, let alone a formal development of its theory.
Towards a better understanding of the formal foundations of CER, a subset of the authors has recently proposed and studied a formal logic that captures the core features found in most CER languages [16]. This logic, which we will call in this paper, combines the regular expression operators (sequencing, to require that some pattern occurs before another somewhere in a stream; iteration, to recognize a pattern a number of times; and disjunction) with data filtering features as well as limitedD data outputting capabilities. follows the approach that seems to be taken by most of the CER literature (e.g., [13, 14, 2, 23, 10], see also [11]) in that data filtering is supported by binding variables to individual events in the stream, which can later be inspected by means of one or more predicates. In this respect, variables in are first order variables, since they bind to individual events. The firstorder nature of variables in CER languages found in the literature on which is based is problematic for two reasons. (1) It interacts awkwardly with pattern iteration (i.e., Kleene closure): if a variable is bound inside Kleene closure, what does the variable refer to when used outside of a Kleene closure? (2) There is an inherent asymmetry between the objects manipulated by the CER language (i.e. individual events bound to first order variables) and the objects that are output by the language (complex events, where one often wants to include the set of all matched primitive events). Both of these issues cause , and the practical languages on which it is inspired, to have rather awkward variablescoping rules and a sometimes unexpected semantics. In a sense, the language becomes quite closely tied to a specific evaluation model. From a query language viewpoint, this is undesirable since it restricts the declarative nature of the language, and hence restricts its optimization and evaluation opportunities.
In this paper, we propose to unify the mechanics of data filtering and output by using second order variables that bind sets of events in a stream. This allows us to introduce a CER language with simple and intuitive semantics, which we call . We study the expressive power of this language and its computational capabilities. Our results are as follows.

We first compare against and show that they are equivalent in expressive power when equipped with the same unary predicates but, surprisingly, incomparable when equipped with ary predicates, . In particular, when equipped with sets of binary predicates, is strictly more expressive than . Conversely, when equipped with sets of ternary predicates, the languages are incomparable. (Section 4.)

To get a fundamental understanding of the expressive power, computational capabilities, and limitations of the basic operators of we then restrict our attention to unary predicates. We compare with such predicates against a computational model for detecting complex events that we call Unary Complex Event Automata (UCEA for short). We show that, in this setting, is strictly weaker than UCEA, but captures the subclass of UCEA that satisfy the socalled *property. Intuitively, this property indicates that the UCEA can only make decisions based on events that are part of the output. As a byproduct of our development we are able to show that certain additional CER operators that have been proposed in the literature, such as and are nonprimitive in while others, such as , are primitive. (Section 5)

Finally, we identify the operations that is lacking to capture UCEA and introduce a natural extension of the language that captures the complete class of UCEA under unary predicates. As a result we are also able to give insight into the selection policy that is supported by some CER languages. (Section 6.)
We intuitively motivate in Section 2 and give its formal definition in Section 3.
Related Work. As already mentioned, the focus in the majority of the CER literature is on the systems aspects of CER rather than on the foundational aspects. A notable exception is the work by Zhang et al on Sase [23], which considers the descriptive complexity of a core CER language. It is unfortunate, however, that this paper lacks a formal definition of the language under study; and ignores in particular the aforementioned issues related to the scoping of variables under Kleene closure, as well as the data output capabilities.
While several automata models for CER have been proposed before [2, 23, 12, 14, 10], these models are all limited in the sense that automata are required to adhere to strict topological constraints. Often, an automaton needs to be a single path from initial to final state, possibly with selfloops on the nodes in the path. In addition, as shown in [16], there exist simple complex event patterns for which the corresponding automata in these models are inefficient. In contrast, our Unary Complex Event Automata do not have topological constraints, and are inherently efficient to evaluate (Proposition 5.1).
Extensions of regular expressions with data filtering capabilities have been considered before outside of the CER context. Extended regular expressions [3, 6, 7, 20], for example, extend the classical regular expressions operating on strings with variable binding expressions of the form (meaning that when the input is matched, the substring matched by regular expression is bound to variable ) and variable backreference expression of the form (referring to the last binding of variable ). Variables binding expressions can occur inside a Kleene closure, but when referred to, a variable always refers to the last binding. Extended regular expressions differ from and in that they operate on finite strings over a finite alphabet rather than infinite streams over an infinite alphabet of possible events; and use variables only to filter the input rather than also using them to construct the output. Regular expressions with variable bindings have also been considered in the socalled spanners approach to information extraction [15]. There, however, variables are only used to construct the output and cannot be used to inspect the input. In addition, variable binding inside of Kleene closures is prohibited.
Languages with secondorder variables, such as monadic second order logic (MSO), are standard in logic and databases [19]. However, to the best of our knowledge we are not aware of any language that combines regular operators with secondorder variables as , neither has been proposed in the context of CER.
2 Secondorder Variables to the Rescue
We dedicate this section to motivate our proposal for using secondorder variables in CER, illustrating how this can enrich and simplify the syntax and semantics of a language.
CER languages usually assume that an event is a relational tuple, composed of a type and a set of attributes, and an event stream is an infinite sequence of events. Events are assumed to appear in generation order in the stream. As a running example, suppose that sensors are positioned throughout a farm to detect freezing plantations. Sensors detect temperature and humidity, generating a stream of events of two types, and , both of which have a value attribute that contains the measured temperature or humidity, respectively. An example stream of events indexed by event generation order is depicted in Figure 1.
type  …  
value  2  30  20  1  27  2  45  50  2  65  … 
index  0  1  2  3  4  5  6  7  8  9  … 
Now, what is a complex event? Most CER frameworks consider, although in general implicitly, that a complex event is a finite sequence of events that represents a relevant pattern for the user. As an example, suppose that plantations might freeze if after having a temperature below 0 degrees, there is a period where humidity increases until humidity is over . If we represent complex events as mappings from types to the position of relevant events of that type, in Figure 1 we would obtain for example that is a complex event matching our description of a possibly freezing plantation. Naturally, a user would like to be notified as soon as this pattern is detected (i.e. once event arrives) and receive the corresponding events to analyze them and possibly take actions. It is not hard to see that several complex events could fire the same pattern at the same time. For example, the above situation is also matched by , which could also be relevant for the user. This illustrates that the output of a CER pattern should be defined by a set of mappings whose image range over sets (i.e. a set of complex events).
Assigning sets of events to types can be, nonetheless, a shallow representation. Naturally, a user might want to make a distinction between events of the same type. For example the complex event does not have the explicit information of which subset of corresponds to the increasing sequence of humidity measure, and which correspond to the measure above (although in this case this can be deduced from the pattern). A richer representation for the user could be an assignment of the form where and are newly defined labels for encoding the Humidity Sequence and High Humidity sets of events, respectively.
The previous discussion suggests that secondorder assignments should be first citizens in CER languages. Furthermore, the semantics of a CER language can be simplified if secondorder variables are used for managing these objects. To motivate this, suppose that we want to declare the plantation freezing pattern above in a CER language. A first attempt could be to use a formula like , where enforces that the values of the events satisfy the corresponding conditions. Intuitively, states that we want to see a temperature () followed by one or more humidities (), and ending with a humidity (), such that the condition is satisfied (as it is standard in CER, here the operators “;” and “+” allow to skip over intermediate events [11]). Note that the pattern , however, is not making any explicit distinction between the captured humidities. Then, how could indicate what are the conditions over the humidity sequence and the final humidity? This could easily be achieved if we had richer complex events, like the one mentioned and . To this end, we include in our language the operator . This allows us to rewrite as . Now has access to the secondorder variables and , making the filtering more natural.
Now, for the plantation freezing pattern, we need secondorder predicates to force that (1) all temperatures in are below (), (2) the set of humidities is an increasing sequence (), and (3) the humidity in is above (). By combining these predicates, we can write our pattern as:
As an example, the complex event will match when evaluated over (Figure 1). It is important to remark that predicates here are evaluated over sets of events. For example the predicate will be satisfied if all temperatures in have value below (this is called an universalextension in Section 4).
Using secondorder predicates might seem loose at first, as predicates could specify arbitrary properties. However, the goal of this approach is to separate what is inherent to a CER framework and what is particular to an application. To illustrate this, consider the framework SASE introduced in [22, 2]. The plantation freezing pattern in the SASE language can be written as follows (its meaning can be easily inferred from its syntax):
What is ? Is
a first or secondorder variable? This pattern illustrates that builtin filtering capabilities of CER languages often result in adhoc syntax and underspecified semantics. Also, the syntax is never general. What happens if instead of an increasing sequence we want to express that the variance of the humidities is less than five? We do not expect the language to be capable of expressing this, but it could be an applicationspecific requirement. For this reason, we parametrize our language
by an arbitrary set of predicates. We believe that filtering should not be a builtin capability but, in contrast, a practical framework should allow to program applicationspecific sets of filters as an extension.Having illustrated that complex events are naturally secondorder objects, in the next section we formally present the language and discuss how the introduction secondorder variables simplifies the syntax and semantics of CER languages.
3 Secondorder Complex Event Logic
In this section, we formally define , a core complex event recognition language based on secondorder variables. This language is heavily based on [16], but it presents a simpler formal definition. We compare against the language of [16] in Section 4.
Schemas, Tuples and Streams. Let be a set of attribute names and be a set of values. A database schema is a finite set of relation names, where each relation name is associated to a tuple of attributes denoted by . If is a relation name, then an tuple is a function . We say that the type of an tuple is , and denote this by . For any relation name , denotes the set of all possible tuples, i.e., .
Similarly, for any database schema , . Given a schema , an stream is an infinite sequence where . When is clear from the context, we refer to simply as a stream. Given a stream and a position , the th element of is denoted by , and the substream of is denoted by . Note that we consider in this paper that the time of each event is given by its index, and defer a more elaborated time model (like [21]) for future work.
syntax. We now give the syntax of . Let be a finite set of monadic secondorder (SO) variables containing all relation names (i.e. ). An SO predicate of arity is an ary relation over sets of tuples, . We write for the arity of . Let be a set of SO predicates. An atom over is an expression of the form where is a predicate of arity , and (we also write for ). The set of formulas in is given by the following syntax:
Where ranges over relation names, and over labels in and over atoms over .
semantics. In order to define the semantics of core formulas, we first need to introduce some further notation. A complex event is a function that assigns a finite set to every . We say that is trivial if for every in which case we denote by . Notice that every complex event can be represented as a finite set of pairs such that iff . We make use of both notations indistinctly. The support of is the set of positions mentioned in , . For every nontrivial complex event , we define the maximum and minimum of as and , respectively. For the special case , we define and . Then for every two complex events and with , we define their concatenation as the complex event such that . For every , we define the extended complex event such that and for every . Furthermore, for every we define the renamed complex event such that , and for every . Finally, given a stream , a complex event naturally defines the function where .
Now we are ready to define the semantics of formulas. Given a formula , a stream , and positions , in Table 1 we define recursively the set of all complex events of that satisfy , starting the evaluation at position and ending at . Observe that, by definition, if then is a subset of and always. We say that belongs to the evaluation of over at position , denoted by , if , namely, we evaluate over starting from position . Intuitively, signifies that complex event was recognized in the stream when having inspected only the prefix .
Consider the pattern introduced in Section 2 to detect possible freezing plantations. We illustrate the evaluation of over the stream depicted in Figure 1. First of all, note that, although the conjunction of predicates is not directly supported in , this can be easily simulated by a nesting of filter operators. Then, for the sake of simplification, we can analyze by considering each filter separately. For the subformula we can see that (i) . On the other hand, the last event (i.e. ) is the only event that satisfies and then (ii) . Now, the intermediate formula captures a sequence of one or more events representing an increasing sequence of humidities. Because Kleene closure allows for arbitrary events to occur between iterations, these sequences can be selected from the power set of all events that produced an increasing sequence like, for example, or . In particular, we have that (iii) . Putting together (i), (ii) and (iii) and noticing that , we have that:
is a possible output of evaluating over . As we saw in the previous example, the operator allows to introduce new names to the output keeping the previous names and positions. However, a user could like to remove or, in other words, rename previous label because there are not relevant for the output. For this, includes the renaming operator . For example, instead of we can use the formula and all complex events that satisfy will not include in the output, i.e. they are replaced by or . In particular:
Notice that renaming operators have been used before in databases and relational algebra [1], so it is a natural operator for managing labels in .
4 The Expressiveness of SO variables versus FO variables
is a natural extension of the logic proposed in [16], which we will refer to as in this paper. uses secondorder variables whereas uses first order variables instead. Since, in traditional logics, secondorder languages can encode everything a firstorder language can, this could suggest to the reader that is more expressive than . In this section, we show that this is only partially true. We begin our discussion with a definition of the syntax and semantics of . For a more detailed explanation of , as well as extensive examples, we address the interested reader to [16].
syntax. Let be a set of first order variables. Given a schema , an FO predicate of arity is an ary relation over , . If is a set of FO predicates then an atom over is an expression with of arity and FO variables in . The set of formulas of (called CEPL in [16]) over schema is given by the following grammar:
Here, ranges over relation names in , over variables in and over atoms in .
semantics. For the semantics of we first need to introduce the notion of match. A match is defined as a nonempty and finite set of natural numbers. Note that a match plays the same roll as a complex event in and can be considered as a restricted version where only the support of the output is considered. We denote by and the minimum and maximum element of , respectively. Given two matches and , we write for the concatenation of two matches, that is, whenever and empty otherwise. Given an formula , we denote by all variables defined in by a clause of the form and by all variables in that are defined outside the scope of all operators. For example, in the formula we have that uses variables , , and . A valuation is a function . Given a finite subset and two valuations and , we define the valuation by whenever and otherwise.
Now we are ready to define the semantics of . Given a formula , we say that a match belongs to the evaluation of over a stream starting at position , ending at position , and under the valuation (denoted by ) if one of the following conditions holds:

, , and .

, and .

and or ).

and there exists and matches and such that , and .

and there exists a valuation such that either or , where .
We say that belongs to the evaluation of over at position , denoted by , if for some valuation .
Consider that we want to use to see how temperature changes at some location whenever there is an increase of humidity from below to above . Assume, for this example, that the location of an event is recorded in its id attribute and its humidity in its hum attribute. Then, using a selfexplanatory syntax for FO predicates, we would write:
Inside the Kleene closure, is always bound to the current event being inspected. The filter ensures that the inspected temperature events of type are of the same location as the first humidity event . Note that, in this case, the output is a match (set of positions), and includes in particular the positions of the inspected events.
In order to make a fair comparison between and we first need to agree how we relate the FO predicates that can be used in to the SO predicates that can be used in . Indeed, the expressive power of both languages inherently depends on what predicates they can use, and we need to put them on equal footing in this respect. In particular, without any restrictions on the predicates of we can easily write formulas that are beyond the scope of . For this reason, we will restrict ourselves to SO predicates coming from the universal extension of FO predicates. Here, given a FO predicate , we define its SOextension to be the SO predicate of the same arity as such that iff . We extend this definition to sets of predicates: if is a set of FO predicates, is the set . In what follows we will compare to .
Using the SOextensions of the unary FO predicates (e.g. ) and the binary idcomparison predicate (e.g. ), the expression of Example 4 can be written in as:
At this point, the reader may wonder why we focus on universal extensions of FO predicates. After all, one could also consider existential extensions of the form where iff . Under this notion, however, cannot meaningfully filter events captured by a Kleene closure. Indeed, if is used with an existential semantics in Example 4, then it would include in the events occurring between the first event and the second event , as long as there is one such event with the same id as the single event in . Therefore, although existential extensions could be useful in some particular CER usecases, we compare with by considering only universal extensions.
Another difference to be considered is that outputs complex events (i.e. secondorder assignments over positions) and outputs matches (i.e. sets of positions). To meaningfully compare both, we consider a formula to be equivalent to a formula (denoted by ) iff for every stream and every position it holds that , where is defined to be . That is, we consider equivalent to if we can obtain by “forgetting” the variables in the complex events of .
We now compare both languages. We start by showing that if is a set of unary FO predicates, and have the same expressive power.
Let be any set of FO unary predicates. For every formula there exists a formula such that , and vice versa.
The previous theorem is of particular relevance since it shows that both languages coincide in a wellbehaved core. with unary predicates was extensively studied in [16] showing efficient evaluation algorithms and it is part of almost all CER languages [11].
Now we show that if we go beyond unary predicates there are formulas that cannot be equivalently defined in . Let be the smallest set of FO predicates that contains the equality predicate and is closed under boolean operations.
There is a formula in that cannot be expressed in .
An example of a formula that can be defined in but it cannot be defined in is , where is defined as . Intuitively, an equivalent formula in for would need to compare every element in with every element in , which requires a quadratic number of comparisons. One can show that the number of comparison in the evaluation of an formula is at most linear in the size of the output and, thus, cannot be defined by any formula in . It is important to note that this result shows the limitations of a CEPlanguage based on FO variables and what can be gained if SO variables are used.
A natural question at this point is whether can define every formula. For binary predicates (e.g. ) the answer is positive, as the following result shows.
Let be any set of FO binary predicates closed under complement. Then for every formula there exists a formula such that .
It is important to notice that closeness under complement is a mild restriction over . In particular, if the set is closed under boolean operations (as usually every CEP query language support), the condition trivially holds.
Interestingly, it is not true that is always more expressive than . In particular, there exists an formula with ternary predicates that cannot be defined by any formulas. For the next result, consider the smallest set of FO predicates containing the sum predicate that is closed under boolean operations.
There is a formula in that cannot be expressed in . In the appendix, we show that the formula in cannot be defined in . This formula injects the variable inside the Kleene closure in order to check that each pair sums . This capability of injecting variables inside Kleene closure cannot be simulated in given that is a composable language. It is important to recall that this does not occur if binary predicates are used (Theorem 4), which are of common use in CER.
5 On the Expressiveness of Unary Formulas
What is the expressiveness of ? Obviously, as already illustrated in Section 4, the answer to this question depends on the predicates that we allow in . To get a first, fundamental understanding of the expressive power of the basic operators of , we will study this question in the setting where is limited to contain only the simplest kinds of predicates possible, namely secondorder extensions of unary FO predicates. When is hence limited, we compare against a computational model for detecting complex events that we call Unary Complex Event Automata ( for short), defined next.
5.1 Unary Complex Event Automata
Let be a schema and be a set of unary FO predicates over . We denote by the closure of under conjunction (i.e. intersection). A unary complex event automaton () over and is a tuple where is a finite set of states, is a finite transition relation, and are the set of initial and final states, respectively. Given an stream , a run of length of over is a sequence of transitions such that , and for every . We say that is accepting if , and denote by the set of accepting runs of over of length . Further, we define the complex event induced by as for all . Given a stream and , we define the set of complex events of over at position as .
are a generalization of the match automata (MA) introduced in [16]. The main difference is that match automata output matches, which are sets of positions, while output complex events (as defined in Section 3). In particular, mark events using SO variables in , while match automata mark events by using the symbols (add the event to the match) or (do not add the event to the match), respectively. The empty set in is the analogous of symbol of match automata meaning that no SO variable is assigned to the position.
further generalize MA by lifting structural restrictions on the latter. MA required, for example, that every transition to a final state mark the event with . No such restriction exists for . This relaxation increases the expressibility of the computational model, at the cost of loosing some closure properties.
Evaluation of of . Since the goal of CEP in practice is to process events in highthroughput environments, one would expect computational models for CEP to be efficient. The following proposition shows that UCEA are inherently efficient under data complexity. A similar proposition was established in [16] for match automata.
Proposition .
For every UCEA there exists a RAM algorithm that maintains a data structure such that: (1) for every , if has processed prefix of stream then can be enumerated from data structure with constant delay, and (2) it takes time to update upon the arrival of a new event .
Here, constantdelay enumeration of from means that there exists a RAM routine enum that takes as input and that enumerates all complex events in without repetition, such that (1) the time to initialize enumeration, finalize enumeration, as well as the time spent between finishing the output of one complex event and starting the output of the next complex event is constant, and (2) for each output complex event , the time spent outputting complex event is linear in the size of .
5.2 Expressiveness of Unary Formulas
The following proposition shows that every formula in with unary extension of FO predicates can be computed by a complex event automaton with the same set of predicates.
Proposition .
Let be a set of unary FO predicates. For every formula in there exists a over such that , for all streams and .
The proof is by a straightforward induction on . It is natural to ask whether the converse of Proposition 5.2 also holds, namely, if every over has an equivalent formula in . Here, however, the answer is no, because can make decisions based on tuples that are not part of the output complex event, while formulas cannot.
Consider for example the of Figure 2. This automaton will output complex events of the form , provided that is of type and there is a position such that is of type . It is straightforward to prove that this cannot be achieved by formulas because either such a formula would not check whether events occurs later, or it would also include the position in —which the automaton does not.
In order to capture the exact expressiveness of formulas with unary predicates, we restrict to a new semantics called the semantics. Formally, let be a complex event automaton and be a stream. A run of over ending at position is a sequence of transitions: such that , and, for every , with and . We say that is an accepting run if . Furthermore, we denote by the complex event induced by as for all . The set of all complex events generated by over under the semantics is defined as: . Notice that under this semantics, the automaton no longer has the ability to verify a tuple without marking it.
We can now effectively capture the expressiveness of unary formulas as follows. For every set of unary FO predicates, is equally expressive as under the semantics, namely, for every formula in , there exists a over such that for every and , and vice versa.
For every stream and complex event , let refer to the subsequence of induced by . An interesting property of the semantics is that, for every , stream , and complex event , we can arbitrarily modify, add and remove tuples in that are not mentioned in , and the original tuples in would still conform a complex event of over the new stream. To formalize this, we need some additional definitions. A processingfunction is a function , where is the set of all streams and is the set of all complex events (i.e. the set of all finite functions ). Although can be any function that returns set of complex events on input streams, we are interested in the processingfunctions that can be described either by a formula (i.e. ) or by a (i.e. ). Let , be two streams and , be two complex events. We say that and are related with and , written as , if .
Consider now a matchfunction . We say that has the property if, for every stream and complex event , it holds that for every and such that . A way to understand the property is to see as the result of fixing the tuples in that are part of and adding or removing tuples arbitrarily, and defining to be the complex event that has the same original tuples of . The following theorem states the relation that exists between the property and the semantics over .
Proposition .
If the processingfunction defined by a has the property, then there exists a such that for every and .
By combining Theorem 2 and Proposition 5.2 we get the following result that shows when a processing function can be defined by unary formula. Let be a processing function. Then can be defined by a over and has the property iff there exists a formula in such that .
Many query languages for CEP have been proposed in the literature and most of them include all of the operators of as defined in Section 3. However, some languages include additional useful operators like , and with the following semantics. Given a complex event , a stream and :
Comments
There are no comments yet.