A Second-Order Approach to Complex Event Recognition

12/04/2017 ∙ by Alejandro Grez, et al. ∙ Université Libre de Bruxelles Pontificia Universidad Católica de Chile 0

Complex Event Recognition (CER for short) refers to the activity of detecting patterns in streams of continuously arriving data. This field has been traditionally approached from a practical point of view, resulting in heterogeneous implementations with fundamentally different capabilities. The main reason behind this is that defining formal semantics for a CER language is not trivial: they usually combine first-order variables for joining and filtering events with regular operators like sequencing and Kleene closure. Moreover, their semantics usually focus only on the detection of complex events, leaving the concept of output mostly unattended. In this paper, we propose to unify the semantics and output of complex event recognition languages by using second order objects. Specifically, we introduce a CER language called Second Order Complex Event Logic (SO-CEL for short), that uses second order variables for managing and outputting sequences of events. This makes the definition of the main CER operators simple, allowing us to develop the first steps in understanding its expressive power. We start by comparing SO-CEL with a version that uses first-order variables called FO-CEL, showing that they are equivalent in expressive power when restricted to unary predicates but, surprisingly, incomparable in general. Nevertheless, we show that if we restrict to sets of binary predicates, then SO-CEL is strictly more expressive than FO-CEL. Then, we introduce a natural computational model called Unary Complex Event Automata (UCEA) that provides a better understanding of SO-CEL. We show that, under unary predicates, SO-CEL captures the subclass of UCEA that satisfy the so-called *-property. Finally, we identify the operations that SO-CEL is lacking to capture UCEA and introduce a natural extension of the language that captures the complete class of UCEA under unary predicates.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

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 above-mentioned 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 trade-offs 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 first-order 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 variable-scoping 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 so-called *-property. Intuitively, this property indicates that the UCEA can only make decisions based on events that are part of the output. As a by-product of our development we are able to show that certain additional CER operators that have been proposed in the literature, such as and are non-primitive 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 self-loops 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 so-called 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 second-order 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 second-order variables as , neither has been proposed in the context of CER.

2 Second-order Variables to the Rescue

We dedicate this section to motivate our proposal for using second-order 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.

value -2 30 20 -1 27 2 45 50 -2 65
index 0 1 2 3 4 5 6 7 8 9
Figure 1: A stream of events measuring temperature () in Celsius degrees and humidity () as a percentage of water in the air.

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 second-order assignments should be first citizens in CER languages. Furthermore, the semantics of a CER language can be simplified if second-order 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 second-order variables and , making the filtering more natural.

Now, for the plantation freezing pattern, we need second-order 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 universal-extension in Section 4).

Using second-order 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 second-order variable? This pattern illustrates that built-in filtering capabilities of CER languages often result in ad-hoc 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 application-specific requirement. For this reason, we parametrize our language

by an arbitrary set of predicates. We believe that filtering should not be a built-in capability but, in contrast, a practical framework should allow to program application-specific sets of filters as an extension.

Having illustrated that complex events are naturally second-order objects, in the next section we formally present the language and discuss how the introduction second-order variables simplifies the syntax and semantics of CER languages.

3 Second-order Complex Event Logic

In this section, we formally define , a core complex event recognition language based on second-order 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 sub-stream 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 second-order (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 non-trivial 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 .

Table 1: The semantics of .

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 second-order variables whereas uses first order variables instead. Since, in traditional logics, second-order languages can encode everything a first-order 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 non-empty 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 self-explanatory 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 SO-extension 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 SO-extensions of the unary FO predicates (e.g. ) and the binary id-comparison 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 use-cases, we compare with by considering only universal extensions.

Another difference to be considered is that outputs complex events (i.e. second-order 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 well-behaved 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 CEP-language 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 second-order 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 high-throughput 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, constant-delay 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.

Figure 2: A Unary Complex Event Automaton that has no equivalent formula in .

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 processing-function 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 processing-functions 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 match-function . 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 processing-function 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 :