Working with PIE Knowledge Base Rules
PIE can obtain its knowledge base rules from any source. An XML parser is provided, as well as a brief example XML rule set. However rules are imported into PIE, they can be challenging to produce.
Essentially, an expert system requires that a "blob" of human knowledge be decomposed into a set of rules. These rules are expressed in a simple way, so seemingly simple ideas appear to require complex implementation. However, this is actually where the power of an expert system comes to the fore. No rules have any implied outcomes, so values don't change unless they're explicitly made to do so. This makes an expert system very thorough in it's ability to evaluate conditions and explain the result.
Here's a brief rule set, expressed in pseudo-code. It checks the state of two servers; if either is "up" then the service is deemed to be "available". However, if both are down, then the service is "unavailable".
IF server1 IS "up" THEN SET service TO "available";
IF server2 IS "up" THEN SET service TO "available";
IF server1 IS "down" AND server2 is "down" THEN SET service TO "unavailable";Note that there is no "else" clause, that programmers may be used to. This requires explicit rules for every permutation to be created (again, all part of having no implied states).
For PIE's XML rule parser, the above rules would be written as:
<xml>
<pieknowledgebase>
<rule name="Check Server 1 Up">
<condition attribute="server1">up</condition>
<action attribute="service">available</action>
</rule>
<rule name="Check Server 2 Up">
<condition attribute="server2">up</condition>
<action attribute="service">available</action>
</rule>
<rule name="Check Servers Down">
<condition attribute="server1">down</condition>
<condition attribute="server2">down</condition>
<action attribute="service">unavailable</action>
</rule>
</pieknowledgebase>
</xml>In the XML case, rules are given names. These names can be used to identify how a decision was reached when asking the system to explain a given outcome.
The above example shows boolean constructs of OR and AND (familiar from traditional programming). The first two rules form an OR case; that is, if either of them is true then the service will be set to "available". The third rule is an AND case, because it requires two conditions to be met before the service is set to "unavailable".
The example does not show how a rule can also have multiple actions. It can set as many attributes as required when the conditions are met.
In addition to rules, there is also the concept of questions. Questions allow the system to find out the values for a given attribute. As delivered, PIE asks questions interactively via the system console. This is not a requirement; questions could be used to make PIE interrogate system settings, or ask for information from a network. Questions are essentially the means by which external information is entered into PIE (although other means exist with Perl programming).
A question sets a single attribute, and in XML is expressed as follows:
<question attribute="server1">What is the state of server 1?
<response>up</response>
<response>down</response>
</question>Here, the use would be asked "What is the state of server 1?" and given two choices for their answer. In many applications, it may be perfectly acceptable for the user to say they don't know the answer, which requires that an extra <response>..</response> be provided for this purpose. If no responses are specified, the user could answer anything they want. This may not be sensible, because the user could easily enter something that is slightly different from what the rules expect (eg. the rules may expect "up" and "down", but the user may enter "working" or "not working").
When working with XML files, it may be preferable to break the system into parts and use a separate XML file for each. For example, all the questions could be in one file, and the rules in another. This may ease the complexity of creating the knowledge base.
PIE has a feature to check the knowledge base integrity. It checks every attribute used in every rule and makes sure that attribute can be set by a question or another rule. The check also makes sure all questions set attributes that are used in the rule set. These checks ensure that all used attributes can be set, and that there are no redundant questions.
