Rule Construction

Understanding the in's and out's of rules is necessary to build an effective Expert System.

Syntax and guidelines

Num field

• optional
• default = 1, 2, 3, ... (change via Edit | Options)
• must be integer, not necessarily unique
• guideline: group rules by some sensible scheme

Comment field

• Use to explain your rules
• Use Edit | edit for viewing (editing) complete rule

Priority

• Can be any integer (default = 50)
• Higher numbers mean higher priority.
• Use: so that a rule will be evaluated before another rule in the "conflict set."

Active

• Guideline: turn rule off to help debug

Rule Structure

• Most rules (not all)have IFs.
• All rules have 1 or more {THENs, ELSEs, UNKNOWNs}

Operators in IF-parts of rules

Guidelines

• Use =, >, <, etc. for numeric comparisons
• Use "is" for symbolic comparisons
• Avoid "isnot" and <>

Precedence

• AND binds more tightly than OR
• use the any( ) function in the place of parentheses

Guideline:

Better to write more, but clearer rules (than 1 which is possilby hard to understand)

Functions in IF-parts of rules

• IF car | color is any(blue, pink, "chocolate ice cream") THEN ...
• IF location | temperature = between(68, 70) THEN ...

THEN parts of rules

• Will "fire" when the IF-part is true
• assigns a value to an object | attribure or causes a "side effect"

Assignment operatorss (guideline)

• Use =, >, < ... for numeric assignments (...THEN a | b = 7.5)
• Use is, isnot for symbolic (isnot is safe here)
• Note: some assignments are INexact (... THEN amount > 5, e.g.)

Side effects

TEXT and SHOW: use to display text and graphics, respectively

• OK: THEN customer | preferred style is any(coupe, convertible, sedan)
• Do NOT write rules like: ... THEN water | temperature = between(23, 56)

ELSE parts of rules

• Fire when the "THEN" part is false
• same assignment operators as for IF

Guidelines

Use with caution. In developing a knowledge base, a heuristic or fact may "sound" like it has a natural "else." In fact, that may be a mistake.

Eg: IF age > 21 THEN Can Vote ELSE Can't .... only sounds right

UNKNOWN parts of rules

• If an object | attribute of a rule becomes a subgoal, has no value assigned to it initially (later we see how to do this), and all efforts to infer a value by firing rules or asking questions fail, the value of the object | attribute is UNKNOWN (though, it's probably better to think that it's UN-KNOWABLE).
• The UNKNOWN part of a rule fires when the rule's value is UNKNOWN.
• Pressing "USE" in response to a question also produces the value UNKNOWN.

Guideline

• Use as rule that you expect to provide a value when you know other rules failed to. E.g., to "force" a recommendation.

Multiple Values

• By default objects | attributes can have multiple values at once.
• Use the Object editor to over-ride this

IF-less Rules:

• Always fire (when their then part is part of a sub-goal).

Other issues of good rule design

• Have "balanced" buttons (automatic values)
• Avoid rules with multiple THENs (each about different ojbect | attributes)
• Try to always handle the "UNKNOWN" (unknowable) cases
• Don't write rules that violate object | attribute principles, such as
• IF I am going | to the store IS true THEN ...
• ... cause "I am going" is not an object, is it?
• Cover cases of "indifference," "don't care"
• Ensure recommendations.
• Avoid tricky rules. Rules should "make sense."
• Document all rules, especially long, subtle, or questionable ones.

Rule base design

• In general, start with goal rules.
• Work "backward" towards support rules.