CHAPTER 11 Modeling and Querying Current Movement
11.3 FTL—A Query Language Based on Future
In this section, we describe FTL, a query language that allows us to express con- ditions about the future. We fi rst introduce the language by some examples ( Section 11.3.1 ), then defi ne the syntax ( Section 11.3.2 ) and semantics ( Section 11.3.3 ) of the language precisely. Finally, in Section 11.3.4 , an algorithm for evaluating FTL queries is presented.
11.3.1 Some Example Queries
Several example queries for moving objects applications have already been men- tioned; let us see how some of them would be expressed in FTL.
EXAMPLE 11.1
Which trucks are within ten miles of truck T68?
RETRIEVE t
FROM trucks t, trucks s
WHERE s.id = ‘ T68 ’ ∧ dist(s, t) ≤ 10 The general form of a query is: 2
RETRIEVE < target-list > FROM < object-classes >
WHERE < FTL-formula >
2 In the original literature describing FTL, the FROM clause is omitted; a single implicit class of moving objects is assumed.
The FTL formula is the interesting part. In the fi rst example, nothing special happens yet. The syntax used is a theoretical one; in practice, we would replace the logical connec- tive ∧ by a keyword and and type < = instead of ≤ . Observe that the distance operator dist is applied to the objects directly rather than to point attributes, as discussed in Section 11.2.1 .
The FTL language as such only deals with instantaneous queries. How we can get from instantaneous to continuous queries has been explained in the previous section. But to require a query to be evaluated as a continuous query is not within the scope of the language; it has to be specifi ed externally (e.g., at the user interface).
Therefore, the previous query is evaluated instantaneously at the time when it is issued. We assume trucks have a dynamic location ( loc ) attribute, and the dis- tance is evaluated on the current positions of trucks s (T68) and t . The distance function dist is also assumed to operate over the network; therefore, it involves a shortest-path computation.
Observe that the query is beautifully (and perhaps deceivingly) simple; nothing needs to be said about time, yet the query refers to the current situation and its result will change when posed at different times.
EXAMPLE 11.2
Will truck T70 reach its destination within the next half hour?
As formulated, the query would require a Boolean (yes or no) result, which is not directly possible. Instead, we will retrieve truck T70 if it reaches its destination in time; otherwise, the result will be empty.
We assume destinations to be modeled as a point object class destinations , where points lie on the traffi c network. The trucks object class has an attribute dest giving its destination in the form of a reference to such a destination object.
RETRIEVE t
FROM trucks t
WHERE t.id = ‘ T70 ’ ∧ eventually _ within _ 30 (dist(t, t.dest) = 0)
Here, we assume again that time units are minutes. New is the temporal operator eventually _ within _ c , where c is a numeric constant referring to time units. It can be applied to a predicate p . The meaning of eventually _ within _ c ( p ) is: Within the next c time units, p will become true.
EXAMPLE 11.3
To make the next example more interesting, we modify our helicopter query a bit: Retrieve the friendly helicopters that will arrive in the valley within the next 15 minutes and then stay in the valley for at least 5 minutes.
RETRIEVE h
FROM helicopters h
WHERE eventually _ within _ 15 (inside(h, Valley) ∧
always _ for _ 5 (inside(h, Valley)))
Here, Valley is a polygon object and inside an operation comparing a point object with a polygon object. We assume that helicopters represented in this object class are all friendly; therefore, there is no explicit condition for that.
Note that the condition says that within 15 minutes a database state will be reached such that helicopter h is inside the valley, and for the next 5 time units, this will always be true.
We can see that it is possible in the language to specify sequences of condi- tions that must become true in a certain order and to specify bounds on the periods of time involved. In the next section, we defi ne the structure of the lan- guage precisely.
11.3.2 Syntax
The interesting part of the FTL language is the FTL formulas. FTL is similar to fi rst-order logic; therefore, the language consists of constants, variables, function symbols, predicate symbols, and so forth.
Defi nition. The FTL language consists of the following symbols:
1. Constants . These may be of the atomic data types (e.g., 54, “ T68 ” ) or named objects in the database (e.g., Valley ). The special database object Time is also a constant.
2. For each n > 0, a set of n -ary function symbols . Each function symbol denotes a function taking n arguments of particular types and returning a value of some type. Examples are + , * on type int , or the “ . ” operator, which takes an object of some object class and an attribute name and returns a value of the attribute type.
3. For each n ≥ 0, a set of n -ary predicate symbols . Each predicate symbol denotes a relation with n arguments of specifi ed types. For example, ≤ and
≥ denote the usual arithmetic comparison operators.
4. Variables . These are typed and can range over object classes or atomic types. For example, h truck is a variable ranging over the truck class, and j int an integer variable. Usually the index denoting the domain of the variable is omitted.
5. Logical connectives ∧ and ơ . 6. The assignment quantifi er ← .
7. Temporal modal operators until and nexttime . 8. Brackets and punctuation symbols ( , ), [ , ] , and ,.
The MOST model and FTL language are designed to be implemented on top of a DBMS providing its own nontemporal query language (e.g., OQL). FTL allows us to embed so-called atomic queries from that underlying language. These are queries returning single values from atomic types (e.g., an integer). For example, the query
RETRIEVE d.name FROM destinations d WHERE d.id = ‘ d12 ’
is such an atomic query returning a string value. Within FTL, this atomic query is viewed as a constant symbol. It is also possible that such a query contains a variable. For example, the query
RETRIEVE d.name FROM destinations d WHERE d.id = y
has a free variable y . This is viewed as a function symbol denoting a unary func- tion that returns for a given argument a string value.
Defi nition. A term is one of the following:
1. A constant c . 2. A variable v .
3. An attribute access v . A .
4. An application of a function to terms of appropriate types f ( t 1 , . . . , t n ).
For example, 10, x + 3, dist ( x, y ), and d.name are terms, and “ retrieve d.name from destinations d where d.id = y ” is also a term.
Defi nition. A well-formed formula is defi ned as follows:
1. If R is an n -ary predicate symbol and t 1 , . . . , t n are terms of appropriate types, then R ( t 1 , . . . , t n ) is a well-formed formula.
2. If f and g are well-formed formulas, then f ∧ g and ơ f are well-formed formulas.
3. If f and g are well-formed formulas, then f until g and nexttime f are well- formed formulas.
4. If f is a well-formed formula, x is a variable, and t is a term of the same type as x , then ( [ x ← t ] f ) is a well-formed formula. A variable in a formula is free if it is not in the scope of an assignment quantifi er of the form [ x ← t ] . The semantics of all this are defi ned in the next section. Observe that FTL does not have the existential and universal quantifi ers of fi rst-order logic; 3 instead, the assignment quantifi er is offered that allows us to bind a variable to the result of a query in one of the states of a database history. In particular, it is possible to
3 It is argued that this is to avoid problems of safety, which are more severe in the context of data- base histories. See standard database textbooks for a discussion of safety of the relational calculus, for example.
capture an atomic value at some point in time and relate it to other values at later points in time.
We have not yet discussed some constructs, such as eventually _ within _ c , occurring in the previous examples. These will be shown to be derivable from the primitives of the language and will be discussed in the following section.
11.3.3 Semantics
Let s u be the state of the database when the query “ retrieve < target-list > from
< object-classes > where f ” is entered. The semantics of formula f are defi ned with respect to the history starting with s u — that is, history H u .
First, we need to defi ne the meaning of the symbols of the language:
1. Constants represent corresponding values from their domain. For example, 54 represents an integer, “ T68 ” a character string, and Valley and Time represent database objects.
2. Function symbols have their standard interpretation or denote functions defi ned in the text. For example, the symbols + and * represent the standard addition and multiplication functions. The dist symbol represents the distance function described in Section 11.3.1 .
3. Predicate symbols also have their standard interpretation. For example,
≤ denotes the standard less than or equal relation.
In the sequel, we do not distinguish in notation between such symbols and their interpretation. For example, for a constant symbol c , the value represented is also denoted as c .
Defi nition. A variable assignment for formula f is a mapping μ that assigns to each free variable in f a value from its domain. We denote by μ [ x / u ] the mapping obtained from μ by assigning the value u to variable x and leaving all other variables unchanged.
EXAMPLE 11.4
Let us assume that in the truck object class in Example 11.1 , there are truck objects with object identifi ers T 1 through T 100 . Consider the formula
s.id = ‘ T68 ’ ∧ dist(s, t) ≤ 10
A possible variable assignment is μ = {( s , T 10 ), ( t , T 20 )}.
Defi nition. For a term t , its evaluation in a state s with respect to a variable assign- ment ϕ s, à , denoted ϕ s, à [ t ] , is defi ned as follows:
1. If t is a constant c , then ϕ s, à [ c ] = s ( c ).
2. If t is a variable v , then ϕ s, à [ v ] = μ ( v ).
3. If t is an attribute access v . A , then ϕ s, à [ v . A ] = s ( μ [ v ] . A ).
4. If t is an application of function f to arguments t 1 , . . . , t n , then ϕ s, à [ f ( t 1 , . . . , t n ) ] = f ( ϕ s , à [ t 1 ] , . . . , ϕ s, à [ t n ] ).
Observe that constants are evaluated in a database state; this is needed in par- ticular for the constant Time . Also dynamic attributes are evaluated with respect to the current state. We now defi ne the satisfaction of a formula at a state s on a history H with respect to a variable assignment μ . Satisfaction is defi ned induc- tively on the structure of formulas.
Defi nition. Formula f is satisfi ed at state s on history H with respect to variable assignment μ (satisfi ed at ( s , μ ), for short):
1. R ( t 1 , . . . , t n ) is satisfi ed : ⇔ R ( ϕ s, à [ t 1 ] , . . . , ϕ s, à [ t n ] ) holds.
2. f ∧ g is satisfi ed : ⇔ both f and g are satisfi ed at ( s , μ ).
3. ơ f is satisfi ed : ⇔ f is not satisfi ed at ( s , μ ).
4. f until g is satisfi ed : ⇔ either g is satisfi ed at ( s , μ ), or there exists a future state s ′ on history H such that ( g is satisfi ed at ( s ′ , μ ) ∧ for all states s i on history H before state s ′ , f is satisfi ed at ( s i , μ )).
5. nexttime f is satisfi ed : ⇔ f is satisfi ed at ( s ′ , μ ), where s ′ is the state immediately following s in H .
6. ( [ x ← t ] f ) is satisfi ed : ⇔ f is satisfi ed at ( s , μ [ x / ϕ s , à [ t ] ] ).
The assignment quantifi er can be used in combination with the nexttime operator to detect change.
EXAMPLE 11.5
The formula ( [ x ← dist ( a, b ) ] ( nexttime dist ( a, b ) > x )) is evaluated as follows. Let us assume it is evaluated in a state s , for which s ′ is the next state.
( [ x ← dist ( a, b ) ] ( nexttime dist ( a, b ) > x )) is satisfi ed at state s
⇔ ( nexttime dist ( a, b ) > β α ) is satisfi ed at state s , where α is the distance between objects a and b , evaluated in state s
⇔ ( dist ( a, b ) > α ) is satisfi ed at state s ′
⇔ ( β > α ) where β is the distance between objects a and b , evaluated in state s ′ So the formula is satisfi ed if the distance between objects a and b increases from the current state to the next state.
Based on the given syntactical primitives for constructing formulas whose meanings are now well defi ned, some derived notations can be defi ned as follows.
First, in addition to the logical connectors ∧ and ơ , we can also use ∨ and
⇒ , which can be defi ned in terms of the fi rst two. Second, temporal operators
eventually and always can be defi ned as follows:
■ eventually g means that g will be fulfi lled at some future state. It can be defi ned as true until g .
■ always g means that g is satisfi ed at all future states, including the present state. It is defi ned as ơ ( eventually ( ơ g )).
In addition, it is useful to have related operators that have bounded, rather than infi nite, periods of time. First, we defi ne bounded versions of the until operator:
■ g until _ within _ c h asserts that there exists a future time within at most c time units from now such that h holds, and until then g will be continuously satisfi ed.
■ g until _ after _ c h asserts that there exists a future time after at least c time units from now such that h holds, and until then g will be continuously satisfi ed.
Based on these, we can defi ne other bounded temporal operators:
■ eventually _ within _ c g asserts that the formula g will be fulfi lled within c time units from the current state, defi ned as true
until _ within _ c g .
■ eventually _ after _ c g means that g holds after at least c units of time, defi ned as true until _ after _ c g .
■ always _ for _ c g asserts that the formula g holds continuously for the next c units of time, defi ned as g until _ after _ c true .
11.3.4 Evaluating FTL Queries
An interesting issue now is how FTL queries are processed and evaluated by an algorithm. From the set of FTL queries that can be formed according to Section 11.3.2 , we here only consider the subset of so-called conjunctive formulas. Such a formula is constructed
■ Without negations.
■ Without the nexttime operator.
■ Without any reference to the Time object ( Section 11.2.1 ).
The reason for excluding negations is safety (i.e., fi niteness of the result), since negations may introduce infi nite answers. The condition of excluding the time variable in queries implies that for every query q that is on the right side of an assignment in f (i.e., as in [ x ← θ ] ), the value returned by q at any time is inde- pendent of the time when it is evaluated; it is only the result of a function applica- tion assigning values to the free variables in q ; and it depends only on the current positions of the objects. This condition also ensures that satisfaction of a nontem- poral predicate when an object is at a particular position depends only on the position of the object but not on the time when the object reached the position.
The bounded temporal operators such as eventually _ within _ c are admitted, however. Since the Time object must not be used, the evaluation algorithm will handle the two basic operators until _ within _ c and until _ after _ c explicitly.
As an additional constraint, only instantaneous and continuous, but not persistent, queries are allowed.
The basic idea for evaluating an FTL formula is to compute for each formula f with free variables x 1 , . . . , x k a relation R f ( x 1 , . . . , x k , t start , t end ). That relation has one attribute for each of the free variables in f and two additional attributes, t start and t end , describing a time interval. Each tuple ( o 1 , . . . , o k , t 1 , t 2 ) of R f represents one instantiation ρ = < o 1 , . . . , o k > of the variables x 1 , . . . , x k such that the formula is true for this instantiation during the time interval [ t 1 , t 2 ] . Furthermore, for two tuples with the same instantiation ρ = < o 1 , . . . , o k > of the variables x 1 , . . . , x k , the time intervals are disjoint and nonadjacent.
A set of tuples T with the same instantiation ρ and set of time intervals I represents a combination of objects < o 1 , . . . , o k > that fulfi lls f during times I . An FTL formula is structured into subformulas. The idea for evaluation is to compute relations for the atomic formulas fi rst and then to evaluate formulas bottom-up, translating connectives into relation operations.
At the beginning of this section, we said that we consider a restricted class of formulas where negation and nexttime are missing and until _ within _ c and until _ after _ c are treated explicitly. Here is an updated defi nition for this case.
Defi nition. A well-formed formula (in the restricted case) is defi ned as follows:
1. If R is an n -ary predicate symbol and t 1 , . . . , t n are terms of appropriate types, then R ( t 1 , . . . , t n ) is a well-formed formula.
2. If f and g are well-formed formulas, then f ∧ g is a well-formed formula.
3. If f and g are well-formed formulas, then f until g is a well-formed formula.
4. If f and g are well-formed formulas, then f until _ within _ c g is a well- formed formula.
5. If f and g are well-formed formulas, then f until _ after _ c g is a well-formed formula.
6. If f is a well-formed formula, x is a variable, and t is a term of the same type as x , then ( [ x ← t ] f ) is a well formed formula. A variable in a formula is free if it is not in the scope of an assignment quantifi er of the form [ x ← t ] . We now consider each of these cases in turn. Let h be a subformula with free variables x 1 , . . . , x l .
Case 1: h ≡ R ( x 1 , … , x l ) Example: h ≡ dist ( x 1 , x 2 ) < 8
We assume that for each such atomic predicate an algorithm exists returning for each possible instantiation < o i , o j > the time intervals when the predicate holds.
Compute a relation R h with all such tuples < o 1 , . . . , o l > and associated time intervals.
Case 2: h ≡ f ∧ g
Let R f and R g be the relations computed for the subformulas; for example:
R f ( x 1 , x 2 , x 5 , t s , t e )
R g ( x 1 , x 4 , x 5 , x 7 , t s , t e )
Then the result relation will have the schema
R h ( x 1 , x 2 , x 4 , x 5 , x 7 , t s , t e )
Suppose for an instantiation < o 1 , o 2 , o 4 , o 5 , o 7 > , f is satisfi ed during I 1 and g is satisfi ed during I 2 . Then f ∧ g is satisfi ed during I 1 ∩ I 2 . Therefore, compute the result relation R h as follows. Compute a join of R f and R g ; common variables must be equal, and time intervals must intersect. For each result tuple its time interval is the intersection of the time intervals of the two joining tuples.
Case 3: h ≡ f until g
Let R f and R g be the relations computed for the subformulas, with p + 2 and q + 2 attributes, respectively.
Consider tuple t 1 in R f . Let T 1 be the set of all tuples with the same values in the fi rst p attributes (same instantiation). Let I 1 be the set of time intervals in T 1 . Similarly, consider t 2 in R g , T 2 , and I 2 . Figure 11.1 shows tuples t 1 and t 2 with overlapping time intervals. Clearly, if f holds for the instantiation of t 1 during its time interval, and if g holds for the instantiation of t 2 during its time interval, then f until g holds for the union of their time intervals.
Now consider the complete sets of time intervals I 1 and I 2 for these two instan- tiations ( Figure 11.2 ). When does f until g hold? Remember the semantics of f
until g: f until g is satisfi ed : ⇔ either g is satisfi ed at ( s , μ ), or there exists a future state s ′ on history H such that ( g is satisfi ed at ( s ′ , μ ) ∧ for all states s i on history H before state s ′ , f is satisfi ed at ( s i , μ )).
FIGURE 11.1
Overlapping time intervals for two instantiations of formulas f and g .
Therefore, f until g holds for periods of time when there are chains of inter- vals alternating between t 1 and t 2 up to the end of a t 2 interval, as illustrated in Figure 11.2 .
Hence, compute R h as follows: Compute a join of R f and R g matching pairs of (sets of) tuples with relation to their variable instantiations. For the two resulting sets of intervals I 1 and I 2 , compute their maximal chains . For each maximal chain, construct one result tuple, with time interval corresponding to the extent of the chain.
An alternative formulation is: Compute solution intervals for any suitable pair of intervals of t 1 and t 2 . Merge all sequences of overlapping solution intervals into one, and return this in a result tuple.
Case 4: h ≡ f until _ within _ c g
Recall the semantics of this case: f until _ within _ c g asserts that there is a future time within at most c time units from now such that g holds, and until then f will be continuously satisfi ed. This case is illustrated in Figure 11.3 .
Let t 1 , t 2 be matching pairs of tuples from R f and R g with overlapping time intervals. Let d = max{ t 1 . l, t 2 . l – c }. 4 Then, f until _ within _ c g holds in the interval [ d, t 2 . u ] . Extend to chains as before — that is, merge any overlapping solution intervals so they are displayed as one. The result relation is computed in a join, similar to Case 3.
Case 5: h ≡ [ y ← q ] f
Here, q is a query yielding an atomic result; for example:
y←height o( )
Let R f be the result relation for f . The term q is in general a query and has to yield an atomic result so that it can be assigned to y . It usually contains some free variables. The result relation R q for [ y ← q ] is assumed to have p + 3 attributes, where the fi rst p attributes relate to the free variables in q ; the number ( p + 1) FIGURE 11.2
Time intervals for f until g .
4 We denote by t.l the left end of the time interval for tuple t , and by t.u the right end.