Abstract Versus Concrete Temporal Query Languages
Temporal query languages are a family of query languages designed to query (and access in general) time-dependent information stored in temporal databases. The languages are commonly defined as extensions of standard query languages for non-temporal databases with temporal features. The additional features reflect the way dependencies of data on time are captured by and represented in the underlying temporal data model.
Most databases store time-varying information. On the other hand, SQL is often the language of choice for developing applications that utilize the information in these databases. Plain SQL, however, does not seem to provide adequate support for temporal applications.
Formulating even simple queries over such a schema is non-trivial. For example, the query GAPS: “List all persons with gaps in their employment history, together with the gaps” leads to a rather complex formulation in, e.g., SQL over the above schema (this is left as a challenge to readers who consider themselves SQL experts; for a list of appealing, but incorrect solutions, including the reasons why, see ). The difficulty arises because a single tuple in the relation is conceptually a compact representation of a set of tuples, each tuple stating that an employment fact was true on a particular day.
The tension between the conceptual abstract temporal data model (in the example, the property that employment facts are associated with individual time instants) and the need for an efficient and compact representation of temporal data (in the example, the representation of continuous periods by their start and end instants) has been reflected in the development of numerous temporal data models and temporal query languages .
The choice of the actual temporal values manipulated by the language. This choice is primarily determined by the underlying temporal data model. The model also determines the associated operations on these values. The meaning of temporal queries is then defined in terms of temporal values and operations on them, and their interactions with data (non-temporal) values in a temporal database.
The choice of syntactic constructs to manipulate temporal values in the language. This distinction determines whether the temporal values in the language are accessed and manipulated explicitly, in a way similar to other values stored in the database, or whether the access is implicit, based primarily on temporally extending the meaning of constructs that already exist in the underlying non-temporal language (while still using the operations defined by the temporal data model).
Additional design considerations relate to compatibility with existing query languages, e.g., the notion of temporal upward compatibility.
However, as illustrated above, an additional hurdle stems from the fact that many (early) temporal query languages allowed the users to manipulate a finite underlying representation of temporal databases rather than the actual temporal values/objects in the associated temporal data model. A typical example of this situation would be an approach in which the temporal data model is based on time instants, while the query language introduces interval-valued attributes. Such a discrepancy often leads to a complex and unintuitive semantics of queries.
In order to clarify this issue, Chomicki has introduced the notions of abstract and concrete temporal databases and query languages . Intuitively, abstract temporal query languages are defined at the conceptual level of the temporal data model, while their concrete counterparts operate directly on an actual compact encoding of temporal databases. The relationship between abstract and concrete temporal query languages is also implicitly present in the notion of snapshot equivalence . Moreover, Bettini et al.  proposed to distinguish between explicit and implicit information in a temporal database. The explicit information is stored in the database and used to derive the implicit information through semantic assumptions. Semantic assumptions related to fact persistence play a role similar to mappings between concrete and abstract databases, while other assumptions are used to address time-granularity issues.
Abstract Temporal Query Languages
Most temporal query languages derived by temporally extending the relational calculus can be classified as abstract temporal query languages. Their semantics are defined in terms of abstract temporal databases which, in turn, are typically defined within the point-stamped temporal data model, in particular without any additional hidden assumptions about the meaning of tuples in instances of temporal relations.
The employment histories in an abstract temporal data model would most likely be captured by a simpler schema “Employment(Date, EID, Company)”, with the intended meaning that a person identified by EID was working for Company on a particular Date. While instances of such a schema can potentially be very large (especially when a fine granularity of time is used), formulating queries is now much more natural.
Temporal Relational Calculus (TRC): a two-sorted first-order logic with variables and quantifiers explicitly ranging over the time and data domains.
First-order Temporal Logic (FOTL): a language with an implicit access to timestamps using temporal connectives.
Here, the explicit access to temporal values (in TRC) using the variables t1, t2, and t3 can be contrasted with the implicit access (in FOTL) using the temporal operators ◆ (read “sometime in the past”) and ◇ (read “sometime in the future”). The conjunction in the FOTL query represents an implicit temporal join. The formulation in TRC leads immediately to an equivalent way of expressing the query in SQL/TP , an extension of SQL based on TRC.
The above query can be formulated in SQL/TP as follows:
The unary constant relation Time contains all time instants in the time domain (in our case, all Dates) and is only needed to fulfill syntactic SQL-style requirements on attribute ranges. However, despite the fact that the instance of this relation is not finite, the query can be efficiently evaluated .
Note also that in all of the above cases, the formulation is exactly the same as if the underlying temporal database used the plain relational model (allowing for attributes ranging over time instants).
The two languages, FOTL and TRC, are the counterparts of the snapshot and timestamp models (cf. the entry Point-Stamped Data Models) and are the roots of many other temporal query languages, ranging from the more TRC-like temporal extensions of SQL to more FOTL-like temporal relational algebras (e.g., the conjunction in temporal logic directly corresponds to a temporal join in a temporal relational algebra, as both of them induce an implicit equality on the associated time attributes).
Temporal integrity constraints over point-stamped temporal databases can also be conveniently expressed in TRC or FOTL.
Multiple Temporal Dimensions and Complex Values
While the abstract temporal query languages are typically defined in terms of the point-based temporal data model, they can similarly be defined with respect to complex temporal values, e.g., pairs (or tuples) of time instants or even sets of time instants. In these cases, particularly in the case of set-valued attributes, it is important to remember that the set values are treated as indivisible objects, and hence truth (i.e., query semantics) is associated with the entire objects, but not necessarily with their components/subparts.
Concrete Temporal Query Languages
Although abstract temporal query languages provide a convenient and clean way of specifying queries, they are not immediately amenable to implementation. The main problem is that, in practice, the facts in temporal databases persist over periods of time. Storing all true facts individually for every time instant during a period would be prohibitively expensive or, in the case of infinite time domains such as dense time, even impossible.
Coalescing is used, explicitly or implicitly, to consolidate representations of (sets of) time instants associated with the same fact. In the case of interval-based encodings, this leads to coalescing adjoining or overlapping intervals into a single interval. Note that coalescing only changes the concrete representation of a temporal relation, not its meaning (i.e., the abstract temporal relation); hence it has no counterpart in abstract temporal query languages.
Implicit set operations on time values are used in relational operations. For example, conjunction (join) typically uses set intersection to generate a compact representation of the time instants attached to the facts in the result of such an operation.
The need for an explicit use of coalescing often makes the formulation of queries in some concrete SQL-based temporal query languages cumbersome and error-prone.
An orthogonal issue is the difference between explicit and implicit access to temporal values. This distinction also carries over to the concrete temporal languages. Typically, the various temporal extensions of SQL are based on the assumption of an explicit access to temporal values (often employing a built-in valid time attribute ranging over intervals or temporal elements), while many temporal relational algebras have chosen to use the implicit access based on temporally extending standard relational operators such as temporal join or temporal projection.
Compilation and Query Evaluation
Most of the practical temporal data models adopt a common approach to physical representation of temporal databases: with every fact (usually represented as a tuple), a concise encoding of the set of time points at which the fact holds is associated. The encoding is commonly realized by intervals [6, 7] or temporal elements (finite unions of intervals). For such an encoding it has been shown that both First-Order Temporal Logic  and Temporal Relational Calculus  queries can be compiled to first-order queries over a natural relational representation of the interval encoding of the database. Evaluating the resulting queries yields the interval encodings of the answers to the original queries, as if the queries were directly evaluated on the point-stamped temporal database. Similar results can be obtained for more complex encodings, e.g., periodic sets, and for abstract temporal query languages that adopt the duplicate semantics matching the SQL standard, such as SQL/TP .
Temporal query languages are primarily used for querying temporal databases. However, because of their generality they can be applied in other contexts as well, e.g., as an underlying conceptual foundation for querying sequences and data streams .
- 2.Chomicki J. Temporal query languages: a survey. In: Proceedings of 1st International Conference on Temporal Logic; 1994. p. 506–34.Google Scholar
- 3.Chomicki J, Toman D. Temporal databases. In: Fischer M, Gabbay D, Villa L, editors. Handbook of temporal reasoning in artificial intelligence. Elsevier Foundations of Artificial Intelligence; 2005. p. 429–67.Google Scholar
- 5.Law Y-N, Wang H, Zaniolo C. Query languages and data models for database sequences and data streams. In: Proceedings of 30th International Conference on Very Large Data Bases; 2004. p. 492–503.Google Scholar
- 6.Navathe SB, Ahmed R. Temporal extensions to the relational model and SQL. In: Tansel A, Clifford J, Gadia S, Jajodia S, Segev A, Snodgrass RT, editors. Temporal databases: theory, design, and implementation. Menlo Park: Benjamin/Cummings; 1993. p. 92–109.Google Scholar
- 8.Toman D. Point vs. interval-based query languages for temporal databases. In: Proceedings of 15th ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems; 1996. p. 58–67.Google Scholar
- 9.Toman D. Point-based temporal extensions of SQL. In: Proceedings of 5th International Conference on Deductive and Object-Oriented Databases; 1997. p. 103–21.Google Scholar