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 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.
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.)
PROXS Inference Engine
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(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).
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.
'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.
Copyright (c)1996 Amzi! inc. All Rights Reserved.