The problem that the declarative semantics of XChangeEQ address can be described on an a very abstract level as follows: given a set of deductive rules (also called program) together with an incoming event stream, i.e., the set of events that happen in the outside world and are not derived by rules, it tells us all events that are derived by the rules. This approach then also covers the issue of finding the answers for a given event query (e.g., that is used in a reactive rule) w.r.t. a program and an incoming event stream.
The idea behind the model theory of XChangeEQ(and other model theories) is view expressions of the language (rules, queries) as sentences of first order logic (or, since events are represented as data terms with occurrence times not logic facts, something similar). These sentences are related to an interpretation by defining an entailment relation. An interpretation contains all events that happen, the base events from the incoming event stream and the derived events. The entailment relation is defined recursively over the structure of the sentences. Of interest for the semantics are those interpretations that (1) satisfy all rules of a program w.r.t. the entailment relation and (2) contain the stream of incoming events. These interpretations are then called models. The model theory of XChangeEQtakes into accounts the special requirements of an event query language as discussed above and will be defined in Chapter 9.
A model theory has the issue of allowing many models for a given program. To give precise semantics to XChangeEQ, we need a unique model and this model should be natural and intuitive. A common and convenient way to obtain such a unique model is to define an accompanying fixpoint theory, which is based on the model theory. The fixpoint interpretation specified by the fixpoint theory is the intended model of an XChangeEQ program. When non-monotonic features like negation or aggregation are combined with recursion of rules, this might lead to some issues that have been mentioned in Chapter 6.10. By restricting ourselves to stratifiable programs, we avoid such cases and ensure that a unique fixpoint interpretation exists. A formal definition of stratification is given together with the definition of the fixpoint interpretation in Chapter 10.
We then have to show that the fixpoint interpretation of stratified programs is really well- defined and unambiguous. Further, and more importantly, we have to show that the seman- tics specified by the model theory and the fixpoint interpretation “make sense” on infinite event streams. It must be possible to evaluate queries in a streaming manner, where answers are gen- erated “online” and we never have to wait for the stream to end. We state all this formally as theorems and give proofs in Chapter 11
Chapter 9
Model Theory
The idea of a model theory, as it is used in traditional, non-event query languages [Llo93, AHV95, Sch04], is to relate expressions to an interpretation by defining an entailment relation. Expres- sions are syntactic fragments of the query language such as rule, queries, or facts viewed as logic sentences. The interpretation contains all facts that are considered to be true. The entailment relation indicates whether a given interpretations entails a given sentence from the language, that is, if the sentence is logically true under this interpretation. Of interest for the semantics of a given query program and a set of base facts are then those interpretations that (1) satisfy all rules of the program and (2) contain all base facts. Because it satisfies all rules, such an interpretation contains in particular also all facts that are derived by rules. We call these interpretationsmodels. When we replace facts that are true with events that happen, this approach can also be applied to event query languages. The problem, of course, is that events are associated with occurrence timesand event queries are evaluatedover timeagainst a potentiallyinfinite event stream. At each time point during the evaluation we know only which events have happened (i.e., been received in the event stream) so far, not any events that might happen in the future.
A core idea in giving model-theoretic semantics to XChangeEQ is to pretend a kind of “om- niscience.” We assume that we know the full, infinite event stream that contains all events that ever happen together with their occurrence times. The semantics are then specified irrespective of the evaluation times of event queries and rules.
With this approach, it is however not clear that the semantics actually “make sense” for event queries. The semantics might easily imply cases where the streaming evaluation of an event query over time is simply impossible because it might require waiting indefinitely for the end of the event stream or crystal gazing into the future. Of course, XChangeEQ and its semantics have been defined in such a way that a streaming evaluation is possible, and we will prove formally in Chapter 11.
The idea of pretending omniscience in the definition of the semantics of an event query language might seem simple enough. However, it turns out that previous event query languages have not defined their semantics this way (see Chapter 3). The semantics that they end up with can be considered more complicated and, because they are to some degree stateful, less declarative. The approach of XChangeEQ in contrast leads to very intuitive and highly declarative semantics.
9.1
Basic Definitions: Time and Events
We start of with some basic definitions that explain how we represent time and events in the semantics of XChangeEQ.
9.1.1
Data Terms
Data terms from Xcerpt are used to represent data and type information for events. Data terms are just syntactic objects. We have seen many examples of data terms in the previous sections. A simplified grammar for Xcerpt data terms is given in Appendix A.2, full grammars can be found in [Sch04] and [Fur08]. For the semantics of XChangeEQ, details on data terms are not important, as we will see in Section 9.2. The set of all data terms is denotedDataT erms.1
9.1.2
Time
Time is represented by a linearly ordered set (T, <) of time points (or time instants). Note that this time domain may be dense, in contrast to the time domain of for example CQL which must be discrete (see Chapter 3.3.5). An example of a suitable time domain would be the real numbers under their usual order. This could represent the number of seconds and fractions thereof elapsed since some epoch such as midnight of January 1, 1970.
To support relative temporal events such astimer:extend, we also need the possibility to add a durationdto a time pointp(p+d) and to subtract a duration from a time pointp(p−d). The result in both cases is another time point. Let Drepresent durations (such as 1 week 2 days). Addition and subtraction of durations to or from time points are then functions + :T×D→T and−:T×D→T.
To support metric temporal constraints such as within, we further need the possibility to measure the durationt1−t2 between two time pointst1, t2 and to compare two durationsd1, d2 (d1< d2). This gives a function−:T×T→Dand an order relation<⊆D×D. In context, it will always be clear if−means the subtraction between time points or between a time point and a duration.
A time intervalt is in our context always a closed an convex subset ofT, i.e.,t= [b, e] ={p| b ≤ p≤ e}, and can be represented by its endpoints b ∈ T and e ∈ T (b ≤e). Note that this definition allows degenerated time intervalst= [p, p] that consist only of a single time pointp∈T. The set of all time intervals isTI ={[b, e]| b ∈T, e∈T, b≤e}. For convenience we define the following functions and relations on time intervals:
• begin([b, e]) =b,
• end([b, e]) =e,
• [b1, e1]t[b2, e2] = [min{b1, b2},max{e1, e2}],
• [b1, e1]v[b2, e2] iffb2≤b1 ande1≤e2.
9.1.3
Events
An event happens over a given (closed and convex) time interval and has a representation as data term, which we also call event message. Formally, an event is therefore a tuple of a time intervalt and a data terme, writtenet. The set of all events is denotedEvents;Events=DataT erm×
TI.