On temporal deductive databases

On Temporal Deductive Databasesy MEHMET A. ORGUN Department of Computing, Macquarie University Sydney, NSW 2109, Australia Tel: +61 (0)2 805-9916, Fax: +61 (0)2 805-8983 E-mail: [email protected] ABSTRACT This paper introduces a temporal deductive database system featuring a logic programming language and an algebraic front-end. The language, called Temporal Datalog, is an extension of Datalog based on a simple temporal logic with two temporal operators, namely first and next. Programs of Temporal Datalog are considered as temporal deductive databases, specifying temporal relationships among data and providing base relations to Tra expressions. The minimum model of a given Temporal Datalog program is regarded as the temporal database the program models intensionally. The algebraic front-end, called Tra, is a point-wise extension of the relational algebra upon the set of natural numbers. When needed during the evaluation of Tra expressions, slices of temporal relations over intervals can be retrieved from a given temporal deductive database by bottom-up evaluation strategies. A modular extension of Temporal Datalog is also proposed, through which temporal relations created during the evaluation of Tra expressions may be fed back to the deductive part for further manipulation. Modules therefore enable the algebra to have full access to the deductive capabilities of Temporal Datalog, and to extend it with non-standard algebraic operators. The paper also shows that the temporal operators of Tra can be simulated in Temporal Datalog by program clauses. Temporal Databases, Temporal Algebras, Deductive Databases, Logic Programming, Temporal Logic, Declarative Semantics, Modules. Keywords: This is a substantially extended and revised version of the paper \A relational algebra as a query language for Temporal Datalog", which appeared in A. Min Tjoa and Isidro Ramos, editors, Proceedings of DEXA'92: The Third International Conference on Database and Expert Systems Applications, Valencia, Spain, September 2{4, 1992. Springer-Verlag, pp.276{281. y 1 Introduction This paper introduces a temporal deductive database system featuring a logic programming language and an algebraic front-end. The language, which we call Temporal Datalog, is an extension of Datalog [6, 30] based on a simple temporal logic with two temporal operators, namely first and next. The ow of time in the temporal logic is modeled by the set of natural numbers with its usual ordering relation <. The algebraic front-end, called Tra for Temporal Relational Algebra [19], is a point-wise extension of Codd's relational algebra upon the set of natural numbers. 1.1 Motivation While there is not a wealth of reported research on deductive systems for temporal data, temporal databases based on the relational model have been extensively studied in the literature (see McKenzie [17] and Snodgrass [28] for a review). In the underlying models of many proposals for temporal databases (e.g., see Tansel [10], Gadia [14] and Sarda [27]), relations extended with extra attributes for moments in time or intervals are often used to model the temporal dimension. \Temporal" extensions of the relational algebra and relational calculus usually complete the picture. However, in these models, it is not possible to formalize temporal relationships and dependencies among data. Temporal extensions of logic programming are considered by Chomicki and Imielinski [9] and Baudinet et al [5]. Both proposals are concerned with modeling and querying in nite temporal data in a language in which predicates are extended with explicit time parameters. We choose to propose an extension of Datalog based on the direct use of temporal logic as a basis for modeling temporal data, because the tools and techniques from temporal logic [25] are then available to us for reasoning about temporal deductive databases. In many of the temporal algebras proposed for non-deductive models, the results of expressions are not always temporal relations of the underlying models. Moreover, since they are speci cally designed to exploit actual representations of temporal data, they cannot be easily ported, if at all possible, to other models for temporal databases based on di erent representations. Cli ord [10] advocates that a temporal algebra should have the familiar relational algebra as a special case, and should be an algebra in the mathematical sense (i.e., it should satisfy the closure property for temporal operators). It is shown in [19] that Tra meets both of these requirements and therefore smoothly inherits all the tools and methodologies available for the relational algebra [16]. This is one of the reasons as to why Tra is a good candidate for coupling with Temporal Datalog. 1.2 Temporal Datalog In Temporal Datalog programs, temporal relationships among data are modeled through the use of temporal operators, not by explicit references to time. For example, given a predicate, say in-circulation, representing all the books which are in circulation in a library, the following rule asserts that all the new arrivals go into circulation after a fourteen day waiting period: next(14) in-circulation(Book) <- new-arrival(Book). 1 Here next(14) is the \fourteen days later" operator. The minimum temporal Herbrand model [20] of a given Temporal Datalog program is regarded as the temporal database the program models intensionally. Therefore Temporal Datalog provides an elegant abstract formalism for modeling temporal databases based on temporal logic. We can naturally use standard logic programming techniques to query a given Temporal Datalog program. However, in Temporal Datalog, since temporal relations are manipulated a tuple at a time, they are not rst-class citizens in the language. Therefore some familiar aggregation operations such as sum, avg and count cannot be provided in Temporal Datalog. This limitation of the language provides part of our motivation for proposing the use of Tra as an algebraic front-end to temporal deductive databases. Tra is already second-order to Temporal Datalog, and temporal relations are therefore the very objects that are manipulated by its operations. An algebraic front-end also opens up the possibility that we no longer have to stay within a rst-order framework for specifying temporal databases. Consider the in-circulation predicate mentioned above: We might also have a rule which says that all the books which are in circulation today will stay in circulation tomorrow: next in-circulation(Book) <- in-circulation(Book). This rule is valid from day one on, and thus it contributes to the de nition of the entire history of the in-circulation predicate. (A more detailed discussion of this library database is given in Section 2.) Therefore temporal relations coming from temporal deductive databases are inherently in nite, that is, they are nite at moments in time or over intervals, but in nite in the aggregate. In many non-deductive models for temporal data [10, 18, 28, 29], temporal relations are restricted to the interval from the beginning up to the current moment in time (say \now", \today", \this month" and so on). The in nitary nature of temporal relations does not cause any problems during the evaluation of Tra expressions, because snapshots (slices) of temporal relations can be retrieved from a given temporal deductive database by bottom-up evaluation strategies [6]. 1.3 A Modular Extension Several researchers [8, 23] have recognized that there is a need for a modular extension of query languages and deductive databases. Just like the algebraic operators of Tra, logic modules can be used to manipulate temporal relations as rst-class citizens. Therefore, through modules, Tra can be turned into an algebraic query language with the true power of a deductive system. In our framework outlined so far, Temporal Datalog is nothing but a one-o device to Tra, just providing base relations to the algebra in the background. A module has a number of input predicates and an output predicate, and a number of rules local to it. In other words, it is a second-order object to the outside world, i.e., an \operator" manipulating predicates. When viewed as an operator of Tra, given a number of temporal input relations, a module returns a temporal output relation represented by its output predicate. Therefore, through modules, temporal relations created during the evaluation of Tra expressions may be fed back to the deductive part for further manipulation. In turn, temporal modules allow us to enrich Tra with non-standard (algebraic) operators which may involve recursion and operations on individual data items. For instance, we can de ne a transitive closure module, say tcm, which behaves 2 just like a genuine algebraic operator of Tra, and apply it to any given expression representing a binary relation. Temporal modules can be de ned on the y during the query evaluation process, and we may even have a number of frequently used modules stored and maintained in a module library. Therefore users can customize Tra to the speci c requirements of their applications with great ease. We can surely study the properties of Tra and Temporal Datalog in complete isolation from each other; but it is the interplay between the two through temporal modules that appeals to us most. For instance, as operators, temporal modules are subject to the same rules that govern the native operators of Tra, and yet they are still subject to the standard logic programming techniques [15]. To summarize, in our approach to temporal databases, the notion of time is abstracted away from the object language, as this would be the case in any framework based on temporal logic. It has a sound formal basis, and enables technology transfer from the established methods and tools that are available for both the relational algebra and deductive databases to temporal databases. In summary, we take all that logic programming and the relational algebra together have to o er, and mold it into one coherent deductive system for specifying and querying temporal data. This approach is in accordance with the conclusion drawn in [22]. 1.4 The Structure of the Paper In the next section, we introduce Temporal Datalog and outline the declarative semantics of programs of the language. Temporal Datalog is the function-free subset of the temporal language Chronolog [20, 21]. In Section 3, we summarize the operations of Tra from [19], and provide the denotational semantics of Tra expressions. In Section 4, we demonstrate how temporal queries may be formulated in Tra and give examples of time-speci c and time-relative selection, temporal splicing, and of temporal join, i.e., combining and manipulating temporal data from di erent moments in time. In Section 5, we introduce a modular extension of Temporal Datalog, based on a syntactic variation of Fitting's modular logic programming [12]. In Section 6, we discuss the simulation of operators of Tra in Temporal Datalog. In Section 7, we relate our work to other approaches to modeling temporal databases. Some further research directions are pointed out in Section 8. 2 Temporal Deductive Databases Logic programs without any function symbols, i.e., Datalog programs [6, 30], are regarded as deductive databases. In a Datalog program, all predicates are guaranteed to represent nite relations, because the domain of any Herbrand interpretation of the program is nite owing to the restriction to the function-free subset of logic programs. In the following, we consider an extension of Datalog based on a simple temporal logic. We call the resulting language \Temporal Datalog". Temporal Datalog programs are regarded as \temporal deductive databases" in which temporal relationships among data are formalized through the use of temporal operators, not by explicit references to time. The minimum model of a given Temporal Datalog program is regarded as the temporal database the program models intensionally, according to which each predicate 3 used in the program represents a temporal relation. Slices of temporal relations from a given temporal database are nite at particular moments in time or over periods of time as the domain of any (temporal) Herbrand interpretation of the database is still nite, but they are in nite in the whole. However, we only need slices of temporal relations in Tra expressions (see the next section) which are computable by bottom-up evaluation strategies such as the xed point computation [6, 15]. 2.1 Temporal Datalog Temporal logic [25] is a kind of modal logic where the set of possible worlds models a collection of moments in time. Temporal Datalog is based on a simple temporal logic, i.e., the function-free subset of the underlying logic of the temporal language Chronolog [20]. We call the logic \TL", in which the set ! of natural numbers is the collection of moments in time with its usual ordering relation <. There are two temporal operators in TL, namely first and next, which are applied to formulas. The temporal operators refer to the initial moment and the next moment in time respectively. Note that these operators are inspired by those of the Lucid language [32]. The values of formulas of TL vary with the moments in time in !. TL extends a rst-order language without any function symbols with two new formation rules: if A is a formula, so are first A and next A. The informal semantics of temporal operators are given as follows: A formula of the form first A is true at time t if and only if A is true at time 0; and a formula of the form next A is true at time t if and only if A is true at time t + 1. In the following presentation, we write next(k) for k successive applications of next. In case k = 0, next(k) is the empty string. Let A be an atomic formula of the form p(e1; : : :; e ) where p is a predicate symbol and all e 's are terms. We call formulas of the form first next(k)A and next(k)A as temporal atoms; temporal atoms of the form first next(k)A are also called canonical. The values of terms in TL (such as the terms e1; : : :; e ) are rigid, i.e., independent of moments in time. The values of canonical temporal atoms are also rigid, because the use of first followed by a number (possibly zero) of applications of next pins a canonical temporal atom to a particular moment in time. For example, the atom first next(5)A is true at time t if and only if A is true at time 5, for any given value for t. The temporal operators first next(5) always move the context to time 5, no matter what the current reference point is. Just as Datalog program clauses are made up of atomic formulas, Temporal Datalog program clauses are made up of temporal atoms. Temporal atoms with arithmetic predicates are allowed in programs provided that they are restricted to nite relations by other predicates in program clauses. A program clause in a Temporal Datalog program is interpreted as an assertion true at all moments in time. We also refer to program clauses as rules, and unconditional rules as facts. The set of facts from a given program forms the extensional database whereas the set of rules the intensional database [6]. Note that the notion of time in TL is uninterpreted; it can be in terms of hours, days, weeks, years and so on, depending on the intended application domain. Below is an example Temporal Datalog program. Example 1 Suppose that new books in a library do not go into circulation until after two weeks of their arrival. After then, they stay in circulation on a daily basis. The logical time (the moments in time) in this example is interpreted as days. Let the n i n 4 in-circulation predicate represent all those books that are in circulation. The following is the partial de nition of the in-circulation predicate: first in-circulation(mobbydick). first in-circulation(les-miserables). first in-circulation(the-hobbit). ::: next(14) in-circulation(Book) <- new-arrival(Book). next in-circulation(Book) <- in-circulation(Book). mobbydick les-miserables the-hobbit The rst three rules in the program de ne three books, namely , and , to be in circulation on the rst day (time 0). The third rule says that new arrivals go into circulation after fourteen days. The last rule says that all books currently in circulation on any given day stay in circulation the next day as well. The last two (temporal) rules de ne temporal relationships among data. All rules in the program are regarded as assertions true at all moments in time. Therefore the rst three rules together with the last rule imply that mobbydick, les-miserables and the-hobbit stay in circulation from the rst day on. The new-arrival predicate is not formalized in the program, but supplied as input. Suppose that we are interested in nding the books that are in circulation on the third day (time 2). We can formulate this query in the logic programming format as follows: . <- first next(2) in-circulation(X) The temporal operators first next(2) move the context to the third day. The answers to the query are obtained as \answer substitutions" for the variable X (instantiations to the variable) such as X=mobbydick, X=les-miserables, X=the-hobbit and so on. In short, Temporal Datalog provides a formalism based on temporal semantics for modeling temporal databases. However, we can only model \valid time" in Temporal Datalog, as opposed to \transaction time", i.e., times of updates to the database [29]. This is because whenever an update operation is performed on a given temporal database (Temporal Datalog program), it is assumed that the updated database is the current version. Therefore all the previous instances of the database will be lost. The current version of the database models the history as it is best known of the enterprise being modeled. 2.2 Declarative Semantics Since Temporal Datalog is a subset of the temporal language Chronolog [20, 26], the declarative semantics of Chronolog programs can be directly applied to Temporal Datalog programs. In [20], it is shown that every Chronolog program has a minimum (temporal Herbrand) model, and the least xed point of a temporal P operation coincides with the minimum model of the program. In this section, we summarize the results for Chronolog programs with their applications to temporal deductive databases (Temporal Datalog programs) in mind. Given a Temporal Datalog program , let P denote the Herbrand universe of constructed as in [15]. The restriction to the function-free subset of Chronolog guarantees that the universe P of is always nite. It is also assumed that P is not T P U P U P U 5 empty. A temporal Herbrand interpretation I of P assigns each predicate symbol used in P a mapping from the collection of moments in time to nite relations over UP . Let Pred be the set of all predicate symbols appearing in P . Then we have that I 2 [Pred ! [ [! ! P (U n )]] n0 P where the notation [X ! Y ] denotes the set of all functions from X to Y , X n the nfolded Cartesian product of X , and P (X ) the power set of X , i.e., the set of subsets of X . For any given n-ary predicate symbol p, I assigns an n-ary temporal relation to p, that is, I (p) 2 [! ! P (UPn )]. In other words, elements of [n0 [! ! P (UPn )] are temporal relations with various arities. This formulation of temporal relations conforms to the abstract formalism used in [19]. Let M(P ) denote the set of temporal Herbrand models of a given Temporal Datalog program P . In other words, we have that for all I 2 M(P ), j=I P , i.e., P is true in I at all moments in time. In [20], it is also shown that the set of temporal Hebrand models of a given Chronolog program is closed under model-intersection. This result directly applies to Temporal Datalog programs. Therefore the model-intersection of all the models in M(P )|the greatest lower bound of M(P ), denoted as uM(P )|exists and it is the minimum temporal Herbrand model of P . The model uM(P ) constitutes the declarative semantics of P , and is regarded as the temporal database that P models intensionally. In summary, we have the following result, which is a restriction of an analogous theorem for Chronolog to Temporal Datalog: Theorem 1 Let P be a Temporal Datalog program. Then the set M(P ) of temporal Herbrand models of P is closed under model-intersection and therefore uM(P ) exists and is the minimum temporal Herbrand model of P. Bottom-up evaluation strategies such as the xed point computation based on the mapping TP |originally de ned by van Emden and Kowalski [31]|are used to compute the entire minimum Herbrand model of a given Datalog program [2, 6]. In Temporal Datalog, this is not possible due to the in nitary nature of time-varying predicates. However, in practice, we are interested in nite portions of a given temporal database. At any given moment in time, all predicates represent nite relations, and we should thus be able to use bottom-up evaluation strategies over any period of time. For example, the slices of (unary) temporal relations that the in-circulation predicate represents over a period, say from time t to time t + 5, is nite. A version of the TP operator de ned in [20] can be used to compute slices of temporal relations represented by time-varying predicates. Let P be a Temporal Datalog program, and H a temporal Herbrand interpretation of P . Let I (p)[t] denote the slice of the temporal relation at time t that p represents with respect to any given interpretation I of P . Then TP (H ) is a temporal Herbrand interpretation of P satisfying the following: For all p 2 Pred, for all ~e 2 U n and for all t 2 !, ~e 2 TP (H )(p)[t] if and only if there exists a canonical ground instance of a program clause in P of the form first nextt p(~e ) <-B0; : : : ; Bn?1 where for all 1  i  n, j=H Bi . Here a canonical ground instance of a program clause consists only of canonical temporal atoms without any uninstantiated variables. The de nition of TP relies on the result that a rule is true in an interpretation I if and only if all of its canonical ground instances are true in I [21]. 6 The xed point semantics of Temporal Datalog programs depends on that the temporal Herbrand models of P are characterized by the mapping TP , and TP over the complete lattice of the set of temporal Herbrand interpretations of P is continuous. Since continuity implies monotonicity, TP is also monotonic. Monotonic mappings over complete lattices have xed points; see [15] for details. Thus the least xed point of TP , denoted as lfp (TP ), exists and coincides with the minimum temporal Herbrand model of P . Again, the following theorem is a straightforward restriction of an analogous result for Chronolog to Temporal Datalog: Theorem 2 Let P be a Temporal Datalog program. Then uM(P ) = lfp (TP ). In [9], it is shown that the iterative bottom-up computation of nite answers is possible for a temporal language which can be used to specify in nite objects such as temporal relations. It can be shown that Temporal Datalog has the same expressive power as that temporal language, and that slices of temporal relations are nite over a nite Herbrand universe. Thus we have the following theorem: Theorem 3 Let P be a Temporal Datalog program and t 2 !. Then for any predicate symbol p 2 Pred, lfp (TP )(p)[t] is computable. When negation is considered in Temporal Datalog, the minimum model semantics is no longer valid. However, the perfect model semantics of strati ed logic programs [2, 24] can be extended to strati ed Temporal Datalog programs in a natural way. In this case, the perfect model of a given strati ed Temporal Datalog can be approximated by using bottom-up evaluation strategies. In the following presentation, we focus on negation-free Temporal Datalog programs. 3 An Algebraic Front-end In Temporal Datalog programs, we do not view predicates as representing an in nite collection of nite relations, nor do we manipulate nite relations at any given moment in time. However, this is not a matter of choice; it is simply so, because temporal relations are not rst-class citizens in Temporal Datalog. In fact, logic queries resemble queries in the \domain-relational calculus [16, 30]". For instance, the intersection operation of the relational algebra can be formulated as a logic query as follows: Given the expression r \ s where both r and s represent binary relations, the query <- r(X,Y), s(X,Y) achieves the desired e ect, with pairwise instantiations to the variables X and Y representing the tuples from the intersection. More complicated expressions may require a fair amount of variable shuing. On the other hand, the relational algebra o ers a more abstract, albeit second-order, notation for expressing queries. It is the second-order nature of the algebra that allows for the smooth incorporation of modules as operators (see section 5). One may feel that the choice between the relational algebra and logic queries is just a matter of taste; but it is not. There are a number of things that we can do in a natural way in an algebraic query language that we cannot do otherwise. For instance, there is no simple way to simulate the union operation as a single query without either modifying the underlying deductive database or introducing the disjunction as a new Boolean operator. Moreover, since temporal relations are not rst-class citizens in Temporal Datalog, it is not possible to specify such familiar aggregate operations as sum, avg, count and so on. 7 Also, without negation, the set di erence operation available in the relational algebra cannot be simulated in Temporal Datalog. Therefore we propose the use of a temporal relational algebra, which is referred to as Tra, as an algebraic front-end to Temporal Datalog. The algebra Tra is introduced in [19] for querying temporal databases based on an abstract model. In the following we summarize the operations of Tra, and then outline the denotational semantics of its expressions, while keeping its application to temporal deductive databases in mind. Examples of the formulation of queries in Tra are given in the next section. 3.1 Temporal Algebra Tra The temporal algebra Tra is a \point-wise extension" of the relational algebra upon ! de ned as follows: Its signature includes all operators of the relational algebra, and its universe is the set of temporal relations [n0 [! ! P (U n )] where U is the domain (Herbrand universe) of interpretations of TL. There is a natural correspondence between this abstract formulation of temporal relations and those represented by time-varying predicates in Temporal Datalog programs. It is in fact this correspondence that enables the use of Tra as an algebraic front-end for Temporal Datalog. Let 5 be a unary operator of the relational algebra, and 5T the corresponding operator of Tra. For any given temporal relation r, the following holds: For all t 2 !, we have that 5T (r)(t) = 5(r(t)): Similarly for the binary operators. The operator 5T denotes the point-wise operation on the universe of Tra corresponding to the operation 5. In other words, when restricted to moments in time, a point-wise operator degenerates into the corresponding operator of the relational algebra. Therefore we can explain what a point-wise operator does to its operand by looking at the individual results for each moment in time. This implies that Tra, by design, has the relational algebra as a special case. Yaghi [33] studied a similar notion in the context of the Lucid language. An expression of Tra consists of compositions of algebraic operators and predicate symbols. In Tra, there are three kinds of algebraic operators: (1) point-wise operators, (2) temporal operators, and (3) aggregation operators. These operators are applied to temporal relations and yield temporal relations as a result which can then be used as operands in other expressions. We use the same symbols for both the point-wise operators and the corresponding operators of the relational algebra. The signature of Tra is extended with temporal and aggregation operators summarized below. We assume familiarity with the notions of a comparator value and comparator formula; see [16, 30] for more details. For convenience, we write < r0; r1; r2; : : : > for a given temporal relation r, and also treat r as a function of moments in time: r = t:rt. Point-wise operators are \; [; ; ?; X , and F . Here X is a nite sequence of values greater than 0, and F a comparator formula. All of \; [ and (?) take two operands (temporal relations) with the same arity. At any given moment in time t, the outcome of a point-wise operation depends only on the values of its operands at time t. For instance, given the expression r \ s, the resulting temporal relation is the \point-wise intersection" of r and s, that is, r \ s =< r0 \ s0; r1 \ s1; r2 \ s2; : : : >. Point-wise Operators 8 Temporal Operators The temporal operators first, next and prev take one argument; fby is a binary operator. Here first is the \initial value" operator, next the \tomorrow", prev the \yesterday" and fby the \temporal splicing". Although the temporal operators first and next of Tra do not behave the same way as those of TL do, we use the same symbols as it can always be understood from the context which ones are referred to. Intuitively, the temporal operator first freezes a temporal relation at its initial value; next and prev shift a given temporal relation in the corresponding direction; and fby does cutting and pasting of temporal relations. Read r fby s as \r at time 0, followed by s from time 1 on. At any given time t, the outcome of a temporal operation may depend on the values of its arguments possibly at time t and at other moments in time. For instance, given a temporal relation r, we have that first r =< r0; r0; r0; : : : > (i.e., the value of first r at time t depends on the value of r at time 0); next r =< r1; r2; r3; : : : > (i.e., the value of next r at time t depends on the value of r at time t +1); and prev r =< ;; r0 ; r1; r2 ; : : : > (i.e., the value of prev r at time t depends on the value of r at time t ? 1 when t > 0; the empty set otherwise). From here on, we use the notation next(n) and prev(n) as syntactic sugar for n-folded applications of next and prev. Given two temporal relations r and s, we have that r fby s = < r0; s1; s2; : : : >. Aggregation Operators Let x  1. Aggregation operators are sumx, avgx, count, and minx with their obvious interpretations. These point-wise operators are applied to temporal relations with arbitrary arities, and produce unary relations as a result. For example, given a temporal relation r whose arity is less than or equal to x, avgx(r) =< avgx (r0); avgx (r1 ); avgx (r2 ); : : : >. The avgx(ri ) operation returns, in a unary tuple, the average of the values of the xth attribute from all the tuples in the given relation ri. maxx 3.2 Denotational Semantics Given a Temporal Datalog program db (a temporal deductive database), an expression over db contains only those predicate symbols used in db, and terms from the Herbrand universe of db. We assume that all expressions are legal, i.e., arities of relations given in an expression match with respect to the operations involved, and so do the types of attributes over which aggregation operations are performed. The meaning of an expression of Tra is a temporal relation, just like the meaning of a predicate symbol de ned in db. Let [ E ] (db) denote the denotation (meaning) of E with respect to a given temporal database db. All predicate symbols appearing in E receive a denotation (a temporal relation) with respect to the minimum (temporal Herbrand) model of db. In particular, given an n-ary temporal relation r, we have that r 2 [! ! P (U n )] where U is the domain of r. Thus [ E ] (db) is also an element of [! ! P (U k )] for some k  0. In general, given an expression E of Tra, we have that [ E ] 2 [DB ! [ [! ! P (U n )]] n0 where DB is the set of Temporal Datalog programs, and U is the set of ground terms of TL (the Herbrand universe of TL). Given db 2 DB, s 2 !, x  1, and Tra expressions A and B , the following are the de nitions of the denotations of each kind of expressions of Tra. 9 1. [ p] (db) = (uM(db))(p) where p is a predicate symbol. 2. [ 5A] (db) = 5[ A] (db) where 5 is a unary operator of Tra. 3. [ A 5 B ] (db) = [ A] (db) 5 [ B ] (db) where 5 is a binary operator of Tra. Item 1 is the basis case of the de nition which establishes the connection to a given temporal deductive database. Items 2 and 3 formalize the meaning of operators of Tra. In [19], it is shown that an analogous denotation function [ :] assigns a temporal relation to each (legal) Tra expression. However, we need a slightly modi ed result which, for the proof of item 1, makes a reference to the minimum model semantics of the given temporal database db. We state the following theorem without proof: Theorem 4 The denotation function [ :] is well-de ned, i.e., for any legal expression E over a temporal deductive database db, [ E ] (db) 2 [n0 [! ! P (U n )]. Put it another way, the theorem says that the algebra satis es the closure property. In some other approaches to temporal relational algebras, the outcome of an expression is not always a temporal relation (possibly slices of temporal relations and temporal elements such as intervals), e.g., the algebras discussed in [10, 14, 27]. It is also natural to talk about the denotation of temporal operators. For instance, next is a mapping from temporal relations to temporal relations. In other words, next is a function of type [ [ [ [! ! P (U n )] ! [! ! P (U n)]]: n0 n0 In fact, we have that next = r:t:rt+1. This formulation of (temporal) operators provides a basis for a study of the formal properties of Tra. For instance, it is known that the operators of the relational algebra except the set di erence are monotonic. Since Tra is a point-wise extension of the relational algebra, the monotonicity result immediately extends to its point-wise operators. In short, Tra inherits all properties of the relational algebra, because the meaning (properties) of point-wise operators can be reduced to, and explained in terms of, the meaning (properties) of the corresponding operators in the relational algebra. Based on this formalism, it is also possible to study the interaction between temporal operators (and that between temporal operators and point-wise operators.) We refer the reader to [19] for a more detailed discussion on this topic. All operators of Tra can be viewed as operations on temporal relations as in nite sequences of nite relations. Although this static view helps us to understand the overall e ect of algebraic operators, we prefer the \dynamic" or localized view while forming queries demonstrated in the next section. 4 Querying Temporal Databases In this section, we give some examples of querying temporal data in a given temporal (deductive) database. It should be kept in mind that Tra is a representation-free algebra; in other words, its operators are not designed to manipulate explicit representations of time, or temporal elements such as intervals. The absence of explicit manipulation of time in Temporal Datalog resulting from the direct use of temporal logic also requires 10 an algebraic front-end such as Tra to be at least as abstract as the language itself. Thus, as a consequence of the level of abstraction that Temporal Datalog and Tra together o er, queries to nd times of when things happen cannot be formulated by Tra expressions. For example, given an employee relation, we cannot answer the query \When did the employee X get promoted to the manager?" However, we can ask the query \Did the employee X get promoted to the manager at a particular time t or within the period of time from s to t?" In the following, we stipulate that all queries be evaluated at a given moment in time|say \now", \today", \this month", \this year" and so on|or over a period of time (interval) identi ed by its starting and ending times. The evaluation of a query over an interval is performed by evaluating the query at all moments in the interval. We regard an interval as a window through which temporal data may be viewed and manipulated. In the following, we assume that base relations come from a temporal deductive database, i.e., a Temporal Datalog program, and are computed by bottomup evaluation strategies when needed. We also provide, wherever appropriate, logic queries corresponding to algebraic expressions. 4.1 Temporal Selection Suppose we are given an employee relation, emp(Name,Dept,Salary) and a department relation dept(Dept,Manager) in a temporal deductive database db. It is assumed that the Name attribute in emp is the key for the employee relation; and the Dept attribute in dept is the key for the department relation. From here on, we refer to the attributes in a given relation by their positions. In the following examples, the logical time is interpreted as \months". Month 0 is when the temporal database came into existence. Below is a partial de nition of the emp and dept relations: first first first first first first ::: emp(kim,toys,2300). emp(joel,toys,2500). emp(bob,shoes,2250). dept(toys,joel). dept(shoes,bob). next emp(kim,toys,2300). first next(5) dept(toys,joel). first next(5) dept(shoes,bob). ::: The rst ve facts formalize the status of the database at month 0. There are three employees, namely Kim, Joel and Bob, and two departments, namely Toys and Shoes. Kim and Joel work in the Toys department whereas Bob works in the Shoes department. Joel is the manager of the Toys department, and Bob is the manager of the Shoes department. The rest of the facts axiomatize the status of the database at months other than month 0 and so on. As one can notice, some of the data in the database do not change over the course of time. In order to avoid the tedious repetition of unchanged data, we use the notation [x; y ] A to denote that the rule (fact) A is valid over the interval [x; y ]. This is just a syntactic sugar for a number of rules (facts) for each moment in the interval. In the above example, the facts saying that Joel is the manager of the Toys department from 11 month 0 to month 5 all together may be replaced by a single rule, that is, [0,5] dept(toys,joel). In many applications, a \snapshot" of temporal data at a particular moment in time is of interest. Snapshots are the status of a given temporal database at a particular moment in time. Queries of this kind are time-speci c. Example 2 Consider the query \Who is the manager of the Toys department at month 5?" The answer should always be the same regardless of when this time-speci c query is asked. The following is the logic query where an instantiation to the variable X provides the answer (in fact there is only one answer). <- first next(5) dept(toys,X) The following is the query in Tra: 2 (1="toys" (first next(5) dept)) The temporal operator(s) first next(5) move the context to month 5. Therefore a temporal selection can be achieved through temporal operators. Since the manager is Joel at month 5, implied by the rule first next(5) dept(toys,joel), the answer is the relation f< joel >g whenever the query is evaluated. Let E be the expression given above. Then we have that [ E ] (db) = t:f< joel >g. Sometimes we are interested in what happens relative to a reference point in time, say \now", \today" and so on. We may pose queries like \Who was the manager of the Toys department two months ago?", or \Is Kim going to get a raise next month?". In such a query, there is no explicit reference to time, thus the value of the query depends on when it is evaluated. Queries about the future are not problematic, because it is assumed that the temporal (deductive) database completely models the reality about the employee and department relations. If future data is not available yet, the answer would be the empty set with respect to the minimum model semantics. Example 3 Consider the time-relative query \Who was Kim's manager last month?" Below is the logic query to which the answer is obtained as an instantiation to the variable Y. <- prev emp(kim,X,S), prev dept(X,Y) The variables X and S have no place in the answer to the query, but X is essential in forming it. Here S is a \don't care" variable; in other words, it is just a place-holder for the salary of Kim, and serves no other purpose. The answer to the query naturally varies with the time of evaluation. The following is the query in Tra: prev(2(2 (1="kim"emp) 1 dept)) 1=1 Here 1 is the point-wise -join operator, de ned in terms of other point-wise operators of Tra. The temporal operator prev moves the context to the last month no matter what the reference point is. Therefore the answer to this query varies depending on when it is evaluated. At month 0, the answer would be the empty set, which is implied by the semantics of prev. At month 1, the answer is the tuple < joel >, because at month 0 Kim works in the Toys department whose manager is Joel and so on. 12 4.2 Temporal Join Temporal data from di erent moments in time can be combined through the use of temporal operators. For instance, we may be interested in what happened over a period of time in a given department. The period of interest may be time-speci c or timerelative. We rst introduce a notation for representing intervals (i.e., periods of time). Let x; y  0.  Time-speci c intervals are denoted as [x; y] where x  y.  Time-relative intervals are denoted as [(+=?)x; (+=?)y] where (+=?)x  (+=?)y. The following are time-relative intervals: [?3; +5], [?6; ?1] and [+2; +4], the rst of which overlaps with \now". The next step is the incorporation of intervals in Tra as temporal operators. The expression [x; y]E is interpreted as combining temporal data by intersection, i.e., all those tuples in E that are common at every moment in the interval [x; y]. With this interpretation, interval operators become a syntactic sugar for expressions involving temporal selections and intersections. For instance, the expression [?1; +1]E is a shorthand notation for the expression prev E \ E \ next E: Such expressions in fact do \temporal join", i.e., combine and summarize temporal data from di erent moments in time. Example 4 Consider the query \Find all those employees who worked in the same department in the last three months". The following is the logic query: <- prev emp(X,Y,S1), prev(2) emp(X,Y,S2), prev(3) emp(X,Y,S3) The answer to the query is in the form of instantiations to the variable X. The variables S1, S2 and S3 are all \don't care". Supposing that Joel works in the Toys department up to and including month 5, the answer to the query at month 2 includes Joel. At months less than 2, the answer to the query is \no". The following is the query in Tra. 1([?3; ?1](1 2 emp)) If any employee is not transferred to another department over the interval [?3; ?1], the corresponding employee tuples are the same with the possible exception of salaries. That is why we can formulate the query by temporal intersection. At months less than 2, the answer to the Tra query is the empty set (corresponding to the \no" answer for the logic query). Suppose we are interested in the total salary of the employees in the Toys department over a period of time. We can answer such a query by aggregation operations over temporal data combined by temporal selections and unions. We use a di erent notation for intervals over which temporal data is joined by unions. Let < x; y > denote an interval de ned just like [x; y]. Intervals of this kind are also applied to expressions of Tra, but with a di erent interpretation. For instance, an expression of the form < 1; 3 > E is just a syntactic sugar for the expression ; first next E [ first next(2) E [ first next(3) E: Using temporal unions, we can also accumulate temporal data over an interval. 13 Example 5 Consider the query \Find all those employees who managed the Shoes department at one time or another." The answer to the query involves temporal selections from all moments in time, and therefore it is not computable. However, in reality, the range of the query should be restricted to the interval from the beginning up to \now", or up to the time of utterance of the query. The following is an attempt at the logic query: <- <0,now> dept(shoes,X) This query in fact stands for a number of distinct time-speci c queries, one for each month t over the interval <0,now>, of the form <- first next(t) dept(shoes,X). The answers to the query are those obtained from distinct queries. The following is the query in Tra. 2(< 0; now > (1="shoes" dept)) Here now refers to the moment in time at which the query is being evaluated. It is the responsibility of implementations to supply the time of evaluation in place of now. 4.3 Temporal Splicing In some cases, we are interested in a di erent form of temporal join, i.e., that of cutting out a portion of a temporal relation, and pasting a portion of another one in its place. This is achieved by the binary temporal operator fby. However, in the following discussion, we consider a more general form of temporal splicing, that is, a parameterized fby operator de ned in terms of the (native) operators of Tra as follows:  r fby[0] s =df r fby s,  r fby[t] s =df r fby (prev(next r fby[t ? 1] next s)), for t > 0. Read r fby[t] s as \r up to and including time t", and s from time t + 1 on. We call time t as the cut-point for fby[t]. Given two temporal relations r and s, it can be seen that r fby[t] s = < r0; r1; : : : ; rt; st+1; st+2; : : : >. The de ned fby[.] operator is very useful, so we employ it as a native operator in Tra. Example 6 Suppose that a 10% overall salary increase is planned starting at month t and the management wants to study its long term e ects on the company. The temporal database is now extended with a new employee relation, say proj-emp, modeling the salary increase starting at month t in order to keep the de nition of the original emp relation intact. Supposing the emp relation is provided for all moments in time (for the future as well), we can de ne the proj-emp relation as follows: next(t) proj-emp(Name,Dept,Salary) <next(t) emp(Name,Dept,S1), first next(t) emp(Name,Dept,S2), Salary is (S1 + 10% * S2). The rule says that the salaries of all employees from month t onwards will be increased by 10% of their salary at month t. There is no need to provide the de nition of proj-emp before time t, because it is the same as emp. For analysis, all references to the employee relation before month t should be regarded as references to the original emp relation, and at and after month t as references to the proj-emp relation. However, in time-relative 14 queries it is not possible to determine which relation should be used as there is no explicit mention of time. Therefore we provide a solution by \temporal splicing". The following Tra expression emp fby[t ? 1] proj-emp should be used whenever the employee relation is required. The fby[t ? 1] operator cuts emp at month t ? 1 and splices proj-emp to it starting from month t. Note that this query cannot be expressed as a single logic query, because it then requires providing the de nition of the new predicate proj-emp before time t as well. In other words, we would have no choice other than modifying the underlying Temporal Datalog program during the query evaluation process. 5 Temporal Modules We have so far considered temporal deductive databases as providing base relations to the expressions of Tra. With this setting, although Temporal Datalog o ers a succinct formalism for specifying temporal databases in the logic programming framework, it does not really matter for Tra from where temporal relations are coming. The ow of temporal data is uni-directional, and thus Temporal Datalog is a one-o device to Tra. What we really need is a mechanism that would enable us to use freely the deductive capabilities of Temporal Datalog for temporal relations created during the evaluation of algebraic expressions. In this section, we o er a solution to this shortcoming of the coupling of Tra and Temporal Datalog by extending it with temporal modules. Temporal modules can be used to feed back temporal relations created during the evaluation of Tra expressions to the deductive part for further manipulation. This extension therefore o ers the ability to specify non-standard algebraic operators. Modular extensions of deductive databases have been considered by many researchers. For example, in the Glue{Nail project [23], generic modules are considered for use in both the deductive part (Nail!) and the procedural query language (Glue). HiLog [8] is a higher-order logic programming language which can be used as a database programming language with generic modules, i.e., second-order predicates with an input predicate. Fitting [12] proposed a modular extension of logic programming with the minimum model property, which can be smoothly adapted to Temporal Datalog. In the following, we therefore use a syntactic variation of Fitting's modular logic programming. 5.1 Modules as Operators In Tra, we cannot compute the transitive closure of a (temporal) relation. It may be argued that a transitive closure operation could be speci ed in Temporal Datalog for any binary relation over the universe of a given temporal database. However, this approach is highly impractical, because it requires that every binary relation be given a name, and its de nition be added to the temporal database. A better and more workable approach is to provide a mechanism for specifying generic modules so that the same de nition can be used for any given binary relation. In the algebra we would like to be able to write tcm(r) for any binary relation r where tcm is the generic transitive closure operator. A generic module has a number of input predicates and an output predicate. 15 Example 7 We de ne a transitive closure module which imports an input predicate , and exports an output predicate tc (representing the transitive closure of the input relation) as follows. ip module tcm, import ip, export tc. tc(X,Y) <- ip(X,Y). tc(X,Z) <- tc(X,Y), tc(Y,Z). end. This module can be regarded as an operator which, given a temporal relation, returns a temporal relation. Therefore, we can use this module as an operator in exactly the same way as we do any other operator of Tra. We can also use temporal rules, other forms of recursion, and arithmetic operations in such a module. In the above example tcm is a point-wise operator, because its de nition does not contain the use of any temporal operator of TL. In Tra, we can now use tcm as a genuine operator in the form tcm(E ) for any given expression E . The only restriction is that the arity of the relation E represents must match the arity of the input predicate ip. Temporal modules allow us to de ne and use non-standard algebraic operators in Tra, through which we have access to the use of recursion, arithmetic predicates and temporal operators. This is where we bene t most from a modular extension of Temporal Datalog: We have an extendible algebraic query language with the full power of a deductive system. For instance, using temporal modules, we can specify \virtual relations", i.e., relations that do not exist in temporal databases, but can be computed from the base relations if and when needed. Example 8 Suppose that we are required to provide a temporal relation, say ediff, formalizing the monthly salary di erences for each employee from the employee relation. The salary di erences are simply calculated by subtracting from the current salary the last month's salary for each employee. Clearly, ediff is a virtual relation; the information about the salary di erences is implicitly available in the temporal database. In order to be faithful to the true nature of ediff, its de nition can be easily provided as a temporal module as follows: module ediff, import emp, export emp-diff. next emp-diff(X,Diff) <emp(X,Y1,S1), next emp(X,Y2,S2), Diff is S2 - S1. end. ediff(emp) emp In Tra expressions, we just write for the salary di erence relation. Note that given , it is not possible to write down a Tra expression that does the same job. This is because Tra cannot be used to manipulate individual data items. The proj-emp relation in example 6 may also be regarded as a virtual relation. Example 9 In example 6, the temporal database is extended with the de nition of . Instead, we can provide a temporal module and keep the temporal database intact until the emp relation is updated. Loosely speaking, this is a form of hypothetical reasoning as we are interested in what would happen when employees were given a 10% salary increase. proj-emp 16 module projected, import emp, export proj-emp. [ ;t ](proj-emp(Name,Dept,Salary) <- emp(Name,Dept,Salary)). next(t) proj-emp(Name,Dept,Salary) <next(t) emp(Name,Dept,S1), first next(t) emp(Name,Dept,S2), Salary is (S1 + 10% * S2). end. proj-emp emp t projected(emp) 0 ?1 The rst clause says that represents the same relation as up to time ? 1. In Tra expressions, we just use the expression whenever the employee relation is required. In this example, \temporal splicing" is done in the module through temporal rules, not by an fby[.] operator in Tra. Example 10 We can also use modules to de ne (additional) temporal operators. For instance, a restricted version of first that operates on unary relations can be de ned as follows: module ufirst, import ip, export op. op(X) <- first ip(X). end. However, module operators are not substitutes for the temporal operators of Tra. Given the above framework for modules, we cannot de ne a temporal operator module, say first, in such a way that it works on any given input relation regardless of the arity. Such a facility can be provided if we employ second-order logic within temporal modules. 5.2 Input-Model Semantics The declarative semantics of Temporal Datalog programs does not extend to temporal modules, because temporal modules are second-order objects to the outside world. However, the semantics of temporal modules can be studied in isolation by xing their input predicates to particular input relations. Note that we ignore temporal modules with no import lists, as they are no di erent in terms of functionality than any other predicate de ned in Temporal Datalog programs. Each module takes a number of temporal relations as input, and returns a temporal relation as output. This implies that the meaning (denotation) of a temporal module is a function operating on temporal relations, just as the denotation of native Tra operators. As an operator of Tra, the transitive closure module tcm is an element of [[! ! P (U  U )] ! [! ! P (U  U )]]: Given an element r of [! ! P (U  U )], we have that (r) = (uI (r)(tcm))(tc) tcm where tcm is the transitive closure operator and I (r)(tcm) = fI j j= I tcm 17 and I (ip) = rg: We di erentiate between the name of the temporal module, i.e., tcm, and the module operator it denotes, i.e., tcm. Using Fitting's terminology [12], I ( )(tcm) is the set of -input models of tcm. In such models, the input predicate ip is assigned to the input relation and nothing more and nothing less; hence the term \ -input models". Fitting [12] showed that the set of -input models of a module is closed under model intersection, and, therefore, there is a minimum -input model. This result naturally extends to temporal modules. This formalism suces to assign a meaning to Tra expressions of the form tcm( ). The output of tcm is the temporal relation represented by its output predicate with respect to the minimum -input model semantics. More formally we have the following theorem: r r r r r r E r Theorem 5 Let mod be a (unary) temporal module and r be temporal relation where the arities of mod's input predicate and r match. Then the set of r-input models of mod is closed under model-intersection and therefore there is a minimum r-input model of mod. Let Mod be a set of temporal modules, and a temporal deductive database. The denotation function [ ] can be extended to include module operators as follows. Let mod 2 Mod. Given Tra expressions 1 n , we have that db : E ;:::;E [ mod ( E1 ; : : : ; E n )]]( ) = mod ([[ 1] ( ) db E [ ] ( )) db ; : : : ; En db where each [ k] ( ) is the th input relation to the temporal module mod. More specifically, let k = [ k] ( ) for 1   , op be the output predicate and ip1 ipn be the input predicates in mod. Then, with a straightforward generalization of the above theorem to modules with more than one input predicates, we have that E r db E k db mod i ( r1 ; : : : ; r n n ;:::; ) = (uI ( r1 ; : : : ; rn )(mod))(op) where I( 1 r ; : : : ; rn )(mod) = f j j=I mod and for all 1   I k n; I (ipk ) = k g r : The above formulation of the denotations of module operators can be generalized to modules with multiple inputs and multiple outputs. However, we omit the details. Note that theorem 4 can be extended to include module operators by replacing the proof of item 1 with the proof of a similar case for module operators | one case is enough, because predicate symbols from Temporal Datalog programs can be considered as modules without any input predicates. Input relations to a module are nite at any given moment in time (or over intervals), which implies that output relations are also nite. Therefore we can adopt bottom-up evaluation strategies for a modular extension of Temporal Datalog. However, in the standard least xed point semantics [15], we start from an interpretation in which all predicates represent empty relations. For a given temporal module, the starting point for bottom-up evaluation would be an interpretation of the module in which all input predicates are exactly assigned to the corresponding input relations, and the rest of the (local and export) predicates represent empty relations. The xed point computation relative to a given interpretation is studied by Apt et al [2] in the context of strati ed logic programs. We can adapt their formalism to temporal modules. 18 Temporal modules can also be used within Temporal Datalog programs, in which case we must be careful in de ning the semantics of temporal modules. Since temporal modules operate on temporal relations, what we have then is a second-order construct in the language. However, the semantics framework for Temporal Datalog presented so far does not extend to second-order programs. There are no problems in Tra with the use of temporal modules, since it is already second-order. In HiLog [7], modules with second-order syntax are given a rst-order semantics. We conjecture that a similar approach can be adapted to a stand-alone Temporal Datalog with modules. Note that the extended semantic framework would enable the use of Tra expressions in Temporal Datalog programs as well as temporal modules. 6 Temporal Datalog Revisited In deductive databases (without negation), all operations in the relational algebra except the set di erence can be simulated by rules [6, 30]. Note that the (standard) relational algebra does not include aggregation operators. However, the simulation does not involve the speci cation of a set of generic rules for each operator that would work on any given input relation, but it rather involves the simulation of particular applications of the operator. For example, given two binary temporal relations and , the intersection operation \ can be simulated by the rule r r s s inter-rs(X,Y) <- r(X,Y), s(X,Y). The inter-rs predicate represents the intersection where the binary predicates r and s simulate the relations and . We cannot simulate the intersection operation in a rst-order framework in such a way that it works on any two given relations with the same arity. In the temporal case, although all point-wise operations from the relational algebra except the set di erence can be simulated by rules in Temporal Datalog, it is not obvious which temporal operations in Tra can be simulated, if any at all. One can observe that the counterparts of the temporal operators first and next are already available in Temporal Datalog (in TL) whereas the counterparts of prev and fby are not. In the following, it is shown that the lack of prev and fby in Temporal Datalog does not a ect the simulation aspects of the language. Let and be binary temporal relations, and r and s the predicates modeling and . The following three rules simulate the operations first , next and prev respectively. The rst two rules are given for the sake of completeness; there is indeed a natural correspondence between first and next of Tra and those of Temporal Datalog. The expression prev can be simulated by a single rule whose conclusion (head) is in the one step future of its premise. r r s s r s r r r r first-r(X,Y) <- first r(X,Y). next-r(X,Y) <- next r(X,Y). next prev-r(X,Y) <- r(X,Y). third rule says that prev-r is true of The a binary tuple, say , at time 0 if r is true of at time ? 1. The rule does not say anything about the prev-r predicate at time 0 because of the use of next. This implies that prev-r represents the empty set at time 0, which conforms to the semantics of prev in Tra. < a; b > < a; b > t 19 t > The operation r fby s can be simulated by two rules, one formalizing the resulting relation as r at time 0, and the other formalizing the resulting relation as s from time 1 on: first fby-rs(X,Y) <- first r(X,Y). next fby-rs(X,Y) <- next s(X,Y). Here fby-rs represents the resulting relation from the operation r fby s. The above discussion leads to the formulation of the following result: Theorem 6 All temporal operators of Tra can be simulated by temporal rules in Temporal Datalog. The theorem can be proved by showing that, with the assumption that the predicates r and s simulate r and s faithfully, the temporal relations represented by the predicates de ned above with respect to the minimum model semantics are the same relations denoted by their corresponding Tra expressions. The temporal logic of Temporal Datalog (or of Chronolog [21]) has only two temporal operators, and therefore it seems to have a limited expressive power. It is also possible to consider extending Temporal Datalog (TL) with extra temporal operators prev and fby. Such an extension would open up the possibility that these two operators can now be used in the heads of rules as well as in the bodies, and the natural correspondence between prev and fby of Tra and those of Temporal Datalog could be exploited further. However, it should be noted that the extension is not necessarily more powerful than Temporal Datalog with only first and next, since fby can in fact be simulated by two rules in Temporal Datalog. As for prev, rules with applications of prev's can be transformed into rules with applications of next's only, by pushing all the rules into their future forms. We do not give the details of the transformation in this paper. 7 Discussion There are many other approaches to temporal databases, most of which extend the relational model with extra time attributes and introduce (temporal) query languages. To the best of our knowledge, temporal deductive databases have not been studied extensively. In the following, we brie y relate our work to some other approaches, and point out the similarities and di erences between our approach and others. Note that we use the term \temporal databases" to refer to those databases that only model \valid time [29]". Cli ord and Warren [11] in their pioneering work describe a query language called ILs , based on Montague's higher-order intensional logic. They also introduce a temporal semantics that formalizes the concept of a temporal database. However, the representation of time in temporal relations is made explicit by an additional state attribute. In contrast, Temporal Datalog provides a more abstract formalism for modeling temporal databases and expressing relationships among temporal data. ILs is very powerful and expressive, and it allows users to formulate yes/no queries and queries about when things happen. However, ILs is also sensitive to the way temporal data is represented in the temporal database. They employ in the model the notion of a completed relation which stipulates that all the values for key attributes be included in a given temporal relation. Therefore the representation of temporal data is highly redundant and each relation is 20 extended with another attribute to indicate whether a given tuple exists in the relation or not. This introduces some complications in query processing. In [10], Cli ord proposes a model and relational algebra for modeling and querying temporal databases. The model is based on an extension of the relational model with complex attributes, some of which are functions from moments in time or intervals to attribute values. The algebra is designed to exploit the representation of time-varying data, and no formal semantics is o ered for it. In the same paper [10], Tansel describes another model and temporal algebra to incorporate the time dimension in relational databases. Just as in Cli ord's approach, Tansel's algebra o ers a number of algebraic operators to manipulate di erent representations of temporal data. However, neither algebra satis es the closure property in the sense the relational algebra does. Sarda [27] proposes another temporal algebra, which has similar features as Tansel's. Sarda also outlines a query language based on an extension of Sql with temporal operators. In Gadia's approach [14], temporal elements (intervals) are also explicitly manipulated in the temporal algebra. Gadia also considers a relational calculus-based query language along with a temporal algebra and shows their equivalence. In our framework, we have a domain-relational calculus in logic queries for free. In [18], McKenzie and Snodgrass introduce an extension of the relational algebra with two rollback operators that can support both the valid time and transaction time, i.e., times of updates to the database [29]. Rollback operators are used to grab snapshots of temporal relations in a given temporal database. The denotational semantics of operators of the algebra are also given. However, the underlying model can only support a nite collection of snapshot states. The query language based on the algebra also includes an update operation which we have not considered yet. We have demonstrated that Tra reaches its full potential when coupled with Temporal Datalog through temporal modules. In such a system combining the features of both a relational query language and a deductive system, there are two components with similar (but not identical) expressive power, and yet the components o er di erent approaches and methodologies for specifying and manipulating temporal data. To the best of our knowledge, temporal modules seem to be original in the context of temporal deductive databases. As mentioned before, Temporal Datalog is the function-free subset of the temporal language Chronolog [20]. However, Chronolog is just one of the many temporal logic programming languages which can be used as a basis for temporal deductive databases. Templog [1] also has a similar time structure as Chronolog with the next time operator and two traditional temporal operators, namely \sometime" and \henceforth". The minimum model and xed point semantics of Templog programs are developed by Baudinet [3] in terms of temporal Herbrand models. The completeness of the proof procedure of Templog is also established by Baudinet [4]. Note that Chronolog also admits a sound and complete proof procedure (and hence so does Temporal Datalog). Temporal Prolog [13] is based on both linear and branching time temporal logics, and also o ers temporal operators to look into the past. Function-free temporal logic programs in any of these languages can be regarded as temporal deductive databases. Temporal deductive databases are also considered by Chomicki and Imielinski [9]. However, their approach is not directly based on temporal logic, since time is explicitly manipulated in rules. Their language is in fact an extension of Datalog in which each 21 predicate symbol has an additional time parameter, and it has the same expressive power as Temporal Datalog. Therefore, if we ignore temporal modules, the two languages can be considered as notational variants of each other. They claim a number of complexity results for query processing and representing in nite answers that can be obtained from periodical temporal data. Baudinet et al [5] describe another deductive language for specifying in nite temporal data, which is an extension of the language of [9] where each predicate symbol can have an arbitrary number of time parameters. Again, this language is not directly based on temporal logic. However, it should be noted that it is more expressive than Temporal Datalog without temporal modules, owing to the use of an unrestricted number of time-dimensions. 8 Future Work We have not considered negation in Temporal Datalog. The perfect model semantics of Przymusinski [24] for strati ed logic programs can be applied to strati ed Temporal Datalog with negation. It can be observed that Temporal Datalog introduces another form of strati cation, i.e., that of \temporal strati cation", due to the time-dependencies resulting from the uses of temporal operators. We call a program P \temporally stratied" if the values of all predicates de ned in P at any given moment in time t depend only on the values of predicates at time t or at times less than t. In other words, a temporally strati ed program does not contain rules with future dependencies such as p(X) <- next(2) q(X). Such rules are called backward in [9]. Future dependencies are contrary to the intuitive idea that only future data should be speci ed in terms of the available past data, and not vice versa. The interaction between \strati cation [2]" and \temporal strati cation" needs to be investigated within the context of the perfect model semantics and xed point computation. We conjecture that ecient bottom-up evaluation techniques can be devised for temporally strati ed Temporal Datalog programs. As function symbols are not allowed in Temporal Datalog programs, predicates are guaranteed to represent nite relations at any given moment in time. As an alternative, we may allow function symbols, but impose a model-theoretic restriction: We require that predicates represent nite relations at any given moment in time with respect to the minimummodel semantics. We know that Temporal Datalog with function symbols is the same as the temporal language Chronolog [20, 26]. However, such a model-theoretic condition on Chronolog programs is impossible to verify. Therefore more research needs to be done to identify larger subsets of Chronolog with the desired property. It is also important to investigate the general properties of temporal modules. It can be shown that temporal modules (without negation) as operators are monotonic and nitary (i.e., compact), and hence continuous; see [12] for a more detailed discussion of these properties. Note that module operators are not necessarily point-wise; the value of the output relation from a module at time t may depend on the values of the input relations at times other than t. For example, the module operators ufirst and ediff are not point-wise. The transitive closure module operator tcm is an example of point-wise module operators, because it does not contain uses of any temporal operators. 22 We now introduce a useful property of temporal operators. Let operator of Tra. We say that 5 is \conjunctive" if and only if 5 be a unary 5(r \ s) = 5(r) \ 5(s): In other words, a conjunctive operator commutes with \. Conjunctivity also implies monotonicity. It is shown in [19] that all temporal operators of Tra (as well as \, X and F ) have the conjunctivity property. This property can be used to push temporal operators inside. However, when module operators are considered, we must be more careful. Let mod be a unary module operator, and A and B expressions. If mod is conjunctive, an intuitive optimization strategy would be to use the conjunctivity property as a \right-to-left" rewrite rule in Tra expressions of the form mod A \ mod B . The rationale behind such a strategy is that the intersection of A and B yields a smaller relation than either of A and B , thereby at least halving the amount of e ort required to compute the output relation from the temporal module mod. We are studying the conditions under which temporal modules specify conjunctive operators. It is also important to explore the other properties that module operators enjoy (such as commutativity and associativity), and to study the interaction between module operators and the native operators of Tra. Consider the following property which says that next and mod commute: r = next mod( ) mod(next r). A sucient condition for this property to hold is that mod should be point-wise. These properties can be used in query optimization. In our opinion, temporal modules promise to be a fruitful avenue of further research. 9 Concluding Remarks In our approach to temporal (deductive) databases, Temporal Datalog provides an abstract formalism for modeling temporal databases, and Tra is an extendible algebraic query language with the closure property. Neither Tra nor Temporal Datalog allows for the speci cation, representation and manipulation of temporal data by explicit references to time. The tools and methods of temporal logic can be used to reason about Temporal Datalog programs and Tra expressions. We also believe that representation is an implementation issue, and should not in uence the design of temporal algebras and the choice of temporal operators thereof. Query optimization strategies can be directly based on the formal properties of Tra [19], and should be considered in conjunction with the xed point computation of the minimum models of Temporal Datalog programs and temporal modules. Acknowledgements I am indebted to W. W. Wadge for many stimulating discussions that led to the formation of the ideas presented in this article. Thanks are also due to J. H. M. Lee and S. R. Tilley for their helpful comments and suggestions on an earlier draft. 23 References [1] M. Abadi and Z. Manna. Temporal logic programming. In Proceedings of the 1987 Symposium on Logic Programming, pages 4{16, San Fransisco, Calif, 1987. IEEE Computer Society Press. [2] K. R. Apt, H. A. Blair, and A. Walker. Towards a theory of declarative knowledge. In J. Minker, editor, Foundations of Deductive Databases and Logic Programming, pages 89{148. Morgan Kaufmann, Los Altos, Calif, 1988. [3] M. Baudinet. Temporal logic programming is complete and expressive. In Conference Record of the Sixteenth ACM Symposium on Principles of Programming Languages, pages 267{280, Austin, Texas, January 1989. The Association for Computing Machinery. [4] M. Baudinet. A simple proof of the completeness of temporal logic programming. In L. Fari~nas del Cerro and M. Penttonen, editors, Intensional Logics for Programming, pages 51{83. Oxford University Press, 1992. [5] M. Baudinet, M. Niezette, and P. Wolper. On the representation of in nite temporal data and queries. In Proceedings of the Tenth ACM Symposium on Principles of Database Systems, pages 280{290. The Association for Computing Machinery, 1991. [6] S. Ceri, G. Gottlob, and L. Tanca. Logic Programming and Databases. SpringerVerlag, Berlin Heidelberg, 1990. [7] W. Chen, M. Kifer, and D. S. Warren. HiLog: A rst-order semantics of higherorder logic programming constructs. In Proceedings of the 1989 North American Conference on Logic Programming, pages 1090{1114. MIT Press, October 1989. [8] W. Chen, M. Kifer, and D. S. Warren. HiLog as a platform for database languages. In W. Kim, editor, Database Engineering, volume 8, pages 162{169. IEEE Computer Society Press, 1990. [9] Jan Chomicki and Tomasz Imielinski. Temporal deductive databases and in nite objects. In Proceedings of the Seventh ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems, pages 61{73. The Association for Computing Machinery, 1988. [10] James Cli ord and Abdullah Uz Tansel. On an algebra for historical relational databases: Two views. In S. Navathe, editor, Proceedings of the 1985 ACM SIGMOD International Conference on Management of Data, pages 247{265. ACM Press, 1985. [11] James Cli ord and David S. Warren. Formal semantics for time in databases. ACM Transactions on Database Systems, 8(2):214{254, June 1983. [12] Melvin Fitting. Enumeration operators and modular logic programming. Journal of Logic Programming, 4:11{21, 1987. [13] D. M. Gabbay. Modal and temporal logic programming. In A. Galton, editor, Temporal Logics and Their Applications, pages 197{237. Academic Press, 1987. 24 [14] Shashi K. Gadia. A homogeneous relational model and query languages for temporal databases. ACM Transactions on Database Systems, 13(4):418{448, December 1988. [15] J. W. Lloyd. Foundations of Logic Programming. Springer-Verlag, 1984. [16] David Maier. The Theory of Relational Databases. Computer Science Press, 1983. [17] Edwin McKenzie. Bibliography: Temporal databases. SIGMOD Record, 15:40{52, December 1986. [18] Edwin McKenzie and Richard Snodgrass. Extending the relational algebra to support transaction time. In U. Dayal and I. Traiger, editors, Proceedings of the 1987 ACM SIGMOD International Conference on Management of Data, pages 467{478. ACM Press, 1987. [19] M. A. Orgun and H. A. Muller. A temporal algebra based on an abstract model. In M. E. Orlowska and M. Papazoglou, editors, Advances in Database Research: Proceedings of the 4th Australian Database Conference, pages 301{316, Brisbane, Queensland, Australia, February 1{2 1993. World Scienti c. [20] M. A. Orgun and W. W. Wadge. Chronolog: A temporal logic programming language and its formal semantics. Department of Computer Science, University of Victoria, Victoria, B.C., Canada, January 1988. [21] M. A. Orgun and W. W. Wadge. Theory and practice of temporal logic programming. In L. Fari~nas del Cerro and M. Penttonen, editors, Intensional Logics for Programming, pages 23{50. Oxford University Press, 1992. [22] D. Stott Parker et al. Logic programming and databases. In L. Kerschberg, editor, Expert Database Systems, pages 35{48. Benjamin/Cummings Publishing Company, 1986. [23] G. Phipps, M. A. Derr, and K. A. Ross. Glue{Nail: A deductive system. In J. Clifford and R. King, editors, Proceedings of the 1991 ACM SIGMOD International Conference on Management of Data, pages 308{317. The Association for Computing Machinery, 1991. [24] T. C. Przymusinski. Perfect model semantics. In Robert A. Kowalski and Kenneth A. Bowen, editors, Logic Programming: Proceedings of the Fifth International Conference and Symposium, pages 1081{1096. MIT Press, 1988. [25] N. Rescher and A. Urquhart. Temporal Logic. Springer-Verlag, 1971. [26] D. W. Rolston. Chronolog: A pure tense-logic-based in nite-object programming language. Department of Computer Science and Engineering, Arizona State University, Tempe, Arizona, August 1986. [27] N. L. Sarda. Algebra and query language for a historical data model. The Computer Journal, 33(1):11{18, 1990. [28] Richard Snodgrass. Temporal databases: Status and research directions. SIGMOD RECORD, 19:83{89, December 1990. 25 [29] Richard Snodgrass and Ilsoo Ahn. A taxonomy of time in databases. In Proceedings of the 1985 ACM SIGMOD International Conference on Management of Data, pages 236{246. ACM Press, 1985. [30] J. D. Ullman. Principles of Database and Knowledge-Base Systems, volume 1. Computer Science Press, 1988. [31] M.H. van Emden and R.A. Kowalski. The semantics of predicate logic as a programming language. Journal of the Association for Computing Machinery, 23:733{42, 1976. [32] W. W. Wadge and E. A. Ashcroft. Lucid, the Data ow Programming Language. Academic Press, 1985. [33] A. A. Yaghi. An Intensional Implementation Technique for Functional Languages. PhD thesis, Department of Computer Science, University of Warwick, Coventry, England, 1984. 26