GUMS 1 : A General User Modeling System 
Tim Finin 
Computer and Information Science 
University of Pennsylvania 
Philadelphia, PA 
David Orager 
Adty Corporation 
Concord, MA 
Abstract 
This paper describes a general architecture of a domain independent 
system for building and maintaining ling term models of individual 
users..The user modeling system is intended Io provide a well 
defined set of services for an application system which is interacting 
with various users and has a need to build and maintain models of 
them. As the application system interacts with a user, it can acquire 
knowledge of him and pass that knowledge on 1o the user model 
maintenance system for incorporation. We describe a prototype 
general user modeling system (hereafter called GUMSI) which we 
have implemented in Prolog. This system satisfies some of'the " 
desirable characteristics we discuss. 
Inlroduction - The Need for User Modeling 
Systems which attempt to interact with people in an intelligent and 
cooperative manner need to know many things about the individuals 
with whom they are interacting. Such knowledge can be of several 
dilferent varieties and can be represented and used in a number of 
different ways. Taken collectively, the information that a.system has 
of its users is typically refered to as its user model. This is so even 
when it is distributed through out many components of the system. 
Examples that we have been involved with include systems which 
attempt to provide help and advice \[4, 5, 15\], tutorial systems \[14\], 
and natural language interlaces \[16\]. Each el these systems has a 
need to represent information about individual users. Most el the 
information is acquired incrementaly through direct observation 
and/or interaction. These systems also needed to infer additional 
facts about their users based on the directly acquired informalion. 
For example, the WIZARD help system \[4, 15\] had to represent 
which VMS operating system objects (e.g. commands, command 
qualifiers, concepts, etc) a user was familiar with and to infer which 
other objects he was likely to be familiar with. 
We are evolving the e design of a general user model maintenance 
system which would support the modeling needs of the projects 
mentioned above. The set of services which we envision the model 
maintenance system pedorming includes: 
• maintaining a data base of observed facts about the 
user. 
• infering additional true facts about the user based on the 
observed facts. 
• infering additional facts which are likely to be true based 
on default facts and default roles. 
• informing the application system when certain facts can 
be infered to be true or assumed true. 
• maintaining the consistency of the model by retracting 
default information when it is not consistent with the 
observed facts. 
providing a mechanism for building hierarchies of 
stereotypes which can form initial, partial user models. 
• recognizing when a set of observed lacts about a user is 
no longer consistent with a given stereotype and 
suggesting alternative stereotypes which are consistent. 
This paper describes a general amhitectura for a domain 
independent system for building and maintaining long term models of 
individual users. The user mocleling system is intended to provide a 
well delined set of services for an app/ication system which is 
interacting with various users and has a need to build and maintain 
models of Ihenr~ As Ihe application system interacts with a user, it 
can acquire knowledge of him and pass that knowledge on to the 
user model maintenance system for incorporation. We describe a 
prototype genera/user modeling system (hereafter called GUMS1) 
which we have implemented in Prelog. This system satisfies some 
el lhe desirable characteristics we discuss. 
What is a User Model? 
The concept of encorporating user models into interactive systems 
has become common, but what has been meant by a user model 
has varied and is not always clear. In trying to specify what is being 
refered to as a user model, one has to answer a number of 
questions: who is being modeled; what aspects of the user are being 
modeled; how is the model to be in'rtially acquired; how will it be 
maintained; and how will it be used. In this section we will attempt to 
characterize our own approach by answering these questions. 
Who is being modeled? 
The primary distinctions here are whether one is modeling individual 
users or a class of users and whether one is attempting to construct 
a short or long term model. We are interested in the aquisition and 
use of lonq ter m models of individual users. We want to represent 
the knowledge and beliefs of Individuals end to do so In a way that 
results in a persistent record which can grow and change as 
neccessary. 
It will be neccessary, of course,to represent generic facts which are 
true of large classes (even all) of users. In particular, such facts may 
include inference rules which relate a person's belief, knowledge or 
understanding of one thing to his belief, knowledge and 
understanding of others. For example In the context of a timeshared 
computer system we may want to include a rule like: 
ff a user U believes that machine M is running, 
then U will believe that it is possible for him to log 
onto M. 
It is just this sort of rule which is required in order to support the 
kinds el cooperative interactions studied in \[6\] and \[7\], such as the 
following: 
224 
User: Xs UPZI~-LXNC up? 
System: Ces, but. you aen't 1o9' on now. 
P~eventatlve maintenance is being 
done until ll:OOam. 
What is to be modeled? 
Our current work is focused on building a general purpose, domain 
independent model maintenance system. Exactly whet information 
is to be modeled is up to the application. For example, a natural 
language system may need to know what language terms a user is 
likely to be familiar with \[16\], a CAI system for second language 
teaming may need to model a user's knowledge of grammatical mias 
\[14\], an intelligent database query system may want to model which 
fields ot a data base reialion a user is Interested in \[10\], and an 
expert system may need to model a user's domain goals \[11).. 
How is the model to be aquired and maintained? 
We are exploring a system in which an initial model of the user will 
be selected from a set of stereotypical user models \[13\]. Selecting 
the most appropriate stereotype from the set can be accomplished 
by a number of techniques, from letting the user select one to 
surveying the user and having an expert system select one. Once 
an initial model has been selected, it will be updated and maintained 
as direct knowledge about the user Is aquired from the interaction. 
Since the use of stereotypical user models is a kind of default 
reason/ng\[12\], we will use truth maintenance techniques\[9) for 
maintaining a consistent model. 
In padicular, if we learn something which contradicts a tact in the our 
current model of the user than we need to update the model. 
Updating the model may lead to an Inconsistency which must be 
squared away. If the mode! can he made consistent by changing any 
of the default facts In the model, then this should be done. If there is 
a choice of which defaults to alter, then a mechanism must be 
provided to do this (e.g. through further dialogue with.the user). If 
there are no defaults which can be altered to make the model 
consistent then the stereotype must be abandoned and a new one 
sought. 
How Is the model to be used? 
The model can be accessed in two primary ways: facts can be 
added, deleted or updated from the model and facts can be looked 
up or inlerad. A forward chaining component together with a truth 
maintenance system can be used to update the default assumptions 
and keep the model consistent. 
Architectures for User Modeling Systems 
Our goal Is to provide a general user modeling utility organized along 
the lines shown in figures 1 and 2. The user modeling system 
provides a service to an application program which interacts directly 
with a. user. This application program gathers Information about the 
user through this interaction and chosas to store some of this 
information in the user model. Thus, one service the user model 
provides is accepting (and storiogl) new Information about the user. 
This Information may trigger an Inferential process which could have 
a number of outcomes: 
• The user modeling system may detect an Inconsistency 
and so Intorm the applioation. 
• The user model may infer a new fact about the user 
which Idggers a demon causing some action (e.g. 
informing the application). 
G-u,,k~ 
A: an Application 
GUMS: General User Modeling System 
GUMS(A): Modeling System for Application A 
GUMS(A,U): Model lor User U in Application A 
Figure 1: A General Architecture for a User Modeling Utility 
U3 • S1 
$2 S3 $4 A A 1 
$5 $6 U2 $7 $8 I 
U1 
NULL: the Empty Stereotype 
St: Stereotype i 
UI: User I 
Figure 2: A User Modeling System for an Application 
225 
• The user model may need to update soma previously 
Infered default Information about the user 
Another kind of service the user model must provide is answedng 
queries posed by the application. The application may need to look 
up or deduce certain Information about its current user. 
We are currently experimenting with some of these ideas in a system 
called GUMSp This system is implemented In proiog and used a 
simple default logic together with a backward chaining Interpreter 
rather than a truth maintenance system and a forward chaining 
engine. The next section describes GUMS t and its use of default 
logic. 
Default Logic and User Modeling 
A user model is most useful in a situation where the application does 
not have complete Information about the knowledge and beliefs of its 
users. This leaves us with the problem of how to model a user given 
we have only a limited amount ol knowledge about him. Our 
approach involves using several forms of default reasoning 
techniques: stereotypes, explicit default rules, and failure as 
negation. 
We assume that the GUMS 1 system will be used In an application 
which incrementaly gains new knowledge about its users throughout 
the interaction. But the mere ability to gain new knowledge about the 
user is not enough. We can not waif until we have full knowledge 
about a user to reason about him. Fortunately we can very often 
make generalization about users or classes of users. We call a such 
a generalization a stereotype. A slereotype consists of a set of facts 
and rules that are believed to applied to a class of users. Thus a 
stereotype gives us a form of default reasoning. 
Stereotypes can be organized in hierarchies in which one stereotype 
subsumes another if it can be thought to be mare general. A 
stereotype S t is said to be mere general than a stereotype S 2 it 
eveq~,thlng which is true about S t is necoessarily true about S 2. 
Looking at this from another vantage point, a stereotype inherits all 
the facts and rules from every stereotype that it is subsumed by. For 
example, in the context of a programmer's apprentice application, we 
might have stereotypes corresponding to different classes of 
programmer, as is suggested by the the hierarchy In figure 2. 
In general, we will want a stereotype to have any number of 
Immediate ancestors, allowing us to compose a new stereotype out 
of several existing ones. In the cmntext of a programmers 
apprentice, gor example, we may wish to describe a particular user 
as a SymbolicsWizard and a UnixNovice and a ScribeUser. Thus, 
the stereotype system should form a general lattice. Our current 
system constrains the system to a tree. 
Within a stereotype we can have default Information as well. For 
instance, we can be sure that a programmer will know what a file is, 
but we can only guess that a programmer will know what a file 
directoq, is. If we have categorized a given user under the 
programmer stereotype and discover 1 that he is not familiar with the 
concept of a file then we can conctudethat we had improperly chosen 
a stereotype and most choose a new one. But if we got the 
information that he did not know what a file directory was, this would 
not rule out the possibility of him being a programmer° Thus GUMS 1 
1perhaps tlwough direct Interac6on with her 
P EOgEz~wI E 
/\... 
/ 
Progr-~4 -,gWizard ! \ 
/ \ 
LispMachineWizard UnixHacker 
l \ I\ / \ ...... 
Sy~olicsWizard XeroxWi=ard 
Figure 3: A Hierachy of Stereotypes 
allows rules and facts within a stereotype to be either definitely true 
or true by default (i.e. in the absence ol information to the contrary.) 
In GUMS t we use the certain/1 predicate to introduce a definite fact 
or rule and the default/1 predicate to indicate a default fact or rule, 
as in: 
certain(P). 
certain(P il Q). 
a definite fact: P is true. 
a definite rule: P is true if Q is 
definitely true and P is assumed to be 
true if Q is only assumed to be true. 
default(P), a default fact: P is assumed to be true 
unless it is known to be lalse. 
default(P if Q). a default rule: P is assumed to be true 
if Q is true or assumed to be true and 
there is no definite evidence to the 
contrary. 
As an example, consider a situation in which we need to model a 
persons familiarity with cedain terms. This is a common situation in 
systems which need to produce text as explanations or In response 
to queries and in which there is a wide varialion in the users' 
famiflarity with the domain. We might use the following rules 
(a) defauit(understandsTerm(ram)). 
(b) delauif(understandsTerm(rom) 
if understandsTerm(ram)). 
(c) cedain(understandsTerm(pc) 
if u nderetandsTerm(ibmpc)). 
(d) certain(~understandsTerm(cpu)). 
to represent these assertions, all of which are considered as 
pertaining to a particular user with respect to the stereotype 
containing the rules: 
(a) Assume the user understands the term ram unless we 
know othePNise. 
(b) Assume the user understands the term rein if we know 
or believe he understands the term ram unless we 
know otherwise. 
(c) This user understands the term pc if he understands 
the term ibmpc. 
(d) This user does understand the term cpu. 
GUMS I also treats negation as failure in some cases as a default 
rule. In general, logic is interpreted using an open wodd assumption. 
That is, the failure to be able to prove a proposition is not taken as 
evidence that it is not tree. Many logic programming languages, such 
a prolog, encourage the interpretation of unprovability as logical 
negation. Two approaches have been forwarded to justify the 
226 
negation as failure rule. One approach IS the closed world 
assumption \[2\]. In tide case we assume that anything not inferable 
from the database is by necessity laise. One problem with this 
assumption is that this IS a mataisvat assumption and we do not 
know what the equlvatent obJecl level assumptions are. A second 
approach originated by Clark is based upon the conce~ of a 
completed database \[I\]. A completed database is the database 
constmctad by rewdtlng the set of clauses deflnlng each predicate to 
an If and only If dalinltion that Is called the completion of the 
predicate. The purpose of the completed delinition is to Indicate that 
the clauses that define a prodioato define OVOry possible instance of 
that Wedioate. 
Any approach to negation as failure requires that a negated goal be 
ground before execution, (actually a sfightly less restrictive rule could 
agow a partially instanfiated negated goal to run but would produce 
the wrong answer if any vadable was bound.) Thus we must have 
some way of Insuring that every negated literal will be bound. In 
GUMS I we have used a simple vadabla typing scheme to achieve 
this, as will be discussed later. 
We have used a vadant of the completed database approach to 
show that a predicate within the scope of a negation is closed. A 
predicate is dosed if and only if if is defined by an ill statement and 
eveP/other predicate in the definition of this predicate IS closed. We 
allow a metaievel statement completed(P) that IS used to signify that 
by predicate P we really Intend the iff definition associated with 
P. This same technique was used by Kowaiskl\[8\] to indicate 
cernplation. By default we believe competed(P) where not indicated. 
So if P IS not explioltly closed not P IS decided by default. 
Thus In GUMS I we have the abiflty to express that a default should 
be taken from the lack of certain information (i.e. negation as failure) 
as well as from the presence of certain information (i.e. default 
rules). For example, we can have a default cuts for the programmer 
stereotype that can conclude knowledge about linkers from 
knowledge about compilers, as in: 
default (knows (linkers) if knows (compilers)) 
We can also have a rule that will take the lack of knowledge about 
compilers as an indication that the user probably knows about 
interpreters, as in: 
certain (knows (interpreters) 
if - knOWS (compilers)) 
This system also allows explicit negative facts and default facts. 
When negation is proved in reference to a negative fact then 
negation is not censldered a default case. Slmilady negation as 
failure IS not considered a default when the predicate being negated 
IS closed. Such dlstinstions are possPate because the GUMSf 
Interpreter Is based on a four value logic. 
The distinction between truth or falsity by default (i.e. assumption) 
and truth or falsity by logical Implication IS an Impodanf one to this 
system. The central predicate of the system is the two aroumenf 
predicate show which relates a goal G expressed as a literal to a 
truth value. Thus show(GoaI,Val) returns in the vadable Va/the 
current beifef In the literal Goal The variable Valcan be Instantlated 
to true, false, assume(true), or ansume(fatse). The meanings of 
these values are as follows: 
true definitely tree aocording to the current 
database. 
assume(true) true by assumption (i.e. tree by default) 
aseume(fatse) false by assumption 
false ¢lefinltely not INs. 
These values represent truth values for a given user with respect to 
a given stereotype. If the stereotype Is net appropriate, then even 
define values may have to change. 
Having a four value logic allows us to distinguish conclusions made 
from purely iogicat information from those dependent on default 
Information. Four value logic also allows a simple type of 
intmspeclive reasoning that may be useful for modeling the beifels o! 
Ihe user. We currently use a default role to represent an uncertai. 
belief about what the user knows or believes, but we could imagine a 
situation where we would like to model uncertainties that Ihe user 
has in his beliefs or knowledge. One such predicate is an embeded 
show predicate. For example we might have a rule that a user will 
use a operating system command that he believe might erase a file 
only if he is certain that he knows how to 0se that command. This 
might encode as: 
cart ain (okay to use (Co~nand) if 
can erase files (Co--and), 
sh~w tkno~(Command) , true) ) . 
Another pmdioate assumed(PrecO will evaluate the troth of Pred and 
"strengthen" the result. That is 
demo(assumed(P),V) :- 
demo (P, V2), 
strengthen (V2, V) . 
where the strengthen relation maps assumed values into definite 
values (e.g. assume(true) becomes true, assume(false) becomes 
false and true and false remain unchanged). The assumed 
predicate Is used to express a cedain belief from an uncertain 
knowledge or belief. For example we might want to express a role 
that a user will always want to use a screen editor if he believes one 
may be available. 
certain (willUse ( screenEditor ) if 
assumed(available (screenEdltor)) ) . 
The interpreter that GUMSf is .base on is a metalevel interpreter 
wdtten in Prolog. The interpreter must generate and compare many 
possible answers to each subquery, because of the multiple value 
logic and the presence of explicit negative information. Slrono 
answers to a query (i.e. true and false) are sought first, followed by 
weak answers (i.e. assume(true) and assume(faLse)). Because 
strong answers have precedence over weak ones, it is not necessary 
to r4move weak information that contradicts strong information. 
Another feature of this system is that we can specify the types of 
arguments to predicates. This type information can be used to allow 
the system to handle non-ground goals. In our system, a type 
provides a way to enumerate a complete set of possible values 
subsumed by that type. When the top-level show predicate is given 
a partially instantlated goat to solve, it uses the type information to 
generate a stream of consistent fully instantiated goals. These 
ground goals are tried sequentially. 
That goals must be fully intantlated follows from the fact that 
negation as failure is built Into the evaluation algorithm. Complex 
terms wifl be instantiated to every pattern allowed by the datatype 
given the full power of unification. To specify the type information, 
one should specify argument types tot a predicate, subtype 
Information and type instance information. For example, the following 
says that the ¢anProgmm predicate ranges over instances of the 
type person and progmmmlngLanguage, that the type 
functtormlLanguage is a sub-type of programmlngLanguage and 
227 
that the value scheme is an instance of the 
functlonalLanguage: 
declare (eanProgram(person, 
programmingLanguage) ) . 
• subtype (progrJm4ngLanguag~, 
functionalLanguage} . 
inst (functionalLanguage, scheme} . 
type 
Limitations of the Present System 
OUr current system has several limitations. One problem is thai it 
does not extract all of the available information Item a now fact 
leamed of the user. If we assert thai a predicate is closed, we are 
saying that the set o! (cedain) rules for the predicate form a 
detinilion, i.e. a neccessary and sufficient description. In our current 
system, however, the information still only liows direction1 For 
example, suppose that we would like to encode the rule that a user 
knows about YO redirection if and only of they know about files and 
about pipes. Further, let's suppose that the default is that a person 
in this stereotype does not know about files or pipes. This can be 
expresses as: 
certain (knows (io redirection} if 
knows (pipes), 
knows (files}) . 
default (~knows (pipes}) . 
default l-knows (files)) 
closed {knows (io redirection} ) . 
It we learn that a particular user doe_._._..s know about I/0 redirection 
then it should follow that she neocessarily knows about i:3oth files and 
pipes. Adding the assertion 
certain (knows (io redirection) } 
however, will make no additional changes in the data base. The 
values of knows(pipes) and knows(files) will not changel A sample 
run alter this change might be : 
?- show fknows (io redlrection) ,Val) . 
Val = true 
?- show (knows (pipes}, Val) . 
Val = assume(false) 
?- show (knows (files}, Val} . 
Val = assume(false). 
The reason for this problem is that the current interpreter was 
designed to be able to Incorporate new information without actually 
using a full truth maintenance system. Before a fact F with truth 
value V Is to be added to the data base, GUMSf checks to see If an 
inconsistent truth value V'can be derived for F. If one can be, then a 
new stereotype is sought In which the contradiction goes away. New 
knowledge that does not force an obvious inconsistency within the 
database is added as is. Neither redundant information or existing 
default information effect the correctness of the Interpreter. Subtler 
inconsistencies are possible, of course. 
Another limitation of the current system its inefficiency. The use of 
default rules requires us to continue to search for solutions for a goal 
until a strong one is found or all solutions have been checked. These 
two limitations may be addressable by redesigning the system to be 
based on a forward chaining truth maintenance system. The 
question is whether the relative elfioiency of forward chaining will 
offset the relative Inefficiency el truth maintenance, "lT'~e use of an 
assumption based truth maintenance system\[3\] Is another 
alternative that we will Investigate. 
The GUMS 1 Command Language 
Our current experimental implementation provides the following 
commands to the application. 
show(Query,Vat) succeeds with Valas the strongest truth value Ior 
the gaol Query. A Query is a partially or tully instantiated positive or 
negative literal. Val is return and is the value the current belief state• 
I1 Queryis partially instantiated then it will return more answers upon 
backlracking il possible. In general one answer will be provided for 
every legal ground substitution that agrees with current type 
declarations. 
add(Fact,Status) sets belief In Fact to true. It Fact or any legal 
Instance of it contradicts the current belief state then the user model 
adopts successively higher stereotypes in the hieramhy until one is 
found in which all el the added facts are consistent. II no stereotype 
is successful then no stereotype Is used, all answers will be based 
entirely on added facts. Fact must be partially or fully instantiated 
and can be either a positive or negative literal. Status must be 
uninstantiated and will be bound to a message describing the result 
of the addition (e.g. one of several error messages, ok, the name of 
a new stereotype, etc.). 
create_user(UserName,Stereotype,File,Status) stores the current 
user it necessary and creates a new user who then is the current 
user. UserName is instantiated to the desired name. Stereotype is 
the logical name of the stereotype that the system should assume to 
hold. File is the name of the file that information pertaining to the 
user will be stored. Status is instantiated by the system and returns 
error messages. A user must be created in order for the system to he 
able to answer queries. 
store_current(Status) stores the current users information and 
clears the workspace for a new user. Status is instantiated by the 
system on an error. 
restoreuser(User,Status) restores a previous user alter saving the 
current user if necessary. User is the name of the user. Status is 
instantiated by the system to pass error messages. 
done stores the system state of the user modeling system, saving 
the current user if necessary. This command should be the last 
command issued and needs to be issued at the end of every 
session. 
Conclusions 
Many Interactive systems have a strong need to maintain models of 
individual users. We have presented a simple architecture for a 
general user modeling utility which is based on the ideas of a default 
logic. This approach provides a simple system which can maintain a 
database of known information about users as well as use rules and 
facts which am associated with a stereotype which is believed to be 
appropriate for this user. The stereotype can contain definite facts 
and define rules of inference as well as default information and rules. 
The rules can be used to derive new information, both definite and 
assumed, from the currently believed information about the user. 
228 
We believe that this Idnd of system will prove useful to a wide range 
of applications. We have Implemented an initial version in Prolog 
and are planning to use it to support the modeling needs of se~,eral • 
pmjecls. We are also exploring a more powedul approach to user 
modeling based on the notion of a truth maintenance systen~ 
Appendix - The Dame Predicate 
This appendix defines the derno predicate which Implements the 
heart of the GUMS! Interpreter. The rata|ion 
show (Goal, Value) 
holds If the truth value of proposition Goalcan be shown to be Value 
for a particular ground instance of GoaL The show predicate first 
makes sure that Goal Is a ground instance via a call to the blndVars 
predicate and then invokes the meta-evaluator demo. The relation 
dame (Goal, Value, Level) 
requires that Goal be a fully instantiated term and Level be an 
integer that represents the level of recursion within the demo 
predicate. The relation holds if the "strongest" troth value for Goalls 
, Value. 
:- op(gso, fy, °-' ) . z- op(1150, xfy,' If') • 
ahow(P,V) z- b~ndVa~stP), domo(LP,V, 0). 
% truth values 
demotP,P, } :- truthValue(P), ! • 
t reflection... 
demo(demo (P,Vl) ,V, D) :- 
I, nonvar (V1), 
dame (P,VI, D) -> V-true;V-false. 
% disjunction . .. 
demottP;Q},v,n) :- |, 
demo (P,VI, D) , 
demo (Q,V2, D) , 
upperbound (Vl, V2, V) . 
% conjunction ... 
de~t~P,O),V,D) ~- \[, dame (P,V1, D), 
demo (O,V2, D), 
Iowerbound (V1, V2, v) . 
• negatlon ... demot-p,V,D) :- |, 
d~mo (P,VI, D), 
negate (V1,V, P) . 
% assumption ... 
demo(assu~d(P),V,D) :- i, 
dame (P,VI, D), 
st rang|hen iV1, V) . 
% oall darnel with deeper depth and then cut. 
dame (P, V, Depth) :- Deeper Is Depth+l, 
darnel (P, V, Deeper) , 
retra¢tall (tamp ( , Deeper) ) , 
I. 
% definite facts... 
demol(P, true, ) :- certaln(P). 
darnel (P,falseT_) :- certain (~P} . 
• find a definite rule that yields TRUE or FALSE. 
darnel (P,V,D) :- forsome (certaln (P if Q) , (demo (Q,V, D), demoNote (V, D) ) ) . 
darnel (P,V, D) :- 
forlometcerta~n(-P if O), (dame (Q, Vl, D), 
negate (Vl, V, P) 
demo~ote iV, D) ) ) . 
• stop if the bQst so far was ASSUME(TRUE). 
darnel (P,assume (true}, D) :- retra¢t (tamp (assume (true), D) ) . 
% default positive faots. 
demotP, assumettrue) , ) :- default (P) . 
• try default rules "tll one gives a positive value. 
darnel (P, assume (true), D) :- forsome (default (P if Q) , tdemo (Q,V# D), positive (V)) } . 
% default negative facts. 
de~o(P,assumetfalse),_) :- default(-P). 
% default negative rules. 
229 
demol (P,assume (false),D) :- 
forsome(default(~P if Q),(demo(Q,V,D),positlve(V))). 
% if P is closed, then its false. 
demol(P,false,) :- closed(P),l. 
% the default answer. 
demol(P,assume(false),_). 
% demoNote(X,D) succeeds if X is TRUE or FALSE, 
otherwise it fails after updating temp(A, ) 
to be the strongest value known so far. -- 
demoNote(V, ) :- known(V). de.~Note(V,D) :- 
notltompl,Dl), 
assert(ten~(V,D)), 
fail. 
demoNote(assume(truo),D} :- 
rotract(temp(_,D)), !, 
assert(temp(assume(true),D)), 
fail. 
% Relations on Truth Values 
positive (X) :- X -- true ; X -- assume(true). 
known(X) :- X -- true ; X -- false. 
hlgher(true, )- hlgher(assum~(trUe) oaSsume(false}). 
higher(_,false). 
upperbound(X,Y, Z} :- higher(X,Y) -> Z-X ; Z-Y. 
lowerbound(X, Y,Z) :- hlgher(X,Y) -> Z-Y ; Z-X. 
strengthen(assume(X)°X}. 
strengthen(true,true). 
strengthen(false, false). 
% negation is relative to a predicate. negate(true, false, ). 
negate(assume(truey, assume(false), ). neqate(assume(false),assume(true},--). 
negate(false, true,P) :- closed(P).-- 
negate(false,assume(true),P) :- not (closed(P)). 
truthValue(nrue). 
truthValue(false). cruthValue(assume(X)) :- truthValue(X}. 
% The Type System 
% isSubtype(TI,T2) iff type T1 has an 
% ancestor type T2. 
isSubtype(TI,T2) :- subtype(Ti,T2}. 
isSub~ype(T1,T2) :- 
sub~ype(T1,T), 
IsSubtype(T, T2). 
% true if instance I is descendant from type T. 
isInscance(I,T) :- Inst(I,T). 
isIns~ance(I,T) :- IsSubtype(TI,T), 
islnstance(I,T1). 
i true if T is • type. 
isType(T} :- inst(,T). 
isType(T) :- subtype(T, ). 
isType(T) :- subtype(_,T}. 
% Grounding Terms 
% blndVars (P} ensures that all variables 
% in P are bound or it fails. 
blndVsrs(P) :- ,ar(P),I,fail. 
bindVara(P) :- atom/c (P)#|. 
bindVars(P) :- 
schema(P,PS), 
p -.. ( iArgs\], 
PS -.. T JTypes|, 
bindArgs~Args,Types). 
blndArgs(\[}#\[\]). bindArgs(\[ArgiArgs\], \[Type lTypes\]) :- 
bindArg(Arg, Type), blndArgs(Args,Types). 
bindArg(Arg,Type) :- 
var(Arg), 
Islnstance(Arg,Type). 
blndArg(Arg,_) :- bindVars(Arg). 
acheme(P,S) is true if S is the schema for P. eg 
achema(glve(John, X,Y),give(person,person,rhing)). 
% find a declared schema. 
schema(P,S) :- 
functor(P,F,N), 
functor(S,F,N), 
declare(S), T. 
use tire default schema F(thlng, thing,...). schonm (P, S) :- 
functor(P,F,N), 
fun~tor(S,F,N), 
for(I,1,N, arg(I,S, thing}), i. 
230 

Bibliography 
1. Clark, Keith L. Negation as Failure. In Logic and Databases, 
J. Minker and H. Gailaire, Ed., Plenum Press, New York, 1978. 
2. Reiter, R. C~sed Wodd Databases. In Logic and Databases, 
H. Gallaire & J. Minker, Ed., Plenum Press, 1978, pp. 149-177. 
3. DeKleer, J. An Assumption Based Truth Maintenance System, 
Proceedings of IJCAI-85, UCAI, August, 1985. 
4. Finin, T.W. Help and Advice in Task Oriented Systems. Proc. 
71h Int'l. Joint Conf. on Art. Intelligence. UCAI, August, 1982. 
5. Howe, A. and T. Finin. Using Spreading Activation to Identify 
Relevant Help. Proceeding of the 1984 Canadian Society lot 
Computational Studies of Intelligence, CSCSI, 1984. also available 
as Technical Report MS-CLS-34-01, Computer and Information Science, U. of Pennsylvania. 
6. Joshi, A., Webber, B. & Welschedel, R. Preventing False 
Inferences. Proceedings of COLING-84, Stanford CA, July, 1984. 
7. Joshi, A., Webber, B. & Welschedal, R. Living Up to 
Expectations: Computing Expert Responses. Proceedings of AAAI-84, Austin "IX, August, 1984. 
8. Kowalsld, Robert. Logic for Problem So/v/ng. North-Hogand, New York, 1979. 
9. McDermott, D and J. Doyle. "Non-Monotonic Logic I'. Artificial Intelligence 13, 1-2 (1980), 41 - 72. 
10. Motto, A. Query Generaifzatlon: A Method for interpreting Null 
Answers. In Larry Kerschberg, Ed., Expert Database Systems, • 
8enjandn/Cummings, Menlo Park CA, 1985. 
11. Pollack, M. Information Sought and Information Provided. 
Proceedings of CHr85, Assoc. for Computing Machinery (ACM), San 
Frencisco CA, April, 1985, pp. 155-160. 
12. Reiter, Ray. "A Logic for Default Reasoning'. Artificial Intelligence 13, 1 (1980), 81-132. 
13. Rich, Elaine. "User Modeling via Stereotypes'. Cognitive Science 3 (1979), 329-354. 
14. Schuster, E. and T. FINn. VP2: The Role of User Modelling in 
Correcting Errors in Second language Learning. Prec. Conference 
on ~l~ficisl Intelligence and the Slmuiatinn of Behavior, AISB, 1985. 
15. Shrager, J. and T. Finin. An Expert System that Volunteers 
Advice. Prec. Second Annual National Conference In Arti(¢ial 
Intelligence, AAAI, August, 1982. 
16. Webber, B. and T. FInin. in Response: Next Steps In Natural 
Language Interaction. In Artificial Intelligence Applications for 
Business, W. Reitman, Ed., Ablex Publ. Co., Norwood NJ, 1984. 
