 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. FIELD OF THE INVENTION
The present invention relates to document generation systems implemented by
means of digital computers and more particularly to document generation
systems employing expert systems and to the knowledge base and inference
engine components of expert systems.
2. Prior Art Many business and legal documents are "written" by combining
pieces of pre-existing text (often called "boilerplate" a required by the
situation for which the document is being written and then adding to or
editing the result, again as required by the situation. Many documents
involving boilerplate were formerly produced rising forms from form books.
The form's text contained the information which did not vary from
transaction to transaction, while blanks were left for varying
information.
With the development of text editing programs (generally termed "editors")
for computers, it became possible to automate the form book. The
originator of the form provided a template document which was stored in
the computer, and people using the editor to make documents which used the
form simply copied the template document into the document they were
making and then filled in the missing information. The automation rapidly
went beyond making a template document and copying it, and a class of
systems called document generation systems emerged. A document generation
system employs a template document and information provided interactively
or from a data base to generate a document which is specifically tailored
to the situation for which it is assembled. A survey of such systems may
be found in the following article:
James A. Eidelman, "The Computer as Electronic Form Book, Available
Software Tools", Legal Economics, May-June 1988
Various approaches have been taken to document generation. Some editing
programs have macro languages, which permit the user to write programs
executed by the editor. By including such a program with a template
document, the template document became a document generation system. Other
document generation programs separate the program which uses the template
from the template. Some document generation systems even employ expert
systems with knowledge bases. The information in the knowledge base is
used to determine what questions should be asked the person for whom the
document is being prepared and to determine to determine what information
should be included in the document being generated.
A persistent problem in the design of document generation systems has been
achieving power without undue complexity. Powerful document generation
systems generally required that the person designing the system have a
programmer's skills; document generation systems which did not require
such skills often did little more than permit the user to select among
parts of the template. In the case of document generation systems using
expert systems, a particular problem has been the integration of the
expert system which provided the information needed to produce the
document with the editor which actually produced it. The foregoing and
other problems are solved by the document generation apparatus and methods
disclosed herein.
SUMMARY OF THE INVENTION
The document generation apparatus of the present invention is an expert
system for generating an output document. The system includes a template
document, a knowledge base for storing knowledge base items, an editor for
editing the template document and an output document produced by the
document generation apparatus, a knowledge base definer for defining
knowledge base items in the knowledge base, and an inference engine which
responds to inputs of information by using the knowledge base to produce
an expert response based on the information. The knowledge base includes a
document portion definer which responds to first user inputs to define a
document portion knowledge base item which is associated with a portion of
the document template. The document portion definer provides the editor to
the user to edit the portion and associate the edited portion with the
document portion knowledge base item. The inference engine includes an
output document generator which responds to a document portion knowledge
base item by employing the editing means to provide the document portion
associated with the document knowledge base item to the output document
when the document knowledge base item and the second user inputs so
require.
In another aspect of the invention, the expert system of the invention is a
definition-based expert system of the type disclosed in the parents of the
present application and the document portions are associated with terms
defined in the definition-based expert system's knowledge base. The
portions in the template document may further contain other terms defined
in the definition-based expert system's knowledge base, including other
terms associated with document portions. When the output document
generator encounters such a term, the output document generator obtains
the term's present value from the knowledge base and outputs the output
document with the value in the place of the term. Further, when the user
of the document portion definer has finished defining a portion of the
template document, the document portion definer determines whether the
other terms in the portion have definitions in the knowledge base; if they
do not, the knowledge base definer asks the user to provide a definition.
It is thus an object of the invention to provide improved apparatus and
methods for generating documents.
It is another object of the invention to provide improved document
generation apparatus and methods which employ expert systems.
It is a further object of the invention to provide document generation
apparatus and methods which employ definition-based expert systems.
It is an additional object of the invention to provide a definition-based
expert system in which a term may be defined as a portion of text and the
portion of text may itself include terms defined in the definition-based
expert system.
BRIEF DESCRIPTION OF DRAWINGS
FIG. 1 is a conceptual block diagram of a prior art expert system.
FIG. 1A is a conceptual block diagram of a prior art expert system shell.
FIG. 2 is a conceptual block diagram of the expert system shell and expert
system of the present invention.
FIG. 3 is a conceptual diagram of a hierarchy of definitions as used in the
present invention.
FIG. 4 is a diagram of the terms and descriptions used to define the term
FRAUD.
FIG. 5 is a diagram of a LISP environment.
FIG. 6 is an overview of a first prototype embodiment of the present
invention.
FIG. 7 is a diagram of TDEF 617 of the first prototype embodiment.
FIG. 8 is a detailed diagram of the function DEFINE of the first prototype
embodiment.
FIG. 9 is a diagram of certain improvements in the second prototype
embodiment.
FIG. 10 is an example template document used in the document generation
apparatus.
FIG. 11 is a conceptual block diagram of the document generation apparatus.
FIG. 12 is a diagram of the document structure of the example template
document.
FIG. 13 is a diagram showing a merge term attribute in the document
structure.
FIG. 14 is a diagram of the index employed in the document generation
apparatus.
For ease of reference to figures, the reference numbers used in the
description of the preferred embodiment have three digits. The two
least-significant digits are reference numbers within a drawing; the most
significant digit is the drawing number. For example, the reference number
901 refers to an item shown in FIG. 9.
DESCRIPTION OF A PREFERRED EMBODIMENT
The following description of a preferred embodiment first presents a
conceptual overview of the expert system and expert system shell of the
present invention and then presents a detailed description of a first
prototype implementation of the invention. Certain improvements made in a
second prototype implementation are discussed. Material added to this
disclosure in the present continuation in part begins at Section 23.
1. Conceptual Overview of the Expert System Shell and Expert System of the
Present Invention: FIG. 2
FIG. 2 is a conceptual block diagram of expert system shell 201 and expert
system 202 of the present invention. Expert system shell 201 has four
components: command processor (CP) 203, definition processor (DP) 207,
term store (TS) 215, and term inference engine (TIE) 219. Expert systems
202 produced using expert system shell 201 have all of these components
but DP 207. As will be explained in more detail below, CP 203 receives
commands from users of shell 201 and system 202 and provides them to the
other components; DP 207 processes definitions; TS 215 stores defined
terms and their definitions; TIE 219 uses a term's definition from TS 215
to evaluate the term and perform other operations on it.
CP 203 converts commands from users of shell 201 and expert systems 202
into definition processor commands (DPCs) 204 and inference engine
commands (IECs) 217. In the prototype, DPCs 204 permit the user of shell
201 to define a term, redefine a term, undefine a defined term, view a
term's definition, save a set of definitions, and restore a set of
definitions. IECs 217 permit the user of shell 201 or an expert system 202
produced by shell 201 to determine the current value of a term, find out
how expert system 202 reached that value, have expert system 202 assume a
different value for a term and see how that affects the value of other
terms, reset the value of any one or all of the terms, and when the
determination of the current value of a term requires a value to be
supplied from outside the definition, to ask expert system 202 why the
value is required.
Definition processor 207 defines TERMs 206. When a TERM 206 has been fully
defined, TS 215 contains a defined term (DTERM) 211 corresponding to TERM
206 and a definition (DEF) 213 for DTERM 211. TERM 206 may be received
either in a DPC 204 or from a description (DESC) 205 DP 207 requested from
the user of expert system shell 201 in response to a TERM 206. DP 207
first determines whether there is already a DTERM 211 corresponding to
TERM 206, i.e., whether TERM 206 is already defined. If it is, DP 207
retrieves DTERM 211 corresponding to TERM 206 from TS 215 and prepares it
for use in the definition DP 207 is currently constructing. If it is not
defined, DP 207 outputs a description request (DESC REQ) to the user of
shell 201. The user provides a description (DESC) 205 of TERM 206 to DP
201, which then makes a DEF 213 for TERM 206 using the information in DESC
205. As will be described in more detail below, DESC 205 is written in a
definition language which permits the user to specify other TERMs 206,
constant values, and that a value is to be obtained from outside expert
system 206 for which the definition is being provided. The definition
further specifies operations which may be performed on the values
represented by TERM 206, constants, and external values in the definition.
If DESC 205 contains TERMs 206, DP 207 treats those TERMs 206 in the
manner just described. If there is a DTERM 211 corresponding to TERM 206,
DTERM 211 is used in DEF 213 being constructed; if there is not, DP 207
requests a DESC 205 defining TERM 206 and processes it as just described.
The repetitive operation of DP 207 is shown in FIG. 2 by arrow 208 showing
how UDESC 210, which contains at least one TERM 206, is again processed by
DP 207. Processing continues in this fashion until the original DESC 205
and all of the TERMs 206 in any DESCs 205 produced for TERMs 206 required
to define the TERMs 206 in the original DESC 205 have been defined, i.e,
have corresponding DTERMs 211 and DEFs 213 in TS 215.
The DTERMs 211 and DEFs 213 resulting from operation of DP 207 are placed
in TS 215. DTERM 211 may be located in TS 215 by name. DEF 213
corresponding to DTERM 211 is associated with DTERM 211, and may thus be
used once DTERM 211 is located. Included in DEF 213 is a modified version
of DESC 205 from which DEF 213 is derived.
The remaining operations specified by DPCs 204 are carried out in DP 207
and TS 215 as follows: when a TERM 206 is undefined, DP 207 removes the
corresponding DTERM 211 and DEF 213 from TS 215; when a TERM 206 is
redefined, DP 207 removes DEF 213 corresponding to TERM 206 and requests a
new DESC 205 for TERM 206. That DESC 205 is then processed in the manner
just described. When a DPC requests that a TERM 206's definition be
displayed, DP 207 displays the DESC 205 which was incorporated into the
DEF 213 for DTERM 211 corresponding to TERM 206. Finally, the save
operation saves the contents of a given TS 215 to a file for later use and
the restore operation restores the contents of the file to TS 215.
Term inference engine (TIE) 219 performs operations using the DTERMs 211
and DEFs 213 in TS 215. The primary operation is the what operation, which
determines the value of a DTERM 211 from its definition and external
values provided by the user of expert system 202 or shell 201. TIE 219
performs the what operation in response to an IEC 217 specifying the
operation and a TERM 206 from CP 203. TIE 219 uses DTERM 211 corresponding
to TERM 206 to locate DTERM 211's DEF 213 in TS 215. It then performs the
operations specified in DEF 213 using the DTERMs 211, constants, and
external values specified in the definition and returns the result, TRES
227, to the user of system 202 or shell 201.
The constants in DEF 213 are available for immediate use in calculating the
value of DTERM 211; in the case of the external values, DTERM 211 contains
a description of how the external value is to be obtained. TIE 219 uses
the description to make a request for an external value (EXVAL REQ) to the
source of the external value EXVAL) 225 and receives EXVAL 225 from the
source. In the simplest case, the source is the terminal being used by the
user of system 202 or shell 201 and the information is obtained by putting
a question on the user's terminal screen and receiving his input; in more
complex cases, the source may be a file or a data base.
In the case of a further DTERM 211 in DEF 213 for the DTERM 211 being
evaluated. TIE 219 obtains the further DTERM 211's DEF 213 and computes
that DTERM 211's value from its DEF 213, evaluating as it does so any
DTERMs 211 in that DEF 213, and continuing thus until all DTERMs 211 from
which the DTERM 211 whose value is being sought in the what operation is
dependent have been evaluated. The constants, external values, and DTERMs
211 specified in each DEF 213 are dealt with in the manner just described.
When all DEFs 213 have been evaluated the value of DTERM 211 whose value
is being sought is computed and returned as TRES 227.
In a preferred embodiment, EXVALs 225 which are obtained during evaluation
of a given DEF 213 become part of that DEF 213's definition; thus, if the
what operation is performed a second time on DTERM 211, TIE 219 will not
produce any EXVAL REQs, but will simply use the stored EXVALs 225 to
recompute the value of DTERM 211. A preferred embodiment has two IECs 217
for modifying the stored EXVALs 225. The first, reset, simply removes all
of the stored EXVALs 225 from the DEFs 213 for the DTERMs 211 specified in
the reset command. Thus, when what is again performed, a new EXVAL 225
will be obtained as previously explained. The second, assume, permits a
new EXVAL 225 to be provided to DEF 213 for TERM 206 specified in the
assume command. When what is again performed in this case, the specified
EXVAL 225 is used to derive the value of DTERM 211 for which the what
operation is being performed.
If a user of shell 201 or system 202 wants to know why TIE 219 is asking
for a given EXVAL 225, he can respond to an EXVAL REQ with the command for
the why operation. In response to that command, TIE 219 outputs DESC 205
from DEF 213 for the DTERM 211 whose value was being computed when the
EXVAL 225 was required, and the user can determine from DESC 205 why the
given EXVAL 225 is important. The user can further use why to ask why any
of the DTERMs 211 whose values are required to obtain the value of the
DTERM 211 whose evaluation produced the EXVAL REQ are required, and TIE
219 provides the DESCs 205 for those DTERMs 211.
3. The Hierarchy of Definitions: FIG. 3
In defining any term, DP 207 produces a hierarchy of DEFs 213. If DEF 213
for the term being defined itself contains no terms, the hierarchy has
only one level. If DEF 13 for the term contains a further term, that term
must be defined before the first term can be defined, and the first term
is the top term in a hierarchy with two levels. If any of the DEFs 213 at
the second level contains a further term, that term must be defined, and
the hierarchy has three levels. The hierarchy thus continues to deepen
until none of the DEFs 213 for the terms upon which other terms depend
contains a further term, but is instead defined solely in terms of
operations on constants or external values. As is clear from the above
discussion, a DEF 213 is always the top DEF 213 in the hierarchy of DEFs
213 required to define the DTERM 211 which DEF 213 defines, but may at the
same time be at a lower level in the hierarchy of DEFs 213 required to
define some other DTERM 211.
FIG. 3 is a conceptual illustration of one such hierarchy of DEFs 213.
Hierarchy 305 contains DEFs 213(A) through 213(E) corresponding to DTERMS
211(A) through 211(E) belonging to set of DTERMS 301. The topmost
definition in hierarchy 305 is DEF 213(A), corresponding to DTERM 211(A).
The notation OP(B,C) in DEF 213(A) indicates that DEF 213(A) specifies
that the value of DTERM 211(A) is obtained by performing an operation on
the values of DTERMs 211 (B) and (C). Similarly, DEF 213 B specifies that
the value of DTERM 211(B) is obtained by performing an operation on the
values of DTERMs 211(D) and (E). Consequently, hierarchy 305 for DEF
213(A) has three levels: level 1 307, containing only DEF 213(A), level 2
309, containing DEF 213(B) and DEF 213(C), and level 3 311, containing
DEFs 213(D) and 213(E). DEFs 213(C), 213(D), and 213(E) do not define
DTERMs 211 C, D, and E with other DTERMs 211, and cannot give rise to
lower levels. Such DEFs 213 are termed terminal definitions 312.
In constructing hierarchy 305 DP 207 begins with TERM 206(A) corresponding
to DTERM 211(A), which it receives from a DESC 205 from which a DEF 213 at
a higher level is being constructed or from a define or redefine DPC 204
DP 207 then requests a DESC 205 for DTERM 211(A). DESC 205 defines DTERM
211(A) in terms of an operation on two TERMS 206, B and C. If DEF 213(B)
and DEF 213(C) already exist, DP 207 can make DEF 213(A) and need go no
further. If either DEF 213(B) or DEF 213(C) does not exist, DP 207 must
produce those DEFs 213 before it can make DEF 213A. DP 207 thus asks for a
DESC 205 for TERM 206(B) and for TERM 206(C). In the case of TERM 206(C),
DESC 205 defines TERM 206(C) only in terms of EXVAL(C) 225, and DEF 213(C)
can be constructed immediately. In the case of TERM 206(B), DESC 205
defines TERM 206(B) in terms of two additional TERMs 206, D and E;
consequently, DP 207 must descend another level and produce DEFs 213 for
those TERMs 206. Again, DP 207 requests DESCs 206 for those terms. In both
cases, the TERMs 206 are defined in terms of EXVALs 225, and consequently,
both DEFs 213 can be constructed. DEFs 213 for all TERMs 206 involved in
the definition of TERM 206 A have now been constructed, DTERMs 211(B)
through (E) corresponding to TERMs 206 (B) through (E) exist, DEF 213(A)
can be constructed, and TERM 206(A) now has a DTERM 211(A) corresponding
to it.
Because hierarchy 305 is constructed repetitively beginning with the top
DEF 213 in hierarchy 305 and only TERMs 206 which have no corresponding
DTERM 211 are defined, no DTERM 211 can have two DEFs 213 and no DEF 213
in hierarchy 305 can refer to a DEF 213 which is above it in hierarchy
305. Consequently, the DEFs 213 in hierarchy 305 are necessarily complete
and consistent with regard to DEF 213(A) in hierarchy 305 or to the top
DEF 213 in any hierarchy incorporating DEF 213(A).
4. The Description Language for Descriptions 205
As previously indicated, DP 207 makes DEFs 213 from descriptions (DESCs)
205. In the prototype, DESCs 205 are made using a description language.
The description language includes predefined terms specifying operations
on terms, a case statement, and operations for obtaining external values.
The operations include Boolean operations, arithmetic operations, and text
concatenation. The case statement is a list of boolean expression-value
pairs of the form:
______________________________________
(boolean.sub.-- exp.sub.-- 1) value 1 . . . (boolean.sub.-- exp.sub.-- n)
value.sub.-- n
(OTHERWISE) otherwise.sub.-- value
______________________________________
When DEF 213 containing a case statement is evaluated, the boolean
expressions 1 through n are evaluated in order until one of them is true.
The value corresponding to the true boolean expression becomes the value
of DTERM 211 defined by DEF 213. If none of the boolean expressions is
true, the value corresponding to OTHERWISE becomes the value of DTERM 211.
The description language of the prototype permits specification of two
classes of operations for obtaining external values. The first class, the
ASK operations, obtains values from the terminal of the user of expert
system 202. The first class, the ASK operations, are used to obtain
external values from the terminal. The second class, the RECORD
operations, are used to obtain external values from a data base system. In
both cases, the external values may be numbers, text strings, or boolean
values, or they may select one of a set of alternative literal terms,
i.e., terms which represent nothing but themselves.
ASK to obtain a numeric value has the form:
ASK NUMBER "prompt.sub.-- string"
When the DEF 213 containing such an ASK operation is evaluated, DP 207
outputs the prompt string to the terminal and waits for a number input
from the terminal. That number is then used in the evaluation of DEF 213.
The prompt string ma itself contain a previously-defined term, and
consequently, a user's response may be made to depend on the value of a
previously-evaluated term. The ASK operations for boolean and text string
values are specified in the same fashion as the ASK operation for numeric
values, except that NUMBER in the above operation is replaced by YES-NO
when a boolean value is sought and TEXT when a text string is sought.
ASK which selects one of a number of literal terms has the form:
______________________________________
ASK CHOICE "prompt.sub.-- string"
(literal.sub.-- term.sub.-- 1 . . literal.sub.-- term.sub.--
______________________________________
n)
When the DEF 213 containing ASK CHOICE is evaluated, the prompt string is
output and the user is asked to select one of the literal terms. That
literal term may then be used in DEF 213 to compute the value of DTERM 211
defined by DEF 213.
The RECORD operations are generally analogous to the ASK operations, except
that the RECORD operation specifies how the external value is to be
located in the data base and the data base supplies the value at the
specified location.
5. Operation of Shell 201 and System 202: FIG. 4
The operation of shell 201 will be explained in detail using a hierarchy of
definitions from which it may be determined whether someone has been
defrauded. The legal definition of fraud requires that one party knowingly
made a misrepresentation to the other party and that the other party
relied on the misrepresentation to his detriment. FIG. 4 shows a hierarchy
of DTERMs 211 which corresponds to that legal definition.
Creation of the hierarchy of FIG. 4 begins when CP 203 receives the DEFINE
FRAUD command. CP 203 then passes TERM 206 FRAUD to DP 207, which requests
a DESC 206 from the expert making the definition. The expert provides the
DESC 206
KNOWING.sub.-- MISREPRESENTATION AND DETRIMENTAL.sub.-- RELIANCE
This DESC 206 contains two further TERMs 206 and the boolean AND operator.
Thus, the value of FRAUD is to be computed by obtaining the values of the
DTERMs 211 corresponding to the TERMs 206 and performing an AND operation
on them.
Since the further TERMS 206 are undefined, DP 207 asks for their
definitions. The expert provides the DESC 205
MISREPRESENTATION AND DEFENDANT.sub.-- KNEW.sub.-- MISREPRESENTATION
KNOWING.sub.-- MISREPRESENTATION and the DESC 205.sub.-- RELIANCE.sub.-- BY
PLAINTIFF AND LOSS.sub.-- BY.sub.-- PLAINTIFF for DETRIMENTAL.sub.--
RELIANCE. Again, these further TERMs 206 are undefined, so DP 207 asks for
their definitions and the expert provides the definitions show in FIG. 4.
While DP 207 may ask for definitions in any order, a preferred embodiment
defines all TERMs 206 necessary to define a given undefined TERM 206
before going on to the next undefined TERM 206.
In the above example, the DESCs 205 for MISREPRESENTATION, DEFENDANT.sub.--
KNEW.sub.-- MISREPRESENTATION, RELIANCE.sub.-- BY.sub.-- PLAINTIFF, and
LOSS.sub.-- BY.sub.-- PLAINTIFF all contain only the system-defined DTERMS
211 used in the ASK YES-NO operation, so DP 207 is now able to produce
DEFs 213 for all of the terms in the hierarchy. The values of all of the
DTERMs 211 in the hierarchy depend ultimately on the values which the ASK
YES NO operation requests from the user of expert system 202 which employs
the FRAUD definition, and thus depends ultimately on what the plaintiff
says about what happened to him.
Use of the FRAUD definition hierarchy in expert system 202 begins with the
WHAT FRAUD command which the user of expert system 202 inputs to CP 203 CP
203 generates a corresponding WHAT FRAUD IEC 217 for TIE 219. TIE 219 then
determines the value of FRAUD by evaluating its DEF 213. In order to do
that, it must evaluate the DEFs 213 for other DTERMs 211 in the hierarchy,
beginning with KNOWING.sub.-- MISREPRESENTATION. The evaluation of
KNOWING.sub.-- MISREPRESENTATION requires the evaluation of
MISREPRESENTATION. The evaluation of that DTERM 211 results in the
execution of the WHAT YES-NO operation in its DEF 213, and TIE 219 outputs
the prompt "Did he tell you anything that wasn't true?" If the user
answers "no", MISREPRESENTATION is false, KNOWING.sub.-- MISREPRESENTATION
is false, and FRAUD is false, so TIE 219 returns TRES 227 to the user
indicating that there is no fraud. If the user answers "yes", TIE 219
evaluates DEFENDANT.sub.-- KNEW.sub.-- MISREPRESENTATION, which again
results in a question to the user. Depending on the answer to the
question, evaluation continues or is finished. TIE 219 proceeds in the
above fashion until it has computed a value for FRAUD.
As previously mentioned, a user of expert system 202 may use the HOW user
command to determine how expert system 202 arrived at its value for FRAUD.
Assuming that the user answered "no" when asked "Did he tell you anything
that wasn't true" (in the definition of MISREPRESENTATION), TIE 219 in the
prototype will respond to HOW FRAUD by outputting
______________________________________
FRAUD is defined to be (KNOWING.sub.-- MISREPRESENTA-
TION AND DETRIMENTAL.sub.-- RELIANCE) where
(KNOWING.sub.-- MISREPRESENTATION) equals FALSE.
______________________________________
As previously mentioned, DP 207 places DESC 205 for a DTERM 211 in the
DTERM 211's DEF 213, and TIE 219 also stores the external values it
receives in evaluating a DTERM 211's DEF 213 in DEF 213. In performing the
HOW operation, TIE 219 first fetches and outputs DESC 205 from DEF 213 for
the DTERM 211 being inquired about and then evaluates the DTERMS 211 in
DEF 213 as required to obtain the value of DTERM 211 being inquired about.
The DTERMs 211 are then output together with their values. If a user
wishes to inquire further, he need only repeat the HOW operation on the
other DTERMS 211 specified in the DESC 205 output in the HOW operation.
As also previously mentioned, a user may respond to a request for an
external value with the WHY command instead of a value. If a user responds
in the case of the FRAUD example with WHY when TIE 219 asks "Did he tell
you anything that wasn't true", TIE 219 responds with:
______________________________________
MISREPRESENTATION is needed to determine the value of
KNOWING.sub.-- MISREPRESENTATION, which is defined to be
MISREPRESENTATION AND SUBJECT.sub.-- KNEW.sub.--
MISREPRESENTATION
______________________________________
and repeats the question.
Again, the information used to respond to the WHY command comes from the
DESCs 205 stored in the DEFs 213 in the hierarchy used to define FRAUD. If
the user wants to know more at this point, he can apply HOW to the DTERMs
211 mentioned in the response to the WHY command.
6. The LISP Environment of the Prototype Embodiments: FIG. 5
Having thus provided a conceptual overview of the structure and operation
of shell 201 and system 202, the discussion proceeds to a detailed
description of the implementation of the first prototype.
Both the first and second prototype embodiments are implemented in the LISP
programming language and execute in the LISP environment. The LISP
programming language and environment are frequently used to implement
prototype and production expert systems and are well-known in the expert
system art. The specific LISP dialect used for the prototype embodiments
is COMMON LISP, which is described in Guy L. Steele, Jr., COMMON LISP, the
Language, Digital Press, 1984. Only so much of the LISP environment and
language are described here as is required for a clear understanding of
the mode of operation of the prototype embodiments.
Beginning with the LISP language, the language differs from languages such
as FORTRAN or PASCAL in that is is chiefly concerned with the processing
of symbols, as opposed to the processing of data which is represented in a
program by symbols. The fundamental components of a LISP program are
atoms. An atom may be a symbol, such as ABC, or a constant. The components
are organized into programs by means of lists which may have no members or
members including atoms and other lists. A list is made by enclosing its
members in parentheses: (ABC) is a list with one member, the symbol ABC.
Functions appear in LISP as lists in which the first symbol in the list
represents the function and the other atoms represent the function's
arguments. For example, the add function is represented in LISP by the
symbol +, and the list (+2 3) specifies that the + operation is to be
applied to the atoms 2 and 3. Any atom or list which has a value when
evaluated by a LISP interpreter is called a form. 5 and (+2 3) are forms,
and if the symbol ABC has a value, it is a form.
Functions are defined in LISP by means of the DEFUN function, in which the
remaining items of the list define the function's name, its arguments, and
the value it returns. For example, (defun five () 5) defines a function
which takes no arguments and always returns the value 5.
Among the things LISP programs can do with symbols and lists is make them.
Since a function definition is only a kind of list, a LISP program can
provide a symbol to DEFUN as the name of the new symbol being created by
DEFUN and then use the symbol to execute the newly-created function.
Symbols may either represent themselves as symbols or values. When a
symbol is representing itself as a symbol in a LISP list, it is preceded
by a' mark. In the case of symbols representing functions, the value of
the symbol is the function. However, if the function is placed in a list
with its arguments and the list evaluated, the result is the value of that
execution of the function. Thus, 'five represents the symbol five, while
five represents the function defined by DEFUN above, and (five) represents
the value of an execution of the function five, i.e., 5.
LISP programs are written and executed in a LISP environment. That used for
the prototype embodiments was made by Gold Hill Computers, Inc. for the
Professional Computer manufactured by Wang Laboratories, Inc. FIG. 5 is a
conceptual block diagram of a typical LISP environment 501. Environment
501 has two main components, LISP interpreter 503, which evaluates LISP
forms, and LISP symbol space 505, which stores LISP symbols (SYM 501) and
their definitions (SYMDEF 509). DEFUN and certain other LISP functions
create and define new LISP symbols or redefine previously-existing LISP
symbols when they are evaluated; consequently, LISP interpreter 503 may be
seen as not only an evaluator of symbols, but also as a creator, defi | | |
