KnowledgeWright Basic Introduction
KnowledgeWright Basic Introduction
KnowledgeWright Basic is a KnowledgeWright Jig that is a powerful tool by itself, but that also provides the foundation for more specialized jigs. So understanding it is key to understanding a number of jigs.
Any knowledgebase or expert system tool has rules of one form or another that are applied to reason over the data gathered during a particular consultation with the tool.
When looking at any knowledgebase or expert system tool, there are two key factors that tell a lot about the system.
As you might imagine, these factors can range from the simple to the complex for any given tool. KnowledgeWright Basic is designed to be easy to work so it opts for simple direct approaches for both.
Data is represented as fact = value pairs.
For example:
color = "blue" operating_system = "Windows 98" Symptom = "Screen is blank" quantity = 14 Problem = "Screen saver on"
Names of facts begin with a letter and have no embedded spaces (otherwise they must be quoted in single quotes).
Values can be either text strings enclosed in "" or numbers.
Fact = value pairs are the fundamental building blocks of a KnowledgeWright Basic knowledge base.
Consider a simple technical support application. The problem is the user's screen is blank and doesn't know what to do. The solution depends on whether the video monitor is turned off, or the screen saver has kicked in. Rules for this system might be:
#1: if symptom = "Screen is blank" and led_light = "on" then problem = "Screen saver on" #2: if symptom = "Screen is blank" and led_light = "off" then problem = "Turned off"
These rules are checking for the values of some facts on the if, or conditions, side of the rules, and setting the value of another fact on the then, or action, side of the rules.
Note - In the actual KnowledgeWright rule editor, you enter the conditions and actions for a rule in a tabular format, rather than in an if-then syntax as above.
In addition to rules, some facts get their values simply by asking the user. In KnowledgeWright you would specify those facts something like this:
question symptom prompt = "What is the symptom of your problem" menu = "Screen is blank", "other" question led_light prompt = "What is the state of the LED light?" menu = "on", "off"
Note - In the actual KnowledgeWright editor, questions have more options that can be specified.
KnowledgeWright Basic uses what is called goal-driven reasoning. This means it starts with the goal of finding the value for a particular fact.
In the case of the example above, the goal of the system is to determine the value of the fact problem.
So the reasoning engine would look to see if there are any rules that can be used to find a value for problem. It would find the first of the rules above and note that in order to use that rule, it needs to know the value for the fact symptom.
So now it gives itself a new goal, which is to find the value of symptom. There are no rules for symtpom, so it would look to see if there was another way to get a value. Finding a question for symptom, it would use that to ask the user.
Now, depending on the value of symptom, it may or may not have to find a value of led_light. If the user answered other for symptom, then our rules don't apply and our user will be out of luck.
But if the user answered Screen is blank, then our rules might apply so the reasoning engine will give itself the sub-goal of finding a value for led_light. Again, there are no rules, but it finds a question specification and uses that to ask the user.
Now with the sub-goals of symptom and led_light solved, it can proceed to find a value for the original goal, problem.
Here's a dialog a user might have with our simple system:
goal problem What is the symptom of your problem? (Screen is blank, other) Screen is blank What is the state of the LED light? (on, off) on answer, problem = Screen saver on
We might prefer to tell the user what to do, once we've found out the problem, rather than just state the problem. So we might add some rules like this:
#1: if problem = "Screen saver on" then action = "Move the mouse" #2: if problem = "Turned off" then action = "Turn the monitor on"
We would now run our system with the goal action.
The reasoning engine would find these rules for action, and determine it needed to first find a value for problem. And then it would work as above, looking for the problem.
Because of the goal seeking nature of the system, and how rules link to other rules based on those goals, you can represent both simple and quite complex diagnostic or advice giving applications with KnowledgeWright Basic.
The advantage of a rule-based system like KnowledgeWright Basic, is that you can add additional knowledge to the system without programming. So we could increase the knowledge in the tech support system by adding these rules:
#3: if symptom = "Mouse doesn't track well" and rollers_clean = "no" then problem = "Dirty rollers" #4: if symptom = "Mouse doesn't track well" and rollers_clean = "yes" then problem = "Mouse is broken" #3: if problem = "Dirty rollers" then action = "Clean the rollers of your mouse" #4: if problem = "Mouse is broken" then action = "Buy new mouse"
We would also add the "Mouse is broken" symptom to our list of symptoms we can ask about, and a question about whether the rollers have been cleaned recently.
The reasoning engine will only ask the user for values of facts that it needs. So if the user's symptom is the faulty mouse, then the engine will not need to ask the user about the LED light. Likewise, if the symptom is the blank video screen, then the user will not be asked about mouse rollers being clean.
A trace of how the reasoning proceeds would look like this:
goal action
considering first rule for action (move mouse)
subgoal problem
considering first rule for problem (screen saver)
subgoal symptom
asking user symptom
found symptom = "Mouse doesn't track well"
first rule for problem doesn't apply (screen saver)
second rule for problem doesn't apply (turned off)
considering third rule for problem (dirty rollers)
subgoal rollers_clean
asking user rollers_clean
found rollers_clean = "no"
found problem = "Dirty rollers"
first rule for action doesn't apply (move mouse)
second rule for action doesn't apply (turn on)
considering third rule for action (clean rollers)
found action = "Clean the rollers..."
KnowledgeWright Basic also supports text objects, which allow for relatively large chunks of text to be the values of facts. So you might have a text object like:
text clean_mouse Clean your mouse by taking off the plate on the bottom and ...
This gives the directions on how to clean your mouse. It could be used as the value of one of the rules, so instead of
action = "Clean the rollers of your mouse"
you would have
action = clean_mouse
Now the user would get the more detailed information about cleaning mouse rollers.
Text objects can also be dynamically generated by taking advantage of the goal-seeking behavior of the reasoning engine. That is, a text object can be made up of the values of other facts.
For example, our tech support system might want to present the user with a document explaining the situation. It could do that like this:
text: final_report The system has determined that the problem is %problem%. The action(s) you should take to fix the problem are: %action%.
The %%s indicate that the reasoning engine should find values for those facts and to put the values in the text at the indicated places.
Now you can give the system the goal of finding a value for final_report. The reasoning engine would then locate the text object for final_report and notice that it has to get a values for problem and action. It would then proceed as before, and at the end display to the user the constructed value of final_report:
The system has determined that the problem is dirty rollers. The action(s) you should take to fix the problem are: Clean your mouse by taking off the plate on the bottom and ....
Of course, the text objects can all contain HTML for deployment on the Web. But this is enough talk, its time to start playing with the system.