The PROXS sample application shows how a subset of Prolog rules can be used for a simple identification expert system (XS). The sample XS encodes a portion of a book on birds of North America. It is not meant to be complete, only a demonstration.
There are two Amzi! Prolog parts to PROXS. One is the Prolog rules used to encode the knowledge, which, in the case of the sample XS, is bird identification knowledge. These rules use a subset of Prolog and, since they are interpreted in source code format, can be modified by a user of the system.
The other part is a collection of compiled Prolog predicates that provide helping services to the expert system, such as querying the user when information is needed and remembering the answer to queries so they aren't asked again. These predicates also know how to answer questions about a given session, such as how was a result reached and why is a specific question being asked.
The two Prolog parts are integrated with a Delphi user interface.
PROXS Knowledgebases - Some background on expert systems and where the PROXS knowledge bases fit in.
PROXS Application Architecture - Details on the application architecture, including annotated source listings.
www.amzi.com - Additional demos, articles, freeware, evaluation copies and information about Amzi! Prolog + Logic Server.
We welcome any and all comments about this demo. Contact us at www.amzi.com
The terms 'expert system' and 'knowledge base' often refer to collections of rules that encode knowledge, or expertise, in a way it can be used by a computer. For example, the bird identification sample knowledge base has rules that were derived from the experts who wrote 'Birds of North America.'
Many Amzi! customers have implemented more practical systems, such as Xircom's installation advisor that provides configuration advice when installing network cards on PCs, Arla's process control advisor that provides advice for tweaking the cheese manufacturing process to ensure a consistent product, and a major computer vendor's marketing CD that provides technical advice for prospects looking at their systems.
The rules by themselves are useless. They need to refer to dynamic data, often called 'working memory,' which changes from run to run. For the bird identification system, this data is the collection of the user's responses to questions. The configuration advisor gets information from both the user and the PC directly, whereas the process control advisor gets its information from sensors connected to the manufacturing process.
Finally, some type of control program is needed, to decide which rules to fire and when. This is called an 'inference engine.' The inference engine and related tools are often called an expert system shell. The rules and data of a particular application are the actual expert system or knowledge base.
Each of these elements, the rules, the data and the inference engine, can range from the relatively simple to the quite complex, depending on application needs. A full discussion is beyond the scope of this document, but no matter what the needs, Prolog is an excellent tool for implementing any type of expert system.
This document describes the components of the PROXS expert system shell and the birds knowledge base.
The data representation in PROXS is the simplest kind, which is attribute(value) pairs. This representation is used throughout, from the highest level goals, such as bird(albatross) to the detailed information such as color(white). The syntax used is a natural Prolog syntax.
The basic information is gathered from the user, who is asked if, for example, color:white is true or not for the bird in question, or who is given a list of menu choices from which to choose a value for size.
The rules in PROXS express relationships built from the underlying facts. The rules are a subset of Prolog syntax, sticking to attribute(value) clauses. For example, the following are the rules that will lead to identifying one of the two types of albatross in the system.
order(tubenose) :- nostrils(external_tubular), live(at_sea), bill(hooked).
family(albatross) :- order(tubenose), size(large), wings(long_narrow).
bird(laysan_albatross) :- family(albatross), color(white).
bird(black_footed_albatross) :- family(albatross), color(dark).
The first rule can be read as 'the order is tubenose if the nostrils are external tubular, the bird lives at sea and the bill is hooked.' (It is relatively easy to provide this type of rule syntax as well, which might be useful if the rules are to be viewed by non-technical individuals.)
Prolog has an inference engine built into the language that can be used directly for many expert system applications. PROXS makes some modifications to normal Prolog inferencing, which we'll discuss later, but in general uses it as is. Given a goal, normal Prolog inferencing looks for rules that match the pattern of the goal on the left of the ':-' symbol (called the neck and read as 'if'). If it finds one, then it takes each of the list of goals to the right of the ':-' and uses it as a subgoal.
If a subgoal fails, then it 'backtracks' and looks for other matches.
For example, given the rules above and the goal bird(X), where X is a variable, Prolog will first try the rule for bird(laysan_albatross).
The first subgoal is then family(albatross), and its first subgoal is order(tubenose) and its first subgoal is nostrils(external_tubular).
nostrils(external_tubular) does not have an inference rule as above. Rather, it is something that requires an answer from the user. In the rule base this is represented by a special rule like this
nostrils(X) :- ask(nostrils,X).
which will trigger a simple yes/no query to the user. Some attributes have menu choices, represented like this
size(X) :- menuask(size,X,[large,plump,medium,small]).
which will trigger a query with a menu.
ask and menuask are called Prolog predicates, and they are implemented in the inference engine portion of PROXS.
Say the system finds out that family(albatross) is true, while it's working on bird(laysan_albatross). The next goal is color(white). If the answer is yes, the bird is identified. If the answer is no, then the bird is not a laysan_albatross, and Prolog backtracking will try the next rule that matches bird(X), which is the one for bird(black_footed_albatross).
This is where the PROXS system makes some modifications to normal Prolog inferencing. Ordinarily, once Prolog starts on bird(black_footed_albatross), it will start all over again with family(albatross) and ask all the same questions. To avoid this repetion, ask and menuask are designed to remember the answers to questions, so they don't have to be asked again.
Given this, family(albatross) will silently succeed the second time, and the next question the user will see is color(dark). If the answer is yes, then the bird is identified as a black_footed_albatross. If the answer is no, then, given just the rules above, the system will stop in defeat.
Some expert systems require various types of explanations as to how results were reached. Typically these are used either to educate or assure the user, or as diagnostic aids for the developers. The PROXS inference engine supports three types of explanations.
'How' explanations are used to show the rule that applied to reach a result. So, asking how bird(black_footed_albatross) would show the rule that led to that conclusion.
'Why' explanations are triggered when the user selects 'why' as an answer to a question. The why explanation shows the chain of inference that led to the question being asked. Ask 'why' to the first question posed by the bird system and you will see the goals from the rules above listed.
'WhyNot' explanations are like 'how' explanations, only they show why certain results were not choosen. For example, if the answer was bird(black_footed_albatross) then whynot bird(laysan_albatross) would show that color(white) fails.
The PROXS rules and data representation use normal Prolog syntax. The PROXS inference engine is the basic Prolog inference engine with modifications that allow answers to questions to be remembered, and explanations of results and questions to be presented.
The PROXS demo application is composed of three distinct parts. The core logic of the system is coded in Prolog. The user interface is coded in Delphi. The knowledge bases used with the system are coded in a subset of Prolog.
Source code for each is available below.
PROXS Engine - The PROXS shell provides a few simple extensions to normal Prolog, that make it possible to create knowledge bases using simple Prolog rules.
PROXS User Interface - The user interface is written in Delphi. It provides both the front end to the application and the back end. The front end is the normal menu and controls of the main form. The back end is the extended predicates implemented in Delphi that are called from the Prolog engine. These are either output predicates, or predicates that prompt the user for information. See also the dialog box for goal, how and whynot queries. For each type of query, a different PROXS predicate is called to generate a list of choices for the user. The Prolog list is used to populate the list box.
Birds Knowledgebase - The sample bird identification knowledge base uses rules derived from a portion of 'Birds of North America' by Robbins, Bruum, Zim and Singer. The rules follow the normal animal heirarchy, with rules for order, family and individual bird. The attributes that require user input are listed at the end. The goal top_goal/1 is used by the PROXS inference engine when no specific goal is given.
Copyright ©1996-98 Amzi! inc. All Rights Reserved.