[Previous]
[Next]
[Title]
1. Building a small wysh inferencing system
This
tutorial aims to provide a practical introduction to rule-based inferencing
systems, and to issues in inferencing over the world-wide-web. It covers the
development of a simply backward and forward chaining rulebase using ysh
(pronounced 'why - shell') and wysh (pronounced 'wish' and standing for
'web-ysh'); publishing a rulebase on the web; integration of rulebases with
hypertext and search resouces on AustLII and elsewhere; and `co-operative
inferencing' (rulebases distributed across the web). If time permits, ysh's
document generation and case-based inferencing can also be covered.
Ysh is the underlying inferencing engine, and wysh is the web interface to ysh.
For convenience, we will refer to both simply as 'wysh' for most purposes.
Anyone who wishes to use these resources for teaching or other non-commercial
purposes should contact AustLII at feedback@austlii.edu.au.
These tutorial exercises are designed to be read with The Wysh User
Manual, AustLII, 1997 and
The
Wysh Developer's Manual, AustLII, 1997. Paragraph references are to that
Manual. Some parts of the Manuals are summarised here, for convenience when
completing the tutorials.
Most of the resources needed for the tutorial can be located from the
'wysh index page' on AustLII:
http://www.austlii.edu.au/links/World/Subject_Index/Computerisation_of_Law/Web_Tools/WYSH_-_AustLII's_Internet_Inferencing_Engine/
The purpose of this exercise is to familiarise you with the ysh
and wysh software to be used in the tutorial. Examples on copyright
and privacy law are used to illustrate some rule-based applications that can be
developed.
When doing the following examples, please test the use of all the system
functions, including the buttons for`Facts' (what have you told the system),
`Conclusions' (what conclusions has the system derived), `Why' (why is the
current question being asked), `What if' (what conclusions will be derived from
a hypothetical fact) and `Uncertain' (if a fact is not essential, inferencing
will continue). You may also wish to refer to the ysh/wysh User Manual
, but there is little need.
Things to note about the interface:
- To choose a goal to be evaluated, type the number of that goal in the
window;
- If `Yes', `No' or `Uncertain' buttons do not appear, you can type `y', `n'
or `u' in the window.
- To forget a single fact, first display the facts (using the `Facts'
button), the enter `forget n' (where n is the number of the fact to be
forgotten) in the window (eg `forget 11' will cause fact 11 to be forgotten
and all conclusions re-derived;
- Do not use the Netscape `back' button in order to change facts - it
won't work and may give bizarre results
The
`Copyright
Consultations' and
`Privacy
Consultations' on the [wysh] index page should be used to answer the
following questions. If you need more facts than are provided, make them up.
- Harold Henning, a famous Australian author, wrote a short story `Lost in
Space' on Xmas Day 1940 when he was young. It has sat in his desk draw ever
since. His `unofficial biographer', Fiona Fail, has obtained a copy and intends
to publish it as an appendix to her book about him. Does Harold still hold
copyright, and if so until when?
- What if Harold died in 1950?
- What if a radio adaptation of the short story had been broadcast once in
1945? Does it matter in this case if Harold is still alive?
- Jana, a freelance journalist, agrees verbally to write a weekly column
`Around the Courts', for a monthly magazine `TV Times'. She has no discussions
about copyright issues with Rupert, the owner.
Before
you leave the copyright problems, make up one of your own and test it. Do the
same after you finish the privacy problems below.
- Is it legal for a credit bureau like the Credit Reference Association of
Australia to hold on file details of a person's racial origin?
- If the Department of Social Security holds your address in its files, can
it disclose that address to the NSW Department of Housing, which wants to serve
a summons on you? (Hint: IPP 11 is the most relevant Information Privacy
Principle)
Some
simple symbolic examples are used to make it easier to see the logic behind
backward and forward chaining without the distraction of real facts.
Assume that you have 5 rules which allow you to reach conclusions about whether
8 propositions (represented as A to F) are true or not:
Rule
|
Conditions
|
Conclusion
|
Rule
1
|
E
and F
|
A
|
Rule
2
|
A
and (B or C)
|
D
|
Rule
3
|
E
or G
|
C
|
Rule
4
|
H
and G and C and not F
|
A
|
Rule
5
|
F
and not E
|
not
D
|
f
you were asked whether D is true or not, given that you know that E, H and G
are true, but F and B are false, how would you go about working out an answer.
Write down each step in your reasoning.
There are
3
wysh files that you can use, entitled `Goal Tests':
- goaltest - forward and backward chaining
- goalback - backward chaining only
- goalfor - forward chaining only
You can now use these files to
test how YSH's inferencing mechanism works. For example, assume the following:
- the objective (goal) is D;
- E, H and G are correct (true);
- F and B are not correct (false).
First, try to work out on paper what
YSH should do, using goaltest (forward and backward chaining) to start with,
then watch to see if it does it. Then try out objective and fact combinations
of your own, and try the versions which just do forward or backward chaining
and observer the differences in behaviour.
Note the order in which rules and attributes are evaluated in YSH's
backward-chaining mode:
- rules are evaluated top-down from the start of the rule-base; and
- attributes are evaluated left to right within a rule
The
purpose of this exercise is for you to work out how to convert a section or two
of an Act into a small rulebase which wysh/ysh can run to infer
conclusions.
So that the collaborative inferencing features of wysh over the web can be best
demonstrated, in the classroom tutorial students will be allocated definitions
and sections from the Copyright Act 1968 to work on.
If you are doing the Tutorial outside a classroom, then for the rest of the
Tutorrial you need to choose an area of law on which to develop a small wysh
application. If it is an area of law with some Australian legislation which is
on AustLII, that will make it possible to use the automated links from
inferencing dialogues to AustLII databases that are covered later. Otherwise,
any legislation can be used - but it is easier if you can find a copy on the
web.
Find on the web any Act that interests you, choose a couple of fairly simple
and inter-related sections, preferably sections that create obligations or
offences. Read the rest of this part, and then convert the section(s) into a
rule or set of rules that will run under ysh/wysh.
The easiest way to proceed may be to save (or cut and paste) the section on
which you wish to start into a word processing document, and then edit it.
These notes are largely derived from the
ysh/wysh
Developer's Manual.
In its simplest form, a rule contains four elements:
- the keyword `RULE', indicating the start of a new rule (in default
of any specification, the type of this rule is that it will be both backward
chaining and forward chaining);
- the name of the rule (usually just the name of the Act and section
that it paraphrases); The name of a rule should differ from that of any other
rule in the rule-base.;
- the keyword `PROVIDES', indicating the start of the body of the
rule; and
- the statement(s) which make up the inferencing content of the rule
(one or more statements). Statements may be thought of as the content of rules.
A rule contains one or more statements. Statements consist of declarations. One
of the simplest forms of a statement is 'IF condition THEN conclusion'.
The
simplest syntax for a rule is therefore as follows:
RULE name PROVIDES statements
The example below shows three rules, each with one moderately complex
statement.
Statements, the content of rules, are made up of declarations. A declaration
consists of various keywords which are used to join together, in a
logical form, a number of descriptors, which are simply terms or phrases
used to describe some object, event etc.
Keywords give rules the logical structure used by YSH to draw inferences. They
are written in FULL UPPER CASE so YSH can distinguish them from their
equivalents in ordinary words (which may occur in descriptors). Examples of
important keywords, or sets of keywords are:
ONLY IF
IF .... THEN
IF ... THEN .... ELSE
IS
AND
OR
PLUS
MINUS
PERSON
THING.
These and other keywords have functions in a YSH knowledge-base which is very
similar to their normal linguistic function as words. This correspondence is a
large part of what gives YSH a 'quasi natural language' or 'English like' syntax.
Descriptors may be any sequence of words or symbols but must not contain
keywords (they can contain the lower case versions of them). Descriptors are
generally written in lower case, with normal capitalisation. In the example
below, some descriptors used are `a person has a legally enforceable right
under s11 to obtain access to a document', `s11(a) applies' and `the document
is not an exempt document'. These are all attributes, but other descriptors
include constants and named subjects.
The Freedom of Information Act 1982 (Cth) s11 reads:
11. Subject to this Act, every person has a legally enforceable right to
obtain access in accordance with this Act to -
(a) a document of an agency,
other than an exempt document; or
(b) an official document of a Minister,
other than an exempt document.
A rule-base of 3 rules consisting solely of this section could read as follows.
The rules have been (over-)simplified, for demonstration purposes, by ignoring
the words `subject to this Act' in s11. Note that you could alternatively have
written one much more complex rule.
RULE Freedom of Information Act 1982 (Cth) s11 PROVIDES
a person has a legally enforceable right under s11 to obtain access to a document ONLY IF
s11(a) applies OR
s11(b) applies
RULE Freedom of Information Act 1982 (Cth) s11(a) PROVIDES
s11(a) applies ONLY IF
the document is a document of an agency AND
the document is not an exempt document
RULE Freedom of Information Act 1982 (Cth) s11(b) PROVIDES
s11(b) applies ONLY IF
the document is an official document of a Minister AND
the document is not an exempt document
The
rules above have been (over-)simplified, for demonstration purposes, by
ignoring the words `subject to this Act' in s11.
One recommended way to start is to create a rule which explicitly models the
structure of the section being represented by the rule, such as:
RULE Freedom of Information Act 1982 (Cth) s11 PROVIDES
a person has a legally enforceable right under s11 to obtain access to a document ONLY IF
s11(a) applies OR
s11(b) applies
`Applies' is a good verb to use with sections. It is asserted as ` ... does
apply', negated as ` ... does not apply', and made interrogative as `Does ....
apply?'.
You will be allocated a definition from the definitions section (s10) of the
Copyright Act 1968. Just type # followed by the defined word at the end of the
URL of
this page (s10), and it will take you to the correct definition.
Copy your definition and paste it into the `wysh - manual start (Enhanced) page (http://www2.austlii.edu.au/~simon/wysh.html)
in order to start editing it to make it run - but first, read further
instructions on doing this in the section following.
The purpose of this exercise is cover how to run ysh rulebases under wysh.
The easiest way to explore ysh rulebases through trial and error is by using
the `wysh - manual start (Enhanced) page (http://www2.austlii.edu.au/~simon/wysh.html),
which can be accessed from the wysh index page.
The wysh manual start page provides a number to simple ways to experiment with
rulebases. First, you need to build a simple rule ...
Type your rule into the following box on the wysh manual start page.
Alternatively, type it in a word processor, then copy it to memory , change
programs to Netscape, and paste it into the box.
Alternatively, copy some text from a section of an Act, paste it into this
window, and edit it into a rule.
The
`paste' window in the wysh manual start page
If you paste a rule into this box, some lines of text may
disappear off the right side of the visible window. You can fix this by
inserting returns at the end of each line. YSH ignores the presence of returns
in knowledgebases.
To run the rule, simply click on the `Consult!' button. Check how the functions
such as `Facts', `Conclusions', `What If?', `Why' and `forget n' command work
with your knowledgebase.
If your rule does not behave as you intended it to, go back to the `manual
start window, edit the rule, and run it again.
To
make backward chaining work, create some additional rules which have as their
conclusions the structural elements of the section that are represented as
attributes in your first rule (eg `s11(a) applies' and `s11(b) applies'. For
example, these rules can be added to the above rule:
RULE Freedom of Information Act 1982 (Cth) s11(a) PROVIDES
s11(a) applies ONLY IF
the document is a document of an agency AND
the document is not an exempt document
RULE Freedom of Information Act 1982 (Cth) s11(b) PROVIDES
s11(b) applies ONLY IF
the document is an official document of a Minister AND
the document is not an exempt document
So
far, the only keywords used have been RULE, PROVIDES, ONLY IF, OR and AND.
There are a lot more that can be used, but these are probably the most
important ones.
Obviously, you do this every time you make a change to the rules. The main
purpose of the type/paste window on the wysh manual start page is to allow you
to test minor changes to rules without having to create a new web page each
time in order to do so. So, you should experiment with changes to rules to see
what effect they have (eg what is the difference between IF and ONLY IF?)
If you wish, you can have references to people and things in your rules
automatically replaced, when the rules are used to run dialogues, with actual
names provided by the user, and correct pronouns and possessives resulting.
Subjects which are to be treated in this way are referred to as named
subjects. The use of named subjects allows you to instantiate the dialogues
that YSH generates, making them appear much more responsive to the answers you
have already given.
Use named subjects wherever possible, as they improve communication.
See
Named
Subjects in the Wysh Developers' Manual.
Named subjects must be declared in a rulebase, and given one of the types
PERSON, THING or PERSONTHING. When an attribute containing a defined subject is
first evaluated, automatic prompts for a subject name and, in the case of
persons, the subject's sex, will be issued. Where the type is PERSONTHING, the
subject may be either a person or a thing (eg where either a natural person or
a company may be a subject), and a prompt (`Is x a natural person ?') will be
issued to determine this.
Named subjects are declared simply be inserting a line or lines anywhere in the
rulebase such as in these examples:
PERSON the claimant
THING the agreement
PERSONTHING the first party
PERSON the intestate
In
the FOI example being used, two useful named subjects are:
PERSON a person
THING the document
Once
a named subject is declared, YSH will recognise it as a named subject in any
subsequent part of the rule-base, without need for any further identification
of it as such. Named subjects referred to in other attributes are recognised
automatically, and their values are substituted in the other attributes.
It is important to test any named subjects thoroughly, as they can sometimes
affect dialogues in unexpected ways. You may need to make subtle distinctions
between, for example `a person' and `the person' (with only one of these being
a named subject, for the dialogues to work as you intend.
In addition to the usual `Consult!' button to start a consultation with your
rulebase, there are on the `wysh - manual start (Enhanced)' page two additional
buttons which allow you to check for some types of errors in your rulebase
before you try to run it.
Both of these error checking mechanisms work for rulebases pasted into the form
on the `manual start' page, and for for rulebases on remote pages where the URL
is pasted in.
Use of similarly named but not identically named attributes is one of the main
causes of errors in YSH rulebases, particularly where rules which are supposed
to chain do not do so. The ` Check Fact Cross References' button allows you to
check for such errors.
The example given below is for the `FOI s11' rulebase used in other exercises (http://www2.austlii.edu.au/~graham/wysh/foi1.html).
Every attribute is printed (in alphabetical order) showing the names of rules
setting (*) and using (-) the attribute.
In the example below, the attribute `s11(a) applies' appears in two rules:
*Freedom of Information Act 1982 (Cth) s11(a)
-Freedom of Information Act 1982 (Cth) s11
The rule(s) `setting' the attribute (*) are those where the attribute is a
conclusion of the rule. Rules `using' the attribute are those where it is one
of the premises.
Named subjects are also listed as part of the alphabetical order (eg `a
person'), but the names of the rules in which they are used are not listed.
This flag is very useful because it allows you to check whether the same
attribute has been mistakenly described in two similar but not identical ways.
(This was the purpose of the -x flag in the DataLex WorkStation Software.)
FACT X-REF ===============
a person
a person has a legally enforceable right under s11 to obtain access to a
document
*Freedom of Information Act 1982 (Cth) s11
s11(a) applies
*Freedom of Information Act 1982 (Cth) s11(a)
-Freedom of Information Act 1982 (Cth) s11
s11(b) applies
*Freedom of Information Act 1982 (Cth) s11(b)
-Freedom of Information Act 1982 (Cth) s11
the document
the document is a document of an agency
-Freedom of Information Act 1982 (Cth) s11(a)
the document is an exempt document
-Freedom of Information Act 1982 (Cth) s11(a)
-Freedom of Information Act 1982 (Cth) s11(b)
the document is an official document of a Minister
-Freedom of Information Act 1982 (Cth) s11(b)
the name of a person
the name of the document
the sex of a person
Use
of the `Check Fact Translations' buttons to check that your attributes are
expressed correctly
For each attribute in the rulebase, in the order in which they occur, it shows
3 translations of the attribute:
- prompts (questions) - how the system will ask for a value for that
attribute when it needs one.
- a translation in positive form - what the system will say if the
attribute is satisfied.
- a translation in negative form - what the system will say if the
attribute is not satisfied.
For example, the interrogative, positive and
negative translations of the attribute `s11(a) applies' are as follows:
-Does s11(a) apply ?
-S11(a) applies.
-S11(a) does not apply.
Named subjects are also listed, but since named subjects do not have positive
or negative values, the translations given are instead:
- the question the system will ask to obtain the name.
- the way in which that name would be reported back to the user (where the
name give is substituted for `<>` - see later).
This allows you to
check that YSH will correctly process the verbs that you have used.
DEFAULT FACT TRANSLATIONS ==============================
-What is a person ?
-A person is <>.
-Has a person a legally enforceable right under s11 to obtain access to a document ?
-A person has a legally enforceable right under s11 to obtain access to a document.
-A person has not a legally enforceable right under s11 to obtain access to a document.
-Does s11(a) apply ?
-S11(a) applies.
-S11(a) does not apply.
-Does s11(b) apply ?
-S11(b) applies.
-S11(b) does not apply.
-What is the document ?
-The document is <>.
-Is the document a document of an agency ?
-The document is a document of an agency.
-The document is not a document of an agency.
-Is the document an exempt document ?
-The document is an exempt document.
-The document is not an exempt document.
-Is the document an official document of a Minister ?
-The document is an official document of a Minister.
-The document is not an official document of a Minister.
-What is the name of a person ?
-The name of a person is <>.
-What is the name of the document ?
-The name of the document is <>.
-What is the sex of a person ?
-The sex of a person is <>.
The error messages most commonly encountered when running ysh rulebases are:
- `Expected block start' - this often means that you have missed part of
the first line of the rule ( RULE rulename PROVIDES) or failed to put the
keywords in capitals.
- 'Missing keyword THEN' - or some other keyword. Check that you have the
correct keywords, and that you have them in capitals.
The number given
before the error message is the number of the line on which the error occurs.
[Previous]
[Next]
[Title]