﻿SEHANTICS OF TEHPORAL QUERIES AND TEHPORAL DATA 
Carole O. Hafner 
College of Computer Science 
Northeastern University 
Boston, MA 02115 
Abstract 
This paper analyzes the requirements for adding a 
temporal reasoning component to a natural language 
database query system, and proposes a computational 
model that satisfies those requirements. A prelim- 
Inary implementation in Prolog is used to generate 
examples of the model's capabi Iltles. 
I. Introduction 
A major area of weakness in natural language (NL) 
interfaces is the lack of ability to understar~ and 
answer queries involving time. Although there is 
growing recognition of the importance of temporal 
semantics among database theoretlcians (see, for 
example, Codd \[6J, Anderson \[2L Clifford and Warren 
\[41, Snodgrass \[ i 5\]), existing database management 
systems offer little or no support for the 
manipulation of tlme data. Furthermore (as we will 
see In the next Section), there is no consensus among 
researchers about how such capabilities should work. 
Thus, the developer of a NL interface who wants to 
support time-related queries cannot look to an 
underlying ~ for he!p. 
Currently available NL systems such as Intellect (SJ 
have not attempted to sugoort temporal queries, 
except in a trivial sense. In Intellect, users can ask 
to retrieve date attributes (e.o~, "When was Smith 
hired'?') or enter restrictions based on the value of a 
date attribute (e.g., "List the employees hired after 
Jan I, 1984"); but more complex questions, such as 
"How long has it been since Smith received a raise~ 
or "What projects did Jones work on last January?', 
are not 'Jnderstoo~ This Is a serious PraCtical 
limitation, since the intended users of NL systems are 
executives and other professionals who will require 
more sopffistlcated temporal capal)illtles. 
This report describes a model of temporal 
reasoning that is designed to be tncoroorated Into a 
NL query system. We assume that a syntactic 
component could be developed to translate explicit 
temporal references in English (e.g., "two years ago') 
into logical representations, and restrict our 
attention to the conceptual framework (including both 
knowledge structures and rules of inference) 
underlying such representations. Section 2 analyzes 
the requirements that the temporal model must 
satisfy: first describing some of the issues that arise 
tn trying to model time in a computer, then defining 
four basic semantic relattonsl~ips that are expressed 
by time attributes in databases, and finally analyzing 
the capat)tlites required to Interpret a variety of 
temporal queries. Based on this analysis, a 
computational model is described that satisfies many 
of the requirements for understanding and answering 
time-related database queries, and examples are 
presented that t l lustrate the model's calDabiltties. 
2. Hodellng Temporal Knowledge 
Hodellng time, dasoite its olovlous importance, has 
proved an elusive goal for artificial Intelligence (AI). 
One of the first formal proposals for representing 
time-dependent knowledge in AI systems was the 
"situation calculus" described by I'lcCarthy a~l Hayes 
\[I I\]. That proposal created a paradigm for temporal 
reasoning based on the notion of an infinite collection 
of states, each reoresenting a single instant of time. 
Prepositions are defined as being either true or false 
in a particular state, and predicates such as "before 
(sl, s2)" can be defined to order the states 
temporally. This approach was used by Bruce \[3\] in 
modeling the meaning of tensed verb phrases In 
English, and It has been refined and extended by 
McDermott ( ! 3~ 
5tare space models describe time as being similar 
to the real number line, with branches for alternative 
pasts and hypothetical futures. Although this 
approach is intuitively appealing, there are many 
unsolved problems from both the logical and the 
linguistic points of view. A few of the current 
problems in temporal semantics are very briefly 
described below: 
a. Non-monotonic reasontno~ In a system for 
automated reasoning, conclusions are drawn on the 
basis of current facts. When a fact that was true 
becomes false at a later time, conclusions that were 
based on that fact may (or may not) have to be 
revised. This problem, which is viewed by many as 
"the" current issue in common sense reasoning, has 
been studied extensively by Doyle \[7\], Moore \[I 4\], and 
McDermott \[I 3\], and continues to occupy the attention 
of John McCarthy \[ ! 2~ 
b. Representation of Intervals and processes. 
Another problem for temporal logic is the 
representation of events that occur over intervals of 
time. Allen \[I\] points out that even events which 
seem to be instantaneous, such as a light coming on, 
cause problems for the state space model, since at 
the instant that this event occurs it is impossible to 
say that either "the light is on" or "the light is not on" 
is true. As a result, Allen chooses a representation of 
time that uses intervals as the primitive objects 
instead of instantaneous states. 
c. Temporal distance. Neither the state space model 
nor the interval model offers a convincing notion of 
temporal distance. Yet, the ability of a system to 
understand how long an event took or how much time 
separated two events Is an Integral part of temporal 
reasonir~ 
d. Periodicity of time. There are many periodic events 
that affect the way we think and talk about time - 
such as day and night, the days of the wee~, etc. 
McDermott \[13\] shows how his tempo~ al logic can 
describe periodic events, and Anderson \[2\] includes a 
representation of periodic data in her model of 
temporal database semantics. However, reasoning 
about periodic time structures is sttli z relatively 
unexplored issue. 
e. Vagueness ana uncertainty. People are able to 
reason about events whose temporal par-~neters are 
not known exactly - in fact, almost all temporal 
descriptions incorporate some vagueness. The most 
direct treatment of this phenomenon was a system by 
Kahn and Gorry \[9\], which attached a "fuzz factor" to 
temporal descriptions. However, Kahn and Gorry 
recognized that this approach was very crude and 
more sophisticated techniques were needed. 
f. Complex event structures. The situation calculus is 
not easily adapted to descriptions of complex acts 
such as running as race, simultaneous events such as 
hiding something from someone by standing in front 
of it while that person is in the room (an example 
dis- cussed by Allen \[I \]), or "non-events" such as 
waitin~ 
Metaphorical time descriptions. In naturally 
occuring NL dialogues, time descriptions are 
frequently metaphoric. Lakoff and Johnson \[I O\] have 
shown that at least three metaphors are used to 
describe time tn English: time as a path, time as a 
resource, and time as a moving object. AI models 
have yet to adequately deal with any of these 
metaphors. 
Considering all of these complex issues (and there 
are others not mentioned here), It is not surprising 
that general temporal capabilities are not found in 
applied AI systems. However, tn the domain of NL 
query systems, it may be possible to ignore many of 
these problems and still produce a useful system. The 
reason for this is, in the world models of computer 
dataOases, most of the complexity and ambiguity has 
already been "modeled out'. Furthermore, current NL 
interfaces only work well on a supclass of databases: 
those that Conform to a simple entity-attribute-rela- 
tionship model of reality. 
The research described in this paper has focused on 
the design of a temporal component for a NL database 
QueP), system This has led to a model of time that 
corresponds to the structure of time attributes in 
databases: i.e., a domain of discrete units 
representing intervals of equal length. (Whether these 
units are SOCOrK2S, minutes, days, or years may vary 
from one aatabase to another.) The description of the 
model presented In Section 3 assumes that the basic 
tempora! units are days, In order to make the model 
more intuitively meaningful; however, the model can 
be easily adaoted to time units of other sizes. 
• 2 
2.1 Analysis of Time Attributes in Databases 
The primary role of time Information In databases 
is to record the fact that a specific event occurred at 
a specific time. (It is also possible to represent 
times in the future, when an event is scheduled to 
occur, e.~, the date when a lease Is due to expire.) 
Having said this, there are still different ways in 
which time attributes may be semantically related to 
the entities in the database, and these require 
different Inferences to be made in translating NL 
queries into the framework of the data model. The 
following categories of time attributes are 
frequently observed in "real world" databases: 
I. Time attributes describing individuals 
2. Time of a "transaction" 
3. Time when an attribute or relationship changed 
4. The time of transition from one stage of a 
process to the next. 
The first two categories are quite straightforward. 
Time attributes of individuals appear In "entity" 
relations, as shown In Figure la; they describe the 
occurrence of a significant, event for each Individual, 
such as an employee's date of birth or the date when 
the employee was hired. This type of temporal 
attribute has a unique (and usually unchanging) value 
for each Individual. 
The term "transaction" is used here to describe an 
event (usually involving several types of entities) 
that does not change the status of the participants, 
other than the fact that they participated In the 
event. For example, the date of each treatment (an 
X-ray, a therapy session, or a surgical procedure) 
given to a patient by a doctor would be recorded in a 
medical records database, as shown in Figure lb. 
Attributes In the third category record the time at 
which some other attribute or relationship changed. 
Databases containing this type of information are 
called "historical databases', in contrast to the more 
traditional "operational" databases, which only record 
a "snapshot" of the current state of the world. The 
salary history and student records databases shown in 
l a. Time Attributes Decribmg Individuals 
EmploLIee Database 
EmD_ID I Name I Address 
lb. Time of a Transaction 
Medical Records Database 
Patient IOoctor IProcedure 
I Birth_Date IHire-Date 
ic Time Whan an Attribute or Relationship Changed 
Salary History Database 
Emp_lO I Salar9 IDate 
Student Records Database 
Date 
Student-IO I Subject IOegree I Date 
I d. Time of a Process Transition 
Publication Database 
ISub-Oate \[Disp-Date JRev-Date \[Pub-Date 
Examples of Temporal Attributes 
Doc_lO J Author 
Figure 1. 
3 
I. Which doctors performed operations on June 15, 19837 
2. How many people received PhD's in Math last month? 
3. What percent of the employees got raises in the 4th quarter of 19847 
4. Did any authors have more than one paper waiting for publication on Jan I? 
5 How much was Jones making in September of 19847 
6. How long has Green worked here? 
7. What was the average review time for papers suDmitted in t go3? 
8. Which patients received operations on each dog last week? 
9. How many Ph. D's were granted to women during each of the pest 10 years? 
Figure 2. 
Figure Ic are examples of this type of temporal datZL 
Within this category, we must recognize a further 
distinction between exclusive attributes such as 
salary and qon-exclustve attributes such as degree. 
When a new salary is entered for an employee, the 
previous salary is no longer valid; but when a new 
degree is entered, it Is added to the individual's 
previous degrees. 
Examples of Temporal Queries 
The last category of temporal data is used to 
record fixed sequences of events that occur in various 
actiivies. For example, the publication database of 
Figure Id records the life-cycle stages of papers 
submitted to a scientific journal: the date the paper 
was received, the date it was accepted (or rejected), 
the date the revised version was received, and the 
date that is it scheduled to be published. We can view 
this sequence as a process with several stages 
('under review', "being revised', "awaiting 
publication'), where each temporal attribute 
represents the time of transition from one stage to 
the next. 
2.2. Analysts of Tempera! Queries 
particular interval of time. Current database systems 
already support time restrictions, such as Query I, 
that use simple, absolute time references. Queries 
such as (2), which use relative time references, and 
(3) which refer to intervals not directly represented 
in the database, require a more elaCx~ate model of 
time structures than current systems provide. The 
time domain model described In Section 3. I can 
support queries of this type. 
The second type of query asks about the 
state-of-the-world on a given date (Query 4) or 
during an interval of time (Query 5). Understanding 
and answering these queries requires rules for 
deducing the situation at a given time, as a result of 
the occurrence (or non-occun'ence) of events before 
that time. For example, Query 5 asks about Jones' 
salary in September of Ig78; however, there may not 
be an entry for Jones in the salary history file during 
that period. The system must know that the correct 
salary can be retrieved from the most recent salary 
change entered for Jones before that date. 5action 
3.2 describes an event model that can represent this 
type of know ledge. 
This section considers four types of queries 
Involving temporal data, and briefly outlines the 
capaDilites that a temporal knowledge model must 
have in order to understand and answer queries of 
ead~ type. 
Oueries I-3 in Figure 2 are examples of time 
restriction aueries, which retrieve data about 
individuals or events whose dates fall into a 
Another type of query asks about the lenoth of time 
that a situation has existed (Query 6), or about the 
duration of one stage of a process (Ouer 7 7). These 
queries require functions to compute and compare 
lengths of time, and rules for deducing the starting 
and King times of states-of-the-world based on the 
events that trigger them. Section 3.3 shows how the 
proposed temporal model handles this type of query. 
4 
The last type of query Is the oertodlc query, which 
asks for objects to be grouped according to one or 
more attributes. High-level data languages and 
current NL interfaces are generally able to handle this 
type of request when it refers directly to the value of 
an attribute (e.~, Query 8), but not when it requires 
information to be grouped by time period, as in Query 
9. To anwer periodic queries requires a formal 
representation for descriptions such as "each of the 
past 5 years'; the "periodic descriptors" defined in 
Section 3. I satisfy this requirement. 
3. A Temporal Reasoning Model for Databases 
In this section, a temporal reasoning model is 
proposed that can interpret the types of queries 
described in Section 2.2. The model, which Is 
expressed as a collection of predicates and rules 
written in Prolng \[S\], consists of the following 
components: 
I. A time domain model for representing units (days), 
intervals, lengths of time, calendar structures, and 
a variety of relative time descriptions. 
. An event model for representing and reasoning 
about the temporal relationships among events, 
situations, and processes in the application domairL 
3. I Time Domain Model 
The basic structures of the time domain model are 
days, intervals. Calendars, and oeriodlc descriotors. 
The days (D, OI, D2.. ) form a totally ordered set, 
with a "distance" function representing the number of 
days between two days. The distance function 
satisfies the laws of addition, i.e.: 
I) dtstance(DI,D2)= 0 <--> Oi-D 
2) distance ( DI, D2 ) - - distance ( D2, DI) 
3) distance ( DI, D2 ) + distance ( D2, D3 ) - 
distance ( D I, 03) 
Intervals (I, I1, 12..) are ordered pairs of days 
\[Ds, De\] such that distance (Ds, De) >= O. If an 
interval I - \[Ds, De\] then: 
4) start(I) • Ds 
5) end( I ) = De 
6) length ( I ) = distance ( start (I), end ( I )) + I 
7) during ( D, I) = "true" <--> 
distance (start(I), D ) >= 0 and 
distance ( D, end(I)) >= 0 
Other temporal relations, such as "before (D I, D2)', 
"after(D I, D2)', and interval relations such as those 
described by Allen \[ i \], can be defined using the 
"distance" function in an equally straightforward 
manner. Also included in the model Is a function 
"today" of no arguments whose value is always the 
current day. 
Formulas (1-7) are repeated below in Prolog notattor~ 
i ) dtstance(D I ,D2,0) :- O I = O2. 
2) distance(D1, D2, Y):- distance(D2, D1, X), Y = -X. 
3) distance(D i, D3, Z) :- distance(D I, D2, X), 
distance(D2, D3, Y), Z=X+Y. 
4) start(I,Ds). 
5) end(I,De). 
6) length(I, Y) :- distance(start(I), end(I), X), 
Y = X+l. 
7) during (D, I) :- distance(start(I), D , X), X >- 0, 
distance (D, end(I), Y), Y >- O. 
Examples of some natural language concepts: 
n_dayq ~jo (N, D) :- today(DT), distance(D, DT, N). 
n_days_from_now (N, O) :- 
today(DT), distance (DT, D, N). 
the..past..n_days (N, I) :- 
today(DT), end(I,DT), length( I ,N). 
the._nexL.l~days (N, I) :- 
teday(DT), start(I,DT), length(I,N). 
the_day_before_yesterday (D) :- n_days_ago(2, D). 
A calendar is a structure for representing 
sequences of intervals, such as weeks, months, and 
years. We will consider only "complete" calendars, 
which cover all the days, although It would be useful 
to define Incomplete calendars to represent concepts 
such as "work weeks" which exclude some days. A 
calendar (CAt) is a totally ordered set of Interval 
descriptors called "calendar elements" (L'~, CEI, CE2. 
.). The following predicates are defined for calen~. 
dtstcal(CAL, CEI, CE2, N). This Is like the distance 
function for days. It is true if CE2 is N calendar 
elements after CE I. For example:, distcal(year, 
1983, 1985, 2) is true. 
5 
getcal(CAL, CE, I). This predicate Is true if I Is the 
interval represented by the calendar element CE. 
For example: getcal(year, 1983, \[ janO I 1983, 
dec311983\] ) is true. 
incal(CAL, D, CE, N). This predicate Is true If D is the 
Nth day of calendar element CE. It is used to map a 
day into the calendar element to which It belongs 
For example:, incal(month, jan 121983, \[jan, 1983\], 
t2\] ) ts true. 
Calendars satisfy the well-formedness rules that 
we would expect; for example, for each day D and each 
calendar CAL, there is at most one (for complete 
calendars, exactly one) calendar element CE and 
positive integer N such that incal (CAL, D, CE, N) is 
true. Also, if CE i is before CE2, then each day in CE I 
is before each day in CE2. And, for complete 
calendars, if CE! immediately precedes CE2, then the 
last day of CEI immediately precedes the first day of 
CE2. 
Although the representation of calendar elements 
Is arbitrary, we have chosen conventions that are both 
meaningful to the programmer and useful to the 
implementation. The simplest calendars are those 
such as "year', containing named elements that occur 
only once. Years are simply represented as atoms 
cor~'espondlng to their names. Cyclic calendars are 
those that cycle within another calendar, such as the 
calendars for "month" and "quarter'. The elements of 
these calendars are represented as 2-tuoles, for 
example: distcal(month, \[dec, 1983\], \[jan, ! 984\], ! ) is 
true. The calendar for weeks presents the most 
difficult problem for the time domain model, since 
weeks are not usually identified by name. We have 
defined the week calendar so that all weeks begin on 
Sunday and end on Saturday, with each element of the 
calendar equal to the interval it rel:cesents. While 
this Is not an entirely satisfactory solution, it allows 
a number of useful "weekly" computations. 
Hore examples of natural language concel)t~ 
from_ce 1_to_ce2(CAL, CE I, CE2, I) :- 
/e from January, I q~3 to duly, 1985 e/ 
getcai(CAL, CE 1, I I ), getcal(CAL, CE2, 12), 
start(I I, S), end (12, E) , start(I, 5), er~KI, E). 
n_cai_elts_ago(CAL, N, D) :- 
/e three weeks ago o/ 
today(OT), lncal(CAL, DT, CEi, X), 
dlstcal(CAL, CE2, CE I, N), Incal(CAL, D, CE2, X). 
The last structure in the time domain model is the 
periodic de-JCrtptor (PO), ~ for PelX%--Jenting 
expressions such as "each of the past 5 years" or 
"each month in 1983". Periodic descriptors ate 
3-tupies consisting of a calendar (to define the size 
of each period), a starting element from that calendar 
(to define the first period), and either an ending 
element from that calendar (to define the last period) 
or an integer (to define how many periods are to be 
computed). Periodic descriptors can run either 
forward or backward in time, as shown by the 
following example: 
each_of_the_gas~cal_elts(CAL,N, PO):- 
PO - \[CAL, CEP, MI, today(DT), incal(CAL, DT, CET, _), 
dtstcal(CAL, CEP, CET, I ), H Is -N. 
To Interpret a query containing a periodic descrip- 
tor, the NL interface must first expand the structure 
Into a list of Intervals (this must wait until 
execution time in order to ensure the right value for 
"today') and then perform an Iteratlve execution of 
the query, restricting it In turn to each interval in 
the list. 
3.2. Event Model 
In the event model, each type of event is 
re~'esented by a unique predicate, as are the 
situations and IX'ocess stages that are signified by 
events. For example, the event of a person receiving a 
degree is represented by: awarded(Person, Subject, 
Degree). The situation of having the degree is 
represented by: holds(Person, Subject, Degree). While 
the "awarOed" medicate is true only on the date the 
degree was received, the "holds" predicate is true on 
that date and all future dates. Below we define a 
straightforward al~:>roach to rewesentlng this type of 
know ledge. 
Five basic tempor'al predicates are Introduced to 
relate events and situations of the al~ltcation model 
to elements of the Lime domain model. 
6 
timeof(E, D) - succeeds whenever an event that 
matches E occcurs In the database with a tlme that 
matches D. This is the basic assertion that relates 
events to their times of occurrence. 
nextof(E, T, D) - asserts that D is the next time of 
occurrence of event E after time T. 
nextof(E, T, D):- tlmeof(E, D) , before(T, D), 
not (tlmeof (E, X), before (T, X), before (X, O). 
startof(5, D) - defines the tlme when a situation or 
process stage begins to be true, based on the 
occurrence of the event that triggers IL Rules of 
this sort are part of the knowledge base of each 
application, for example: 
startof (holds(Person, Subject, Degree), Date) :- 
timeof (awarded( Person, Subject, Degree), Date). 
endof(5, D) - defines the time when a situation ceases 
to be true. For an exclusive attribute such as 
salary(jones, 40000), the "end-of" a situation is the 
"next-of" the same kind of event that triggered the 
situation (i.e., when Jones gets a new salary then 
salary(jones,40000) is no longer true). For other 
kinds of situations, a specific "termination" is 
required to signify the ending; e.g., a publication 
ceases to be "under review" when It Is accepted. 
trueon(S, D) - succeeds if situation S is true at time 
D. Given the predicates described above, the 
definition of trueon might be:. 
trueon(S, D):- startof (S, A), not (after(A,D)), 
not (endof(5, B), before (B, D)). 
This rule asserts that situation S is true at time 0 
if S began at a time before (or equal to) O, and dill 
not end at a time before D. 
3.3. An Example Query 
We can now bring the two parts of the model 
together to describe how a temporal query is 
represented anti interpreted using the predicates and 
rules defined above. We will consider the following 
query, addressed to the salary histor'/database:. 
Which employees are making at least twice as much 
now as they made 5 years ago. 
For experimental purposes, we have defined our 
database as a collection of Prolog facts, as proposed 
by Warren\[ 16\] ; thus, the database can be queried 
directly in Prolog. We have also defined the "days', 
which are the primitive elements of the time domain 
model, to have names such as janO11982 or 
jul041776; these names appear in the database as the 
values of temporal attributes, as shown below: 
salhistory(jones, 30000, janO I 1983). 
salhistory(smith, 42000, jan l5 i 983). 
Each of the event-model predicates described in the 
previous section has also been created, with 
"nowsalary(EHPlD, 5At)" substituted for E and 
"makes(EHPlD, SAt.)" substituted for 5. For example.- 
timeof(newsalary(EHPlO, SAt), D):- 
salhistory(EHPlD, $AL, D). 
startof(makes(EHPlD, SAL), D):- 
timeof(newsalary(EMPlO, SAt), O). 
endof(makes(EHPlO, 5AL), D2):- 
timeof(newsaiary(EHPl D,SAL), D), 
nextof(newsalary(EHPlO,SAL2), D, O2), 
SAt --- SAt2 
trueon(malces(EHPlD, 5At), D):- 
startof(makes(EMPlD,SAL), D. 
trueon(makes(EHPlD, S/d.), D):- 
stattol'(mdcedBMPlD, SAL), DI ), befote(DI,D), 
(e~do((makes(EMPlD, SAL), I)2), before(D2, D)). 
We can now express the sample query in Proiog: 
resuit(EHPlO, 5AL, OLDSAL):- 
teday(DT), 
trueon(makes(EHPlD, $AL), OT), 
n_caL.elts_ago(year, 5, DFYA), 
trueordmakes(EHPlO, OLDSAL), DYFA), 
SAL >= 2 * OLDSAL. 
This Prolog rule would be the desired output of the 
linguistic comoonent of a NL query system. 
ParalXcased in English, it says: retrieve all triples of 
employee td, current salary, and old salary, such that 
the employee makes the current salary today, the 
employee made the old salary five years ago, and the 
current ~alary is greater than or equal to two times 
the old salary. If we exoand all of the Prolog rules 
that would be invoked in answering this query, leaving 
only database access commands, arithmetic tests, and 
computations of the "distance" function, the complete 
translation would be:. 
result(EMPlD, SAt, OLDSAL) :- 
today(DT), 
saihistory(EMPlO, SAt, O), 
distance(D, DT, X I ), 
Xl >=0, 
not(salhistory (EHPlD, SAL2, D2), 
distance(D, D2, X2), 
X2>O, 
distance (D2, DT, X3), 
X3>=O, 
S~J. - SAL2), 
lncal(year, DT, YR1, Y), 
distcal (year, YR1, YPfA, -5), 
incal(year, DFYA, YFYA, Y), 
salhlstory (EMPlD, O(.DS~., D3), 
distance (D3, DYFA, X4), 
X4>= O, 
not(salhistory(EMPlD, OLDSAL2, D4), 
distance(OZ, D4, X5), 
X4> O, 
distance(D4, DYFA, XS), 
X5 >- O, 
OLDSAL I ",= OLDSAL2). 
4. Conclusions 
This paper has proposed a temporal reasoning model 
based on the use of time attributes in databases, and 
the types of queries that we would expect in 
"real-world" applications. The model includes 
constructs for representing events, situations, and 
processes that are similar to those found in other 
temporal reasoning models. It also addresses some 
!ssues of particular importance for NL query systems, 
which are not addressed by other recent work ;n 
temporal reasoning, includir~. 
I. Representing the time between two polnts, and the 
lengths of intervals. 
2. Representing weeks, months, years, and other 
stendm-d calendee structur¢-~. 
3. ~epresenting information relative to "today", "this 
month', etc. 
4. Representing periodic time descriptions. 
The use of discrete, calendar-like structures as a 
basis for representing tim.e in a computer is a 
simplification that is compatible with the discrete 
representation of information in databases. 
Hopefully, this simplification will make IL easter to 
program the model and to integrate it Into a 
state-of-the-art NL quer~ system. 

References 

1. Alien, J. F., "Towards a General Theory of Action 
and Time. Artificial Intelllaence. Voi. 23, No. 2 
(1984) 123-154. 

2. Anderson, T. L, "Modeling Time at the Conceptual 
Level." In P. Scheuermann, ed., II~orovino Oatabase 
Usability and ResPonsiveness. pp 273-297. 
Jerusalem: Academic Press, 1982. 

3. Bruce, B., "A Model for Temporal Reference and its 
Application in a Question Answering System." 
Artificial Intellioence. Vol 3, No. I (1972), 1-25. 

4. Clifford, J. and D. S. Warren, "Formal Semantics for 
Time in Databases." A(:M TOOS. Vol. 8, No. 2 (1983) 
214-254. 

5. Clocksin, W.F. and C. 5. Melltsh, Proorammino in 
proloo. Berli~ Springer-Verlag, 1981. 

6. Codd, E. F., "Extending the Database Relational Model 
to Capture More Meanino~" Ai~l TOO5. Vol. 4, No. 4 
(1979) 397-434. 

7. Doyle, J., "A Truth Maintenance System." Artificial 
I ntelltoence. Vol. 12, No. 3 (1979), 231-272. 

8. INTELLECT Reference Manual, INTELLECT LEX Utility 
Reference, Program Offerings LY20-9083-0 and 
LY20-9082-0, IBM Corp., 1983. 

9. Ka~n, K. and G. A. Gorry, "Mechanizing Temporal 
Knowledge." ~Jflciai Intelligence. Vol 9 (1977), 
87-108. 

I0. Lakoff, G., andM. Johnson, Metaohors We Live BY. 
The University of Chicago Press, Chicago ILL (1980). 

11. McCarthy, J. and P. J. Hayes, "Some Philosophical 
ProOlems from the Standpoint of Artificial 
Intelligence." In B. Mettzer and D. Mtchle, eds., 
Machine Intellloence 4. American Elsevier, New York 
(1969). 

12. McCarthy, J., "'#hat is Common Sense?" 
Presidential Address at the National Conference on 
Artificial Intelligence (AAAI-84), Austin, TX (1984). 

13. McDermott, D., "A Temporal Logic for Reasoning 
About Processes and Plans." Coonittve Science. Vol. 
6 (1982) 101-155. 

14. Moore, R. C., "Semantical Considerations on 
Nonmonotonic Logic." Artificial Intelllaence. Vol. 
25, No. 1 ( 1 983), 75-94. 

15. 5nodgrass, R., "The Temporal Query Language 
TOuel." In Proc. 3rd ACM SIGPIOD Svmo. on princtoles 
qf Database Systems. Waterloo, ONT (1984). 

16. Warren, D. I-L O., "Efficient Processing of 
Interactive Relational Database Queries Expressed 
in Logic" In proc 7th Conf. on Very Laroe 
Databases. pp. 272-281. IEEE Computer Society 
(1981). 