\documentstyle[fullpage]{report} %switch back to 12pt after drafting % done?? \title{Integrated Generic Task Toolset\\ Fafner Release 1.0\\ Introduction and User's Guide} \author{John R. Josephson \and Diana Smetters\\ \and Richard Fox \and Dan Oblinger \and Arun Welch \and Gayle Northrup} \makeindex \begin{document} \sloppy \tableofcontents \listoffigures \maketitle %-----------------------Abstract------------------------------------- \begin{abstract} The Integrated Generic Task Toolset provides computational mechanisms especially suited for certain reasoning tasks which are typically encountered during the course of diagnosis, design, planning, and similar knowledge-based activities. By directly supporting a set of basic reasoning tasks, the toolset provides building blocks out of which more complex reasoning systems can be built. To support a particular reasoning task, the toolset provides a set of appropriate mechanisms, each with its own control strategies and characteristic ways of organizing and representing knowledge. Thus, the toolset provides to the knowledge system builder an advantage over rules, logic, semantic nets, frames, and neural nets, similar to the advantage that higher-level languages provide over assembly language for the computer programmer. A release of the integrated toolset, called Fafner, is available for research use. Fafner provides the ``toolbed,'' a framework for integrating the individual tools, the RA tool, and the CSRL tool. The RA tool provides the facilities for constructing recognition agents, agents designed to determine the degree of match between a hypothesis and a situation. RA is the first of six tools to be included in this and later releases, and is an important foundation for the others. The CSRL tool builds on the foundation provided by RA, and allows the construction of hierarchies of classification specialists. Such hierarchies are used to perform the hierarchical classification task, an important part of both diagnosis and reasoning in general. Fafner is written completely in Common Lisp and CLOS (Common Lisp Object System) and is fully portable at that level. \end{abstract} %------------------------------------------------------------------- \part{Introduction to the Toolset} %--------------------Chapter 1--Introduction------------------------ \chapter{Introduction} % Section----------------------------------------------------------- \section{The Integrated Generic Task Toolset} What is here called the ``generic task toolset'' has been an active project, in one form or another, at the Ohio State LAIR for several years. MDX, a medical system built in 1979, decomposed the diagnostic task into a classification component \cite{84-FG-FGBC} and a data-abstraction component \cite{MITT80C,83-BC-MDX}. This idea of different types of problem solving was then expanded to a broader theory of {\bf generic tasks}, where complex problem-solving behavior is conceived of as a cooperation between simpler, more fundamental types of reasoning \cite{83-BC-TAXONO,86-BC-IEEEX,87-BC-IJCAI}. In generic task theory, specialized knowledge structures and control strategies come together to form building blocks for knowledge-based reasoning. A natural step was to support each of the generic tasks with its own ``shell'' or ``language'' or ``tool,'' following in the path of EMYCIN's generalization of MYCIN \cite{VANM80}. CSRL was therefore built to capture abstractly the hierarchical classification portion of MDX's knowledge structures and control strategies \cite{86-TB-CSRL}. In using hierarchical classification for diagnosis, the patient (or device) is identified as belonging to one or more disease categories (malfunction categories), the categories being hierarchically organized according to their levels of generality or inclusiveness. Thus, we speak here of ``hierarchical classification'' as the process of {\em using\/} a classification hierarchy on a new case, not as the {\em building\/} of the hierarchy itself, which can be viewed as a form of learning with the hierarchy being the target structure of the learning process. A natural overall control strategy for hierarchical classification is {\bf establish-refine}: top-down, prune-or-pursue behavior, where a node in the hierarchy either {\em establishes\/} its classification hypothesis and goes on to {\em refine\/} it by calling on subnodes, or rejects its hypothesis and prunes the search tree at that point. The sort of functional architecture we see here for hierarchical classification, this coming together of knowledge organization (hierarchical by generality of category) and control strategy (establish-refine) to serve a generic knowledge-level purpose (hierarchical classification), is precisely what Chandrasekaran has been calling a {\bf ``generic information processing task''} \cite{86-BC-IEEEX,87-BC-IJCAI}. After hierarchical classification, other generic tasks were discovered, yet hierarchical classification served as a guiding example all along. For each generic task, a tool was constructed which supports knowledge organization and control for that task. CSRL, the tool for hierarchical classification, allows the user to encode the hierarchy of categories and provides the establish-refine control strategy to use for problem solving. It does this by providing for the construction of ``classification specialists:'' problem-solving agents, one agent for each classification category, that cooperate by exchanging messages to solve the overall problem. Actually CSRL originally did much more, since it allowed the user to encode knowledge and control for another task too, the task that supports the establishing and rejecting of hypotheses. Eventually this other ``recognition'' or ``concept matching'' task was separated off from CSRL and embodied in the HYPER tool \cite{Johnson86}, now reimplemented as RA. RA provides knowledge structures and control specifically for the recognition task, while the new CSRL provides only for hierarchical classification as such. For the most part, each of the generic task tools was implemented separately by a different researcher studying a different task in a different domain. Eventually, however, it became clear that an {\bf integrated toolset} was possible, providing for interactions between the various sorts of problem solvers set up by the various different tools. Moreover, our work on explaining the reasoning processes in routine design and planning \cite{86-BC-EXPCON} showed that meaningful explanations can come from the interactions of heterogeneous problem-solving agents if each agent has a functionally distinct task and if the interactions between them make sense. A new integrated implementation of the toolset was then envisioned which would make possible the building of complicated systems relying on any of the various forms of reasoning we had discovered. This toolset would embody in software our progress and experience so far in building knowledge-based systems, and would provide a platform for further work. The new toolset would use a society-of-minds metaphor \cite{MINSKY-SOCIETY-79,MINSKY-SOCIETY-86} for expressing the organization of knowledge and control, and give it knowledge-level content by using families of functionally typed, mechanism-appropriate problem-solving agents. In this way, the appropriateness of certain (simple?) mechanisms for certain basic reasoning tasks could be expressed---the essence of the generic task idea. Furthermore, progress could go on empirically by building many systems with the new toolset and finding out what real-world domains have to say to us about the forms of knowledge and the structure of reasoning. The new toolset would provide the functionalities of all of the older generic task tools and would provide a toolbed for extending the framework to new generic tasks. This document describes the Integrated Generic Task Toolset which has resulted from that vision. % Section----------------------------------------------------------- \section{The Individual Tools} The Integrated Generic Task Toolset is projected to provide tools to support reasoning for the following generic tasks: \begin{itemize} \item {\bf Routine Recognition}---recognize whether a concept applies to a given situation. {\bf RA} (Recognition Agent) is a tool for constructing ``recognition agents'' which are individual problem solvers, each one assigned to a specific recognition task. Each recognition agent is associated with a particular concept or abstraction. When the agent is invoked, it performs appropriate tests on features of the situation and produces a confidence symbol representing whether the concept applies to the situation. Knowledge is typically organized hierarchically, along lines of abstraction of features. That is, a ``feature'' may itself be recognized based upon a further set of features. Control may be organized for either hypothesis-driven or event-driven invocation. The task of the recognition agents may also be described as ``hypothesis scoring'' or ``concept matching for relevance.'' \index{RA} \item {\bf Hierarchical Classification}---classify an object, event, or situation with respect to a taxonomic hierarchy. {\bf CSRL} (Conceptual Structures Representation Language) is the tool for implementing this form of reasoning. It supports a top-down, establish-refine control strategy, and variations of this strategy, on a hierarchy of specialists, each specialist representing a classification hypothesis, and each associated with knowledge necessary to establish or reject that hypothesis. \index{CSRL} \item {\bf Routine Design}---construct a design or plan according to specifications. {\bf DSPL} (Design Structures and Plans Language) is a tool designed to support ``plan selection and refinement,'' reasoning which occurs when plans for the design are known in advance, but how plans and sub-plans fit together must be decided at run time \cite{86-DB-KNOWCO}. Each design task or subtask is represented by a specialist, and a sponsor/selector control regime is used to decide between design plans. \index{DSPL} \item {\bf Knowledge-Directed Data Retrieval}---perform indirect inference for ``intelligent'' data retriev\-al. {\bf IDABLE} is the tool for constructing intelligent databases (IDBs) and database front-ends. These can be used by other automated problem solvers, or they can stand alone for human use. Data-related concepts are represented as ``data model objects'' (DMOs), specialized agents which participate in networks of semantic relations along links which may be supplied by the knowledge engineer. At a basic level, the control mechanism is indirect inference (attached inference procedures) whereby the DMO that catches a question (because it specializes in a concept that occurs in the question) knows what to do to infer an answer. IDABLE supports the encoding of specialized forms of attached inference which take advantage of the semantic relations between DMOs. Automatic conversion of numerical units is built in. Some temporal reasoning ability is provided, as well as support for reasoning about the normality and abnormality of data values.\cite{84-SM-PATREC} \index{Idable} \item {\bf Abductive Hypothesis Assembly}---construct the best composite explanation of some body of data using a set of plausible hypothesis fragments. {\bf Peirce} is a tool for setting up inference-to-the-best-explanation reasoners. A Peirce-based problem solver uses a specialized means-ends control regime to form composite explanatory hypotheses and to evaluate them by detecting the presence of alternative explanations \cite{87-JJ-MECHANISM,86-WP-PEIRCE,88-JJ-REDUNCERT,84-JJ-RED,88-AG-CONSYNCOMP}. \index{Peirce} \item {\bf Prediction by State Abstraction}---predict the effects on a system, given changes to lower-level subsystems. Control proceeds bottom-up through a hierarchy of specialists representing the various subsystems. The tool is called {\bf WWHI} (What Would Happen If).\index{What Would Happen If} \item {\bf Functional Representation of Devices}---represent an agent's ``deep knowledge'' of how a device works in a way that shows how an intended {\it function} is accomplished as a result of the {\it behaviors} of its components, leading to a series of {\it states} of the device. The Functional Representation can also be used to represent how aspects of a {\it plan} can be understood, viewing the plan as an abstract device. A Functional Representation compiler takes as input the functional representation of a device and builds from this a diagnostic system to determine malfunctions. Current and further research includes using the representation as a basis for {\it simulating} plans in order to check the featsibility of planning decisions, for {\it creating} and {\it modifying} plans based on desired goals, and for {\it predicting} consequences to device functionality, given changes in the structure of the device. \index{Functional Representation of Devices} \end{itemize} % Section------------------------------------------------------------- \section{The Toolset in Common Lisp} Source code for systems built using the Common Lisp version of the toolset takes the form of valid Lisp forms that can be read by the READ function. Together these forms set up a problem-solving system, primarily by defining dragons that communicate and cooperate to solve problems. Evaluating the form defining a dragon (e.g., upon LOADing the form into Common Lisp) causes the specified dragon to be constructed. .GT is the standard file extension for generic task source code. %-------------------Chapter 2--------------------------------------- \chapter{The Fafner Release} The Fafner release of the Generic Task Toolset contains implementations of RA, the hypothesis recognition tool, and CSRL, the hierarchical classification tool; as well as a minimal implementation of Idable to serve as an information-storage facility. The emphasis in this release is to flesh out the groundwork laid in the Draco release by expanding to a full-scale implementation of CSRL, and increasing the general usability of the system through utilities such as a case-saving mechanism for IDB's, dragon fasload forms, user-defined confidence sets, and the hierarchy data abstraction. The Toolset is a powerful set of tools for capturing large quantities of domain-specific and general-purpose knowledge in a task-specific architecture, making it easy for the tool builder to quickly and intuitively build large knowledge-based systems which depend on certain reasoning tasks. The presence of a full implementation of CSRL in this release of the GT Toolset marks its readiness to be used in building large-scale systems. The combination of the CSRL tool and the RA tool, with the addition of the mini-IDB is admirably suited to implementing systems to perform diagnostic classification, or any other sort of hierarchical classification. The abundant facilities for building systems using both the Toolset and Common Lisp itself means that the tool builder can easily overcome any deficit in functionality caused by the lack of the other tools in this release through use of the underlying object layers or Lisp. We have also emphasized portability at the Common Lisp and CLOS (Common Lisp Object System) level. As a result the user interface is impoverished relative to what we envision for later versions. For now the user builds a knowledge system by editing the GT toolset source code itself. In later versions the user will interact with graphical editors, primarily network browsers and special form editors, which present the high-level constructs, and allow knowledge structures to be edited in a natural way at a high level of abstraction. Source code will then recede in importance to becoming at most a machine-independent form in which systems can be stored and transported, never to be seen by normal users. % Section------------------------------------------------------------- \section{Portability} This release is written in Common Lisp and the Common Lisp Object System \footnote{The Common Lisp Object System, CLOS, is freely available from Xerox for most Common Lisps under the name PCL.} The Fafner release expects to run in the 12/7/88 ``no cute name'' release of PCL. This release has been tested under Kyoto Common Lisp, Ibuki Common Lisp, Xerox Common Lisp (Medley release), and Franz/Allegro Common Lisp. In previous releases, it has been tested under Kyoto Common Lisp, Xerox Common Lisp (Lyric and Medley releases), CMU Common Lisp (on the IBM RT/PC), Franz/Allegro Common Lisp, Allegro/Coral Common Lisp (on the Macintosh II), and Vaxlisp.\footnote{Moving the toolset to new Common Lisps or new machines is generally unproblematic, and requires no serious porting effort.} The Fafner relase, including CLOS, is available for research use by tape or FTP from the Ohio State LAIR.\footnote{For information about installing the Fafner release of the Generic Task Toolset, see Appendix A, Installing the toolset.} This extreme level of portability means that applications based on the Generic Task Toolset will be immediately runnable on a wide variety of machines and Common Lisps. %-------------------Chapter 3--------------------------------------- \chapter{Dragons\index{dragon}} The primary organizing construct for the {\bf toolbed}, the framework for integrating the individual tools, is a class of knowledge-using problem-solving agents called {\bf dragons}. The tools enable the user to define dragons of various sorts which cooperate with each other to solve problems. A dragon has an assigned job and embedded knowledge to get that job done. A dragon is invoked by sending it a message. Thus, the building of systems by defining and linking dragons fits in well with the object-oriented style of programming and with computer architectures based on message passing. Furthermore, since message-passing architectures are so supportive of it, dragon communities may perform parallel and distributed processing at a wide variety of grainsizes. Thus, knowledge systems can be built without unnecessarily and artificially introducing serial-processing assumptions. For a short while after it acts, a dragon retains a memory record of what it has done. The record of a single dragon invocation is called an {\bf engram}. Engrams are very useful for providing a system with the ability to explain and justify its reasoning. An engram records all interaction with other dragons, so a record of the run-time dependencies between the parts of the problem-solving process is retained. The organizing principle for (the lowest level of) explanation is that {\em the agent which makes a decision is the one with primary responsibility for justifying that decision\/}. By retaining a well-organized record of significant problem-solving events, the memory structures also lay the groundwork for various forms of machine learning if we are clever enough to build on it. To keep a system from choking on its own memory structures, the memory capacity of each dragon is limited. At the present time we do not have much theory of which memories to retain, or of how to organize and learn from them, so in this release older engrams simply fall off the end of the fixed-length ``conveyor belt'' buffer from which each dragon's memory is constructed. % Section------------------------------------------------------------- \section{Communication Between Dragons\label{messages}} Dragons are problem-solving agents that interact by exchanging messages. When a dragon receives a message calling for problem-solving activity, it does its business, and then reports the result by sending off another message. This result-reporting message may or may not go back to the dragon that provoked the activity to start with, depending on how it is set up for that particular dragon. The message-passing mechanism used for all communication between dragons is called {\bf invoke}. The form of an invoke is: \index{invoke} \index{dragon communication} \begin{tabbing} 123456\=123456\=123456\= \kill \>({\bf invoke} {\it dragon\/} {\bf '}{\it verb\/} {\it arg arg}\ldots) \\ \end{tabbing} where {\it dragon} is the dragon being invoked, {\it verb} is a symbol which specifies the action to be performed by that dragon, and {\it arg arg arg...} are the arguments required by that dragon for use with that verb. Invoke is a common lisp function, but in some places in the source code definition for a dragon, the availability of preprocessing allows a call to ({\bf invoke} {\it dragon\/ 'verb\/ arg arg}\ldots) can be abbreviated by ({\bf verb} {\it dragon\/} {\it otherstuff}). Details are given in the source code description below. Any given dragon can usually respond to several verbs. The system will assign a dragon a set of default actions to perform in response to a small set of verbs when that dragon is defined. The verbs and actions so specified depend on the type of dragon being defined. The user can redefine any system-defined verb, or define any number of new verbs, for a particular dragon by specifying the verbs and the actions to be performed in response when defining that dragon. %-------------------Chapter 4--------------------------------------- \chapter{Using the Toolset} This chapter contains a high-level description of the structure of systems written using the tools in the Generic Task Toolset. It discusses the types of agents used in each tool and the types of tasks each type of agent is designed to perform. It is meant as a general overview or introduction to designing a system using the Toolset. % Section------------------------------------------------------------- \section{RA For Constructing Recognition Agents\index{RA}} {\bf RA} (Recognition Agent tool) supports the construction of ``recognition agents,'' individual problem solvers, each assigned to a specific recognition task associated with a particular ``concept'' or ``abstraction''. When the agent is invoked, it performs appropriate {\bf tests} on {\bf features} of the situation, and produces a confidence symbol representing whether the concept applies to the situation. \index{recognition agent} \begin{figure} \vspace{7.0cm} \caption{Recognition agents map concepts and situations to confidences. For a particular agent the concept is constant, and the situation varies.} \end{figure} RA is a descendant of the HYPER (HYPothesis matchER) tool developed at OSU-LAIR for the ``concept matching'' or ``hypothesis scoring'' task. In turn HYPER was derived from a part of the original CSRL tool (Conceptual Structures Representation Language); HYPER was implemented as a tool separate from CSRL as a result of discovering that there are generic uses for HYPER's powers, separate from the hierarchical classification task to which CSRL is dedicated. In particular we found that plan sponsoring as it occurs in DSPL (Design Structures and Plans Language) calls for the same sort of {\em graded-response\/}, {\em matching-to-situation\/} activity as that typically required for establishing or rejecting nodes in a classification hierarchy. % Subsection------------------------------------------------------------- \subsection{Types of recognition agents} \index{recognition agent subtypes} Recognition agents have a number of subtypes.\footnote{These subtypes include those corresponding to HYPER's ``hypothesis-matchers'' and CSRL's ``knowledge groups.''} They are distinguished from one another by their mechanisms, i.e., their means of accomplishing the recognition task. RA supports three distinct recognition agent subtypes: {\bf discrete-pattern}, {\bf match-1}, and {\bf free-form}.\footnote{A {\it hierarchical} subtype was supported in earlier releases, but is no longer supported due to lack of usefulness.\index{hierarchical-recognition-agent}} We hope before long to support two other forms: {\bf linear-perceptron} and {\bf neural-net}. \begin{itemize} \item \index{discrete-pattern-recognition-agent} A {\bf discrete-pattern} recognition agent sets its confidence value based upon whether a particular pattern matches or not. Associated with the agent is a small set of {\bf features} to be checked to determine whether the pattern matches.\footnote{``A small set'' here means that the user is encouraged to analyze the recognition task into meaningful and manageable subtasks; ``small'' means small enough to be comprehensible to whoever will ultimately {\em maintain\/} the knowledge system; ``small'' means no more than 7. This is not enforced, however.} When a feature is checked, it produces a symbol or a symbolic expression. \index{pattern} \index{feature} A {\bf pattern} consists of a set of {\bf tests}, each test corresponding to one feature. In order to facilitate communication between agents using different vocabularies, an agent builder can request that a feature will be processed through a predefined {\bf transform} before it is subjected to its corresponding test. Transforms are provided only for certain operations on confidence symbols (vocabulary change, inversion, thresholding). The {\bf NO-OP} transform is provided for other occasions. The specifics will be described later in this document. The features are checked as needed, with one test being performed for each feature that is checked. If a sufficient number of the tests succeed, the pattern is considered to be matched, and the specified {\bf match-confidence} is the result. Otherwise the {\bf no-match-confidence} is the result. How many of the tests must succeed in order for the pattern to be considered matched, is a parameter set by the builder of the agent. The success or failure of the pattern may have side effects -- the builder of the agent may specify a {\bf match-action}, a set of actions to be performed if the pattern matches, and a {\bf no-match-action}, a set of actions to be performed if the pattern does not match. \item \index{match-1-recognition-agent} A {\bf match-1} recognition agent has a sequence of patterns to be checked against its set of features. The first pattern to match will set the confidence symbol. Features are checked as needed, after being processed through the same feature transforms as are provided for discrete-pattern recognition agents. One transform per feature may be specified. For each pattern in the table, the agent-builder may specify a {\bf match-action} to be performed if that pattern matches. If none of the patterns match, the confidence symbol is set according to the {\bf no-match-confidence}, and the {\bf no-match-action}, if specified, is performed. Match-1 agents are readily displayed in the form of decision tables, so they present a compact and comprehensible decision logic. They are very useful for representing knowledge elicited from experts by questions of the sort, ``How confident would you be in the hypothesis if you saw such-and-so a pattern of evidence?'' The expert's reply establishes the confidence for one row in the decision table. \item \index{free-form-recognition-agent} The method of determining a confidence in a {\bf free-form} recognition agent is completely up to the knowledge engineer; the language for specifying this is Common Lisp enhanced by certain functions and variables made available by the tool. Any portion of the functionality of any of the other types of recognition agents may be used. \end{itemize} % Subsection------------------------------------------------------------- \subsection{Using RA for recognition tasks} A recognition agent, or a hierarchy of recognition agents is geared towards answering a question of the form ``does the current situation match hypothesis X'' (ex. a recognition agent may answer the question ``is anabolic steroid present in the patient's blood?). A hierarchy will generally consist of several recognition agents, each of which solves part of the problem by recognizing some aspect of the situation recognized by the hypothesis as a whole. RA's are most commonly used to perform only part of the general problem-solving task at hand (the task is generally more complex than simply one of recognition). For example, hierarchies of recognition agents are often embedded in CSRL systems, as described in the next section. % Section------------------------------------------------------------- \section{CSRL for hierarchical classification\index{CSRL}} A CSRL hierarchy generally answers a question of the form ``which category or categories match the current situation?''. This is the task of classification, which is often useful for performing diagnosis. CSRL allows the user to build a taxonomy or hierarchy of categories and provides an establish-refine control strategy for use in determining which category or categories apply to a given situation. It does this by providing for the construction of ``classification specialists'': problem-solving agents, one agent for each classification category, that cooperate by exchanging messages to solve the overall problem, under direction of an agent called a ``classifier''. In short, RA provides the user with the facilities to answer the question ``does {\bf this} hypothesis apply to this situation'', while CSRL provides the facilities to answer ``{\bf which} hypotheses apply to this situation''. % Subsection------------------------------------------------------------- \subsection{Operation of classification specialists and classifiers} \index{classifier} \index{classification-specialist} A classifier is a special agent that manages bookkeeping, etc. for a hierarchy of classification specialists (a group of classification specialists geared towards solving a particular classification problem, where the group is organized as an acyclic directed graph). The classifier maintains an image of the hierarchy, and is useful for certain problem-solving and information-retrieval tasks. Normally, a CSRL hierarchy will be built by defining the classifier, then defining each of the specialists in the hierarchy (the classifier must be defined before any of the specialists that belong to its hierarchy in order to correctly build the hierarchy data structure inside the classifier). The only information that the system-builder has to give the system to create the classifier is the classifier's name (and the name of the author of the classifier, see {\bf define-classifier}, below). The system will generate all the other necessary information (though the system-builder is welcome to build as much additional complexity into the classifier as she desires by overriding the default configuration with either one of the alternate system-defined configurations or one of her own). To build a classification specialist, the system-builder must define many of the parts of its internal mechanism. To do this, the system-builder must understand how classification specialists function: \subsubsection{Operation of Classification Specialists} Classification specialists operate in a very simple way. An individual classification specialist represents a hypothesis at a certain level of specificity in a hierarchy of hypotheses. The parents of that classification specialist represent more general hypotheses, where this specialist is a refinement, or narrowing, of its parents' hypotheses. The children of this specialist represent a refinement on this specialist's hypothesis. (For example, this specialist might represent the hypothesis ``X is a bird.'', while it's parent represents the hypothesis ``X is an animal'', and it's children represent ``X is a sparrow'', ``X is an ostrich'', ``X is a penguin'', etc.) The objective of a CSRL hierarchy is to return the most specific hypotheses it can that are supported sufficiently by the available data. \paragraph{Determining Status --- Establishing\index{status}} This basic function of classification specialists has two parts: {\bf establishing} and {\bf refining}. When an individual hypothesis in the hierarchy comes into consideration, the first question that must be answered is ``do I match this situation?''. To answer this question, the specialist performs several problem-solving steps to determine its {\it status} with respect to the current situation (this process is called {\it establishing\/}). A specialist's status at any given time will be one of four values: \begin{itemize} \index{establish} \item {\bf established:} An established hypothesis is one that matches the situation according to the criteria set up by the system builder. \index{suspend} \item {\bf suspended:} A suspended hypothesis has undefined status; it cannot be determined to be true or false with the information the specialist has examined to this point. \index{rule-out} \item {\bf ruled-out:} A ruled-out hypothesis is one so low in possibility as to be considered essentially false. \index{not-run} \item {\bf not-run:} This indicates that the specialist has not yet attempted to determine its status in this case. \end{itemize} A specialist sets out to determine its status by first evaluating its {\bf ESTABLISH-REJECT} method -- this is a form that returns a confidence value representing the degree of confidence with which the specialist's hypothesis matches the situation. The ESTABLISH-REJECT method may be a call to a recognition agent (or a hierarchy of recognition agents) (using an invoke or a judge call), it may be a call to a database (using ask), it may be a request of the user (using ask-user), or it may be an arbitrary Lisp form to evaluate. Whatever is returned by the ESTABLISH-REJECT method is first processed by the specialist's {\bf TRANSLATOR} method before being used to determine whether or not the agent establishes. The TRANSLATOR method exists to deal with the possibility that the incoming confidence value may not be in the confidence set of the specialist, or the possibility that the incoming value may not yet be a confidence at all -- it may be a numeric value, such as 3, or an arbitrary symbol, such as green, which must be converted into the specialist's confidence vocabulary. The TRANSLATOR also provides the ability to invert a value within a confidence set, thus allowing the system-builder to perhaps phrase a question more clearly, or allowing the same database question to be used by different classification specialists, taking advantage of the fact that the answer will be cached by the database the first time the question is asked.\footnote{For example, if there are two classification specialists, one of whom will establish when the answer to the question ``Is feature x present?'' is greater than or equal to neutral, and one who will establish when the answer is less than neutral, a way to encode these agents to make fullest use of database caching would be to have both their ESTABLISH-REJECT methods be {\bf (ask database ``Is feature x present?'')}, give the first an ESTABLISH-THRESHOLD of {\bf neutral}, and the second and ESTABLISH-THRESHOLD of {\bf somewhat-likely} and a TRANSLATOR of {\bf invert}. So, if the answer is neutral or greater, the first agent will establish, and if it is not, it will be inverted by the second agent, coming out with a value that is somewhat-likely or greater, and the second agent will establish. This design requires only one query to the user, and uses database caching to do the rest, as opposed to a design using two different questions, which requires two user queries. See the chapter on databases for more information.} A TRANSLATOR can be a request for a conversion between confidence sets, a request for inversion within a confidence set, or an arbitrary Lisp lambda. Once the specialist has gotten a confidence value from its ESTABLISH-REJECT method and used its TRANSLATOR to convert it into a form it can use, it will use that value to determine its status. To do that, it uses a threshold value, its {\bf ESTABLISH-THRESHOLD}. If the confidence value it has is {\it greater than or equal to} its ESTABLISH-THRESHOLD, the specialist may establish (whether or not it actually will establish depends on the additional factor of context, discussed below). To get the value to use as its ESTABLISH-THRESHOLD, the specialist first looks at its local establish-threshold. If that is non-nil, the value there is used as the ESTABLISH-THRESHOLD. If the local value is nil, the value of a global variable {\bf *CSRL-ESTABLISH-THRESHOLD*} is used, allowing global tuning of specialists. (To be used, the value of the threshold in question, as well as the confidence value to be compared, must both be in the ESTABLISH-CONFIDENCE-VOCABULARY of the specialist.) If the value gotten by applying its TRANSLATOR to the result of its ESTABLISH-REJECT method and then comparing it to its ESTABLISH-THRESHOLD is not high enough to allow it to establish, the specialist will then compare that value to its SUSPEND-THRESHOLD\footnote{Like the ESTABLISH-THRESHOLD, to get the value to use as its SUSPEND-THRESHOLD, the specialist first looks to see if it has a local SUSPEND-THRESHOLD. If so, it uses that. If not, it uses the value of the global variable {\bf *CSRL-SUSPEND-THRESHOLD*}.} to see if its status should be {\it suspended\/}. If the value is greater than or equal to its SUSPEND-THRESHOLD, then the specialist can suspend. If not, the specialist will have a status of {\it ruled-out\/}. At the level of the individual agent, the process of determining its status can be thought of as the agent simply comparing the result of its ESTABLISH-REJECT too see if it is greater than or equal to its ESTABLISH-THRESHOLD. If so, the agent will establish. If the specialist does not establish, it then would compare the result of its ESTABLISH-REJECT method to see if it is greater than or equal to its SUSPEND-THRESHOLD. If so, the agent will suspend, and if not it will rule-out. Actually, though, the process of establishing is more complex. The agent represents a hypothesis in a hierarchy of other hypotheses. For this hierarchy to work as a unit to solve a problem, the individual agents within the hierarchy must be consistent with each other. For example, if CANARY is a child of BIRD, it must usually be the case that BIRD is not an impossible hypothesis if CANARY is to be considered to be true (to establish). Therefore, the status of an individual agent is determined not only by the results of the threshold comparisons, but also by additional factors including {\bf CONTEXT}. To determine whether or not the specialist will actually establish (if the value returned by its ESTABLISH-REJECT method is above its ESTABLISH-THRESHOLD), first the system must ensure that the more general categories which contain the specialist's category are sufficiently likely, or at least not impossible. To do this, the classifier is asked to {\bf GET-CONTEXT} for the specialist. This simply goes through each of the specialist's parents and checks to see if they have established in this case. If a given parent has not run in this case, the system gets context for it, and if it has context, then the system attempts to establish it.\footnote{This is accomplished by simply invoking the parent with ESTABLISH, which will force the parent to get context without using a separate call to GET-CONTEXT.} To determine whether or not a given agent has context, they system uses the value of its PARENT-JOIN. If it's parent-join is AND (the default if not specified), this indicates that {\it all} of that specialist's parents must establish for it to establish. If the specialist's parent-join is OR, this indicates that at least one of its parents must establish for it to be able to establish. (This behavior is configurable. See the section on get-context, below.) If the specialist gets context, and its establish-recject value was above its establish-threshold, it establishes. If the specialist does not get context, and one (in the case of an AND node) or all (in the case of an OR node) or its parents RULE-OUT, it represents a category that has very low confidence in this situation (the category ruled out), and so the specialist will {\it rule-out}. The question of whether or not a specialist will establish or get-context can also be affected by that specialist's {\bf CHILD-JOIN}, or the {\bf CHILD-JOIN} of the specialist's parent (see discussion of CHILD-JOIN, below). If a specialist establishes, it's described as having a status of {\it established\/}. If a specialist does not establish (its confidence value is not greater than or equal to its establish-threshold), its status is determined by comparing its confidence value to another threshold, its {\bf SUSPEND-THRESHOLD} (once again, the SUSPEND-THRESHOLD can be specified locally on the specialist, or it will be taken from the value of {\bf *CSRL-SUSPEND-THRESHOLD*}). If the confidence value is greater than or equal to the SUSPEND-THRESHOLD, the classifier is called with {\bf GET-CONTEXT} to check the specialist's context (described above). As long as the specialist's context does not indicate that the specialist should rule out (GET-CONTEXT returns CONTEXT or NO-CONTEXT), the specialist is considered to have a status of {\it suspended\/}. If get context returns RULED-OUT, its status is {\it ruled-out\/}. If the confidence value is less than the SUSPEND-THRESHOLD, the specialist's status is {\it ruled-out}. (As before, the value of the threshold in question, as well as the confidence value to be compared, must both be in the ESTABLISH-CONFIDENCE-VOCABULARY of the specialist.) A status of {\it established} indicates that the hypothesis represented by the specialist actually matches the current situation, at least to the degree of certainty represented by the ESTABLISH-THRESHOLD. A status of {\it ruled-out} is used to indicate an impossible conclusion, one from which no refinements can be made (none of its subhypotheses could possibly be true). A status of {\it suspended} indicates an indeterminate state -- one from which refinement will not proceed right now, but one the user might want to come back and consider later if the space of possible hypotheses needs to be expanded. In order to maintain consistency in the hierarchy, if a specialist establishes, it will propagate that value back up the hierarchy using {\it stipulate\/}, forcing all of its ancestors to establish (see discussion of {\it stipulate} below). This will have no effect if the agent is using the standard method for get-context (where an agent establishes only if the correct combination of its parents (based on its parent-join) establishes), as all those nodes that would be established by the stipulation would have already had to have been established for the node to establish in the first place. However, it can have an effect if an alternate behavior for get-context is chosen. This behavior is controlled by the classifier, and can be turned off. (See discussion in the chapter on classifiers.) \paragraph{Refining} If a specialist {\it establishes\/}, it can then go on to {\it refine\/}. To do this, it examines its children (subcategories, or more specific versions of the specialist's category), to see whether they can establish (whether the more specific category does indeed match the situation). If a child establishes, it will usually go on to see if it can refine, this continuing the refining process recursively until the most specific category (or categories) that matches the situation is found. The exact algorithm used to refine (choosing how the children will be examined, and what categories will be followed up on, etc), is highly configurable by the system-builder, and is decribed in Section~\ref{user-defined refine forms}. Classification specialists, and the hierarchies of classification specialists represented by classifiers will actually perform different portions and combinations of the above process, depending on the message with which they are invoked. \subsubsection{Messages to classification-specialists} \begin{itemize} \item {\bf ESTABLISH-REFINE}-- when a classification specialist is invoked with establish-refine, it goes through essentially the entire process described above. It first attempts to determine its status (by the process known as establishing), and if it succeeds, it communicates with its children to refine the hypothesis in question. It eventually returns the portion of the hypothesis tree below and including the specialist that matches the situation. (It returns the names of all the hypotheses that establish in the portion of the hierarchy with the first specialist called as its top node.) If the classifier variable {\bf PROPAGATE} it T, the classifier will {\bf stipulate} the parents of any agent that establishes, thus maintaining the consistency of the hierarchy (this only has an effect if the context-type of the agent is not establish). \item {\bf ESTABLISH}-- a specialist invoked with establish simply tries to establish (determine its status), using its ESTABLISH-REJECT method and making sure it has context, returning T if it can, and nil otherwise. If the classifier variable {\bf PROPAGATE} it T, the classifier will {\bf stipulate} the parents of any agent that establishes, thus maintaining the consistency of the hierarchy (this only has an effect if the context-type of the agent is not establish). \item {\bf REFINE}-- a specialist invoked with refine will execute its refine method, calling its subs to see if they can establish and refine. The specialist will ignore its own status, and will not attempt to establish or get context. This allows the system-builder to follow up on any hypothesis she wishes to, even if that hypothesis is ruled out. \end{itemize} \subsubsection{Messages to classifiers, and functions using classifiers\label{get-context}} \begin{itemize} \item {\bf GET-CONTEXT}-- get-context is actually a function on its own, rather than an invoke message to a classifier.\footnote{This was done for implementation reasons, rather than due to a conceptual difference beteen GET-CONTEXT and the other messages to classifiers. It is noted here only for the benefit of system-builders who which to use it.} Get-context takes a classification specialist, and attempts to make sure that none of its ancestors represent impossible hypotheses in such a way that it would prevent this specialist's hypothesis from being possible in the current situation. Get-context does this by determining the status of each of the specialist's parents. If a given parent already has a status assigned to it for this case, that status value is used. If the parent has not yet run in this case (or has only been invoked with refine, which would run the parent but not determine its status), its status is determined by invoking that parent with ESTABLISH. Note that this establish message to the parent will recursively call get-context, so if the establish message to the parent returns T, this indicates that the parent both can establish and has context. For the case of a specialist with only one parent, the final determination of context is then simple. If the parent's status is established, that will allow the specialist to get context. If the parent's status is ruled-out, the specialist represents an impossible hypothesis, and the specialist will rule out. If the parent's status is suspended, the specialist will not get context, but it will not rule out. \paragraph{Parent-join} If the specialist has more than one parent, those parents can combine in two ways -- they may combine in an {\bf and} join, where {\bf all} of the specialist's parents must establish in order for the specialist to establish. This is the default. The parents may also combine in an {\bf or} join, where {\bf at least one} of the specialist's parents must establish in order for the specialist to establish. In the case of an and-join node, if any of the specialist's parents rule out, the specialist rules out. In the case of an or-join node, if all of the specialist's parents rule out, then the specialist rules out. \paragraph{Context-type} This behavior can be customized.\index{context-type=} The above behavior is the default, but it can be changed by using the {\bf CONTEXT-TYPE=} specifier in the agent definition. If this specifier is not given in the agent definition, the default is taken from the variable {\bf *CONTEXT-TYPE-DEFAULT*}, which defaults to {\bf establish}. A context-type value of {\bf establish} provides the above behavior. A given node cannot establish unless the correct combination of its parents also establish. A context-type value of {\bf suspend} changes this behavior slightly -- it allows a node to establish whenever the correct combination of its parents establishes {\bf or} suspends. (The only thing that prevents context is the presence of parents that are ruled-out, and then only in the appropriate combination.)\footnote{With a context-type of {\bf establish}, GET-CONTEXT will return {\bf got-context} if the node's parents establish in the right combination, {\bf no-context} if they don't but also don't rule out, and {\bf ruled-out} is one or all (depending on the PARENT-JOIN) of the parents rule out. With a context-type of {\bf suspend}, GET-CONTEXT will return {\bf got-context} if the node's parents establish or suspend in the right combination, and {\bf ruled-out} otherwise (the only case were a node does not get context is one in which it should rule out).} The third context-type value is {\bf none} -- this indicates that the specialist needs no context to establish, and context is not checked.\footnote{With a context-type of {\bf none}, GET-CONTEXT will issue a warning if called, and will return {\bf got-context}.} The specialist's status is determined solely by the result of its establish-reject method in combination with its threshold values. The context-type of an agent must be determined at the time of agent definition, and cannot be changed after that without redefining the agent. \paragraph{Child-join} The behavior of GET-CONTEXT can also be affected by the {\bf CHILD-JOIN=} specificator. If an agent has defined its children to represent exclusive alternatives (as indicated by a CHILD-JOIN of {\bf exclusive}), it will implement this exclusivity in its response to requests for context. This is easiest to understand if you visualize the process of getting context as a request from child to parent(s) for context, and a resulting granting or refusal of context by the parent. If a child asks its parent for context, and that parent's children are exclusive alternatives, the parent will first query all of its other children as to their status. If any of its other children have established, it will respond to the request for context with {\bf ruled-out}, indicating that the child is an impossible hypothesis. The child will then rule out. Note that this implementation has two important consequences. First, if an agent has exclusive children, the question of which child will be allowed to establish (thus forcing all other children to rule out) is determined by the order of requests for context. The first child who requests context who is able to establish will establish, and all others will be ruled out. This should be considered when designing refein-forms and other problem-solving tools which attempt to establish each child individually. Second, children of a parent with an exclusive child-join may have tentative statuses of {\it not-run} or {\it suspended} when their functional status is {\it ruled-out}, and so may respond to queries with not-run or suspended. Their status won't be ruled-out until they or one of their siblings attempts to get context when one of the siblings has already established. The fact that one of the children has established does not cause the ruled-out status to be propagated to the other siblings. The ruled-out status is only propagated when the next sibling asks for context, at which time it is propagated both to the sibling that requested context {\it and} to all other siblings of the child that established. \item {\bf STIPULATE}-- this message to the classifier takes as an argument a list of specialists and an optional {\it case} For each of those specialists, it sets that dragon's status to {\bf established}, by fiat, and sets the dragon's last case to {\it case\/}. If no {\it case} argument is given, the value of {\bf *current-case*} is used. It then goes recursively up through the specialists' parents, setting each of the parents' status to {\bf established} and case to {\it case\/}, if the current specialist has either only one parent or the parent-join is AND. (The recursive stipulate up the tree stops at any point where the current specialist's has multiple parents joined with OR, stipulating that specialist as established, but leaving its parents unchanged.) \item {\bf TELL-ME-ABOUT}-- this message to the classifier takes the name of a specialist in the hierarchy and gains all the information it can about that specialist -- it does it's problem-solving by ``jumping into the middle'' of the hierarchy. Essentially, it starts with the named specialist, and gets context for it, to see if it can extend the tree of established specialists from that agent to the top of the tree. Then it sees if the agent can establish, and if so, refines the agent to see how far below the agent in the tree it can get. Essentially, it finds that section of the hypothesis space that is either an ancestor or a dependent of the named agent that can establish. Doing a tell-me-about when the specialist in question is the top specialist in the classification hierarchy is equivalent to invoking that specialist with establish-refine. \item {\bf PROPAGATE}-- this variable controls propagation of status among items in a classifier's hierarchy. If it is T (the default), any agent that establishes will use {\bf stipulate} to ensure that all its parents establish also (thus maintaining consistency in the hierarchy, by ensuring that if a subhypothesis is considered true (established) its superhypotheses are also true (established)). This only has an effect on nodes whose context-type is not {\bf establish} (if the context-type is establish, this activity would have no effect as no agents would be changed -- all those that the stipulate would set to establish must have already been established for the system to get to that point in the first place). \end{itemize} \subsection{Return Values\label{return values}} The return value from a CSRL hierarchy is usually a list of the unique names of all the dragons that established. It is of the form: \begin{verbatim} (topdragon (sub1 subsub1 subsub2) sub2) \end{verbatim} {\it Topdragon} is the top of this portion of the tree. It's children are {\it sub1} and {\it sub2\/}. {\it Sub1} has parentheses around it (it is a list, rather than an atomic symbol) because it has children - the parentheses will be there, whether the children establish or not. {\it Sub1\/}'s name is followed by the names if its children who established. If any of their names have parentheses around them (if they are lists), it indicates that they have children. If any names follow the first inside the parentheses, (as {\it subsub1} and {\it subsub2} follow {\it sub1\/}), it indicates that those children established. {\it Sub2} in the above example is the second child of topdragon to establish, and it has no children (indicated by the lack of parentheses surrounding its name (the fact that it is an atomic symbol, rather than a list)). %====================================================================== \part{Building systems with the Toolset: Programming with communities of agents} %====================================================================== %--------------------------------------------------------------------- \chapter{Defining Agents} Currently, all types of agents used by the Toolset are defined by lisp forms written in text files. In later implementations, there will be a window and menu based editor for defining agents. % Section------------------------------------------------------------- \section{Notation\label{notation}} In describing syntax we use the following notation: \begin{tabbing} 123456\=123456789012345\=123\= \kill \\ \>{\bf BOLDFACE}\>denotes literals, i.e., expressions which stand for themselves. \\ \>{\it italics\/}\>denotes meta variables, i.e., expressions which stand for pieces of code. \\ \>[ ]\>indicate optional items. \\ \>( )\>stand for themselves. \\ \>|\>separates syntactic alternatives. \\ \>\ldots\>indicates a series, e.g., {\it form form\/} \ldots\ means one or more forms. \\ \>::=\>indicates a production, i.e., the thing on the left side can take the \\ \>\>\>form on the right side. \\ \\ \end{tabbing} Capitalization is not significant except in strings. %--------------------------------------------------------------------- \section{Forms for defining agents} There is one form for defining each type of agent (recognition agents, idb's, classification-specialists, and classifiers). These forms are described individually below. The forms for defining each type of agent look basically like: \begin{tabbing} 123456\=123456\=12345678\= \kill \\ \>({\bf DEFINE-{\it agent-type\/}} {\it unique-name body}) \\ \\ \>\>{\it unique-name} may be any valid Common Lisp symbol name. This name will differentiate\\ \>\>\>the dragon from all other dragons in the system. \\ \\ \>\>{\it body} \>::= {\it specifier specifier ...} \\ \>\>{\it specifier}\> ::= {\it (keyword otherstuff)} \\ \end{tabbing} Within the body of an agent definition, the order of specifiers is not significant, but within a specifier the order of symbols may be significant. Some specifiers are mandatory, and the rest are optional. A keyword introducing a specifier is always a token ending in ``=.'' The notation used in the following sections is described in section~\ref{notation}. There are many different specifiers, most of which are specific to particular types of agents. However, there is also a group of specifiers that can be used in any agent definition, with any type of defining form. These specifiers are described in the next section. % Section------------------------------------------------------------- \section{Specifiers Common to all Dragon Types}\label{general dragon specifiers} \index{display-name=} \begin{tabbing} 1234\= \kill \\ ({\bf DISPLAY-NAME=} {\it string\/}) \\ \end{tabbing} This specifies a name, not necessarily unique, used for interaction with the knowledge engineer. If this is not supplied, it will be assumed to be the same as the print name of the unique-name. \index{associated-concepts=} \begin{tabbing} 1234\=123456\=123456\= \kill \\ ({\bf ASSOCIATED-CONCEPTS=} {\it symbol symbol\/}\ldots) \\ \\ \>\>{\it symbol\/} may be any valid common Lisp symbol; its use as a retrieval key will not restrict\\ \>\>\>other uses. \end{tabbing} The system maintains a collection of ``associational concepts,'' or {\bf ``a-concepts,''} a set of symbols that can be used for associative retrieval. The idea is that a knowledge-based system might contain several different dragons, of differing functions and perspectives, that all relate to some central idea. For example a medical system might contain a recognition agent for hepatitis which looks at the data from the point of view of clinical signs and symptoms, another recognition agent for hepatitis that depends on lab tests, a data-abstraction dragon that checks the patient's record for a history of hepatitis, and a therapy planner that specializes in hepatitis. In the interests of making systems easier to build and maintain, the GT Toolset maintains a way of linking disparate fragments of a system together by way of a single a-concept. Which a-concepts a particular dragon is linked with are declared by the ASSOCIATED-CONCEPTS= specifier. There are two utility functions available for working with associated concepts: \index{return-associated-concepts} \begin{tabbing} 123456\=123456\= \kill \\ \>({\bf return-associated-concepts} {\it dragon-name\/}) \\ \>\>this returns a list of the concepts associated with the dragon named {\it dragon-name\/}. \\ \>\>Ex. ({\bf return-associated-concepts} 'foo) \\ \\ \>({\bf return-associated-dragons} {\it concept\/}) \\ \>\>this returns a list of the dragons associated with the concept {\it concept\/}. \\ \>\>Ex. ({\bf return-associated-dragons} 'liver) \\ \end{tabbing} \index{return-associated-concepts} \index{tool-user-slots=} \begin{tabbing} 1234\= \kill \\ ({\bf TOOL-USER-SLOTS=} {\it slot-spec slot-spec\/} \ldots) \\ \end{tabbing} This enables the knowledge engineer to use the dragon as a frame or record in addition to its other uses. Values of slots can be written to, and read, in actions and abilities set with the specifiers: CONTROL-ADDITIONS=, TRACING-CONTROL-ADDITIONS=, AFTERWARDS=, MATCH-ACTION=, and NO-MATCH-ACTION=. Status: In Fafner anything the user supplies after the keyword can be read with \begin{tabbing} 123456\= \kill \\ \>({\bf slot-value} {\it unique-name\/} {\bf 'tool-user-slots}) \\ \end{tabbing} and written with \begin{tabbing} 123456\= \kill \\ \>({\bf setf} ({\bf slot-value} {\it unique-name\/} {\bf 'tool-user-slots}) {\it value-to-store\/}). \\ \end{tabbing} A smoother interface and more elaborated slot-frame functionalities will be supported eventually. \index{afterwards=} \begin{tabbing} 1234\= \kill \\ ({\bf AFTERWARDS=} {\it action action\/} \ldots) \\ \end{tabbing} Final things to do after finishing with other activities. The specified actions will occur after {\em each\/} invocation of the dragon, regardless of which verb has been used. In Fafner an action is assumed to be a Lisp form to evaluate, and if more than one action is specified, they will be evaluated inside a progn. This specifier is optional. % Subsection------------------------------------------------------------- \subsection{Responding to messages}\label{controllers}\index{controllers} As discussed in Section~\ref{messages} different types of dragons respond to different messages. Recognition agents perform their primary recognition tasks in response to messages with the verb {\bf JUDGE}; intelligent databases do their principal problem solving in response to {\bf ASK}; and classification specialists perform various parts of their problem solving in response to {\bf ESTABLISH}, {\bf REFINE}, or {\bf ESTABLISH-REFINE}. The responses to these messages (and others) are defined by the system and installed in the dragon at compile time. However, it is possible for the user to either override one of these default actions, or to define a response to an entirely new verb. Each dragon has a {\bf controller} which directs its activities, its ways of responding to messages. All but FREE-FORM recognition agents come with built in controllers. Dragon subtypes (except FREE-FORM recognition agents) can be thought of as ``shells'' where the knowledge-system builder, after choosing the reasoning task to be performed (by choosing the dragon type) and choosing the mechanism by which to perform it (by choosing the subtype), needs only to fill in the domain knowledge, and her work is done. When the dragon receives a message, it already knows what to do in order to respond to it, based on knowledge-use abilities that are built into its controller. Yet sometimes built-in abilities will not be enough. Perhaps the domain knowledge is only available in a form that is not supported by any of the built-in mechanisms, even though the reasoning task to be accomplished is supported by some dragon type. In this case the knowledge engineer can choose the free-form subtype, and provide her own mechanism for responding to messages which call for that reasoning task. For example the task might clearly be a {\em recognition\/} one, and yet none of the supported mechanisms are adequate to represent the domain knowledge, so she specifies a FREE-FORM recognition agent and writes her own way of responding to a JUDGE message. Or, to allow the Toolset to interact with any database system, she could redefine the ASK message in an IDB in such a way that allows the IDB to access the desired information (in fact, given a Lisp/C interface, one could use this technique to use information from almost any source). Alternatively, she may wish to extend a new ability to a dragon (FREE-FORM or not) beyond those that are invoked by the primary verbs. In this case she will specify a new verb and way of handling it, or she will specify a new way of handling a default verb. The vehicle for expressing new abilities is the CONTROL-ADDITIONS= specification. For a FREE-FORM recognition agent, a CONTROL-ADDITIONS= specification that defines a way of handling the verb {\bf JUDGE}\footnote{As well as any other verbs the user wishes to define.} is mandatory; for other dragon subtypes it is optional. {\bf NOTE:} If the system builder defined a {\bf JUDGE} mechanism for any type of recognition agent\footnote{This does not apply to classifiers, classification specialists, IDB's, etc.} other than a FREE-FORM, that recognition agent will be converted into a FREE-FORM. The syntax for a CONTROL-ADDITIONS= specification is: \index{control-additions=} \begin{tabbing} 123456\=123\=123456\=123456\= \kill \\ ({\bf CONTROL-ADDITIONS=} \\ \>\>({\it verb (args) form form\/} \ldots) ({\it verb (args) form form\/} \ldots) \ldots) \\ \\ \>\>\>{\it verb\/} is the verb this action will be performed in response to.\\ \>\>\>{\it args\/} are the names to which the arguments to this action will be bound.\\ \>\>\>{\it form\/} is any Common Lisp form. It will be evaluated in a lexical context that allows it to\\ \>\>\>\>refer to the inherited and tool-user supplied slots appropriate to the dragon type. \\ \end{tabbing} We anticipate that eventually fancier dragon editors will assist the knowledge engineer in making small changes to built-in abilities by letting the user edit changes to the built-in parts of a controller, rather than having the knowledge engineer write the controller from scratch. \index{tracing-control-additions=} \begin{tabbing} 1234\=123\= \kill \\ ({\bf TRACING-CONTROL-ADDITIONS=} \\ \>\>({\it verb (args) form form\/} \ldots) ({\it verb (args) form form\/} \ldots) \ldots) \end{tabbing} A dragon that has been loaded into Lisp is always in one of two states: either tracing is enabled, or it is not. The specification TRACING-CONTROL-ADDITIONS= is for defining tracing forms for non-built-in abilities. \index{arguments=} \begin{tabbing} 1234\= \kill \\ ({\bf ARGUMENTS=} ({\it (verb (args)) (verb (args))\/} \ldots))\\ \end{tabbing} The ARGUMENTS= specifier is for declaring arguments that will be passed to a dragon each time it is invoked. This specifier is used only for introducing arguments to be used with built-in abilities; arguments for user-supplied abilities are declared within the CONTROL-ADDITIONS= specifier. ARGUMENTS= is an optional specifier; the default will be that arguments are not used. % Subsection------------------------------------------------------------- \subsection{Documentation and Explanation Specifiers} \index{specific-function=} \begin{tabbing} 1234\= \kill \\ ({\bf SPECIFIC-FUNCTION=} {\it string\/}) \\ \end{tabbing} A description of the function of the particular dragon, e.g., ``to evaluate the clinical evidence for hepatitis.'' This is an optional specifier. \index{rationale=} \begin{tabbing} 1234\= \kill \\ ({\bf RATIONALE=} {\it string\/}) \\ \end{tabbing} A comment explaining non-obvious aspects of how the knowledge is structured, e.g., why feature evaluations are ordered the way they are. This is an optional specifier, but the use of it is especially encouraged. \index{expert=} \begin{tabbing} 1234\= \kill \\ ({\bf EXPERT=} {\it name\/}) \\ \end{tabbing} {\it name\/} is a string. Warning! The expert's name may be used in a justification by authority for the knowledge, as in ``Because John Svirbely, M.D. said so.'' This is an optional specifier. \index{citations=} \begin{tabbing} 1234\= \kill \\ ({\bf CITATIONS=} {\it citation citation\/} \ldots) \\ \end{tabbing} A paper authority. Optional specifier. In Fafner a citation is a string. \index{disclaimer=} \begin{tabbing} 1234\= \kill \\ ({\bf DISCLAIMER=} {\it string\/}) \\ \end{tabbing} An optional specifier. \index{other-knowledge-sources} \begin{tabbing} 1234\= \kill \\ ({\bf OTHER-KNOWLEDGE-SOURCES=} {\it string\/}) \\ \end{tabbing} Optional. \index{author=} \begin{tabbing} 1234\= \kill \\ ({\bf AUTHOR=} {\it name\/}) \\ \end{tabbing} The one who is responsible for capturing and recording the knowledge. May be used against you in court! Used in justifications like, ``Because Kathy Johnson said that John Svirbely said so.'' This is a MANDATORY specifier. \index{creation-date=} \begin{tabbing} 1234\= \kill \\ ({\bf CREATION-DATE=} {\it date\/}) \\ \end{tabbing} Optional. \index{last-modification-date=} \begin{tabbing} 1234\= \kill \\ ({\bf LAST-MODIFICATION-DATE=} {\it date\/}) \\ \end{tabbing} Optional. \index{hypertext-link=} \begin{tabbing} 1234\= \kill \\ ({\bf HYPERTEXT-LINK=} {\it pointer\/}) \\ \end{tabbing} Status: Not implemented yet. %--------------------------------------------------------------------- \chapter{Defining Recognition Agents} % Section------------------------------------------------------------- \section{Defining Recognition Agents} The function for defining a recognition agent is: \begin{tabbing} 123456\=123456\=12345678\= \kill \\ \>({\bf DEFINE-RECOGNITION-AGENT}{\it unique-name ra-type body\/}) \\ \\ \>\>{\it unique-name\/} may be any valid Common Lisp symbol name. This name will differentiate \\ \>\>\>the dragon from all other dragons in the system. \\ \>\>{\it ra-type\/} a recognition agent subtype, one of:\\ \>\>\>{\bf DISCRETE-PATTERN-RECOGNITION-AGENT}, \\ \>\>\>{\bf MATCH-1-RECOGNITION-AGENT}, or \\ \>\>\>{\bf FREE-FORM-RECOGNITION-AGENT} \\ 123456\=123456\=1234567890\=123456\= \kill \>\>{\it body\/} \>::= {\it specifier specifier\/} \ldots \\ \>\>{\it specifier\/} \>::= ({\it keyword otherstuff\/}) \\ \end{tabbing} \index{define-recognition-agent} Within the body of an agent definition the order of specifiers is not significant, but within a specifier the order of symbols may be significant. Some specifiers are mandatory, others are optional, depending on the dragon type and subtype. A keyword introducing a specifier is always a token ending in {\bf ``=''}. % Section------------------------------------------------------------- \section{Specifiers for All Types of Recognition Agents} Recognition agents are dragons, so the specifiers which apply in general to dragons apply also to recognition agents. The following specifiers may (and sometimes must) be supplied for any type of recognition agent: \index{output-confidence-vocabulary=} \begin{tabbing} 123456\= \kill \\ ({\bf OUTPUT-CONFIDENCE-VOCABULARY=} {\it confidence-set\/}) \\ \end{tabbing} The output of a recognition agent is a symbol in some vocabulary expressing a degree of confidence that the concept has been recognized. Several alternative vocabularies (confidence sets) are supplied by the system, and there are facilities for users to define their own confidence sets (see Chapter~\ref{confidence sets}, Confidence Sets), and there are facilities for automatic conversion between confidence sets. The system-supplied confidence sets are: {\bf USUAL-9-VAL}, {\bf USUAL-3-VAL}, {\bf USUAL-2-VAL}, and {\bf USUAL-CONTINUOUS-VAL}. The default output confidence vocabulary is {\bf USUAL-9-VAL} if none is supplied. See Chapter~\ref{confidence sets} for more information on confidence sets. \index{features=} \label{features} \begin{tabbing} 1234\= \kill \\ ({\bf FEATURES=} {\it feature feature\/} \ldots) \\ \end{tabbing} A recognition agent's features are the specific inputs that it relies on to make its judgments. {\it feature\/} may be one of the following eight types currently supported: an invocation of another recognition agent, a query to an IDB, a request to the user for information, an invocation of a dragon which has special abilities supplied by the knowledge system builder, the value of a Lisp variable which the system builder has set up, the value of a Lisp form, or an explicit literal symbol or number. These are specified as follows: \begin{tabbing} 123456\=123456\=123456\= \kill {\bf {\it features} ::= }\\ \\ \>({\bf JUDGE} {\it recognition-agent\/} [({\it arg arg\/} \ldots)] [{\it confidence-set\/}]) \\ \\ \>\>{\it confidence-set\/} specifies the confidence vocabulary that is expected for the input. \\ \>\>\>If not supplied, the default will be {\bf USUAL-9-VAL}. \\ \\ \>| ({\bf ASK} {\it database question answer-type\/}) \\ \\ \>\>{\it database\/} is the unique-name of an IDB dragon. \\ \>\>{\it question\/} is a a string. \\ \>\>{\it answer-type\/} either the name of a confidence set, indicating that a symbol \\ \>\>\>from that confidence vocabulary is expected, or {\bf SYMBOL}, or {\bf NUMBER}.\\ \>\>\>The default is {\bf USUAL-3-VAL}, i.e., the default presumption is that queries to a \\ \>\>\>database will produce an answer from the set {\bf \{YES NEUTRAL NO\}}. \\ \\ \>| ({\bf ASK-USER} {\it question-string answer-type\/}) \\ \\ \>\>{\it question-string\/} should end with ``?'' if appropriate. It will not be supplied by the system. \\ \>\>{\it answer-type\/} as above for database queries, including the default to {\bf USUAL-3-VAL}. \\ \\ \>| ({\bf INVOKE} {\it dragon} '{\it user-verb\/} ['{\it arg} '{\it arg\/} \ldots] '{\it answer-type\/}) \\ \\ \>\>{\it user-verb\/} is the verb the user associates with the ability when it is established with the\\ \>\>\>{\bf CONTROL-ADDITIONS=} specifier. \\ \>\>{\it answer-type\/} is as above for database queries, but it is MANDATORY.\\ \>\>{\it arg}\ldots are the arguments to the controller for that verb, if any are required. \\ \>\>\>They must follow the standard Lisp quoting procedure for arguments to a function. \\ \\ \>\>This is how the knowledge engineer specifies invoking a dragon of arbitrary type \\ \>\>for which she has supplied abilities using the {\bf CONTROL-ADDITIONS=} specifier. \\ \\ \>| {\it symbol\/} \\ \\ \>\>{\it symbol\/} can be any Common Lisp symbol, unquoted. It will be treated as a literal, and can only\\ \>\>be tested to see if it is EQ to another symbol.\\ \\ \>| {\it number\/} \\ \\ \>\>{\it symbol\/} can be any number. It will be used directly for numeric comparisons.\\ \\ \>| ({\it answer-type} {\it lisp-form})\\ \\ \>\> {\it lisp-form} can be any Common Lisp form which, when evaluated, will return \\ \>\>a symbol, a number, or a member of a valid confidence set. {\it answer-type} should be SYMBOL, \\ \>\>NUMBER, or the name of the confidence set of which the return value is a member. For instance, \\ \>\>(number (/ 47 (+ 56.13 7.3))), (symbol (cadr '(foo bar baz))), (usual-3-val (maximum-value 'usual-3-val)) \\ \\ \>| ({\it answer-type} {\it lisp-variable\/})\\ \\ \>\> {\it lisp-variable} is the name of a global Lisp variable. The variable will be evaluated to get \\ \>\>the value of the feature. That value must be of the type {\it answer-type}, which may be \\ \>\>any of the types mentioned above in the description of lisp forms as features. \\ \\ \>\>\>This is the knowledge engineer's opportunity to provide an input to the recognition agent \\ \>\>\>from outside the constructs provided by the toolset. \\ \\ \end{tabbing} These eight are the only types of features that are supported in RA. \index{output-destination=} \begin{tabbing} 1234\= \kill \\ ({\bf OUTPUT-DESTINATION=} {\it dragon\/} | {\it list-of-dragons\/}) \\ \end{tabbing} If this is supplied, the output, in the form of a {\bf RESULT} message, will be directed to the specified dragon or dragons. If this is not supplied, the result will go to the dragon that invoked the recognition agent. This specifier is not currently used by the system. % Section------------------------------------------------------------- \section{Specifiers for Discrete Pattern Recognition Agents} Note that the FEATURES= specifier must be supplied for all types of recognition agents. A feature may be any of the five types: invocation of another recognition agent, question to an IDB, query to the user, dragon invocation explicitly using the INVOKE function, or the value of a Lisp variable set up by the system builder. \begin{tabbing} 1234\= \kill \\ ({\bf PATTERN=} {\it test test\/} \ldots) \\ \end{tabbing} \index{pattern=} Precisely as many tests must be specified as there are features for this particular agent. The first test will be applied to the first feature (by way of the transform), and the second to the second, and so on. Tests always return either T or NIL. Certain tests are only appropriately applied to certain types of input. The system expects certain types of features to return certain types of answers. This can be overridden with the answer-type argument for the feature specification. However, only like items can be compared by the system, so a test whose input is a feature returning a number must only compare that feature to other numbers (or to members of the same confidence set for confidence values, or to symbols for a symbol-returning feature). After a recognition agent invocation, by default a confidence value is expected. The confidence set of the answer is determined by either the default type for the invocation type (database invocations with ask return usual-3-val) or the answer-type specification in the feature definition, in combination with any possible changes in confidence set brought about by a transform application. An answer-type of SYMBOL or NUMBER will cause the system to expect the feature to return a symbol or a number. The items to be compared in the test specification must be consistent with the type of the answer returned by the feature. For testing a confidence value: \begin{tabbing} 123456\=123456\=123\=123456789012345678901234567890123\= \kill \>{\bf {\it test\/} ::=} \\ \>\>\>{\it confidence-symbol\/} \>Interpreted as EQ {\it confidence-symbol\/}. \\ \>\>|\>({\bf RANGE} {\it conf-symbol conf-symbol\/}) \>inclusive \\ \>\>|\>({\bf GT} {\it confidence-symbol\/}) \>greater than \\ \>\>|\>({\bf GE} {\it confidence-symbol\/}) \>greater than or equal to \\ \>\>|\>({\bf LT} {\it confidence-symbol\/}) \>less than \\ \>\>|\>({\bf LE} {\it confidence-symbol\/}) \>less than or equal to \\ \>\>|\>{\bf ?} \>always succeeds\\ \>\>|\>{\bf *} \>always succeeds \\ \end{tabbing} These tests are valid for any feature returning a member of a particular confidence set. {\it Confidence-symbol} may be either a member of that confidence set, or the name of a global variable, which, when evaluated at run-time, will return a member of that confidence set, or a lisp form, which, when evaluated at run-time, will return a member of that confidence set. For testing a symbol (if the feature returns a value of type SYMBOL): \begin{tabbing} 123456\=123456\=123\=1234567890123457890\= \kill \>{\bf {\it test\/} ::=} \\ \>\>\>{\it symbol\/} \>Interpreted as EQ {\it symbol\/}. \\ \>\>|\>({\it list-of-symbols\/}) \>Interpreted as MEMBER {\it list\/}. \\ \>\>|\>{\bf ?} \>always succeeds\\ \>\>|\>{\bf *} \>always succeeds \\ \end{tabbing} Note that {\it symbol\/} above is not EVAL'd. For testing a number (if the feature returns a value of type NUMBER): \begin{tabbing} 123456\=123456\=123\=12345678901234567890123456789012345678\= \kill \>{\bf {\it test\/} ::=} \\ \>\>\>{\it number\/} \>Interpreted as = {\it number\/}. \\ \>\>|\>({\bf RANGE} {\it lower-number higher-number\/}) \>inclusive \\ \>\>|\>({\bf GT} {\it number\/}) \>greater than \\ \>\>|\>({\bf GE} {\it number\/}) \>greater than or equal to \\ \>\>|\>({\bf LT} {\it number\/}) \>less than \\ \>\>|\>({\bf LE} {\it number\/}) \>less than or equal to \\ \>\>|\>{\bf ?} \>always succeeds\\ \>\>|\>{\bf *} \>always succeeds \\ \end{tabbing} The {\it number} specification for these tests may be either an actual number, or a global variable or lisp form which, when evaluated at run-time, will return a number. After input from a user-supplied variable, any Lisp form using the variable may be used as a test. The knowledge engineer should take care to ensure that the form will always return T or NIL. The user may supply a ? or a * as a test, which always returns a value of T and thus counts towards the success-threshold. Additionally, the user may supply a bare symbol as a test, which will be interpreted as EQ {\it symbol\/}. \index{transforms=} \begin{tabbing} 1234\=123456\=123456\=123456\= \kill \\ ({\bf TRANSFORMS=} {\it transform transform\/} \ldots) \\ \\ \>{\bf {\it transform\/} ::=}\\ \\ \>\>({\bf CONVERT-TO} {\it confidence-set\/}) \\ \\ \>\>\>Default conversion methods are provided for the built-in confidence sets. \\ \\ \>\>| ({\bf THRESHOLD-AT} {\it number\/}) \\ \\ \>\>\>Used for converting from continuous to binary confidences.\\ \>\>\>The knowledge engineer supplies the cutoff value. \\ \\ \>\>\>| ({\bf INVERT}) \\ \\ \>\>\>| ({\bf NO-OP}) \\ \\ \>\>\>| ({\it transform transform\/} \ldots) \\ \end{tabbing} Non-NO-OP transforms are appropriate only after confidence-symbol inputs. Specifying transforms is optional. If none are specified, all will default to NO-OP. If transforms are specified, their number must be the same as the number of features. \index{success-threshold=} \begin{tabbing} 1234\= \kill \\ ({\bf SUCCESS-THRESHOLD=} {\it positive-integer\/})\\ \end{tabbing} The number of tests that must succeed in order for the pattern to match successfully. Must be an integer between 1 and the number of tests, inclusive. The default is the number of tests, i.e., that they all must succeed. \index{match-confidence=} \index{no-match-confidence=} \begin{tabbing} 1234\= \kill \\ ({\bf MATCH-CONFIDENCE=} {\it confidence-setting-action\/}) \\ \\ ({\bf NO-MATCH-CONFIDENCE=} {\it confidence-setting-action\/}) \end{tabbing} Determines the confidence values that the recognition agent will produce if its pattern matches, or does not match, respectively. MATCH-CONFIDENCE= must be supplied. If NO-MATCH-CONFIDENCE= is not supplied, it will be defaulted to NEUTRAL.\footnote{Note that if the confidence set used by the agent does not have NEUTRAL as a member and has not specified a valid NEUTRAL-EQUIVALENT (see the chapter on confidence-sets), the user must specify these values as the default of NEUTRAL will have no meaning.} \begin{tabbing} 1234\=123456\=123456\=1234\= \kill \\ \>{\bf {\it confidence-setting-action\/} ::=} \\ \\ \>\>{\it confidence-symbol\/} \\ \\ \>\>| ({\bf JUDGE} {\it recognition-agent etc.\/}) \\ \\ \>\>| ({\bf ASK} {\it intelligent-database question answer-type\/}) \\ \\ \>\>| ({\bf ASK-USER} {\it question confidence-set\/}) \\ \\ \>\>| ({\it form\/}) \\ \>\>\>{\it form\/} is a user-supplied Lisp form that will return \\ \>\>\>\>a confidence symbol in the appropriate vocabulary. \\ \\ \>\>| ({\bf INVOKE} {\it dragon} '{\it user-verb\/} ['{\it arg} '{\it arg\/} \ldots] '{\it confidence-set\/}) \\ \end{tabbing} The user may specify the action to be taken as a result of either a matching pattern or the absence of a matching pattern. \begin{tabbing} 1234\= \kill \\ ({\bf MATCH-ACTION=} {\it action\/}) \\ \\ ({\bf NO-MATCH-ACTION=} {\it action\/}) \end{tabbing} \index{match-action=} \index{no-match-action=} User-supplied things to do if the pattern matches, or doesn't match, respectively. An {\it action\/} is a Lisp form (or forms) to evaluate. These are optional specifiers. % Section------------------------------------------------------------- \section{Specifiers for Match-1 Recognition Agents} Match-1 recognition agents are similar to discrete pattern recognition agents, except that they will consider more than one pattern, seeking a match. Thus specifiers for transforms and tests are the same as for discrete pattern recognition agents. The FEATURES= specifier, described in section~\ref{features}, is mandatory. \begin{tabbing} 1234\= \kill \\ ({\bf PATTERNS=} {\it pattern-rule pattern-rule\/} \ldots)\\ \end{tabbing} \index{patterns=} An ordered set of patterns to be matched against the features, each pattern accompanied by a way of setting a confidence value. For each pattern one or more actions may be specified to be performed if the pattern matches. These actions are optional. Also a success threshold may be specified, in which case the pattern will be considered to be matched if at least that many tests succeed. The form is as follows, where {\bf ``=>''} is a literal. \begin{tabbing} 123456\=123456\=123456\=1234\= \kill \\ \>{\bf {\it pattern-rule\/} ::=}\\ \>\> (({\it pattern\/}) [{\it success-threshold\/}] {\bf =>} {\it confidence-setting-action\/} [{\it action action}\ldots]) \\ \\ \>\>{\it pattern} is as described above for discrete pattern recognition agents' PATTERN= \\ \>\>\>specification. \\ \\ \>\>{\it success-threshold} is as described above for discrete pattern recognition agents'\\ \>\>\> SUCCESS-THRESHOLD= specification. \\ \\ \>\>{\it confidence-setting-action\/} is as described above for discrete-pattern recognition agents'\\ \>\>\> MATCH-CONFIDENCE= specification. \\ \\ \>\>{\it action action}\ldots is the action to be performed if this pattern succeeds.\\ \>\>\>This is similar to the MATCH-ACTION= specification for discrete pattern recognition agents,\\ \>\>\>but allows the user to specify a different MATCH-ACTION for each pattern \\ \>\>\> that might match. \\ \end{tabbing} Patterns must be specified for a Match-1 recognition agent. If only one pattern is specified, the agent is equivalent to a discrete pattern recognition agent. \begin{tabbing} 1234\= \kill \\ ({\bf NO-MATCH-CONFIDENCE=} {\it confidence-setting-action\/})\\ \end{tabbing} \index{no-match-confidence=} The resulting confidence value if no pattern matches; an otherwise clause. The default, if no specification is made, will be NEUTRAL. The {\it confidence-setting-action} is described in the description of this specifier for discrete pattern recognition agents. \begin{tabbing} 1234\= \kill \\ ({\bf NO-MATCH-ACTION=} {\it action\/})\\ \end{tabbing} \index{no-match-action=} Optional action to perform if no pattern matches. This is a Lisp form (or forms, which will be wrapped inside a progn) to evaluate. % Section------------------------------------------------------------- \section{Specifiers for Free-Form Recognition Agents} Free form recognition agents can use any specifier discussed above for all dragons, all recognition agents, or any specific type of recognition agent. The only mandatory specifier is CONTROL-ADDITIONS=, which is summarized here for convenience. For a free-form recognition agent it is necessary to specify a way to handle messages which have the {\bf JUDGE} verb. The vehicle for this specification is the CONTROL-ADDITIONS= specifier.\footnote{For more explanation of controllers, see Section~\ref{controllers}.} The syntax is: \begin{tabbing} 1234\=123456\= \kill \\ ({\bf CONTROL-ADDITIONS=} \\ \>\>({\bf JUDGE} {\it (args) form form\/} \ldots) ({\it verb (args) form form\/} \ldots) \ldots) \\ \end{tabbing} \index{control-additions=} To supply tracing versions of these control additions: \begin{tabbing} 123456\=123456\= \kill \\ ({\bf TRACING-CONTROL-ADDITIONS=} \\ \>\>({\bf JUDGE} {\it (args) form form\/} \ldots) ({\it verb (args) form form\/} \ldots) \ldots) \end{tabbing} % Section------------------------------------------------------------- \section{Examples} \subsection{Example discrete-pattern-recognition-agent} \begin{verbatim} (DEFINE-RECOGNITION-AGENT CALL-PEDIATRICIAN-FEVER DISCRETE-PATTERN-RECOGNITION-AGENT (AUTHOR= "John R. Josephson") (CREATION-DATE= "24 Jan 1988") (LAST-MODIFICATION-DATE= "24 Jan 1988") (ASSOCIATED-CONCEPTS= FEVER CALL-DOCTOR) (FEATURES= (ASK PATREC "CHILD ?" USUAL-2-VAL) (ASK PATREC "FEVER TODAY ?" USUAL-3-VAL ) (JUDGE COMMON-VIRAL-INFECTION USUAL-9-VAL)) (PATTERN= T YES (LE UNLIKELY)) (RATIONALE= "Call the doctor if there is fever, and if it is unlikely that the child has a common viral infection.") (OUTPUT-CONFIDENCE-VOCABULARY= USUAL-3-VAL) (MATCH-CONFIDENCE= YES) (NO-MATCH-CONFIDENCE= NEUTRAL) (EXPERT= "Jack G. Shiller, M.D.") (CITATIONS= "Shiller, J.D. Childhood Illness: A Common Sense Approach, Stein and Day, New York, 1972, p.37")) \end{verbatim} \subsection{Example match-1-recognition-agent} \begin{verbatim} (DEFINE-RECOGNITION-AGENT COMMON-VIRAL-INFECTION MATCH-1-RECOGNITION-AGENT (AUTHOR= "John R. Josephson") (CREATION-DATE= "24 Jan 1988") (LAST-MODIFICATION-DATE= "24 Jan 1988") (ASSOCIATED-CONCEPTS= VIRAL-INFECTION COMMON-INFECTION) (OUTPUT-CONFIDENCE-VOCABULARY= USUAL-9-VAL) (FEATURES= (ASK PATREC "ACHY-EYES THIS-ILLNESS ?" USUAL-3-VAL ) (ASK PATREC "FEVER THIS-ILLNESS ?" USUAL-3-VAL ) (ASK PATREC "ACHINESS THIS-ILLNESS ?" USUAL-3-VAL ) (ASK PATREC "RUNNY-NOSE THIS-ILLNESS ?" USUAL-3-VAL ) (ASK PATREC "SCRATCHY-THROAT THIS-ILLNESS ?" USUAL-3-VAL ) (ASK PATREC "SLIGHTLY-UPSET-STOMACH THIS-ILLNESS ?" USUAL-3-VAL ) (ASK PATREC "TIREDNESS THIS-ILLNESS ?" USUAL-3-VAL ) (ASK PATREC "MALAISE THIS-ILLNESS ?" USUAL-3-VAL ) (ASK PATREC "HEADACHE THIS-ILLNESS ?" USUAL-3-VAL )) (PATTERNS= ((YES ? ? ? ? ? ? ? ?) => LIKELY) ((? YES YES YES YES YES YES YES YES ) 5 => VERY-LIKELY) ((? YES YES YES YES YES YES YES YES ) 4 => LIKELY) ((? YES ? YES ? ? ? ? ? ) => LIKELY) ((? YES YES YES YES YES YES YES YES ) 3 => SOMEWHAT-LIKELY) ((? YES YES YES YES YES YES YES YES ) 2 => NEUTRAL)) (NO-MATCH-CONFIDENCE= UNLIKELY) (RATIONALE= "Achy eyes almost certainly means flu or grippe. Otherwise confidence depends on how many of the symptoms are present. Fever and runny nose alone are sufficient to make the diagnosis likely.") (EXPERT= "Jack G. Shiller, M.D.") (CITATIONS= "Shiller, J.D. Childhood Illness: A Common Sense Approach, Stein and Day, New York, 1972, p.37") ) \end{verbatim} \subsection{Example free-form-recognition-agent -- the *USER* dragon\label{*user*}} \begin{verbatim} (define-recognition-agent *user* free-form-recognition-agent (author= "System") (creation-date= "The Epoch") (last-modification-date= "Thursday") (control-additions= (judge (\&rest args) (format *trace-output* "The dragon USER has no Judge action. It is only meant to be ~ used with ASK-USER.")) (ask-user (question \&optional (answer-type 'usual-3-val)) (let ((answer)) (loop (format *query-io* ``~\% ~A '' question) (setf answer (read *query-io*)) ;;type checking of answers here (if (confidence-set-p answer-type) (if (member-confidence answer answer-type) (progn (remember question answer) (return answer))) (if (typep answer answer-type) (progn (remember question answer) (return answer)))) (format *query-io* "~\% Please give an answer of type: ~A ~\%" (if (confidence-set-p answer-type) (confidence-values answer-type) answer-type))) (remember answer) answer)))) \end{verbatim} % Chapter------------------------------------------------------------- \chapter{Defining classification specialists} \section{Defining classification specialists} The function for defining classification specialists has the form: \begin{tabbing} 123456\=123456\=12345678\= \kill \\ \>({\bf DEFINE-CLASSIFICATION-SPECIALIST} {\it unique-name body}) \\ \\ \>\>{\it unique-name} may be any valid Common Lisp symbol name. This name will differentiate\\ \>\>\>the dragon from all other dragons in the system. \\ \>\>{\it body} \>::= {\it specifier specifier ...} \\ \>\>{\it specifier}\> ::= {\it (keyword otherstuff)} \\ \end{tabbing} \index{define-classification-specialist} Within the body of an agent definition, the order of specifiers is not significant, but within a specifier the order of symbols may be significant. Some specifiers are mandatory, and the rest are optional. A keyword introducing a specifier is always a token ending in ``=.'' The notation used in the following sections is described in section~\ref{notation}. \section{General dragon specifiers} Classification specialists, like RA's Recognition Agents, are subtypes of the Dragon problem-solving agent type. As such, the general specifiers common to dragons are available when defining a classification specialist. These are listed and described in section~\ref{general dragon specifiers}. \section{Specifiers Specific to Classification Specialists} \begin{tabbing} 123456\= \kill \\ ({\bf CLASSIFIER=} {\it classifier-name\/}) \\ \end{tabbing} \index{classifier=} This is the name of the classifier storing the hierarchy in which this specialist will operate. This is a mandatory specifier for all classification specialists, and the classifier named here must have been defined using {\bf DEFINE-CLASSIFIER} before the definition of the specialist is evaluated. Classifiers and their definition are discussed in Chapter~\ref{classifiers}. \begin{tabbing} 123456\= \kill \\ ({\bf ESTABLISH-CONFIDENCE-VOCABULARY=} {\it confidence-set-name}) \\ \end{tabbing} \index{establish-confidence-vocabulary=} This is used as the confidence set for the comparison of the value gotten from applying a specialist's TRANSLATOR to the value returned by its ESTABLISH-REJECT agent. The limitations on its use are described above. For more information on confidence sets, see the RA documentation. If not specified, it defaults to USUAL-9-VAL. \begin{tabbing} 123456\= \kill \\ ({\bf ESTABLISH-REJECT=} {\it agent}) \\ \end{tabbing} \index{establish-reject=} The form provided as {\it agent} is evaluated by the system to return the confidence of the classification specialist's concept matching the current situation. This value is passed through the specialist's TRANSLATOR, if it has one, and is then compared to the applicable threshold to determine whether or not the specialist establishes. \begin{tabbing} 123456\=123456\=123456\=123456\= \kill \>{\bf {\it agent\/} ::= }\\ \\ \>\>({\bf judge} {\it recognition-agent\/} [({\it arg arg}\ldots)] [{\it answer-type}]) \\ \\ \>\>| ({\bf ask} {\it database question answer-type\/}) \\ \\ \>\>\>{\it database} is the unique name of an IDB \\ \>\>\>{\it question} is a string \\ \>\>\>{\it answer-type} is the name of a confidence set, indicating that the answer is expected to be \\ \>\>\>\>a value from that confidence vocabulary, or one of {\bf SYMBOL} or {\bf NUMBER}, indicating that the \\ \>\>\>\>answer is expected to be a symbol or a number, respectively.\\ \\ \>\>\>\>It defaults to {\bf USUAL-3-VAL}. \\ \\ \\ \>\>| ({\bf ask-user} {\it question answer-type\/}) \\ \\ \>\>\>{\it question} is a string, {\it answer-type} defaults to USUAL-3-VAL \\ \\ \\ \>\>| ({\bf invoke} {\it dragon} '{\it verb} ['{\it arg} '{\it arg}\ldots] '{\it answer-type\/}) \\ \\ \>\>\>ex. (invoke idb 'ask ``Why?'' 'usual-3-val) \\ \\ \\ \>\>| {\it symbol} \\ \>\>\>this will be treated as a variable name and eval'ed to get the establish value. \\ \\ \>\>| {\it Lisp form} \\ \\ \end{tabbing} Examples: If foo is a recognition agent, and database is a database, some allowable specifications would be: \begin{verbatim} (establish-reject= (judge foo)) (establish-reject= (ask database ``Did you eat the oreos?'' usual-3-val)) (establish-reject= (invoke foo 'judge)) (establish-reject= var1) \end{verbatim} In the last example, eval'ing var1 returns a value (ex. 45 or ``foobar''), which, after application of the dragon's translator, comes out as a symbol (or number) in the agent's establish-confidence-vocabulary \begin{verbatim} (establish-reject= (progn (format t ``I really find this dragon specification ~ stuff to be kind of long-winded.~% All these specifiers.~% It just goes on and on, without end.~%'') (setf *globalvar1* 45) ;;get some extra work done here (setf *csrl-establish-threshold* 'likely) ;;change the system-wide establish threshold (+ 4 96) ;;finally get a value to return )) \end{verbatim} A Lisp form used as an ESTABLISH-REJECT= agent, as in the example above, must meet the same requirements as the variable value above -- after translation, it must be in the same confidence set (the establish-confidence-vocabulary) as the threshold it will be compared to. \index{translator=} \begin{tabbing} 123456\=123456\=123456\=123456\= \kill \\ ({\bf TRANSLATOR=} {\it translator-form}) \\ \\ \>{\bf {\it translator-form} ::=} \\ \>\>\>\>Lisp Lambda form \\ \\ \>\>\>\>| {\bf INVERT}\\ \index{invert} \end{tabbing} Allowable specifications would be: \\[10pt] \verb$(translator= invert)$ \\ This will invert the value returned by the establish-reject agent within that confidence set before comparing it to the threshold (what to use if the question the database knows the answer to is ``Did Jones do it?'', and the question you want to ask is ``Is Jones innocent?'') \\[10pt] \verb$(translator= (lambda (x) (= x 4)))$ \\ This will apply an arbitrary lisp form to the value returned by the establish-reject agent. Since this will be a lisp APPLY, the form specified to the translator must either be a function name, or a lambda form. The example given above shows how to squash between vocabularies - the establish-reject agent returns a number, but you want to convert it to T or NIL, based on whether or not it is equal to 4. (To see an example of this in practice, look at the testcase SHAPE.GT, distributed with the toolset. The database knows the answer to ``How many sides does it have?''. Instead of asking ``Does it have 5 sides?'', ``Does it have 6 sides?'', and so on, the classification specialists in this part of the test case all ask ``How many sides does it have?'', then use their translators to see if the number returned is 5, 6, etc. This functionality will hopefully no longer be necessary when the database system becomes more intelligent. To convert the incoming value from some confidence set into the confidence set used as the specialist's establish-confidence-vocabulary, use the function {\bf convert-form} to get an appropriate translation form.\index{convert-form}\index{confidence} \begin{tabbing} 1234\=1234\= \kill \>(translator= ({\bf convert-form} {\it source-conf-set\/} {\it dest-conf-set\/}))\\ \end{tabbing} where {\it source-conf-set} is the confidence set of the establish-reject method's result, and {\it dest-conf-set} is the specialist's establish-confidence-vocabulary. \index{establish-threshold=} \begin{tabbing} \\ 123456\=123456\=123456\= \kill ({\bf ESTABLISH-THRESHOLD=} {\it confidence-value}) \\ \>\>{\it confidence-value} ::= \\ \>\>\>a value from the establish-confidence-vocabulary of this agent. \\ \\ ({\bf SUSPEND-THRESHOLD=} {\it confidence-value}) \\ \>\>{\it confidence-value} ::= \\ \>\>\>a value from the establish-confidence-vocabulary of this agent.\\ \\ \end{tabbing} \index{suspend-threshold=} The {\bf establish-threshold} value is compared to the value gotten by applying the translator to the value returned by the establish-reject agent. It acts as a threshold - if the establish-reject value is greater than or equal to this value, the agent establishes. If the value is not specified (the specifier is not used), or the value is nil, the value of {\bf *CSRL-ESTABLISH-THRESHOLD*} will be used instead. This value defaults to {\bf likely}. \index{*csrl-establish-threshold*} The {\bf suspend-threshold} value is compared to the value by gotten by applying the translator the value returned by the establish-reject agent to determine the status of the classification specialist if it does not establish. If the value is greater than or equal to the {\bf suspend-threshold}, the agent {\it suspends}. If it is not, the agent is considered to be {\it ruled-out}. If the value is not specified (the specifier is not used), or the value is nil, the value of {\bf *CSRL-SUSPEND-THRESHOLD*} will be used instead. This value defaults to {\bf neutral}. \index{*csrl-suspend-threshold*} These values are accessed dynamically at run-time, rather than being compiled into an agent's definition. Therefore, they can be changed at run-time, and the agent's action will change. If either of them is changed to nil, the corresponding global variable will be used instead. The forms to set these values are: \begin{tabbing} 123456\=123456\= \kill \\ \>({\bf setf} ({\bf slot-value} {\it specialist-name\/} {\bf 'establish-threshold}) {\it new-value\/}) \\ \\ \>({\bf setf} ({\bf slot-value} {\it specialist-name\/} {\bf 'suspend-threshold}) {\it new-value\/}) \\ \\ \end{tabbing} {\bf NOTE:} The value used as the threshold for a classification-specialist, whether it comes from that specialist's ESTABLISH/SUSPEND-THRESHOLD or from *CSRL-ESTABLISH/SUSPEND-THRESHOLD*, must be a member of the same confidence set as the value gotten by applying the specialist's TRANSLATOR to the value returned by the specialist's ESTABLISH-REJECT agent. This confidence set must be the same as the value of the agent's ESTABLISH-CONFIDENCE-VOCABULARY.\index{establish-confidence-vocabulary} Therefore, if *CSRL-ESTABLISH-THRESHOLD* is set to .5 (from the USUAL-CONTINUOUS-VAL confidence set), and your classification-specialist's ESTABLISH-CONFIDENCE-VOCABULARY is USUAL-3-VAL, you must either specify an ESTABLISH-THRESHOLD for the agent, or reset *CSRL-ESTABLISH-THRESHOLD*. This limitation will hopefully be removed in later releases. \index{sub-specialists=} \begin{tabbing} 1234\=123456\= \kill \\ ({\bf SUB-SPECIALISTS=} {\it dragonname dragonname\/}\ldots) \\ \end{tabbing} This is the list of the specialist's children. It is used when the specialist goes to {\bf refine} -- this is the list of agents used by the dragon to refine itself. Conceptually, it should represent sub-concepts or sub-hypotheses of the hypothesis represented by the specialist. \begin{tabbing} 1234\=123456\= \kill \\ ({\bf SUPER-SPECIALISTS=} {\it dragonname dragonname\/}\ldots) \\ \end{tabbing} \index{super-specialists=} This is the list of the specialist's parents. Each parent should list this specialist on its list of sub-specialists. This specification is used when a specialist is invoked directly, not from above, and it needs to look up the hierarchy to see if the ``context'' of its decision to establish or suspend is such that it actually can establish or suspend. \begin{tabbing} 1234\=123456\=123456\= \kill \\ ({\bf PARENT-JOIN=} {\it join-type}) \\ \>\>{\it join-type} ::= \\ \>\>\>or \\ \\ \>\>\>| and \end{tabbing} \index{parent-join=} This specifier determines what the dragon will require to establish if it has multiple parents. If the specifier is {\bf and}, and the classification specialist has more than one parent, all of those parents must establish or suspend for the specialist to establish or suspend. If any of the specialist's parents rule out, the specialist will rule out as well. If the specifier is {\bf or}, and the classification specialist has more than one parent, at least one of those parents must establish or suspend for the specialist to establish or suspend. If all of the specialist's parents rule out, the specialist will rule out as well. \begin{tabbing} 1234\=123456\=123456\= \kill \\ ({\bf CHILD-JOIN=} {\it join-type\/}) \\ \\ \>{\it join-type\/} ::= \\ \\ \>\>\>exclusive \\ \\ \>\>\>| exhaustive\\ \\ \>\>\>| exhaustive exclusive\\ \end{tabbing} \index{child-join=} This specifier determines the method in which a dragon's children will influence the problem-solving of the parent or of each other. If the {\bf exclusive} specifier is given, the dragon's subs are exclusive alternatives -- as soon as one of them has established, the others will rule out. The actual ruling out of the other children takes place when the first of those children decide to establish (the system uses the get-context mechanism to allow the parent to cause them to rule out, without the subs having to know that they are defined as exclusive alternatives). Until that point, the children who have not yet established have undefined status (effectively ruled-out, but if their status is queried with get-status, the result may differ from that). The {\bf exclusive} specifier is inconsistent with one of the subs having multiple parents joined with {\bf or}. This inconsistent status will produce a warning, and the results of problem-solving with such a situation are undefined. For the exact workings of the {\bf exclusive} specifier, please see section~\ref{get-context}, on GET-CONTEXT. The {\bf exhaustive} specifier indicates that the dragon's subs are exhaustive alternatives: one of those alternatives must be true for the parent to be true. If the parent attempts to refine (through refine, establish-refine, or tell-me-about), and all of its children rule out, the parent will rule out. If any of its children establish or suspend, the parent's status will be determined as usual (for dragons without exhaustive children). Until the refine is attempted, the parent may have another status. \begin{tabbing} 1234\=123456\=123456\= \kill \\ ({\bf CONTEXT-TYPE=} {\it type\/}) \\ \\ \>{\it type\/} ::= \\ \\ \>\>\>establish \\ \\ \>\>\>| suspend \\ \\ \>\>\>| none\\ \end{tabbing} \index{context-type=} This specifier determines what statuses the specialist requires of its parents in order for it to get context. In the case of {\it establish\/}, the agent's parents must establish (in the right combination, depending on the agent's parent-join) for it to establish. If the value is {\it suspend\/}, the agent's parents must establish or suspend. If the value is {\it none}, the agent requires no context form its parents. For more details, see the section on get-context, above. \begin{tabbing} 1234\=123456\= \kill \\ ({\bf REFINE-FORM=} or | return-first | {\it form\/} | {\it form form\/}\ldots) \\ \end{tabbing} \label{user-defined refine forms} \index{refine-form=} If a classification specialist is invoked with {\bf ESTABLISH-REFINE} and it establishes, or if it is invoked with {\bf REFINE}, that specialist will go on to refine --- to call its subspecialists in order to refine the hypothesis it represents even further. The actions the specialist uses to refine the hypothesis under consideration are determined by the {\bf REFINE-FORM}. There are several system-defined refine-forms available, or the user can write their own. The possible arguments to the {\bf REFINE-FORM=} specifier are: \begin{itemize} \item {\bf or} -- this is the default refine form, used if no refine form specification is made. This refine form method invokes each of the specialist's children (in current implementations, this occurs serially, but conceptually it is designed to run in parallel) with {\bf ESTABLISH-REFINE}, gathering up what they return into a list, and if that result is non-nil, prepending the name of the parent specialist to that list, then returning it. If all of the specialist's children return nil, the refine-form returns nil. If this refine form returns nil the refine or establish-refine method for the specialist returns the listified name of the specialist. If the specialist has no children, the refine or establish-refine method for the specialist returns the name of the specialist. \item {\bf return-first} -- this refine form invokes each of the specialist's children one at a time with {\bf ESTABLISH-REFINE}, in the order they were specified in the {\bf SUB-SPECIALISTS=} specifier. As soon as one of them returns a non-nil value (one of them establishes and refines as far as it can), the refine form prepends the name of the parent specialist to the child's result and returns the resulting value, and does not invoke any more of the specialist's children. If none of the specialist's children establish, the refine form returns nil. If this refine form returns nil the refine or establish-refine method for the specialist returns the listified name of the specialist. If the specialist has no children, the refine or establish-refine method for the specialist returns the name of the specialist. This behavior is useful in representing the case where a specialist's children represent mutually incompatible hypotheses. \item {\bf {\it form\/}} or {\bf {\it form form} \ldots} -- a set of Lisp forms which will be evaluated when the time comes for a specialist to refine. If more than one {\it form\/} is given, the set of forms will be surrounded by a {\bf progn}. The form that results (either the single form specified by the user, or the group of forms specified by the user which the system makes into a {\bf progn}) should return a value appropriate for processing by the specialist in the manner described above. An example of a user-defined refine-form is given at the end of this chapter. \end{itemize} {\bf NOTE:} if you change the number or identity of a specialist's children, any system-defined refine form used by that specialist will not be updated to reflect that change until the specialist is redefined. (The list of subs is built into the refine form at agent-build-time for efficiency.) There are several utility functions and special forms available to the system builder for use in building refine forms: \index{*current-dragon*} \begin{tabbing} 123456\=123456\=123456\= \kill \\ \>\>{\bf *CURRENT-DRAGON*}-- at the time the specialist's {\bf refine-form} is evaluated, \\ \>\>\>*CURRENT-DRAGON* is set to the specialist.\\ \\ \>\>({\bf get-subs}) --this returns a list of the names of the specialist's subs.\\ \\ \>\>({\bf sub} {\it n\/}) -- this returns the name of the specialist's {\it n}th sub, with indexes starting at 0.\\ \\ \end{tabbing} \begin{tabbing} 1234\= \kill \\ ({\bf ESTABLISHED-ACTION=} {\it form\/} | {\it form form}\ldots) \\ \\ ({\bf NOT-ESTABLISHED-ACTION=} {\it form\/} | {\it form form})\ldots) \\ \end{tabbing} \index{established-action=} \index{not-established-action=} This is a Lisp form or set of Lisp forms to evaluate if the specialist establishes (ESTABLISHED-ACTION) or fails to establish (NOT-ESTABLISHED-ACTION). If more than one form is specified, they are wrapped inside a progn. \begin{tabbing} 1234\=123456\= \kill \\ ({\bf USE-CACHE=} t | nil) \\ \end{tabbing} \index{use-cache=} This determines whether the classification specialist will use its cache of the last answer it gave when asked to respond about a given case twice in a row. Normally, (with the default value of T), a specialist will not re-do a problem-solving action (such as refining or evaluating its establish-reject method) if the value of *CURRENT-CASE* is the same as the last case it ran in\footnote{The last case a classification specialist ran in can be detemined using ({\bf get-case} {\it classification-specialist-name\/}).}, and it has an answer to the question being asked in one of its caches. (Classification specialists only cache the last answer they recieved to any given problem-solving action.) Instead, it will simply use the cached answer, assuming that if the situation had changed (so that redoing the problem-solving action would return a different value from the cached one), the case would have changed to reflect that. If USE-CACHE= is not specified, the default value is taken from the global variable {\bf *CSRL-USE-CACHE*}, which is originally set to T. A given dragon's value of use-cache is checked dynamically at runtime, so it can be changed to change the dragon's behavior without recompiling that dragon. However, *CSRL-USE-CACHE* is only used as a default value at compile time -- to change a dragon's runtime behavior it's use-cache value must be individually set. \begin{tabbing} 1\=12345\=123456\= \kill \>To see the use-cache value of a dragon, do: \\ \>\>({\bf slot-value} {\it dragon-name} '{\bf use-cache}) \\ \\ \>To set the use-cache value of a dragon, do: \\ \>\>({\bf setf} ({\bf slot-value} {\it dragon-name} '{\bf use-cache}) {\it new-value}) \\ \>where {\it new-value} is {\bf T} or {\bf nil}. \\ \end{tabbing} \section{Examples} \subsection{Example classification-specialist} \begin{verbatim} (define-classification-specialist anxiety (establish-reject= (judge anxiety-symptoms)) (classifier= psychologist) (author= "dks") (establish-confidence-vocabulary= usual-9-val) (establish-threshold= likely) (suspend-threshold= unlikely) (sub-specialists= organic-anxiety inorganic-anxiety)) \end{verbatim} \subsection{Example user-defined refine-form} The following is a rather extreme example of a user-define refine-form. It can be found in the file animal-game.gt, in the directory of csrl testcases provided with the Toolset. This set of forms defines a classification-specialist, animal, to be the top of a hierarchy. Animal's refine form is geared to play the ``animal'' game -- if the animal currently being examined, or one of its descendants, is not the one the user is searching for, it will create a new classification specialist and add it to the hierarchy. \begin{verbatim} (eval `(define-classification-specialist animal (classifier= foo) (establish-reject= (judge isitananimal)) (establish-threshold= yes) (suspend-threshold= neutral) (refine-form= ,expanding-refine-form) (author= "dks") (establish-confidence-vocabulary= usual-3-val))) (setf expanding-refine-form `(let ((result-list nil) (new-sub nil)) (dolist (asub (get-subs)) (if (eq (ask-user (animal-question-string (slot-value *current-dragon* 'unique-name)) usual-3-val) 'yes) ;; This is as far as we wanted to go, return name, listifed ;; if necessary. (if (get-subs) (list (slot-value *current-dragon* 'unique-name)) (slot-value *current-dragon* 'unique-name)) ;; We can go farther, add a new sub. (progn (setf new-sub (add-new-animal *current-dragon*)) (setf result-list (invoke new-sub 'establish-refine)) (if result-list (return (append (list (slot-value *current-dragon* 'unique-name)) (cons result-list nil))) (return (list (slot-value *current-dragon* 'unique-name))))))) (setf result-list (invoke (eval asub) 'establish-refine)) (if result-list (return (append (list (slot-value *current-dragon* 'unique-name)) (cons result-list nil))))))) (defun animal-question-string (name) `(concatenate 'string "Is " (string ',(eval name)) " the animal you were thinking of? ")) (defun add-new-animal (parent-dragon) ;; Add a new animal as a sub of parent. If parent has other ;; children, make sure this is not actually an intermediate between ;; the parent and (some of) its children, if it is, insert it ;; also as the parent of those children (removing the old parent). ;; First, get the name of the child. ;; Get the author. -- Have this be defined at the beginning. ;; Set up its superspecialists list -- if it is the parent of some of its ;; parent's children, make it a subspecialist list \& alter parent ;; and children accordingly. Add it to its parent's sub list. ;; Build the form. ;; Eval it. (let ((parent-classifier (eval (slot-value parent-dragon 'classifier))) (define-form nil) (supers nil) (subs nil) (is-defined nil) new-node name) (format *query-io* "What animal do you want to add? ") (setf name (read *query-io*)) (if (is-node name parent-classifier) (setf is-defined t)) (if (get-subs (slot-value parent-dragon 'unique-name) parent-classifier) (progn (format *query-io* "Is it the parent of any of ~S? " (get-subs (slot-value parent-dragon 'unique-name) parent-classifier)) ;; make this error-checking read (if (equal (read *query-io*) 'yes) (progn (format *query-io* ``Please list the names of those animals:'') (setf subs (read-delimited-list #\Newline *query-io*)) ;; set up these as children of the new agent - change ;; their super-lists, and sub-list of parent (setf (get-subs (slot-value parent-dragon 'unique-name) parent-classifier) (remove-if `(lambda (x) (member x ',subs)) (get-subs (slot-value parent-dragon 'unique-name) parent-classifier))) (dolist (sub subs) (break-link sub (slot-value parent-dragon 'unique-name) (slot-value parent-classifier 'hierarchy)) (setf (get-supers sub (slot-value (eval sub) 'classifier)) (cons name (get-supers sub (slot-value (eval sub) 'classifier))))))))) ;; add it as a sub of its new parent (setf (get-subs (slot-value parent-dragon 'unique-name) parent-classifier) (cons name (get-subs (slot-value parent-dragon 'unique-name) parent-classifier))) (if is-defined (progn (setf (get-subs name (slot-value (eval name) 'classifier)) (remove-duplicates (append subs (get-subs name (slot-value (eval name) 'classifier))))) (setf (get-supers name (slot-value (eval name) 'classifier)) (cons (slot-value parent-dragon 'unique-name) (get-supers name (slot-value (eval name) 'classifier))))) (progn (setf define-form `(define-classification-specialist ,name (classifier= ,(slot-value parent-classifier 'unique-name)) (establish-reject= (ask animaldb ,(concatenate 'string "Is it a " (string name) "? "))) (establish-threshold= neutral) (suspend-threshold= neutral) (establish-confidence-vocabulary= usual-3-val) (author= "system") (parent-join= and) (super-specialists= ,@supers ,(slot-value parent-dragon 'unique-name)) (refine-form= ,expanding-refine-form) (sub-specialists= ,@subs))) (format *trace-output* "About to define ~S.~%" name) (eval define-form))))) \end{verbatim} %-------------------Chapter 6--------------------------------------- \chapter{Defining Classifiers\label{classifiers}} \section{Defining classifiers} The function for defining a classifier has the form: \begin{tabbing} 123456\=123456\=12345678\= \kill \\ \>({\bf DEFINE-CLASSIFIER} {\it unique-name body}) \\ \\ \>\>{\it unique-name} may be any valid Common Lisp symbol name. This name will differentiate\\ \>\>\>the dragon from all other dragons in \\ \>\>\>the system. \\ \\ \>\>{\it body} \>::= {\it specifier specifier ...} \\ \>\>{\it specifier}\> ::= {\it (keyword otherstuff)} \\ \end{tabbing} \index{define-classifier} Within the body of an agent definition, the order of specifiers is not significant, but within a specifier the order of symbols may be significant. Some specifiers are mandatory, and the rest are optional. A keyword introducing a specifier is always a token ending in ``=.'' The notation used in the following sections is described in section~\ref{notation}. \section{General dragon specifiers} Classifiers, like RA's Recognition Agents, are subtypes of Dragon. As such, the general specifiers common to dragons are available when defining a classifier. These are listed and described in section~\ref{general dragon specifiers}. \section{Specifiers Specific to Classifiers} There are no specifiers specific to classifiers. They use only the general dragon specifiers. The only mandatory specifier for classifiers is {\bf AUTHOR=}. \section{Functions to operate on classifiers -- Running the toolset} There are a large group of functions that get information from classifiers or classification specialists. \footnote{The functions that query classification specialists directly are listed here because the information they provide is related to the classifier's information-management function, and the fact that the functions that implement these information-gathering facilities do not explicitly call on the classifier is simply a matter of convenience of implementation and use.} Other related functions operate on the hierarchy representation carried by the classifier, and so are described in the chapter on hierarchies, chapter~\ref{hierarchies}. \begin{tabbing} 123456\= \kill ({\bf get-status} {\it specialist-name\/} \&optional {\it case\/}) \end{tabbing} \index{get-status} This function returns the status of specialist {\it specialist-name\/} in the case {\it case\/}. The value returned will be one of {\it established\/}, {\it suspended\/}, {\it ruled-out\/}, or {\it not-run\/}. If {\it case} is not the last case the specialist was run in, the specialist will return {\it not-run\/}.\footnote{Eventually, this function may search the specialist's memory to retrieve its status in earlier cases, but this functionality is not implemented in this release.} {\it Case} defaults to the value of {\bf *current-case*}. \begin{tabbing} 123456\= \kill \\ ({\bf get-case} {\it specialist-name\/}) \end{tabbing} \index{get-case} This function returns the name of the last case that specialist {\it specialist-name\/} ran in. \begin{tabbing} 123456\= \kill \\ ({\bf get-last-result} {\it specialist-name\/}) \end{tabbing} \index{get-last-result} This function returns the result of the last time the specialist's ESTABLISH-REJECT method was run (the result of applying the TRANSLATOR to the result of running the ESTABLISH-REJECT method) of specialist {\it specialist-name\/}. \begin{tabbing} 123456\= \kill ({\bf get-refine-result} {\it specialist-name\/}) \end{tabbing} \index{get-refine-result} This function returns the result of the last time the specialist {\it specialist-name} refined. \begin{tabbing} 123456\= \kill \\ ({\bf get-establish-threshold} {\it specialist-name\/}) \end{tabbing} \index{get-establish-threshold} This function returns the establish-threshold of specialist {\it specialist-name\/}. \begin{tabbing} 123456\= \kill \\ ({\bf get-suspend-threshold} {\it specialist-name\/}) \end{tabbing} \index{get-suspend-threshold} This function returns the suspend-threshold of specialist {\it specialist-name\/}. \begin{tabbing} 123456\= \kill \\ ({\bf get-last-establish-threshold} {\it specialist-name\/}) \end{tabbing} \index{get-last-establish-threshold} This function returns the establish-threshold that specialist {\it specialist-name} used the last time it was invoked with establish or establish-refine. This may be different than its current establish-threshold returned by {\bf get-establish-threshold} (thee stablish-threshold may have been changed since the last time the specialist ran). \begin{tabbing} 123456\= \kill \\ ({\bf get-last-suspend-threshold} {\it specialist-name\/}) \end{tabbing} \index{get-last-suspend-threshold} This function returns the suspend-threshold that specialist {\it specialist-name} used the last time it was invoked with establish or establish-refine. This may be different than its current suspend-threshold returned by {\bf get-suspend-threshold} (the suspend-threshold may have been changed since the last time the specialist ran). \begin{tabbing} 123456\= \kill \\ ({\bf hierarchy-complete?} {\it classifier-name\/}) \end{tabbing} \index{hierarchy-complete?} This function returns T if there are no more specialists expected to be added to {\it classifier-name\/}'s hierarchy, and nil if more specialists are expected (ex. a specialist has been named as the child of another specialist, but it hasn't been defined yet). \begin{tabbing} 123456\= \kill \\ ({\bf hierarchy-correct?} {\it classifier-name\/}) \end{tabbing} \index{hierarchy-correct?} This function performs minimal checking on a hierarchy to determine if it is complete and correct, printing out diagnostic messages if it finds anything wrong. Currently, it checks to ensure: \begin{itemize} \item the hierarchy is complete -- nothing it knows of is undefined (see {\bf hierarchy-complete?}) \item the hierarchy has one and only one root node (node with no parents) \item the hierarchy has no nodes who have both a) multiple parents joined with {\bf or} and b) a parent who has a {\bf child-join} containing the {\bf exclusive} specifier \item it issues a diagnostic notice if any nodes have more than one parent (this is not necessarily a problem, but should be noted) \end{itemize} This function should be run on every hierarchy before using the hierarchy for problem-solving. \begin{tabbing} 123456\= \kill \\ ({\bf local-establish-threshold?} {\it specialist-name\/}) \\ ({\bf local-suspend-threshold?} {\it specialist-name\/}) \\ \end{tabbing} \index{local-establish-threshold?} \index{local-suspend-threshold?} These functions return the specialist's local establish/suspend threshold if it has one, and nil if it doesn't (in which case it will use *CSRL-ESTABLISH-THRESHOLD* and *CSRL-SUSPEND-THRESHOLD* to do its problem solving). \begin{tabbing} 123456\= \kill \\ ({\bf run-yet?} {\it specialist-name\/} \&optional {\it case\/}) \end{tabbing} \index{run-yet?} This function returns T if the last case {\it specialist} ran in was {\it case\/}. If {\it case} is not specified, it defaults to *CURRENT-CASE*. \section{Example} \begin{verbatim} (define-classifier Psychologist (display-name= "DSM III Psychological Disagnosis Hierarchy") (author= "Diana K. Smetters") (creation-date= "10/31/88") (last-modification-date= "10/31/88")) \end{verbatim} %-------------------Chapter 7--------------------------------------- \chapter{Hierarchies\label{hierarchies}} A {\it hierarchy} is a data structure for storing parent-child relations among nodes in a directed graph. Any type of Lisp object may be used as a hierarchy node. There are a large number of utility functions available for creating, altering, and getting information from hierarchies. \section{Functions for operating on hierarchies} Most of these functions are completely generic, and relate only to the hierarchy data abstraction per se, with no consideration of their use in CSRL. However, most of the functions in this section have been extended to accept classifiers or other CSRL entities as arguments. This is simply to make these functions easier for CSRL users to use. The hierarchy data structure itself is completely independent of CSRL, and is suitable for use in almost any system that needs to represent hierarchical structures (or, more generally, directed graphs). Unless stated otherwise for a particular function, an argument, {\it hierarchy\/}, may be an object of type {\bf hierarchy}, an object of type {\bf classifier}, the name of a classifier, or the quoted name of a classifier. \subsection{Functions that return information about hierarchies} These functions will be used both by individuals using the hierarchy package as a data abstraction to build their own system, and by individuals using the hierarchy package as a part of CSRL. \begin{tabbing} 123456\= \kill \\ ({\bf get-nodes} {\it hierarchy\/}) \end{tabbing} \index{get-nodes} Get-nodes returns a list of the nodes in {\it hierarchy\/}. \begin{tabbing} 123456\= \kill \\ ({\bf is-node} {\it node} {\it hierarchy\/}) \end{tabbing} \index{is-node} Is-node returns non-nil if {\it node} is one of the nodes in {\it hierarchy\/}. {\it Node} should be of type {\bf node-type}, as specified for the hierarchy in question. {\it Hierarchy} may be any of the types mentioned above. \begin{tabbing} 123456\= \kill \\ ({\bf is-sub} {\it child} {\it parent} {\it hierarchy\/}) \end{tabbing} \index{is-sub} Is-node returns non-nil if {\it child} is a child of {\it parent} in {\it hierarchy\/}. \begin{tabbing} 123456\= \kill \\ ({\bf is-super} {\it parent} {\it child} {\it hierarchy\/}) \end{tabbing} \index{is-sub} Is-node returns non-nil if {\it parent} is a parent of {\it child} in {\it hierarchy\/}. \begin{tabbing} 123456\= \kill \\ ({\bf hierarchy-contents} {\it hierarchy\/}) \end{tabbing} \index{hierarchy-contents} Hierarchy-contents returns a nested-list structure representing the structure of {\it hierarchy\/}. At this time, it does not cope with the existence of cycles. If a node has two parents, it will represent that shared subtree twice. For a description of the structure it returns, see section~\ref{return values}. \begin{tabbing} 123456\= \kill \\ ({\bf get-subs} {\it node} {\it hierarchy\/}) \end{tabbing} \index{get-subs} Get-subs returns a list of {\it node\/}'s children in {\it hierarchy}. If {\it node} is not a node of {\it hierarchy\/}, get-subs signals an error. Get-subs is suitable for use with {\bf setf}, as in (setf (get-subs 'anode ahierarchy) '(node1 node2)). \begin{tabbing} 123456\= \kill \\ ({\bf get-supers} {\it node} {\it hierarchy\/}) \end{tabbing} \index{get-supers} Get-supers returns a list of {\it node\/}'s parents in {\it hierarchy}. If {\it node} is not a node of {\it hierarchy\/}, get-supers signals an error. Get-supers is suitable for use with {\bf setf}, as in (setf (get-supers 'anode ahierarchy) '(node1 node2)). \begin{tabbing} 123456\= \kill \\ ({\bf get-all-subs} {\it node} {\it hierarchy\/}) \end{tabbing} \index{get-all-subs} Get-all-subs returns a list of all of {\it node\/}'s descendants in {\it hierarchy}. If {\it node} is not a node of {\it hierarchy\/}, get-subs signals an error. \begin{tabbing} 123456\= \kill \\ ({\bf get-all-supers} {\it node} {\it hierarchy\/}) \end{tabbing} \index{get-all-supers} Get-all-supers returns a list of all of {\it node\/}'s ancestors in {\it hierarchy}. If {\it node} is not a node of {\it hierarchy\/}, get-all-supers signals an error. \begin{tabbing} 123456\= \kill \\ ({\bf get-top-node} {\it hierarchy\/}) \end{tabbing} \index{get-top-node} Get-top-node returns the top node of {\it hierarchy\/}. It assumes that the hierarchy has only one top node. (A top node is a node with no parents.) If a hierarchy has more than one top node, the first such node found is returned. \begin{tabbing} 123456\= \kill \\ ({\bf top-nodep} {\it node} {\it hierarchy\/}) \end{tabbing} \index{top-nodep} Top-nodep returns T if {\it node} is a top node of {\it hierarchy} (i.e. {\it node} has no parents). \begin{tabbing} 123456\= \kill \\ ({\bf get-tip-nodes} {\it hierarchy\/}) \end{tabbing} \index{get-tip-nodes} Get-tip-nodes returns a list of the tip nodes (nodes with no children) in {\it hierarchy\/}. \begin{tabbing} 123456\= \kill \\ ({\bf tip-nodep} {\it node} {\it hierarchy\/}) \end{tabbing} \index{tip-nodep} Tip-nodep returns T if {\it node} is a tip node of {\it hierarchy} (i.e. {\it node} has no children). \begin{tabbing} 123456\= \kill \\ ({\bf treep} {\it hierarchy\/}) \end{tabbing} \index{treep} Treep returns T if {\it hierarchy} is a tree (i.e. none of its nodes has more than one parent), and nil otherwise. It does not currently handle cycles. \subsection{Functions for creating and altering hierarchies} These functions will primarily be used by individuals using the hierarchy data abstraction to build their own system. They will not normally be used by individuals wanting to use the normal capabilities of CSRL (though they can be used to extend those capabilities). \begin{tabbing} 123456\= \kill \\ ({\bf make-hierarchy} \&optional {\it node-type\/}) \end{tabbing} \index{make-hierarchy} Make-hierarchy makes an object of type hierarchy and returns it. If {\it node-type} (a symbol) is supplied, it is used to typecheck nodes that are added to the hierarchy. For example, \\[8pt] \verb$(setf new-hier (make-hierarchy 'number))$ \begin{tabbing} 123456\= \kill \\ ({\bf add-node} {\it node\/} {\it parent-list\/} {\it child-list\/} {\it hierarchy\/}) \end{tabbing} \index{add-node} Add-node adds {\it node} as a new node in {\it hierarchy}, with parents {\it parent-list} and children {\it child-list}. If {\it node} is already a node in {\it hierarchy}, an error is signalled (to redefine a node, first delete it with {\bf delete-node}, then re-add it). {\it Node} must be of the correct type --- {\it hierarchy\/}'s node type. Consistency checking is performed in the following way: if any of the nodes on {\it parent-list} have already been defined, add-node checks to make sure each of them specified {\it node} as one of their children (if they haven't, an error is signalled, and {\it hierarchy} is not changed). For any nodes on {\it parent-list} that have not yet been defined, a note is made of the fact that {\it node} claimed them as parents in order to check this relationship when they are defined (or to signal a problem through {\bf hierarchy-complete?} if they are never defined). If any of the nodes on {\it child-list} have already been defined, add-node checks to make sure each of them specified {\it node} as one of their parents (if they haven't, an error is signalled, and {\it hierarchy} is not changed). For any nodes on {\it child-list} that have not yet been defined, a note is made of the fact that {\it node} claimed them as parents in order to check this relationship when they are defined (or to signal a problem through {\bf hierarchy-complete?} if they are never defined). \begin{tabbing} 123456\= \kill \\ ({\bf break-link} {\it node1\/} {\it node2\/} {\it hierarchy\/} \&key {\bf :delete}) \end{tabbing} \index{break-link} Break-link breaks a parent-child link between {\it node1} and {\it node2} (it doesn't matter which node is the parent, unless the link between them goes both ways, in which case the link from {\it node1} as parent to {\it node2} as child will be removed). Both {\it node1} and {\it node2} must be nodes in {\it hierarchy}, and there must be a parent-child link between them, or an error will be signalled. If {\bf :delete} is non-nil, and the child node has no other parents (breaking the link between parent and child would orphan the child), the child (and the entire subtree below it) will be removed from the hierarchy. If {\bf :delete} is nil (the default if {\bf :delete} is unspecified), and the child has only one parent, an error will be signalled and the link will not be broken. \begin{tabbing} 123456\= \kill \\ ({\bf add-link} {\it parent\/} {\it child\/} {\it hierarchy\/}) \end{tabbing} \index{add-link} Add-link adds a link from {\it parent}, to {\it child}. Both {\it parent} and {\it child} must be nodes in {\it hierarchy\/}, or an error will be signalled. \begin{tabbing} 123456\= \kill \\ ({\bf insert-node} {\it new-node\/} {\it node1\/} {\it node2\/} {\it hierarchy\/}) \end{tabbing} \index{insert-node} Insert-node takes a new node, {\it new-node}, and inserts it into {\it hierarchy} between {\it node1} and {\it node2}. {\it New-node} must not already be a node in the hierarchy, and there must be a parent-child link between {\it node1} and {\it node2} (which must also be in the hierarchy), or an error is signalled. {\it New-node} has as a parent whichever of {\it node1} and {\it node2} is the parent, and has the other as a child. The direct link between {\it node1} and {\it node2} is then broken. \begin{tabbing} 123456\= \kill \\ ({\bf change-node} {\it old-node\/} {\it new-node\/} {\it hierarchy\/}) \end{tabbing} \index{change-node} Change-node replaces {\it old-node}, an node in {\it hierarchy}, with {\it new-node}, another object of the same type (of {\it hierarchy\/}'s node-type). After the switch, {\it new-node} will occupy the same position in the hierarchy that {\it old-node} used to -- it will have the same parents, children, etc. \begin{tabbing} 123456\= \kill \\ ({\bf move-node} {\it node\/} {\it new-parent-list\/} {\it new-child-list\/} {\it hierarchy\/} \&key {\bf :delete}) \end{tabbing} \index{move-node} Move-node moves {\it node} from one place in {\it hierarchy} to another. {\it Node} and all of the nodes on {\it parent-list} and {\it child-list} must be nodes in {\it hierarchy\/}, or an error is signalled. After the move, {\it node\/}'s parents are {\it parent-list} and it's children are {\it child-list\/}. If {\bf :delete} is specified and non-nil, and moving the node causes one of its old children to be orphaned, that child will be deleted (with delete-node's {\bf :recursive} argument set to T, see below). If {\bf :delete} is unspecified or nil, and an orphan would be created by the specified operation, an error will be signalled and {\it node} will not be moved. \begin{tabbing} 123456\= \kill \\ ({\bf delete-node} {\it node\/} {\it hierarchy\/} \&key {\bf :recursive}) \end{tabbing} \index{delete-node} Delete-node removed {\it node} from {\it hierarchy\/}. It signals an error if {\it node} is not a node in {\it hierarchy}. If {\it node} has children who have no other parents (who will be orphaned by deleting {\it node\/}), and {\bf :recursive} is nil (the default if it is not specified), an error will be signalled. If {\bf :recursive} is non-nil, {\it node} will be deleted, and {\bf delete-node} will be called to delete the orphaned child (with the {\bf :recursive} aregument set to T, to continue recursive deletion). \begin{tabbing} 123456\= \kill \\ ({\bf destroy-hier} {\it hierarchy\/}) \end{tabbing} \index{destroy-hier} Destroy-hier destroys {\it hierarchy} by recursively deleting all its nodes and then deleting the hierarchy itself. This is the appropriate method for getting rid of a hierarchy, as it is a highly circular structure and \verb$(setf hierarchy nil)$ may not ensure that it is garbage collected. %-------------------Chapter 8--------------------------------------- \chapter{Databases} ``Intelligent'' databases (IDBs) are for the task of ``data abstraction,'' i.e., answering questions about data at the level of abstraction of the questioner, which may not correspond to the level of the raw data. For example, a diagnostic system might want to know whether a certain parameter is within the normal range, and it will be up to the IDB to infer this from the raw data using domain knowledge embedded in the IDB. One type of intelligent database is provided in this release. This type, STUB-IDB, has no special machinery provided yet, except the default behavior of turning to the user for needed answers and caching the user's replies. It is easy for the user to extend this behavior by turning to Lisp, redefining the standard actions or creating new ones. However, the standard question to an ASK method must be a string, so if the tool builder wants a question of a different form, she must define her own verb, rather than redefining ASK. In future releases, other types of IDB's will be provided, hopefully providing additional functionality. \section{Defining IDB's} The source code for defining an IDB has the form: \begin{tabbing} 123456\=123456\=123456\= \kill \\ \>({\bf DEFINE-IDB} {\it unique-name} {\bf stub-idb} {\it body\/}) \\ \\ \>\>{\it unique-name\/} may be any valid Common Lisp symbol name. This name will differentiate\\ \>\>\>the dragon from all other dragons in the system. \\ 123456\=123456\=1234567890\=123456\= \kill \>\>{\it body\/} \>::= \>{\it specifier specifier\/} \ldots \\ \>\>{\it specifier\/} \>::= \>({\it keyword otherstuff\/}) \\ \end{tabbing} The specifiers for an IDB are the same as those listed under specifiers for all dragon types, in section~\ref{general dragon specifiers}, with two additions: \begin{tabbing} 1234\=123456\= \kill \\ ({\bf ANSWER-CACHE-LIMIT=} {\it number\/}) \\ \>\>this is the number of question and answer pairs that the IDB will save during the execution \\ \>\>of a single case. \\ \\ \\ ({\bf SAVED-CASE-LIMIT=} {\it number \/}) \\ \>\>this is the number of cases that the IDB can save (see below). \\ \end{tabbing} \index{answer-cache-limit=} \index{saved-case-limit=} \section{The case mechanism} In order to make IDB's more useful, their facility to save and cache cases has been considerably enhanced in this release. \subsection{Specifying cases} Cases can now be specified as either a symbol or a list of symbols. Cases that are specified by a list of symbols conceptually represent {\it composite} cases, made up of the individual subcases represented by each symbol in the list. For example: \begin{verbatim} (start-solving (March-case week3-case Internist-on-call-case) dragon-name establish-refine) \end{verbatim} \subsection{Using Saved Cases} When an IDB is asked a question, it checks to see if this is a new case to find out whether it should flush its old case cache (If its name is not on *IDB-FLUSHED-LIST*, it will flush its cache and add its name to the list. *IDB-FLUSHED-LIST* is set to nil every time a new case is started (whenever start-solving is executed with a case argument different from the last time start-solving was executed). {\bf NOTE:} If you execute start-solving twice in a row with the same case argument (ex. by using a ``redo'' facility), the second time is considered to be a continuation of the case started by the first, and no caches are flushed. Whenever the IDB is asked a question, it will check to see if this is a new case. If the IDB is on a new case (it just flushed its cache), it will then look at the variable {\bf *IDB-USE-SAVED-CASES*} to see whether it should use its saved cases on this case. If *IDB-USE-SAVED-CASES* is T (the default), the IDB will build an answer-cache to use in this case based on the contents of its saved case cache and the value of *CURRENT-CASE*. If the value of *CURRENT-CASE* is a list, the IDB will first check to see if it has any saved cases whose names exactly match that list. If so, it will put the question-answer pairs it saved for that case into its answer cache (where they will be used exactly as if those questions had been already asked -- the answer will be taken out of the cache instead of asking the user). Then, the IDB will go through the list of symbols in *CURRENT-CASE* (or the one symbol, if *CURRENT-CASE* is not a list), checking to see if any of its saved cases match that symbol. If so, it adds the question-answer pairs for that case to the end of its answer-cache (to be used only if information previously added to the cache earlier in this procedure does not provide an answer to the question being asked). This system of using the answers associated with the case name as a whole (most specific), then the answers associated with each symbol in the list that makes up the case name in order, allows this case-caching mechanism to not only save cases, but to selectively use saved cases and subcases, depending on the value of *CURRENT-CASE*. For example, say I have a system in which a certain number of the answers to questions are dictated by what quarter of the year it is. I will then save four separate cases, autumn, winter, spring, and summer, each containing the appropriate answers for that quarter. Another set of questions will get different answers depending on what month it is. I then save 12 cases, each named after a month, that represent the answers to those questions appropriate for that month. There are also another set of questions whose answer is appropriate to the week of the month (1st, 2nd, 3rd, 4th), so I make cases for those as well. It is easy to see how, by combining these symbols into a list, I can form composite cases out of several subcases. However, the system affords more complex posibilities. Say there are a few of the per-month questions that have the same answer if it is February, August, or December. I can then make another case, feb-aug-dec, containing those answers. Then, I can specify the case for those months as, for example, '(autumn feb-aug-dec feb week4). This way, the answers appropriate for February, August, and December will come out ahead of those appropriate for just February. (This is useful, for example, if February, Aug., and Dec. are singled out this year because they are months in which budget reports are due, and next year the budget report months are July, March, and January. Instead of calling the case feb-aug-dec, you could call it budget-report, and use it to override the normal answers for some of the questions in July, March, and January.) In another case, suppose that during the fourth week of September, everything varies from its normal pattern -- you could save those answers in a case called '(week4 february autumn), and because you have a saved case whose name exactly matches that list, the answers in that case will be used before those appropriate for week4, february, or autumn. \subsection{Saving cases} The function {\bf SAVE-CASE} can be used to save an IDB's cached set of answers to a given case. \index{save-case} \begin{tabbing} 123456\=123456\= \kill ({\bf save-case} \&key (delete nil)) \\ \end{tabbing} Save-case takes the current set of answers cached in an IDB's answer-cache (the result of running it on a given case and answering the questions it asks) and saves it in the IDB's cache of saved cases as a case named by the value of *CURRENT-CASE*. The number of cases that can be saved is determined by the value of the IDB's SAVED-CASE-LIMIT (see above). If the keyword {\bf :delete} is non-nil, and saving this case would put the IDB over it's SAVED-CASE-LIMIT, the oldest saved case will be deleted in order to make space for the new case. Otherwise, save-case will signal an error (with instructions on ways to proceed). Saved cases will be retained when an IDB is written to or read from a fasload file. So, to get a set of answers into an IDB's saved-case cache for later use (so you don't have to answer the questions again), run the case (using start-solving), with the name you want to call the case as the case argument. Answer the IDB's questions with the answers you want stored. When the case is finished, execute {\bf save-case}. \subsection{Forgetting saved cases} The function {\bf FORGET-CASE} can be used to remove an IDB's set of saved answers from the saved case cache. \index{forget-case} \begin{tabbing} 123456\=123456\=1234\= \kill \\ ({\bf forget-case} {\it case-name} {\it idb}) \\ \>\>{\it case-name} is a symbol or a list, the name of the case to be removed. \\ \>\>{\it idb} is the idb who is to have the case removed. \\ \\ \>Ex. ({\bf forget-case} '(case42a case3b) the-idb) \\ \end{tabbing} Forget-case removes a case from an IDB's saved case cache. \subsection{Other functions for manipulating cases} \index{cases-saved} \begin{tabbing} 123456\=123456\=1234\= \kill \\ ({\bf cases-saved} {\it idb}) \\ \end{tabbing} This returns a list of the names of the cases saved by IDB {\it idb\/}. \index{case-saved?} \begin{tabbing} \\ 123456\=123456\=1234\= \kill ({\bf case-saved?} {\it case} {\it idb}) \\ \end{tabbing} This returns non-nil if {\it case} is in the saved-case-cache of IDB {\it idb\/}. \index{set-saved-case-limit} \begin{tabbing} \\ 123456\=123456\=1234\= \kill ({\bf set-saved-case-limit} {\it idb} {\it number}) \\ \end{tabbing} This sets IDB {\it idb\/}'s SAVED-CASE-LIMIT to {\it number\/}. \index{saved-case-limit} \begin{tabbing} \\ 123456\=123456\=1234\= \kill ({\bf saved-case-limit} {\it idb}) \\ \end{tabbing} This returns IDB {\it idb\/}'s SAVED-CASE-LIMIT. \section{Example} \begin{verbatim} (define-idb mhdb stub-idb (author= "DKS") (display-name= "DSM III Case Data Base")) \end{verbatim} %-------------------Chapter 9--------------------------------------- \chapter{Confidence Sets\label{confidence sets}} As stated earlier, the output of a recognition agent is a symbol in some vocabulary expressing a degree of confidence that the concept has been recognized. Several confidence sets are supplied by the system, as well as facilities for automatic conversion between confidence sets. \section{System-defined confidence sets} The system-supplied confidence sets are: USUAL-9-VAL, USUAL-3-VAL, USUAL-2-VAL, and USUAL-CONTINUOUS-VAL. \begin{itemize} \item {\bf CONFIDENCE-SET} is the top of the type hierarchy of confidence sets, all other types are subtypes of CONFIDENCE-SET. If a supertype is not specified to DEFINE-CONFIDENCE-SET, the new confidence set is created as a direct subtype of CONFIDENCE-SET. This is not meant to be used as the confidence vocabulary of an agent, it is only used to fill a space in the type hierarchy. \item {\bf DISCRETE-CONFIDENCE-SET} represents the top of the type hierarchy of confidence sets composed of discrete values, like symbols or integers. It is a direct subtype of CONFIDENCE-SET. Typically, values in a DISCRETE-CONFIDENCE-SET will be listed out, or generated by rule (ex. you wouldn't want to list the integers, but you could easily characterize them by: 0 is an integer, 1 is an integer, integer + integer is an integer, and integer - integer is an integer), instead of by specification of endpoints. This class is also simply meant to occupy a place in the type hierarchy, rather than to serve as an agent's confidence vocabulary. \item {\bf CONTINUOUS-CONFIDENCE-SET} represents the top of the type hierarchy of confidence sets composed of ranges of continuous values. It is a direct subtype of CONFIDENCE-SET. Typically, CONTINUOUS-CONFIDENCE-SETS are specified by their endpoints. This class is also simply meant to occupy a place in the type hierarchy, rather than to serve as an agent's confidence vocabulary. \item {\bf USUAL-9-VAL} provides the vocabulary (from highest confidence to lowest): {\bf CONFIRMED}, {\bf VERY-LIKELY}, {\bf LIKELY}, {\bf SOMEWHAT-LIKELY}, {\bf NEUTRAL}, {\bf SOMEWHAT-UNLIKELY}, {\bf UNLIKELY}, {\bf VERY-UNLIKELY}, and {\bf RULED-OUT}. The intended semantics is non-dogmatic, i.e., that even CONFIRMED and RULED-OUT can in principle be reconsidered. A direct subtype of DISCRETE-CONFIDENCE-SET, {\bf USUAL-9-VAL} is the default output confidence vocabulary if none is supplied. \item {\bf USUAL-3-VAL} provides {\bf YES}, {\bf NEUTRAL}, and {\bf NO}. It is a direct subtype of DISCRETE-CONFIDENCE-SET. \item {\bf USUAL-2-VAL} provides {\bf T} and {\bf F}, a binary confidence vocabulary. For compatibility with Lisp {\bf NIL} may often be used as a synonym for {\bf F}. It is a direct subtype of DISCRETE-CONFIDENCE-SET. \item {\bf USUAL-CONTINUOUS-VAL} permits any floating-point number between 0 and 1, inclusive, to be used as a confidence symbol. It is a direct subtype of CONTINUOUS-CONFIDENCE-SET. There are a variety of interpretations that might be given to, or imposed on, the use of this confidence vocabulary.\footnote{It might be used in a system to represent ``probabilities'' under at least three alternative interpretations of that idea: {\it frequencies\/} of occurrence, the {\it propensities\/} of various mechanisms to produce certain frequencies of occurrence, or {\it degrees of belief\/} which may or may not be the same as expected frequency. Related to degrees of belief, continuous confidences might also be used to represent {\it activation levels\/} in a neural network model.} \end{itemize} \section{Defining your own -- define-confidence-set} The defining construct {\bf DEFINE-CONFIDENCE-SET} can be used by the knowledge engineer to set up new confidence vocabularies. \begin{tabbing} 1234\=1234\=123456\=123456\= \kill \\ \>({\bf DEFINE-CONFIDENCE-SET} {\it set-name} {\it body\/}) \\ \>\>{\it set-name\/} may be any valid Common Lisp symbol name. \\ \\ \>\>{\it body\/} \>::= \>{\it specifier specifier\/} \ldots \\ \>\>{\it specifier\/} \>::= \>({\it keyword otherstuff\/}) \\ \end{tabbing} \subsection{Specifiers for confidence sets} \begin{tabbing} 1234\=1234\=1234\= \kill \\ ({\bf SUPERCLASS=} {\it confidence-set-name}) \\ \\ \>{\it confidence-set-name} must be the name of an already defined confidence set.\\ \>\> If not specified, this defaults to CONFIDENCE-SET. \\ \\ \end{tabbing} \index{superclass=} \begin{tabbing} 1234\=1234\=1234\= \kill ({\bf SUPERCLASS=} {\it type}) \\ \>{\it type} must be a symbol naming a legal type (usable with typep).\\ \>\>If not specified, this defaults to the type of the superclass.\\ \>\>If this is not available, it defaults to T. \\ \end{tabbing} \index{type=} \begin{tabbing} 1234\=1234\=1234\= \kill ({\bf MIN=} {\it value}) \\ ({\bf MAX=} {\it value}) \\ \>MIN and MAX are the endpoints for the range of values encompassed by this confidence set.\\ \>\>\> They can be any sort of values of type TYPE=, as long as they will be accepted by the comparison functions \\ \>\>\>discussed below. \\ \end{tabbing} \index{min=} \index{max=} \begin{tabbing} 1234\=1234\=1234\= \kill ({\bf VALUES-LIST=} {\it value value\/}\ldots) \\ \>the values listed here are the values in the confidence set. \\ \>\>They should be listed {\bf in order, from highest to lowest}. \\ \>\>They must be of the appropriate type to be operated on by the comparison functions described below. \\ \>\>\>(Specified by the TYPE= specifier.)\\ \\ \end{tabbing} \index{values-list=} {\bf NOTE:} either MIN and MAX (both of them) or VALUES-LIST {\bf must} be specified, or it must be possible to inherit their values from their superclass (they must not be a direct subclass of CONFIDENCE-SET, DISCRETE-CONFIDENCE-SET, or CONTINUOUS-CONFIDENCE-SET, which do not have these values to inherit). If both are specified, the VALUES-LIST specification is used. If neither are specified, and they cannot be inherited from the superclass, DEFINE-CONFIDENCE-SET will signal an error. {\bf NOTE:} if you redefine a confidence set without reloading the definition of dragons that use that confidence set, unpredictable results may arise. Many of the parts of the confidence set (especially comparison functions) are expanded inline into a dragon when that dragon is defined, for efficiency reasons. These forms will not be updated till the dragon is redefined. \index{gt=} \index{ge=} \index{lt=} \index{le=} \index{eq=} \index{member-confidence-set=} \begin{tabbing} 1234\=1234\=1234\= \kill \\ ({\bf GT=} {\it lambda-form}) \\ ({\bf GE=} {\it lambda-form}) \\ ({\bf LT=} {\it lambda-form}) \\ ({\bf LE=} {\it lambda-form}) \\ ({\bf EQ=} {\it lambda-form}) \\ ({\bf MEMBER-CONFIDENCE-SET=} {\it lambda-form}) \\ \end{tabbing} {\it Lambda-form} should be a standard Lisp lambda capable of taking in the appropriate number of arguments (1 for MEMBER-CONFIDENCE-SET=, 2 for all others), and performing the requisite comparison on them, returning T if the indicated relationship holds, and nil if it doesn't. The relationships in question are: \begin{tabbing} 1234\=1234\=1234\= \kill \>GT=\>({\bf GT} x y) returns T if x is greater than y, nil otherwise.\\ \>GE=\>({\bf GE} x y) returns T if x is greater than or equal to y, nil otherwise.\\ \>LT=\>({\bf LT} x y) returns T if x is less than y, nil otherwise.\\ \>LE=\>({\bf LE} x y) returns T if x is less than or equal to y, nil otherwise. \\ \>EQ=\>({\bf EQ} x y) returns T if x is equal to y, nil otherwise. \\ \>MEMBER-CONFIDENCE-SET= \\ \>\>({\bf MEMBER-CONFIDENCE-SET} x) returns T if x is a member of the confidence set,\\ \>\>\>nil otherwise \\ \end{tabbing} All of these functions except MEMBER-CONFIDENCE-SET can expect that their arguments are actually members of the confidence set in question. All of these functions can expect that the arguments the get will not be aliases of values in the set. If aliases are handed to the systems that use these comparison functions (see discussion of utility functions below), the interfaces to these functions will convert the aliases to the values they are aliases of before the values are handed to these functions. (So, when writing a comparison function, you don't have to worry about the contents of the ALIASES= specification (see below).) {\bf NOTE:} None of these lambdas are mandatory. If the user does not specify them, the system will inherit them from the superclass if possible, and if not, the system will either generate them from the functions it has been able to get (e.g. generating LE by composing LT and EQ), or it will generate default forms. In the usual case, the user will not specify these, and will allow the system to fill them in. The specifications are here to let users who want a behavior very different from the standard to define their own comparison functions. (To allow for non-linear confidence sets, for instance.) The user does not actually work with these lambdas directly to perform confidence comparisons. Instead, a number of interface functions are provided. These functions are described in the next section. \begin{tabbing} 1234\=1234\=1234\=1234\= \kill \\ ({\bf ALIASES=} {\it alias-spec\/} {\it alias-spec\/}\ldots)\\ \\ \>{\it alias-spec} ::= \\ \>\>({\it conf-value\/} {\it alias\/} {\it alias\/}\ldots) \\ \\ \>\>\>{\it conf-value} is a value from the confidence set. \\ \>\>\>{\it alias} is an alias for that value (of practically any type).\\ \end{tabbing} \index{aliases=} This specification allows you to list aliases (other names) for values in the confidence set. The aliases will be treated as equivalent to the values they are aliases for. \begin{tabbing} 1234\=1234\=1234\=1234\= \kill ({\bf NEUTRAL-EQUIVALENT=} {\it conf-value})\\ \>{\it conf-value} is a value in the confidence set \end{tabbing} \index{neutral-equivalent=} If NEUTRAL is not a member of the confidence set, it is set up as an alias for {\it conf-value}, otherwise the NEUTRAL-EQUIVALENT= specification is ignored. \subsection{Examples} \begin{verbatim} (define-confidence-set usual-2-val (superclass= discrete-confidence-set) (values-list= t f) (gt= (lambda (x y) (member y (cdr (member x '(t neutral f)))))) (lt= (lambda (x y) (member x (cdr (member y '(t neutral f)))))) (ge= (lambda (x y) (member y (member x '(t neutral f))))) (le= (lambda (x y) (member x (member y '(t netural f))))) (aliases= (t yes yup yeah y) (f no nope nil forgetit))) (define-confidence-set usual-3-val (superclass= discrete-confidence-set) (values-list= yes neutral no) (neutral-equivalent= neutral) (aliases= (yes confirmed) (no ruled-out))) (define-confidence-set continuous-confidence-set (min= 0) (max= 1) (neutral-equivalent= 0.5) (ge= #'>=) (le= #'<=) (member-confidence-set= (lambda (x) (and (>= x min) (define-confidence-set usual-continuous-val (superclass= continuous-confidence-set) (min= 0) (max= 1)) \end{verbatim} \section{Functions to work with confidences and confidence sets} \index{member-confidence} \begin{tabbing} 1234\=1234\=1234\= \kill \\ ({\bf member-confidence} {\it confidence-value\/} {\it confidence-set}) \\ \\ \>\>{\it confidence-value} is a confidence value. \\ \>\>{\it confidence-set} is the name of a confidence set or an instance of a confidence set.\\ \end{tabbing} Member-confidence takes a {\it confidence-value\/}, and returns T if it is a member of the confidence set {\it confidence-set\/}, and nil otherwise. It correctly handles aliases for values in the set. It relies on the member-confidence function of the set itself to handle checking that the argument is of the correct type to be in the set (as given by the set's TYPE= specifier). \index{confidence-compare} \begin{tabbing} 1234\=1234\=1234\= \kill \\ ({\bf confidence-compare} {\it comparison-function\/} {\it arg1\/} {\it arg2\/} {\it confidence-set}) \\ \\ \>{\it comparison-function} is one of {\bf gt}, {\bf ge}, {\bf lt}, {\bf le}, or {\bf eq}. \\ \>{\it arg1} and {\it arg2} are confidence values. \\ \>{\it confidence-set} is the name of a confidence set or an instance of a confidence set. \\ \end{tabbing} Confidence-compare compares {\it arg1} to {\it arg2} using the comparison {\it comparison-function}. (For example, \begin{verbatim} (confidence-compare 'gt 8 6 integer-confidence-set) \end{verbatim} would use the {\bf gt} comparison function of INTEGER-CONFIDENCE-SET to compare 8 to 6, coming up with T if INTEGER-CONFIDENCE-SET uses the default {\bf gt} function of \#'>.) It correctly handles aliases. {\bf NOTE:} confidence-compare does not currently check membership in the confidence sets in question (though it does do aliasing). The only membership checking would be done by the comparison functions themselves, and the system-generated comparison functions do no membership checking. It is therefore important to make sure the values in question are in the right confidence set (using {\bf member-confidence}), before handing them to confidence-compare. Confidence-compare does, however, check to make sure that the arguments it is given, when unaliased, are of the correct type to belong in the confidence set (as give by the set's TYPE= specifier), and signals an error if they are not. \index{unalias} \begin{tabbing} 1234\=1234\=1234\= \kill \\ ({\bf unalias} {\it confidence-value\/} {\it confidence-set}) \\ \\ \>{\it confidence-value} is a confidence value. \\ \>{\it confidence-set} is the name of a confidence set or an instance of a confidence set. \\ \end{tabbing} Unalias takes {\it confidence-value} and checks to see if it is an alias for a value in {\it confidence-set}. If so, it returns the value {\it confidence-value} is an alias for. If not, it returns {\it confidence-value\/}. It does not ensure that {\it confidence-value} is in {\it confidence-set\/}. \index{confidence-set-p} \begin{tabbing} 1234\=123456\= \kill \\ ({\bf confidence-set-p} {\it set-name}) \\ \\ \>{\it set-name} is a symbol. \\ \end{tabbing} Confidence-set-p returns non-nil if {\it set-name} names a confidence set, and nil otherwise. \index{confidence-values} \begin{tabbing} 1234\=1234\=1234\= \kill \\ ({\bf confidence-values} {\it confidence-set}) \\ \\ \>{\it confidence-set} is the name of a confidence set or an instance of a confidence set. \\ \end{tabbing} Confidence-values take the name of (or an instance of) a confidence set, and returns either its VALUES-LIST, or a list containing its MAX and its MIN, depending on which of these it has. \index{conf-set-name} \begin{tabbing} 1234\=123456\= \kill \\ ({\bf conf-set-name} {\it conf-set-instance}) \\ \\ \>{\it conf-set-instance} is an instance of a confidence set.\\ \end{tabbing} Conf-set-name takes an instance of a confidence set and returns the name of the set to which it belongs. \index{return-generic-instance} \begin{tabbing} 1234\=123456\= \kill \\ ({\bf return-generic-instance} {\it set-name}) \\ \\ \>\>{\it set-name} is a symbol. \\ \end{tabbing} Return-generic-instance takes the name of a confidence set, and returns an instance of that set. (Comparison functions, etc., are only retrievable from an instance of the confidence set.) Most functions that any user/system builder will want to use will take a confidence set name as an argument, so this function should not be used by anyone who is not working with the implementation of the confidence-set handling mechanism. It is documented here only for completeness. \subsection{Coercion between confidence sets} The function {\bf convert-form} creates Lisp lambda forms to be used to convert confidence values from one confidence set to another. \index{convert-form} \begin{tabbing} 1234\=123456\=12345\= \kill ({\bf convert-form} {\it source-confidence-set\/} {\it dest-confidence-set\/}) \\ \\ \>{\it source-confidence-set} may be an instance of a confidence set or the name of a confidence set.\\ \>{\it dest-confidence-set} may be an instance of a confidence set or the name of a confidence set. \\ \end{tabbing} Convert-form will return a lambda which, when applied to a member of {\it source-confidence-set\/}, will return a corresponding member of {\it dest-confidence-set\/}. This form will signal an error if the value handed to it is not a member of {\it source-confidence-set\/}, and will take care of handling aliases (you can handle aliased values to this form, and it will convert them just like the values they are aliases of). The following diagrams show the algorithm by which confidence values in one confidence set are converted to confidence values in another confidence set. Note that converting from lower to higher precision causes a loss of accuracy, whereas converting from higher to lower precision causes a loss of precision. \begin{figure} \vspace{7.5cm} \caption{Conversions From Lower to Higher Precision} \end{figure} \begin{figure} \vspace{6.0cm} \caption{Conversions From Higher to Lower Precision} \end{figure} \subsection{Inversion of confidence sets} The function {\bf invert-form} creates Lisp lambda forms to be used to invert confidence values within a confidence set. \index{invert-form} \begin{tabbing} 1234\=1234\=12345\= \kill ({\bf invert-form} {\it confidence-set\/}) \\ \\ \>{it confidence-set} may be an instance of a confidence set or the name of a confidence set. \\ \end{tabbing} Invert-form will return a lambda which, when applied to a member of {\it confidence-set\/}, will invert that value within the confidence set. If the value in question is {\it n} units away from the minimum point of the range of confidence values (either an actual range or a list of values) for {\it confidence set\/}, applying the result of {\bf invert-form} to it will return a value that is {\it n} units away from the maximum value of {\it confidence-set\/}. (For example, inverting the value .2 in a continuous confidence set whose minimum value is 0 and whose maximium value is 1 will result in .8. Invertinf the value 'yes in a discrete confidence set whose values are '(yes neutral no) will result in 'no.) The form produced by INVERT-FORM will signal an error if the value handed to it is not a member of {\it source-confidence-set\/}, and will take care of handling aliases (you can handle aliased values to this form, and it will convert them just like the values they are aliases of). %-------------------Chapter 10--------------------------------------- \chapter{Interactions with the user} In order to make the interface uniform, and to get the results of all interactions into the appropriate memory stores to be used for justification and explanation, the special invoke message {\bf ASK-USER} is provided for communication with the user. (For a description of the use of ASK-USER, see the description on FEATURES in section~\ref{features}.) The user of the system is hidden behind a special dragon called {\bf *USER*}, and all questions to the user are posed by invoking that dragon with ASK-USER. (A call to (ask-user ``question-string'' 'result-type) will, in most circumstances (feature specification, etc), be turned automatically into a call to (invoke *USER* 'ask-user ``question-string'' 'result-type).) ASK-USER does the same sort of answer type-checking as does ASK with IDB's but it does no cacheing whatsoever. In reality, *USER* is a free-form recognition agent. It's definition is given as an example in section~\ref{*user*}. %-------------------Chapter 11--------------------------------------- \chapter{Monitors} The toolset provides a facility for data-driven problem-solving called monitors. You can use monitors to set up a dragon to notify another agent when its value changes. This facility allows the system to monitor and respond to changes in the environment, without requiring that the user explicitly order problem-solving to take place for the changes in the environment to be noted. \section{Functions for using monitors} The method for placing a monitor on a dragon is called {\it cast-spell\/}. It is an actual CLOS method, specialized on its {\it drag} argument. The system provides one version of cast-spell, specialized to handle recognition agents. Other versions may be provided in later releases, and the user is welcome to specialize the {\it cast-spell} method to perform whatever functionality she needs. \index{cast-spell} \begin{tabbing} 1234\=1234\=1234\=1234\= \kill \\ ({\bf cast-spell} {\it drag\/} {\it args\/} {\it report-to\/}) \\ \end{tabbing} Cast-spell sets up a monitor to watch {\it drag\/}. It goes through {\it drag}'s features, and for each feature that is an invoke with the verb {\bf judge}, it recursively calls {\it cast-spell} on the dragon that is to recieve that {\bf judge} message, telling it to report back to {\it drag\/}'s monitor. The {\it args} argument to cast-spell is assumed to be of the form {\bf (verb arg arg \ldots)}, where {\bf verb} is the verb to with which to invoke {\it drag} in order to cause it to do its problem solving, and the {\bf args} are the arguments to that invoke. {\it Report-to} is a monitor to report to when this agent's value changes. When a monitor is placed on a dragon, the form to be monitored, called the monitor's {\it eval-form}\index{eval-form} (in the case of the default method for cast-spell, an invoke of the dragon with the verb and arguments given in {\it args}) is evaluated to get a base value for later results to be compared to. Cast-spell returns the monitor it placed on the dragon. \index{poke-monitor} \begin{tabbing} 1234\=1234\=1234\=1234\= \kill \\ ({\bf poke-monitor} {\it monitor\/}) \\ \end{tabbing} In order to cause a monitor to look at the environment to see if the value it is monitoring has changed, that monitor must be poked with poke-monitor. When a monitor is poked, it evals its {\it eval-form} to see if the value it is monitoring has changed. If it has, it updates the value it is monitoring to that new value, and then pokes all of the monitors it has been told to report to with {\bf poke-monitor}, propagating the change upwards through the hierarchy, until it either reaches the top or reaches a level where the change is not great enough to change the output of an agent's {\it eval-form}. The {\it monitor} argument is the value returned by the call to {\bf cast-spell}. \index{remove-monitor} \begin{tabbing} 1234\=1234\=1234\=1234\= \kill \\ ({\bf remove-monitor} {\it monitor\/}) \\ \end{tabbing} Remove-monitor removes a monitor from the object it was set up to monitor. It will recursively remove all dependent monitors with no other parents. The {\it monitor} argument is the value returned by the call to {\bf cast-spell}. WARNING: do not use this function unless you know there are no other monitors which depend on this monitor (whose values should change if this monitor's value changes). If there are, use {\bf remove-parent-from-monitor} instead. \index{remove-parent-from-monitor} \begin{tabbing} 1234\=1234\=1234\=1234\= \kill \\ ({\bf remove-parent-from-monitor} {\it child\/} {\it parent\/}) \\ \end{tabbing} Remove-parent-from-monitor removes {\it parent} from the list of monitors which {\it child} should report to. ({\it Parent} and {\it child} should both be monitors, returned by {\bf cast-spell}.) If {\it child} then has no parents to report to, it removes {\it child\/}. %-------------------Chapter 12--------------------------------------- \chapter{Justification\index{justify}} The justification mechanism provided in the Fafner release of the toolset allows the tool user to get an explanation of why an agent returned the answer that it did for a given case. The justification mechanism for the Fafner release is only capable of justifying the problem-solving of discrete-pattern-recognition-agents, match-1-recognition-agents, and classification-specialists. Hopefully, more types of justification will be added in later releases. \section{How to use the justification mechanism} To get the system's justification of the response given by the recognition agent {\it dragon} for the case {\it case-name}, use the function {\bf justify}. If {\it case-name} is not specified, it defaults to the last case in which the agent was run. NOTE: Because of memory limitations, the information about a particular invocation of a dragon is only kept for a certain number of invocations of that dragon after it. This number is defined by the dragon's {\bf memory-retention-limit}, which defaults to 8 (but can be changed in the dragon definition). \index{justify} \begin{tabbing} 1234\=1234\= \kill ({\bf justify} {\it dragon} '{\it case-name})\\ \end{tabbing} This will give you a menu which allows you to choose between three levels of justification. These three levels provide different information for recognition agents and classification specialists. \subsection{Justifying recognition agents} When you ask to justify a recognition agent, you will be given a menu which allows you to choose from three levels of justification. Level 1 shows you the features of {\it dragon} and their run-time values. Level 2 again shows you the features of {\it dragon} and their values, and also gives you a comprehensive explanation of why each pattern in the RA failed up until the matched pattern. The matched pattern is displayed, and an explanation is given of exactly why it matched. If no patterns matched, this fact is stated. Level 3 presents you with a menu which allows you to display information about the dragon such as author, citations, rationale, etc. \subsection{Justifying classification specialists} When you ask to justify a recognition agent, you will be given a menu which allows you to choose from three levels of justification. Level 1 tells you what the status of the classification specialist was ({\it established, suspended, ruled-out, not-run\/}). To explain why the specialist had that status, it also tells you what value the specialist's establish-reject method returned, what the effects of the specialist's translator (if any) on that value were, what the thresholds used by the specialist at the time were, and what type of context the specialist got from its parents. Level 2 tells you how the specialist was invoked. Level 3 presents you with a menu which allows you to display information about the specialist, such as author, citations, rationale, etc. %-------------------Chapter 13--------------------------------------- \chapter{Configuring the system} \section{Variable parameters available to the user} \index{*current-case*} \begin{tabbing} 123456\= \kill \\ {\bf *CURRENT-CASE*} \end{tabbing} Used to set and keep track of the current case context. Since the case may have subcases, and subcases may have sub-subcases to arbitrary depth, *CURRENT-CASE* will eventually be a pointer into a tree structure. In Fafner it is treated simply as a global variable. \index{*decision-support-mode*} \begin{tabbing} 123456\= \kill \\ {\bf *DECISION-SUPPORT-MODE*} \end{tabbing} If this is non-NIL the system will pause after each Dragon invocation, report to the user the Dragon's decision in the form of a recommendation, and inquire whether the user wishes to accept the decision or supply another. \index{*invocation-trace-flag*} \begin{tabbing} 123456\= \kill \\ {\bf *INVOCATION-TRACE-FLAG*} \end{tabbing} Used to set whether dragon invocations are traced as they happen. If set to T, then for every invocation, the invoker, invokee, arguments to the invoker, and the result of the invocation are printed out to *TRACE-OUTPUT*. \index{*memory-on-flag*} \begin{tabbing} 123456\= \kill \\ {\bf *MEMORY-ON-FLAG*} \end{tabbing} Used to set whether memory records (engrams) are generated or not as dragons are invoked. If set to T (the default case), then dragons generate memory records. \index{*invocation-single-step-flag*} \begin{tabbing} 123456\= \kill \\ {\bf *INVOCATION-SINGLE-STEP-FLAG*} \end{tabbing} Used to set whether invocations are single-stepped or not. If set to T, then each invocation pauses during execution and waits for a space keypress. \index{*idb-flushed-list*} \begin{tabbing} 123456\= \kill \\ {\bf *IDB-FLUSHED-LIST*} \end{tabbing} Used to indicate whether the memory of a certain IDB has been flushed or not. If the name of the IDB appears in the *IDB-FLUSHED-LIST*, the IDB has been flushed. \index{*csrl-establish-threshold*} \begin{tabbing} 123456\= \kill \\ {\bf *CSRL-ESTABLISH-THRESHOLD*} \end{tabbing} The value used as a threshold to determine whether a classification specialist establishes or not if the current specialist's local-threshold is unset or nil -- to work correctly, must be a member of the specialist's establish-confidence-vocabulary set. Defaults to NEUTRAL. \index{*csrl-suspend-threshold*} \begin{tabbing} 123456\= \kill \\ {\bf *CSRL-SUSPEND-THRESHOLD*} \end{tabbing} The value used as a threshold to determine whether a classification specialist suspends or rules out if the current specialist's local-threshold is unset or nil -- to work correctly, must be a member of the specialist's establish-confidence-vocabulary set. Defaults to NEUTRAL. \index{*csrl-use-cache*} \begin{tabbing} 123456\= \kill \\ {\bf *CSRL-USE-CACHE*} \end{tabbing} The value used at compile-time as a default to determine whether a classification specialist will use its cache when invoked successively in the same case, if the user does not specify USE-CACHE=. Defaults to T. \section{Functions available to the user} The following is a partial list of functions available to the user. Other functions are described in the chapters on confidence, hierarchies, idb's, saving dragons, etc. \index{start-solving} \begin{tabbing} 123456\= \kill \\ ({\bf START-SOLVING} {\it case-name dragon verb\/} [({\it arg arg\/} \ldots)]) \end{tabbing} Prepares the system for problem solving using the case name given and then invokes the {\it dragon\/} using the {\it verb\/} and any given arguments. \index{invoke} \begin{tabbing} 123456\= \kill \\ ({\bf INVOKE} {\it dragon verb\/} [{\it answer-type\/}] [({\it arg arg\/} \ldots)]) \end{tabbing} Invokes the {\it dragon\/} using the {\it verb\/}. This is a form of dragon invocation available for use in specifying features, actions, and control-additions. For standard uses in recognition agent specifications, the JUDGE and ASK verb-first forms of invocation are preferred. However there is no alternative but to use the INVOKE form for non-standard invocations, as, for example, where new verbs have been defined by the user, or where a dragon is being invoked that is not a recognition agent or IDB. When INVOKE is used for a recognition-agent feature, the {\it answer-type\/} argument must be supplied, in order for the system to properly interpret the specifiers for transforms and tests that will be applied to that input. In other cases the argument is optional. In this release the {\it answer-type\/} argument is mandatory for all IDB invocations, to provide the IDB with guidance in what sort of response to make. In later releases, however, this restriction may be relaxed. \index{judge} \begin{tabbing} 123456\= \kill \\ ({\bf JUDGE} {\it recognition-agent\/} [{\it confidence-set\/}] [({\it arg arg\/} \ldots)]) \end{tabbing} The preferred way to invoke a recognition agent from within another recognition agent's definition or a classification specialist's establish-reject method. Not available outside these contexts. \index{ask} \begin{tabbing} 123456\= \kill \\ ({\bf ASK} {\it database question answer-type\/}) \end{tabbing} The preferred way to invoke an intelligent-database agent from a recognition agent or from a classification-specialist's establish-reject method. Not available outside these contexts. \index{ask-user} \begin{tabbing} 123456\= \kill \\ ({\bf ASK-USER} {\it question answer-type\/}) \end{tabbing} The preferred way to query the user from a recognition agent or from a classification-specialist's establish-reject method. Not available outside these contexts. \index{match-pattern} \begin{tabbing} 123456\= \kill \\ ({\bf MATCH-PATTERN} {\it pattern-number success-threshold\/}) \end{tabbing} For use in control-additions for match-1 and free-form recognition agents where several patterns are recorded. This causes the pattern numbered by {\it pattern-number\/} to be matched against the features. The function returns T or NIL depending on whether the number of tests that succeed is greater than or equal to {\it success-threshold\/}. Pattern counting begins at 0. \index{conf} \begin{tabbing} 123456\= \kill \\ ({\bf CONF} {\it pattern-number\/}) \end{tabbing} For use in control-additions for match-1 and free-form recognition agents where several patterns are recorded. Retrieves the confidence value, or confidence setting action, associated with the pattern of the given number. Pattern counting begins at 0. \index{flush-feature-cache} \begin{tabbing} 123456\= \kill \\ ({\bf FLUSH-FEATURE-CACHE}) \end{tabbing} For use in control-additions for recognition agents. Causes cached values for features to be flushed so that attempts to determine feature values (e.g., by using MATCH-PATTERN) will provoke their recomputation. \index{check-feature} \begin{tabbing} 123456\= \kill \\ ({\bf CHECK-FEATURE} {\it i\/}) \end{tabbing} Causes the value of the {\it i\/}th feature to be fetched from the cache if it exists there. If not, it gets the feature value from the FEATURES slot of the recognition agent and caches the result. It does not evaluate {\bf flush-feature-cache}, which the user can do explicitly. \index{fetch-transformed-feature} \begin{tabbing} 123456\= \kill \\ ({\bf FETCH-TRANSFORMED-FEATURE} {\it i\/}) \end{tabbing} Evaluates ({\bf CHECK-FEATURE} {\it i\/}) to get the feature value, and then performs the {\it i\/}th transform to the value in order to obtain the final value. Note that {\bf MATCH-PATTERN} does this implicitly. \index{display} \begin{tabbing} 123456\= \kill \\ ({\bf DISPLAY} {\it thing print-spec\/}) \end{tabbing} Causes {\it thing\/} to be displayed on *TRACE-OUTPUT* with the specified {\it print-spec\/}. Currently {\it thing\/} must be an {\bf engram}, i.e., a memory trace left by a dragon invocation. {\it Print-spec\/} allows the user to print a specific action/transaction/consultation record, or all records stored in the engram. {\it Print-spec\/} may be {\bf ALL}, which prints out all records of {\it thing\/}, {\bf FIRST}, which prints only the first record of {\it thing\/}, {\bf LAST}, which prints only the last record, a positive integer {\it n\/}, which prints the {\it n\/}th record, or a negative integer {\it -n\/}, which prints the {\it n\/}th from the last record. If {\it n\/} is out of range, the last record is printed. If no {\it print-spec\/} is given, all records are printed. \index{remember} \begin{tabbing} 123456\= \kill \\ ({\bf REMEMBER} {\it thing\/}) \end{tabbing} For use in actions and control-additions. Records {\it thing\/} in the engram associated with the currently active dragon. Useful for storing things for explanation purposes. Nothing will be stored when the global *MEMORY-ON-FLAG* is set to NIL. \index{destroy} \begin{tabbing} 123456\= \kill \\ ({\bf DESTROY} {\it thing\/}) \end{tabbing} Destroys {\it thing\/}. Currently {\it thing\/} must be a DRAGON or an ENGRAM. Care has been taken so that destroying {\it thing\/} leaves no dangling pointers, and leaves the underlying structures collectible by the Lisp garbage collector. \index{trace-dragon} \begin{tabbing} 123456\= \kill \\ ({\bf TRACE-DRAGON} {\it dragon\/}) \end{tabbing} Sets up the dragon so that invocations of it will be traced. \section{Talking to Lisp\index{lisp}} In specifying actions, either the special purpose {\it confidence-setting-actions\/} associated with the success and failure of recognition patterns, or more generally, the actions the user may attach at various places to the problem solvers; and also in modifying dragon controllers using the CONTROL-ADDITIONS= specifier; the user is writing in an extension of Lisp. At least this is so for Fafner. The forms the knowledge engineer writes will be processed by Fafner's parser before they are transformed to Lisp and compiled into problem solvers. The parser recursively descends into these forms, checking for certain specially distinguished subforms. Subforms which are not recognized as special are let alone, and assumed to be meaningful Lisp code; special forms are transformed to Lisp according to their special uses, which may depend on context. User defined functions may be called as long as there are no conflicts. After subforms are transformed recursively by the Fafner parser, the resulting forms are set in a (WITH-SLOTS {\it dragon\/}) context (this is CLOS talk). This makes it possible to refer to certain slots that a dragon has in the underlying CLOS object system as if they were variables. In order to prevent unintended name conflicts, while still giving the knowledge engineer convenient access to a dragon's innards, the names of dragon slots that can be referenced will be publicly documented. They appear in Section 4.6 of this document. %-------------------Chapter 14--------------------------------------- \chapter {Saving and Fasloading Dragons\index{save-dragon}} \index{intermediate forms} \index{fasload forms} \index{compiling dragons} This release of the Toolset now provides facilities for creating intermediate (fastloading) forms of CSRL and RA hierarchies. To do this use the SAVE-DRAGON function. \begin{verbatim} (save-dragon dragonname \&optional filename) (save-dragon 'dragonname \&optional filename) (save-dragon '(dragonname1 dragonname2 dragonname3....) \&optional filename) \end{verbatim} This will save the specified dragons to {\it filename}. If no filename is specified, the dragons will be saved to a file named dragonname1.GT, where dragonname1 is the first specified dragon name. If the keyword argument, {\bf :append} is non-nil, if the specified file already exists, instead of creating a new version or destroying the file, appends the new dragons to its end. \section{Loading from fasload forms} To reload the system from fastload forms, simply load the fastload file into a lisp world that has the toolset loaded into it. You do not need to load the source form of the file. Note: these forms do not save the memory of the dragons. If you save a dragon and then load in the saved forms, the memory of that dragon will be destroyed. If there is enough interest, we will look into the possiblity of also saving the memory. \section{Even faster -- compiled fasload forms} To speed up things even more, run the .GT file through compile-file. Ignore the messages about the compiler being called recursively, if there are any. The resulting file can also be loaded directly into a lisp world with the toolset loaded, and will reconstruct the hierarchy as it was before saving. {\bf NOTE:} This option does not work under Kyoto or Ibuki Common Lisp, as their compilers are non-reentrant. It will not work with any non-reentrant compiler. %-------------------Appendix A-------------------------------------- \appendix \chapter{Installing, loading, running, and compiling the Toolset} \section{Installing the Toolset\index{installation}} To install the Toolset, edit the file ``load-toolset.lsp'', following the directions you find therein. There are several fields to customize, all of which are marked with the string ``***\#''. You can easily customize the load file for your site by editing the load-toolset.lsp file, repeatedly searching for the string ``***\#'', and following the directions given with each instance you find. \section{Loading the Toolset\index{load-toolset}} To load the Toolset, start up your favorite Common Lisp. Find the directory with the Toolset code in it. Load the load file, called something like ``load-toolset.lsp''. Then execute the function {\bf (load-toolset)}\footnote{Load-toolset is an external symbol in the TOOLBED package, but is imported into the USER package. If (load-toolset) returns an ``Unbound function'' error, try (toolbed:load-toolset).} {\bf Load-toolset} will attempt to load the binary of each of the toolset files in turn (looking for the binary in the directory specifiec during installation). If, for a given file, it cannot find the binary, it will then try to find the source for that file. The keyword {\bf :sources}, if its argument is non-nil, will attempt only to load the source version of each file. They keyword {\bf :query}, with a non-nil argument, will ask before loading each of the files. {\bf :sources} and {\bf :query} can be used separately or in combination. \begin{verbatim} > (load ``/ai0/toolset/ra-1/load-toolset.lsp'') Loading /ai0/toolset/ra-1/load-toolset.lsp... T > (load-toolset) Loading /ai0/toolset/pcl/defsys.lsp... \end{verbatim} The {\bf load-toolset} function will load PCL if necessary, then will load all of the Toolset, including RA and CSRL. It will finish in the RA-1 package, where you should execute your cases.\footnote{If there are any errors of the ``Unable to find file x'' form, check the installation of the Toolset on your system.} \section{Building a System\index{building a system}} To make a source file, just make an ordinary text file with your favorite text editor, containing the forms necessary to define agents for your RA and/or CSRl system. To insure maximum portability of the file, make the first line of the file a Lisp comment (beginning with a `;'). Make sure the file ends with a carriage return. To load your system, simply load the file(s).\footnote{If you get a load error of the form ``Unexpected end of file'', the most likely cause is unbalanced parentheses.} To run a CSRL or RA case, you use the function {\bf START-SOLVING}. After having loaded the Toolset and your source files (or the fastload versions of your system), execute the following function: \begin{verbatim} RA-1> (start-solving casename topdragon verb) \end{verbatim} where {\it casename} is the name of the case (a symbol or a list of symbols), {\it topdragon} is the {\it unique-name} of the top dragon in your problem-solving hierarchy, and {\it verb} is {\bf JUDGE} for an RA case, and {\bf ESTABLISH-REFINE} for a CSRL case. (Use {\bf JUDGE} if {\it topdragon} is a recognition agent, and {\bf ESTABLISH-REFINE} if {\it topdragon} is a classification specialist.) \section{Compiling the Toolset\index{compile-toolset}} If you wish to compile the toolset, change directory to the directory specified in the Toolset installation as the location of the binary files. Then, start a lisp and load ``load-toolset.lsp''. After that, simply execute the function {\bf (compile-toolset)}. In some lisps, it may be necessary to load the toolset as source code before compiling it. To do this, execute the function {\bf (load-toolset)} before the function {\bf (compile-toolset)}.\footnote{{\bf compile-toolset} is defined as an external symbol in the TOOLBED package, but has been imported into the USER package.} %-------------------Appendix B-------------------------------------- \chapter{Acknowledgements} Support for development of the toolset has been provided over the years by a number of sponsors including the National Science Foundation under grant MCS-8305032 for diagnostic reasoning, the Battelle Memorial Laboratory University Distribution Program for initial prototype design of CSRL, the Air Force Office of Scientific Research under grants 82-0255 and 87-0090 for development of DSPL, the National Library of Medicine of the National Institutes of Health under grant LM-04298 for research in diagnostic reasoning in liver pathology, the National Library of Medicine under Research Career Development Award LM-00083 for research in diagnostic reasoning in medicine, and the National Heart Lung and Blood Institute of the National Institutes of Health under grant HL-38776 for decision-support systems in immunohematology. Support for the Integrated Generic Task Toolset in particular has been provided by the Defense Advanced Research Project Agency, RADC Contract F30602-85-C-0010, and Digital Equipment Corporation. The project has also benefited from grants of equipment from Xerox Corporation, IBM, and Texas Instruments. We are especially grateful to Mike Tanner, Tom Bylander, Todd Johnson, Bill Punch and Dave Herman for their many suggestions and critical comments. Fafner Release Credits: John Josephson, design; Diana Smetters, CSRL, parsers, software integration, revised design and case mechanism of IDB's, revised design and implementation of hierarchies, Fafner release documentation, test cases; Arun Welch, INVOKE function and engrams; Gayle Flores, original design and implementation of hierarchies, documentation; Richard Fox, INVOKE and DESTROY functions, justification; David Lyndes, original IDB design; Dan Oblinger, Monitors. %-------------------Appendix C-------------------------------------- \chapter{Summary of Dragon Specifiers} What follows is a list of the specifiers available in defining the various types of dragons available in the Fafner release. It is indicated for which types they are optional O, mandatory M, or forbidden F. After optional specifiers the default is shown; (-) means that no action will be taken. \begin{tabular}{|l|c|c|c|c|c|c|} \hline Specifier & D.Pattern & Match-1 & F-Form & IDB & C-Spec & Class \\ \hline \hline AFTERWARDS= & O(-) & O(-) & O(-) & O(-) & O(-) & O(-) \\ ANSWER-CACHE-LIMIT= & F & F & F & O(1000) & F & F \\ ARGUMENTS= & O(-) & O(-) & O(-) & O(-) & O(-) & O(-) \\ ASSOCIATED-CONCEPTS= & O(-) & O(-) & O(-) & O(-) & O(-) & O(-) \\ AUTHOR= & M & M & M & M & M & M\\ CHILD-JOIN= & F & F & F & F & O(none) & F \\ CITATIONS= & O(-) & O(-) & O(-) & O(-) & O(-) & O(-) \\ CLASSIFIER= & F & F & F & F & M & F \\ CONTEXT-TYPE= & F & F & F & F & O\footnotemark & F \\ CONTROL-ADDITIONS= & O(-) & O(-) & M & O(-) & O(-) & O(-) \\ COMPONENT-OF= & O(-) & O(-) & O(-) & O(-) & O(-) & O(-) \\ COMPONENTS= & F & F & O(-) & O(-) & O(-) & O(-) \\ CREATION-DATE= & O(-) & O(-) & O(-) & O(-) & O(-) & O(-) \\ DISCLAIMER= & O(-) & O(-) & O(-) & O(-) & O(-) & O(-) \\ DISPLAY-NAME= & O & O & O & O & O & O\footnotemark \\ ESTABLISH-CONFIDENCE- & F & F & F & F & O & F \\ \ \ \ \ \ \ VOCABULARY= & & & & & & \\ ESTABLISH-REJECT= & F & F & F & F & M & F \\ ESTABLISH-THRESHOLD= & F & F & F & F & O & F \\ EXPERT= & O(-) & O(-) & O(-) & O(-) & O(-) & O(-) \\ FEATURES= & M & M & O & F & F & F \\ HIERARCHY= & F & F & O(-) & F & F & F \\ HYPERTEXT-LINK= & O(-) & O(-) & O(-) & O(-) & O(-) & O(-) \\ LAST-MODIFICATION-DATE= & O(-) & O(-) & O(-) & O(-) & O(-) & O(-) \\ MATCH-ACTION= & O(-) & F & O(-) & F & F & F \\ MATCH-CONFIDENCE= & M & F & O(-) & F & F & F \\ MEMORY-RETENTION-LIMIT= & O(8) & O(8) & O(8) & O(1000) & O(8) & O(8) \\ MEMORY-RETENTION- & O(6) & O(6) & O(6) & O(950) & O(6) & O(6) \\ \ \ \ \ \ \ WARNING-LIMIT= & & & & & & \\ NO-MATCH-ACTION= & O(-) & O(-) & O(-) & F & F & F \\ NO-MATCH-CONFIDENCE= & O & O & O\footnotemark & F & F & F \\ OTHER-KNOWLEDGE- & O(-) & O(-) & O(-) & O(-) & O(-) & O(-) \\ \ \ \ \ \ \ SOURCES= & & & & & & \\ OUTPUT-DESTINATION= & O & O & O\footnotemark & F & F & F \\ OUTPUT-CONFIDENCE- & O & O & O\footnotemark & F & F & F \\ \ \ \ \ \ \ VOCABULARY= & & & & & & \\ PARENT-JOIN= & F & F & F & F & O(and) & F \\ PATTERN= & M & F & O(-) & F & F & F \\ PATTERNS= & F & M & O(-) & F & F & F \\ RATIONALE= & O(-) & O(-) & O(-) & O(-) & O(-) & O(-) \\ REFINE-FORM= & F & F & F & F & O(or) & F \\ SAVED-CASE-LIMIT= & F & F & F & O(50) & F & F \\ SPECIFIC-FUNCTION= & O(-) & O(-) & O(-) & O(-) & O(-) & O(-) \\ SUB-SPECIALISTS= & F & F & F & F & O(nil) & F \\ SUCCESS-THRESHOLD= & O(All) & F & O(-) & F & F & F \\ SUPER-SPECIALISTS= & F & F & F & F & O(nil) & F \\ SUSPEND-THRESHOLD= & F & F & F & F & O & F \\ TO-DO-FLAG= & O(NIL) & O(NIL) & O(NIL) & O(NIL) & O(NIL) & O(NIL) \\ TOOL-USER-SLOTS= & O & O & O & O & O & O\footnotemark \\ \hline \end{tabular} \addtocounter{footnote}{-4} \footnotetext{defaults to the print name of the unique name} \addtocounter{footnote}{1} \footnotetext{defaults to NEUTRAL} \addtocounter{footnote}{1} \footnotetext{defaults to whatever invoked the dragon} \addtocounter{footnote}{1} \footnotetext{defaults to USUAL-9-VAL} \addtocounter{footnote}{1} \footnotetext{defaults to no user slots} \newpage \begin{tabular}{|l|c|c|c|c|c|c|} \hline Specifier & D.Pattern & Match-1 & F-Form & IDB & C-Spec & Class \\ \hline \hline TOP-NODE= & F & F & O(-) & F & F & F \\ TRACING-CONTROL- & O & O & O & O & O & O\footnotemark \\ \ \ \ \ \ \ ADDITIONS= & & & & & &\\ TRANSFORMS= & O & O & O\footnotemark & F & F & F \\ TRANSLATOR= & F & F & F & F & O\footnotemark & F \\ USE-CACHE= & F & F & F & F & O(t) & F \\ \hline \end{tabular} \addtocounter{footnote}{-1} \footnotetext{defaults to value of *CONTEXT-TYPE-DEFAULTS*, which defaults to ESTABLISH} \addtocounter{footnote}{1} \footnotetext{defaults to value of CONTROL-ADDITIONS=} \addtocounter{footnote}{1} \footnotetext{defaults to NO-OP} \addtocounter{footnote}{1} \footnotetext{defaults to NIL} Note: ``All'' in SUCCESS-THRESHOLD= above means that all tests must succeed for the success threshold to be met. \chapter{Index} \include{docindex} \bibliography{gt} \bibliographystyle{plain} \end{document}