4. Rule-based inferencing (III): Rule types, statements and evaluation order

Rule types and statements control the order in which the evaluation of rules, and attributes within rules, take place in a DataLex inferencing session.

4.1 Order of evaluation of rules, and within rules, in inferencing

The main elements of the process whereby DataLex uses a rule-base to draw inferences are as follows:

(i) The evaluation of a particular attribute (eg determining the truth of a fact) is set as DataLex's current 'goal' - see 2.14 below concerning 'LISTED' and 'GOAL' rules for how such goals are determined.

(ii) DataLex uses the rules in its rule-base to infer a value for this attribute, principally through the use of backward chaining and forward chaining reasoning. DataLex uses both backward and forward chaining reasoning, in that rules are first invoked in a backward-chaining fashion whenever an attribute needs to be evaluated in order to determine whether a rule will 'fire'. However, whenever a new attribute value becomes known, all rules using that attribute are silently evaluated (a forward chaining daemon).

However, which rules participate in the backward chaining process and which in the forward chaining process, and how they do so, is determined to some extent by what types of rules they are declared to be - see below concerning Types of rules.

(iii) Once a rule is being evaluated for purposes of either backward or forward chaining, the order in which the attributes and statements which make up the rule's content are evaluated depends largely on the order in which they occur.

4.2 Goals - LISTED rules and GOAL rules

DataLex must start its inferencing process by determining what its current goal is. DataLex will attempt to evaluate the first rule in the rule-base, if no rule is declared to be either a GOAL or LISTED. If only one rule other than the first is a GOAL RULE or LISTED RULE, DataLex will start to evaluate that rule. Otherwise, DataLex will start by giving the user a choice between all rules in the rule-base which are declared to be either GOAL or LISTED rules. The chosen rule is then treated as the current goal.

For present purposes, there is no difference between LISTED rules and GOAL rules.

4.2.1 Multiple GOALS

More than one rule may be declared to be a GOAL. When DataLex is invoked it will automatically present the user with a list of the names of all rules specified as GOALS, and ask the user which one is to be evaluated. Names of rules which are GOALS must therefore be sensible enough to appear in a menu of goals.

4.3 Order of evaluation of rules

When the system is inferring a value using backward and/or forward chaining rules, it will evaluate rules in the order in which they appear in the knowledge-base. The order of appearance will not normally have any effect on the outcome of a consultation, but can affect whether questions of the user are asked in a sensible order. More general rules should be declared before more specific ones, where they relate to the same subject matter. Procedures may be declared in any order.

4.3.1 Calling rules [advanced]

All types of rules can be specifically CALLed. The syntax is:

CALL rule/procedure name

The statements for the named rule or procedure will be executed and control will be returned to the next statement after the CALL. This statement should only be used to control knowledge-rich rules. It should not be part of any rule which itself contains knowledge of any sort.

4.3.2 Rule names

The rule name is used to document what the rule is about and to give a point of reference for calls. Each rule name should be different. Rule names are essential if a rule is to be a GOAL RULE, because the user must know which rule they are choosing to evaluate. Rule names are optional but should be used.

Examples of some ways of naming rules:

RULE subsistence of copyright PROVIDES ....

RULE Copyright Act s36(1) PROVIDES ....

RULE Copyright Act s36(2) PROVIDES ....

RULE Copyright Act s36(2) [continuation 1] PROVIDES ....

4.3.3 The ORDER declaration [advanced]

The order of rule evaluation can be controlled by specifying the rule order in an ORDER block, with the syntax: ORDER rule name {THEN rule-name}

The main purpose of this is to allow rules to be written in the order in which they appear in legislation, without this necessarily determining the order in which they might fire. An order declaration must appear before the rules named.

4.4 Types of rules

4.4.1 The default type - backward and forward chaining

The default rule type is both backward chaining and a forward-chaining daemon. So, a rule that starts

RULE name of the rule PROVIDES ...

will be both backward and forward chaining, in default of any other specification.

Use the default form unless there is good reason not to.

4.4.2 Declaring other types of rules

You can alter this rule behaviour by declaring the type of the rule. The possible types are BACKWARD, DAEMON, DOCUMENT, FORWARD and PROCEDURE. Each is explained below.

To declare that a rule is a particular type, you put the type of the rule before the keyword RULE at the start of the rule. Examples:

BACKWARD RULE the name of the rule PROVIDES ...

This rule will only be backward chaining.

FORWARD RULE the name of the rule PROVIDES ...

This rule will only be forward chaining.

4.4.3 Syntax for rule types

The rule declaration syntax is:

[GOAL] PROCEDURE|DAEMON|BACKWARD|FORWARD|RULE
[RULE] [name] PROVIDES statements

4.4.4 Backward rules

If a rule is declared to be a BACKWARD RULE it is only ever used for backward chaining.

4.4.5 Forward rules

FORWARD RULES are only used for forward-chaining. DataLex attempts to evaluate a FORWARD rule when the first attribute needed to execute the rule becomes known. Where necessary, FORWARD rules will ask the user for any other attribute value necessary to evaluate the rule (ie they do not operate ‘silently’ - they ask questions where necessary).

4.4.6 Daemons

DAEMONS are like FORWARD rules but operate silently (ie they never ask the user for information and will silently fail to file if they need to do so).

4.4.7 Procedures

PROCEDURES are not invoked by either forward or backward chaining. Evaluation of a procedure must be invoked explicitly, either by the procedure being called (see 2.17.4 below concerning calls), or by the procedure being declared to be a goal and invoked as a goal.

4.4.8 Documents

DOCUMENTS are like procedures but are used to generate documents (see later Chapter 4 concerning Documents ).

4.5 Statements

There are several different types of statements. These include: assignments and assertions (using ONLY IF, IS and ASSERT), conditional evaluation of facts (using IF-THEN and IF-THEN-ELSE statements), conditional looping (using WHILE-DO and REPEAT-UNTIL statements), DETERMINE statements and CALL statements.

For most purposes, conditional evaluation of facts (IF-THEN-ELSE) and assignments and assertions (using ONLY IF, IS and ASSERT) are the only types that need to be used.

4.5.1 Conditional evaluation of facts (IF-THEN-ELSE statements )

IF-THEN-ELSE statements provide for conditional evaluation of attributes. The syntax is:

IF expression THEN statement [ ELSE statement ]

expression is evaluated and if true, the statement following the THEN is executed. If an ELSE statement is provided and expression evaluates false, then the statement following ELSE will be executed.

The ELSE part of the statement is optional.

Examples:

     IF  it is raining

     THEN  you should take an umbrella

     ELSE  you should go out

4.5.2 Inclusive definitions

Where a statutory definition is only inclusive (ie not exhaustive), the IF-THEN form is appropriate. For example, the definition of 'dramatic work' in the Copyright Act 1968 (Cth) can be represented in part as

IF the work is a choreographic work or other dumb show OR 
  the work is a scenario for a script for a cinematograph film
    THEN the work is a dramatic work

There is no ELSE because many other undefined types of drama may qualify as dramatic works.

One rule can include a number of IF-THEN statements in succession.

4.5.3 Assigning values - Assignments and Assertions (IS, ONLY IF and ASSERT)

Values may be assigned to attributes by use of the IS operator (or the equivalent ONLY IF operator) or (in the case of boolean attributes) by assertion.

4.5.4 Assertions

An assertion is used to state that an attribute has a true or false value (ie to assert that it is true or false). Assertions can therefore only be used with boolean (true or false) attributes. An assertion statement simply consists of a boolean attribute name expressed in the positive or negative form, optionally preceded by the keyword ASSERT or AND. For example:

the Act applies

is the same as

ASSERT the Act applies

The following are also the same:

the corporation is an overseas corporation AND the Act does not apply

ASSERT the corporation is an overseas corporation AND the Act does not apply

The ASSERT or AND keyword should only be used where it is necessary to separate multiple assignments and assertions, or to separate an assignment or assertion from a previous expression. For example:

the circuit layout is in material form AND

the circuit layout is an eligible layout

4.5.5 Assignments

IS and ONLY IF are used to assert that two attributes have identical values (but not that either are true/false), or that an attribute is identical to a constant. They can therefore be used in either of two ways:

attribute IS constant

attribute1 (unknown) IS attribute2 (known)

There is no difference between the IS and ONLY IF operators, but normally the use of IS will yield more natural English statements in relation to valued attributes (dates, numbers etc) where ONLY IF is more appropriate in the case of booleans (true/false).

4.5.6 Syntax for assignments and assertions

The syntax for assignments and assertions is:

[AND|ASSERT] attribute IS expression

or [AND|ASSERT] attribute ONLY IF expression

Where an ELSE statement is merely the negation of a THEN statement, this is exactly the same as an ONLY IF statement (which is preferable as it is more understandable). For example,

     IF  it is raining

     THEN  you should take an umbrella

     ELSE  you should not take an umbrella

would be better expressed as

you should take an umbrella ONLY IF it is raining

4.5.7 DETERMINE Statement

The DETERMINE statement allows for control over attribute evaluation. The syntax is:

DETERMINE [IF] attribute

The effect is to cause DataLex to determine a value for the attribute by first evaluating any relevant backward chaining rules (commencing with any which have attribute as a conclusion), and then, if necessary, prompt the end-user for a value.

The DETERMINE statement is sometimes useful as part of a GOAL RULE. It allows the user to simply specify that DataLex should attempt to evaluate a particular attribute. For example, the FOI example given earlier could commence with a rule including the statement:

DETERMINE IF a person has a legally enforceable right under s11 to obtain access to a document

However, this procedural approach will defeat the purpose of a declarative rule base if mis-used. In the above example, it would provide no advantages.

Avoid the use of DETERMINE statements.

4.5.8 CALL Statement [advanced]

The CALL statement allows rules and procedures to be invoked explicitly. The syntax is:

CALL procedure-name

The statements for the named rule or procedure will be executed and control will be returned to the next statement after the CALL. This statement should only be used to control knowledge-rich rules. It should not be part of any rule encompassing knowledge of any sort. CALLs are a procedural device which detracts from the declarative nature of the knowledge-base. They are valuable mainly for document generation, which is inherently procedural (see Chapter 4).

Use of CALLs should generally be avoided (except in DOCUMENT rules).

4.5.9 WHILE-DO and REPEAT-UNTIL Statements [advanced]

The WHILE-DO and REPEAT-UNTIL statement pairs, provide for conditional looping. The syntax is:

WHILE expression DO statement

and REPEAT statements UNTIL expression

4.5.10 Use of BEGIN - END pairs

Multiple statements can be grouped by use of a BEGIN-END pair. This is the same as using parentheses to group statements.

Example:

     IF the Act does not apply THEN BEGIN

           the claimant fails AND
           there is nothing more to do

     END

The use of BEGIN-END pairs is largely unnecessary due to the AND/OR operator (see below).

4.6 Appendix – List of Main Keywords (all types) used by DataLex

4.6.1 Rule types

RULE

GOAL

PROCEDURE

BACKWARD

FORWARD

DAEMON

DOCUMENT

EXAMPLE

4.6.2 Attribute types

BOOLEAN

INTEGER

REAL

DOLLAR

SEX

STRING

DATE

4.6.3 Document types

(Documents only)

PARAGRAPH

LINE

TEXT

4.6.4 Named subject types

THING

PERSONTHING

4.6.5 Translation operators

TRANSLATE - AS

PROMPT

4.6.6 Statement operators

ASSERT

DETERMINE

IF - THEN - ELSE

ONLY IF

IS

WHILE - DO

REPEAT - UNTIL

CALL

BEGIN - END

4.6.7 Expression operators

4.6.7.1 (Pre) Unary Operators

NOT

MINUS

PLUS

DAY

MONTH

YEAR

4.6.7.2 (Post) Unary Operators

DAYS

WEEKS

MONTHS

YEARS

4.6.7.3 Binary Operators

DIVIDED BY

TIMES

PLUS

MINUS

IN

EQUALS

NOT EQUALS

IS GREATER THAN

IS LESS THAN

IS GREATEREQUAL THAN

IS LESSEQUAL THAN

AND/OR

AND/OR/WITH

AND

AND/WITH

OR

OR/WITH

4.6.8 Layout operators

(Documents only)

NUMBERED

LEVEL

4.6.9 Miscellaneous keywords

RANGE - TO

VERBS

PROVIDES

ORDER