PCjs Machines
Home of the original IBM PC emulator for browsers.
PC-SIG Diskette Library (Disk #976)
[PCjs Machine "ibm5170"]
Waiting for machine "ibm5170" to load....
Information about “MANAGEMENT ACTION EXPERT”
MAE (Management Action Expert) is an expert system shell that can solve
problems in a non-procedural manner from an application of rules and
facts about a problem.
MAE reads a file known as a "knowledge base," and asks you a series of
questions to determine the cause of the problem. Based on the answers
and the information in the knowledge base, a recommended course of
action is given.
Create your own knowledge base with a few simple commands and use the
program for a variety of applications.
FILE0976.TXT
Disk No: 976
Disk Title: Management Action Expert
PC-SIG Version: S3.1
Program Title: Management Action Expert
Author Version: 3.2
Author Registration: $25.00
Special Requirements: None.
MAE (Management Action Expert) is an expert system shell that can solve
problems in a non-procedural manner from an application of rules and
facts about a problem.
MAE reads a file known as a ``knowledge base,'' and asks you a series of
questions to determine the cause of the problem. Based on the answers
and the information in the knowledge base, a recommended course of
action is given.
Create your own knowledge base with a few simple commands and use the
program for a variety of applications.
PC-SIG
1030D East Duane Avenue
Sunnyvale Ca. 94086
(408) 730-9291
(c) Copyright 1989 PC-SIG, Inc.
GO.TXT
╔═════════════════════════════════════════════════════════════════════════╗
║ <<<< Disk #976 MANAGEMENT ACTION EXPERT >>>> ║
╠═════════════════════════════════════════════════════════════════════════╣
║ To unarchive the program, type: UNPACK MAE.ARC ║
║ ║
║ To run the program Management Action Expert, type: MAE (press enter) ║
║ ║
║ To print the documentation for Management Action Expert, Type: ║
║ COPY MAE.DOC LPT1: (press enter) ║
╚═════════════════════════════════════════════════════════════════════════╝
CIR.DOC
Client Information: Access, Security And Technology.
----------------------------------------------------
Abstract
--------
The necessity of record keeping is reviewed. Client privacy and
confidentiality are recognized as important determinants of
record keeping. The grounds for policies and procedures to
govern record keeping, with primacy to client 'ownership' of
their own data, are reviewed. Finally, the role of an emerging
computer software technology, Expert Systems, in assisting staff
to administer such policies is explored.
-----------------------------------------------------------------
Keeping records is a vital part of any rehabilitation process.
They are necessary to track progress during a rehabilitation
episode and to provide continuity between episodes, even if these
are separated by years. Records of all the services provided
within an organization are the statement of outcomes for that
organization, and at least in theory, the records of all the
organizations in a given area amount to the history of work in
that sector of the industry. In not-for-profit agencies,
services are the outgoing side of the ledger, and records are the
beinnings of financial accountability for services. Without
records, evaluation of service quality and effectiveness is a
dream.
Record keeping, however, is not without cost. Tangible costs
are those of collecting, storing, processing and rectrieving
information and records. Unless record systems are carefully
designed to meet information goals, they rapidly become costly
exercises in 'make work'. And they can make plenty of it !
Since many of the costs are widely distributed or hidden amongst
other administrative overheads, the burden of record keeping is
frequently unrecognized.
Perhaps the most important and intangible cost of record keeping
is the loss of client or patient privacy, and the accompanying
risk of compromising client or patient confdentiality. Any
serious client information system must address these issues. It
is important for the organization to have a clear, formal policy
on the issues. What is more, such a policy must be widely
communicated and the terms of this policy enforced.
The first step in developing such a policy is to consider the
issue of client consent. What consent procedures or forms
currently function in your organization ? Do they mention
permission to keep records and exchange information ? It
important that a client record system rest on an adequate basis
of client consent. It is useful if the terms of the consent are
the same throughout the organization. The wording of the
consent need not be legalistic, in fact in the interest of
informed consent it should be simple,direct and descriptive.
Such a consent should allow the organization to keep records as
necessary, for professional reasons only. Permission to
exchange information with other relevant professionals and
agencies for the purposes of facilitating services to the client
should also be sought.
For a variety of reasons, clients may refuse to give their
consent for these activities. It is their right to do so. It
is useful if the policy guiding the administration of consent is
sufficiently flexible to allow clients to negotiate the terms of
a consent with which they will feel comfortable. It is
important that the organization then work within the terms of
that consent.
Once the terms of the client consent have been settled the policy
maker should turn their attention to the question of access.
Who needs access to the client record and when ? Related to
this is the issue of security, that is stopping people who have
been denied access gaining it in any event.
Internal access should be governed by the relevance of the
request for information to delivery of service to a client.
This will depend on the working arrangements of the organization.
If there is a heirachy amongst service deliverers this will need
to be catered for. However, no one should have veto over access
policy. The records administrator needs to be given the
organizational clout to say 'No' to anyone in the organization
who wants access to client information outside the agreed
guidelines. Particularly sensitive areas should be catered for
with special access arrangements if necessary. An example would
be enhanced security on the client record of people who have
received serives and work for the organization or clients who
serve on the board of management
External requests for information are relevant to the service
needs of the client and the terms of the consent obtained. A
consent by the client to the requesting person or organization
can override those terms. At any time, the client should be
given the opportunity of directing access to his/her record.
After all, the information collected is in a very intimate way
their property. Approaching the issue in this fashion provides
a first principle which will clear away many imaginary barriers
and problems in administering record access.
Some external requests for information are of course
irresistable. These are legally enforcable requests such as
subpoena and those made by government bodies with extraordinary
powers to force access, such as the Taxation Department. Such
requests must obviously be complied with.
Security is an issue which is often thrown up during
computerization of the client information function. People are
legitimately concerned that computer records may be more easily
compromised than physical ones. Their faith in your answer will
depend on the integrity with which physical files have been
handled. In general terms, it is in fact easier to define and
enforce security in a computer system than it is in a physical or
paper record system.
Many organizations do not take adequate steps to secure physical
files. Files should be well controlled, housed in a secure
environment when not in use, and in accountable hands when they
are used. Rooms which house record systems should be locked
when not under the supervision of a responsible manager and
filing cabinets must always be lockable.
Computer systems should have access controlled by password and in
shared systems, file protection mechanisms offered by most
operating systems should be used to guard against unauthorized
access. Controlling access to actual computer equipment is also
effective in stopping casual inspection of records. An
important point to note is that for the forseeable future client
record systems will consist of both computer and paper records,
and the need for adequate security on both is the same.
Once the points above have been resolved in terms which accord
with the philosophy and practice of the organization, and have
been agreed by relevant management, they need to be put into
practice. Traditionally, this would involve drafting and
issuing a policy statement, and perhaps a procedural document.
If a manual of Policies and Procedures exists, then such
statements would be included in it. An additional step would be
to include coverage of these policies in both orientation and
refresher training programs within the organization.
One of the classic problems which emerges is that such statements
of policy, when sufficiently exhaustive to cover likely
eventualities, become complex documents. While these state a
defensible position, they are not always useful to the staff on
the spot in assisting them to make their decision about releasing
or allowing access to client information. People often do not
read manuals until they know they have made a mistake, which is
ironic because the manual is there to help them not to make that
error. The problem is compounded when the issue is one which
staff confront infrequently, so lessons learnt in one epsiode can
easily extinguish before the situation is confronted again.
A computer technology called Expert Systems, currently growing in
use offer a possible avenue to address this problem. Expert
Systems are a software technique for embodying decision making
knowlege in an operational way. Procedures such as the rules
governing the release of client information are the sort of
problem domain in which they work well.
A variety of commercial systems to build Expert Systems exist,
ranging from very expensive systems designed to run on mainframe
computers, to relatively cheap systems to run on micro-computers.
I have designed and written a system (MAE or Management Action
Expert) to run on personal computers. Using this tool I have
written an example Expert System to show how such technology
could be used to assist the staff of client service
organizations.
Using the system is called a consultation. When a consultation
is commenced the system loads the rules about client information
release (the collection of rules is called the 'Knowledge Base').
While it is doing that it, a preliminary Flag page of information
about the purpose of the Knowledge Base is displayed, as in
Figure 1.
Figure 1
--------
Preliminary Expert System Display
---------------------------------
Management Action Expert [MAE] Inference Engine V2.02 27-Dec-1987
K Base is: a:cir. LOG is: NONE. Attributes = 8 Rules = 34
-------------------------------------------------------------------------
Rehabilitation and Welfare Agency
Client Information Release
--------------------------
Expert System Advisor
Author: Charles C. Britton
When asked for information about a client, it is
very important to maintain client confidentiality,
but at the same time aid service to the client.
This system will help you in the decision about
how much information to release to whom under
what circumstances.
NOTE: SHOULD THERE BE ANY POSSIBLE AMBIGUITY OR CONFUSION
ABOUT ANY REQUEST FOR CLIENT INFORMATION, REFER THE
REQUEST TO RELEVANT SENIOR MANAGEMENT !
-------------------------------------------------------------------------
Press any key to start Query
Knowledge Base Loaded
Once the Knowledge Base has loaded, the Expert System then
presents the staff member with a list of possible choices about
who is making the request for information, as is Figure 2.
Depending on the choice made here, the Expert System will prompt
for further information relevant to the decision path which is
being taken. Thus, for instance, if Item 6 in Figure 2 (Co-
Ordinator) were chosen, the query
What is the status of the client ?
1) NON-CURRENT
2) CURRENT
3) STAFF
would appear, whereas if Item 2 in Figure 2 (Solicitor) were
chosen, the query
Has a subpoena for this information been issued ?
1) NO
2) YES
would be issued.
When the particular path produced by the queries and answers
concludes, the Expert System produces a recommendation for
action. In the instance when the person requesting the
information is the co-ordinator, the client is a staff member, in
which the co-ordinator has a legitimate professional interest,
but for which the client has not given a specific request, this
system gives the advice that:
RELEASE_ACTION value is ...
Deny access, until Client consents to this request.
This is one of many possible paths through the Expert System, and
one of many answers it may give. The point illustrated is not
the action that should be taken under the circumstances described
- your organization may well solve the problem differently. The
point is that the person who needs to make the decision can be
stepped through the solution to the problem by the Expert System.
They did not have to wade through a five page document full of
details and policies irrelevant to the problem at hand. The
system focusses attention on relevant factors, but makes sure
that steps in the decision process are not skipped.
Figure 2
--------
Expert System Choice Display
----------------------------
Management Action Expert [MAE] Inference Engine V2.02 27-Dec-1987
K Base is: a:cir. LOG is: NONE. Attributes = 8 Rules = 34
-------------------------------------------------------------------------
Who is making the request ?
Choose the number of an option below:
1) CLIENT
2) SOLICITOR
3) GOVERNMENT
4) MEDICAL
5) STAFF
6) COORDINATOR
7) OTHER
-->
-------------------------------------------------------------------------
Type ? for more information on prompt
The Expert System could be written to embody any set of rules
whch are agreed upon for the release of client information. It
provides an alternative technology to paper and ink as a method
of communicating that policy to the actual decision makers on the
job. What it does demand is ready access to computer resources
for those people to be able to consult such an advisor when and
as they need to. This is a relatively simple example of the
technology at work, but the application of the technique to
larger and more complex procedural problems is simply a question
of working out an adequate rule structure. In fact doing so
frequently forces a critical examination of the rules in place,
to the surprise of all concerned in terms of what is really
important in making the relevant decision.
MAE.DOC
Management Action Expert
---------------------------
Introduction
------------
MAE or Management Action Expert is a simple general purpose Expert
System shell. A knowledge base, defined in terms of rules and
data about the components of the rules known as 'attributes', is
read by the system at the beginning of a 'consultation'. Based
on the answers given by the operator, and the state of knowledge
generated by the internal operation of the system, a recommended
course of action relevant to the problem domain covered by the
Knowledge Base is given. The system can be asked to justify it's
working at this point.
Expert Systems are part of the more general area of interest known
as Artificial Intelligence. They are being explored by most major
corporations and many government agencies. They have found practical
application in many industrial and commercial niches, where they
allow the knowledge of experts in a given field to be codified and
stored in an operational way which makes it available to people who
are less expert in the field. Hence the term Expert System.
Operation of the MAE system
---------------------------
The Management Action Expert is invoked from the DOS prompt in
two ways:
1) issuing the command MAE, thus:
C:>MAE <Return>
The MAE program will load, and display a flag page
of information about the system, and the conditions
of use, see Attachment at end of this file. To
continue, press the <Return> key.
MAE will next prompt you for the name of the
knowledge base to be loaded. This is the name of the
.KB (Knowledge Base) file as described below in the
section entitiled Knowledge Base Documentation. To
run the demonstration knowledge base which
accompanies the MAE program, you enter:
PC <Return>
You are then asked for the mode of DEBUG you wish to
generate. MAE has the facility to generate a trace
of it's internal workings. This can be directed to
the screen or written out to the printer or to a
disk file with the name of the knowledge base and
the extension .LOG. Using a Debug log may slow the
system down, and is not required. Unless you are
developing a new system it should not be necessary
unless you are curious to see what goes on behind
the scenes.
2) issuing the command MAE, with the name of the KB you
wish to use, thus:
C:>MAE PC <Return>
The MAE program will load, and will then
automatically load the nominated KB. This is a
useful feature if you wish to run MAE from a DOS
batch file for instance. You do not have the option
of creating a Debug output and when the KB session
terminates, your options are limited to consulting
again or exit, you cannot load another KB without
terminating MAE.
If a FLAG has been defined for the KB (see below) then the flag
text will be displayed during the rule load.
Once the Knowledge Base has loaded the second line of the screen
displays a status line, which shows you the name of the Knowledge
Base selected and the name of the .LOG file, or NONE.
How many rules and attributes are in the Knowledge Base are also
displayed on the status line when they have been loaded, and
their appearance indicates a successful load of the KB file.
The user will then be prompted to push Return to clear the screen
and continue with the KB query.
Once the load phase has completed, the status line for the
PC Knowledge Base is:
-----------------------------------------------------------------------
Management Action Expert [MAE] Inference Engine V3.20 15-DEC-1989
K Base is: PC. LOG is: NONE. Attributes = 22 Rules = 31
-----------------------------------------------------------------------
You will then be presented with the first prompt options for
information required by the system to solve the goal defined in
the KB file. You have the option at this point of typing a
'?'. In response, the system will display help text about the
question being posed.
After requesting help, or without it if it is not needed, you
select the number of the answer option which answers the question
for your problem. MAE will either list another question and set
of answer options, in which case you proceed as above, or MAE
will provide you with a recommendation, such as the one below:
FIX_PC value is ...
Increase buffers allocated on BOOT.
The appearance of this recommendation indicates that you have
completed the consultation.
An alternative is that MAE will run another KB, or provide access
to an external file of information screens. How this is
achieved is described in the manual below. If either of these
outcome actions occurs, the next section about asking MAE to
justify the outcome does not apply.
You will then be asked if you want the system to justify why it came
up with this recommendation. You must answer:
Y
or
N
If you answer Y, MAE will display:
Firstly, the set of facts you gave, or it discovered during
the consultation, and the values attached to them.
Secondly, the particular rule which was found to be true and
render the recommendation.
If you answer N, or after these justifications have been displayed, MAE
will prompt you with three possible options;
K: which enables you to consult this Knowledge Base again,
perhaps responding in a different way and so provoking a
different recommendation.
A: which enables you to load a different Knowledge Base, and
proceed to consult it.
Q: which leaves MAE, and returns you to the operating system.
Brief Sample Session using the
PC Knowledge Base
------------------------------
What follows below is the briefest possible consultation with MAE.
The operator responses are enclosed in angle brackets <thus>.
------------------------ START CONSULTATION ---------------------------
Are the expectations of the user's realistic ?
Choose the number of an option below:
1) NO
2) YES
--> <?> <Return>
Before complaint, users should be aware of the capabilities of the PC.
1) NO
2) YES
--> <1> <Return>
FIX_PC value is ...
Send users on training course.
--> Do you want the system justify this conclusion [Y/N] <Y>
The reason for this conclusion is:
The attribute EXPECTATIONS was given the value NO
--> Press any key to continue
This makes the following rule true:
For the rule ROOT-4
if
EXPECTATIONS is NO
then
The correct course of action is :
Send users on training course.
--> Press any key to continue
------------------------ END CONSULTATION -----------------------------
Knowledge Base Documentation
----------------------------
The knowledge base consists of text rules stored in a single
file, the filename of which is effectively the name of the
knowledge base. This should be a plain ASCII format file created
with a text editor, not a file from a wordprocessor which may
embed stray control characters in your text.
For example, one of the example knowledge bases is called PC, and
consists of a file called PC.KB. This contains the goal and the
rules which ultimately satisfy the goal and the attributes for
the rule base, which describe the aspects of the knowledge base
given values in the rules.
SYNTAX for structuring the Knowledge Base with MAE.
---------------------------------------------------
General Syntax:
COMMENTS
--------
Comments are marked with an asterisk - '*'.
Any material in a line after an '*' will be skipped when
being read into MAE, so it should never be used in a rule
or attribute element.
Comments should be included to name the Knowledge Base to which
the file belongs, to note the Author and Date created, and to
record any significant edit history. Much the same as for good
program documentation. For example:
*
*
* PC Expert System
* ----------------
*
*
* Author: Charles C. Britton
* Date: February 1987
*
Comments can also be used to delimit segments of the relevant
file and for simple spacing between rules or attributes.
For example:
*
***************
*
* RULES TO INVESTIGATE APPLICATION USE OF MEMORY
*
***************
*
LITERAL TEXT
------------
The knowledge base consists of 2 types of text, that which is
used by the Inference Engine to make it's decisions, and
that which is displayed when a decision is made or a
question is asked. That which will be used for screen
displays must be surrounded by double quotation marks,
thus:
"This material would be displayed on screen".
Otherwise, MAE converts all unquoted lower case to upper
case and strips all spaces away. Only quoting one end of
a screen literal will lead to unpredictable results from MAE.
SPACING
-------
Spacing is not important, since spaces are
stripped out, except where literal text has been quoted.
GOAL definition.
----------------
A goal must be specified once and once only in each rule
file, in the form
GOAL 'goal name' or PROMPT
'goal name' must be an attribute defined as an
attribute capable of being resolved as a goal. If
PROMPT is specified, then MAE will prompt for a
goal at runtime, when the goal must conform to the
points above.
FLAG definition.
----------------
A FLAG is optional in the KB file. If defined it will
be displayed during the loading of the KB, so long as it
is defined early in the KB file. It can be defined
anywhere. Display of a flag page during the load can be
a useful diversion for the user during a long load of a
large KB.
The start of a FLAG block of text is marked by the key
word FLAG. Flag text then follows. Each line of such
text needs to be enclosed in "double quotes". The end
of the block is marked with the key word ENDFLAG.
Rule Syntax:
------------
Each rule is defined as a block, beginning with the RULE
operator and ending with the THEN operator. The conditional
and concluding parts of the rule are specified in between
using the 'IF', 'AND', & 'THEN' operators.
EXAMPLE RULE 1
---------------
*
RULE CPU-2
IF SW8087 is YES
AND INTERP is NO
AND INVEST is YES
AND INV is C
THEN FIX_PC is "Install co-processor chip in PC."
*
RULE specifies the beginning of a rule block in the form
RULE;'rule label'
'rule label' is an arbitrary label assigned by the
knowledge base builder. It serves no purpose for the
operation of MAE, and should be chosen to reflect the
tree structure guiding your development of rules, or
some other useful purpose you may decide upon.
IF specifies the first conditional attribute of the rule
block, in the form:
IF 'conditional attribute' IS 'value'
'conditional attribute' must be an attribute
defined as an attribute (see below).
IS functions as a delimiter between the
'conditional attribute and the 'value' specified
in the instance of this particular rule block.
'value' is the value which will satisfy this
conditon of the rule, and which will either be
obtained from the user in interactive dialogue or
be derived from the operation of the Inference
Engine.
AND specifies the subsequent conditional attributes of the
rule block, in the form:
AND 'conditional attribute' IS 'value'
'conditional attribute' must be an attribute defined
as an attribute.
IS functions as a delimiter between the
'conditional attribute and the 'value' specified
in the instance of this particular rule block.
'value' is the value which will satisfy this
conditon of the rule, and which will either be
obtained from the user in interactive dialogue or
be derived from the operation of the Inference
Engine.
THEN specifies the concluding attribute of the rule block, in
the form:
THEN 'concluding attribute' IS 'value'
'concluding attribute' must be an attribute defined
as an attribute.
IS equates the value following with the
'concluding attribute' within the MAE System,
where it may either resolve the goal, or provide
intermediate values for the context used to
resolve the goal.
'value' will either be:
(1) a "quoted screen literal" in which case it
will be used to give information about the
resolution of the goal, (see example rule 1).
or
(2) it will be an unquoted value which will be
tested in conditional parts of some other
rule block ( as in example rule 2).
EXAMPLE RULE 2
--------------
*
RULE ROOT-2
IF OUTOFMEM is YES
AND DISKACTIVE is NO
AND EXPECTATION is YES
THEN INV is M
*
or
(3) it will contain a statement expressing a Goal
Outcome Command. Such Outcome Commands are
expressed in a quoted string, beginning with
a > sign. A space must be left between the
final command parameter and the closing quote
mark for the string. Available commands
are:
RUN. This command will activate another MAE
knowledge base. The KB which is RUN may
itself RUN another one. There is no limit to
the number of KB's which can be nested in
this fashion. When consultation with a
KB completes with an outcome which does not
run another KB, the user will be returned to
the original KB. The general form is:
">RUN KBname "
SHOW. This command will provide access to an
external file of information constructed with
the accompanying program FRAMER. FRAMER
commands are given in Appendix 1 to this
Manual. FRAMER sets up a file of Screen Frames
keyed by values you supply. These keys are
used in the SHOW command to access the
Frames.
Once in the SHOW option, the user can use the
arrow keys to change screens (Up and Down),
while the Home key and the End Key take them
to the Top and Bottom of the file
respectively. The Escape key will return the
user to the MAE environment.
A number of options are available in
specifying the SHOW command. The general
form (where square brackets indicate optional
parameters) is:
">SHOW FrameFilename [StartKey [TO Endkey] ] "
[StartKey [N number] ] "
Specifying a FrameFilename only will start at
the beginning of the File with all Show
facilities.
Giving an optional StartKey will start at the
specified Key, with access to the full file
with all Show facilties.
Giving a TO Endkey clause will establish a
subrange of the File, for which all Show
facilties are available, restricted to the
Subrange established.
Giving an N number clause will give access to
the number of Frames specified in strict
sequential sequence. Once the Sequence
completes, the User returns to MAE. N 0 is
a special case, which will show just the
specified frame, and return the User to MAE
when they press the Escape key.
DUMP. This command will cause Mae to dump
the Context Stack (the list of Facts MAE has
gathered during the Consultation) to a file.
It is optional to specify a Dump File. If
you do not, MAE will simply produce a
dumpfile with the name of the KB you are
using. In any event the Dump File will have
a .DMP extension. You must not specify a fie
extension if you specify a Dump File name.
The general form of the command is:
">DUMP [DumpFilename] "
Attribute Syntax:
-----------------
Each attribute is defined as a block, beginning with
NAME and ending with the key word END.
These attributes describe the elements which appear in
the RULE blocks as the conditional and concluding
attributes.
Thus, from the Example Rule 1, the conditional
attribute SW8087 is described as below:
EXAMPLE ATTRIBUTE 1
--------------------
*
NAME SW8087
TRANS "Target software supports a co-processor."
PROMPT "Does target software support a co-processor [YES/NO] ?"
LEGAL YES NO ENDLEGAL
HELP "However, only specific software will utilize
this delegation function."
END
*
NAME specifies the beginning of an attribute block in the form:
NAME 'attribute name'
'attribute name' is assigned by the knowledge
engineer, and is the link with the rule. When
the rule block is being examined by the Inference
Engine the name is used to access Prompt, Help
etc., as detailed below.
TRANS specifies a non-question statement of the utility
of the attribute in the form:
TRANS ' "quoted string of literal text" '
This is used when justifying the results of the
Knowledge base query.
PROMPT specifies the form in which unknown data during
a knowledge base consultation will be solicited
from the operator, in the form:
PROMPT ' "quoted string of literal text" '
This text needs to be carefully thought about
since it is one of the main things a user will see
in any system you design. How easily these
prompts are to understand will govern how usable
the system is.
LEGAL specifies the answers which MAE will display in
the menu of answer options in the form:
LEGAL 'legal answer','legalanswer', ... ENDLEGAL
These legal answers must correspond to the
alternatives specified in the value component of
the IF and AND segments of the Rule Block. These
are space delimited, and the string terminated
with the key word ENDLEGAL. There is no
arbitrary limit on the number of legal values,
although a sensible limit would be the number
which can be accomodated on the screen at once.
HELP specifies text to be displayed when requested by
the operator, in the form:
HELP;' "quoted string of literal text" '
This text should amplify the information given in
the prompt.
END signals the end of the attribute block to the MAE
input parser
Special attributes:
-------------------
There are a special class of attributes, which are not
used in the same way as most. These are the GOAL
attribute, and other particular attributes which have
been designed to function as links or branches in the
knowledge tree, rather than to convey information at the
leaves of the tree. The following attribute of the PC
knowledge base is an example.
EXAMPLE ATTRIBUTE 2
--------------------
*
NAME APP_PHYS
TRANS "Physical memory or way application uses memory be investigated."
PROMPT none
HELP none
LEGAL none ENDLEGAL
END
*
Note about this special form of the Attribute Block:
1) The PROMPT must be specified as 'none'
2) HELP must be specified as 'none'
3) the LEGAL none ENDLEGAL section
Developing A Knowledge Base
With MAE
---------------------------
The first step in developing a Knowledge Base for a given problem domain
is to develop an understanding of common problems, their solution and
the method by which that solution is obtained. It is generally agreed
that for an Expert System to be successful it should address a a problem
area which has definable boundaries, within which there is a good measure
of agreement about solutions to problems. If the solutions to problems
cannot be generated by a human expert, your Expert System will not be able
to generate them. An expert system communicates the solution to problems,
and is totally dependent on the quality and organization of the knowledge
fed into it by the Knowledge Engineer.. What it does achieve however, is
the isolation of the knowledge from the mechanics of the decision making,
and makes available to the Knowledge Base Builder a non-procedural way of
building, that is, he/she does not need to be concerned with how the
inference engine solves the problem.
Next construct a TREE DIAGRAM of the way in which problems are commonly
solved. You will find this an excellent 'navigational aid' as you develop
the actual rules and attributes of the system. The initial tree of the
PC base looks like this:
EXPECTATIONS <----------- node (Attribute)
|
|
--------------------- <----------- decision (Rule fact)
| |
No Yes
| |
| |
ROOT-6* DISKACTIVE
|
|
---------------------
| |
Yes No
| |
| |
ROOT-1 OUTOFMEM
|
|
---------------------
| |
Yes No
| |
| |
ROOT-2 CPUACTIVE
|
|
---------------------
| |
Yes No
| |
| |
ROOT-3 ROOT-5*
This TREE consists of nodes, decision points, and outcome
'leaves'. The nodes equate to the ATTRIBUTES. The logic of the
decision points equates to the FACTS defined in the rule blocks.
The outcome leaves equate to the solution defined in the RULE
BLOCKS. In the high level tree fragment shown above, most of
the outcomes in fact link to other tree segments. Those marked
with an asterisk (*) are true outcome rules. You will find the
rules and attributes by name in the KB file.
LOOK AT THEM NOW AND MAKE SURE YOU UNDERSTAND
HOW THIS PORTION OF THE TREE OPERATES.
Thus, rule ROOT-2, which is:
*
RULE ROOT-2
IF OUTOFMEM IS YES
AND DISKACTIVE IS NO
AND EXPECTATION IS YES
THEN INV IS M
*
can be seen to be derived from the tree.
Construct the rules and attributes for your knowledge base using
the tree as a guide. In constructing the MAE rule,
ensure that the attributes in the rule are placed so that they trace the
occurrence of the attributes in the tree, as in ROOT-2. That is,
EXPECTATIONS occurs first in this portion of the tree, so it is placed
first before the THEN clause. DISKACTIVE occurs next, and is placed so.
Then OUTOFMEM is last. When MAE finds this collection of rules to be
true, the system proceeds to the next segment of the tree. If the
rule is one which defines a final outcome, the system halts and the
defined answer is issued.
Developing the rule base is a question of extending the tree.
E.G.
Link from ROOT-2 which has made INV equal to 'M':
RESIDENTS
|
|
---------------------
| |
Yes No
| |
| |
MEMORY-1* LOAD_OK
|
|
---------------------
| |
Yes No
| |
| |
MEMORY-2 MEMORY-3
Link from MEMORY-3, which has made APP-PHYS equal to 'P':
INVEST
|
|
---------------------
| |
No Yes
| |
| |
PHYSMEM-1* MEMLIMIT
|
|
---------------------
| |
No Yes
| |
| |
PHYSMEM-2* EXTMEM
|
|
---------------------
| | |
U V N
| | |
| | |
PHYSMEM-5* PHYSMEM-4* PHYSMEM-3*
Note that in this final tree fragment, all the outcome leaves are
starred. Therefore when MAE reaches this end of the tree, a solution
must be found. If you leave some solutions undefined, MAE will
terminate the operation of the system with a message indicating there
is an inconsistency in the rule base.
To repeat, the things at the nodes are the names of attributes.
The things at the end of the lines at the decision points are the names of
rules which satisfy the cumulative effect of the decision points past.
By setting up the decision tree and coding your knowledge base from it,
you are making the operation of the problem solving choices an expert makes
clearer. Unlike an ordinary tree, you climb downwards, but as you go
the trunk branches with the first decision, and then goes on branching
according to the choices you continue to make. As you climb down, each
decision closes off alternative routes for MAE until you reach a terminal
branch.
MAE UTILITIES
-------------
MAEPARSE:
This utility program takes a MAE Knowledge Base file
and parses it to check for errors and create a disk
listing file to page and title the KB you have created.
Unlike the error checking during the live MAE KB load,
MAEPARSE will attempt to continue parsing the KB after
it has detected an intial error. With this
"incremental" style of error checking, a number of
errors can be picked up in one pass thru the parser.
For an example see the TEST.KB and TEST.LIS files which
should accompany this one.
VERSION NOTES
-------------
VERSION 1.0
This is the introductory version of MAE. Directions for future development
include:
-further development of the boolean function definable in the
rule with NOT and OR.
-introduction of a facility to store 'static data', which the
system would prompt for at the beginning of a consultation.
-improved DEBUG info in the Debug Log File.
-a back-tracking facility, to allow the logic of the rule base
to cater for reversals within the tree structure.
-arithmetic operations defined in the rule base and executed
within the Expert System shell.
-better error detection for rule and attribute parsing.
-development of a pre-processor to allow more automated development
of the rules and attributes.
-development of utility programs to aid knowldge base file
management.
Version 2.0
-the parsing aspect of MAE completely rewritten, so that
1 KB file is used.
-FLAG implemented.
Version 3.00
Converted to Turbo Pascal Version 4.0
Set MAE to RUN another KB if defined in the Goal Attribute of
a rule, Format 'goal IS RUN kbname' where kbname is valid name
of an existing KB file.
Version 3.10
Added ShowUnit features to enable random access to Indexed
Information files from the GOAL outcomes and Dump file
option.
FLAG PAGE ATTACHMENT
--------------------
********************* Management Action Research Systems ******************
P R E S E N T S
MAE (Management Action Expert) V3.20
An Expert System Inference Engine
*** Written by Charles C. BRITTON **************** (c) 1987,1989 *****
MAE is an Expert System shell, which means that it will solve problems
in a non-procedural manner from a description of rules and facts about a
problem domain. To find out more about the syntax required for these
read the documentation files which should accompany this program.
MAE has been placed in the Public Domain by MANAGEMENT ACTION RESEARCH
SYSTEMS mainly for the purpose of helping you to learn about expert systems
and how they work. To that end a sample Knowledge Base is included along
with the system documentation on disk. Please use this program freely and
share it with friends and acquaintances. Do not sell it for a profit.
Management Action Research Systems and the author will not be responsible
for any loss or damage arising from the use or misuse of this program by
anyone in any circumstances.
If you wish to learn more about Expert System technology, you may care to
to register with Management Action to receive the source code(*) of this shell
PLUS a database of more than 500 book, magazine and newspaper references
to Expert Systems,and Artificial Intelligence. It is growing all the time.
This will cost you $150. You also get the most up to date version
of MAE. Register to P.O. Box 47,Dulwich Hill, N.S.W. 2203,Australia.
To continue, press the <Return> key.
(*) Turbo Pascal source
Directory of PC-SIG Library Disk #0976
Volume in drive A has no label
Directory of A:\
ARC EXE 32051 1-31-86 1:19p
FILE0976 TXT 1925 1-04-90 2:16p
GO BAT 38 1-28-88 4:33p
GO TXT 771 1-05-90 4:19p
MAE ARC 196225 11-01-89 8:57a
UNPACK BAT 199 12-10-89 4:03p
6 file(s) 231209 bytes
88064 bytes free