Formal Semantics for Rule-Based Systems

報告者：黃怡玲指導教授：丁德榮

Introductin

Goal:develop a formal semantics in the denotational style for rule-based productino systems

A formal description of a generalized, hypothetical language for rule-based expert systems is developed as a base.

Building on this base, specifying in details the variations that distinguish individual real-world systems in a usable way.

Introductin

The use of production systems in the development of a KB API has been popular since they were demonstrated in the MYCIN and R1.

Fast and easy development of otherwise complex or infeasible systems.

Bring a new style of programming based on the paradigm of rule-based systems.

Along with many shells, environments, and languages simplified many programming tasks.

Problem

However the growth in rule-based environments was not supported by any theoretical model of these system.

This led to significant problems in the validation and verification of rule-based systems.

The development of an exact formal description of the new language is a step toward reliable validation and verification.

But focus on the specification of the shells inference process

A Simple Rule-Based System(1/2) The semantic system is constructed aroun

d a simple but representatve system.A formal description of just one hypothetical r

ule-based language;limited. A program in this hypothetical system con

sists of a collection of rules their associated declarations.

A Simple Rule-Based System(2/2)〈 rule 〉 → IF 〈 cond 〉 〈 acts 〉 [BECAUSE

〈 exp1 〉 ]〈 cond 〉 → 〈 identifier 〉 | 〈 relat 〉 |

〈 cond 〉 AND 〈 cond 〉 | 〈 cond 〉 OR 〈 cond 〉 | NOT 〈 cond 〉 | ( 〈 cond 〉 )

〈 relat 〉 → 〈 expr 〉 = 〈 expr 〉 | 〈 expr 〉 < 〈 exper 〉……………………

Modes and Declarations

To enable type checking, a declaration is required for every variable used.A type, a mode, and an accessibility with each

identifier.

Semantics-Domains(1/3)

The behavior of any rule is dependent on the current state of the system, so before the semantics of rules may be defined, a representation for the state must be selected.

Identifier:name, accessibility, mode, type, value

Semantics-Domains(2/3)

ID = NAME╳ACC╳MODE╳TYPE╳VAL╳REASON NAME=String ACC={Var,Fix} MODE={Ask,Ded} TYPE={Num,Bool,Str} VAL=Real+{True,False}+String+{Undefined} Reason=String Ex. 〈 “ class”, Fix, Ask, Num, 1, “user input” 〉

Semantics-Domains(3/3)

Val=undefined isNum (x) ≡ x€Realˇx=Undefined isBool (x) ≡ x€{True,False}ˇx=Undefined isStr (x) ≡ x€Stringˇx=Undefined

rule=<cond>╳<acts>╳<expl> 。

Semantics- Evaluation Function

E defines the result of this evaluation. It is not possible for the evaluation of any expression to res

ult in a change to the state of the system. D check that an expression or condition is being evaluated

within its domain and will not result in an invalid operation. V determines which questions may be asked of the user a

s a precursor to the firing of a rule. V and D determine whether a rule may be considered for f

iring, and E makes the final determination of firability and aids in the calculation of the effects of any rule that is fired.

Semantics-Variables(1/2)

Function V: 〈 expr 〉╳ State→ (setIdentifier) provides a list of those identifiers that are required for the evaluation of an expression, but are still both undefined and askable.

A AND B ： A may evaluate to false, knowns in B are not necessarily required; A may evaluate to true, then unknowns of B are required.

The purpose of V is to determine which questions may be asked of the user as a precursor to the firing of a rule.

Semantics-Variables(2/2)

V and D together determine whether a rule may even be considered for firing, and E (applied to the rule’s condition) makes the final determination of firability and aids in the calculation of the effects of any rule that is fired.

Semantics-Selection

Condition, action, reason A rule may not be fired if so doing would

cause an error when evaluating the actions or the reason.

A system will ask just one of the questions returned @ by before reconsidering what step to take next, by reevaluating F.

Semantics-Actions

An addition to D is required to ensure the validity of a deduction. The deduction of a new value for a variable is valid only if the type of

that value is the same as the declared type of the variable. A multiple action is only valid if all of its components are valid. A models the result of performing a deduction, return type of A is

STATE. Assign : only if the variable already exists and has the appropriate

type may an assignment take place R is a string-evaluating function used to construct reasons.

Semantics-Initial State(1/2)

F: 〈 prog 〉╳ STATE ╳ PROG → STATE ╳ PROGF(empty)s,p= 〈 s,p 〉

F(IF c: 〈 cond 〉 a: 〈 acts 〉 BECAUSE r: 〈 exp1 〉 pp: 〈 prog 〉 )s,p = F(pp)s,(p∪{<c,a,r>})

F(a:<acc> m:<mode> t:<type> n:<identifier> pp:<prog>)s,p=<{},{}> if <n,a’,m’,t’,v’,r’>€s

F(pp)[s∪{<n,a,m,t,Undefined, “ “>}],p otherwise

Semantics-Initial State(2/2)

F(a:<acc> m:<mode> t:<type> n:<identifier>=e:<expr> pp:<prog>)s,p

=<{},{}> if <n,a’,m’,t’,v’,r’>€s <{},{}> if Dt(e){}=False

F(pp)[s∪{<n,a,m,t,Undefined, “ “>}],p otherwise

THE EXECUTION CYCLE

The execution cycle of a typical system, after the initial state has been constructed.

SYS is a compound of four parts:Representing the current stateThe program under executionThe user input yet to be read The output so far produced

VARIATIONS-Evaluation of Logical Expressions(1/2) Logical expressions are subject to short-

circuit evaluation; the first operand of an AND or OR operation is always evaluated if the value of the first makes it necessary.

A AND B- A: False, B: undefined, short-circuit evaluation would return False, full evaluation would attempt to evaluate B and cause an error.

VARIATIONS-Evaluation of Logical Expressions(2/2) Full evaluation may be specified through s

ome simple alterations to the functions D and V .

D is changed to insist that the second operand of AND or OR is valid.

V determines the set of askable variables that are essential in an expression, but still undefined.

VARIATIONS-Undefined Vaiables (1/2) The function D returns false if applied to an

undefined identifier. If a run-time error is the correct behavior when

an undefined identifier is used, then it is sufficient to specify ┴ as the result of lookup.

A result of ┴ (“bottom”) will be propagated through any functions or operators that subsequently receive it as an operand.

VARIATIONS-Undefined Vaiables (2/2) 〈 n, a, m, t, v, r 〉€ s ^ v≠Undefined => lookupt ( i,

s)=v 〈 n, a, m,Num, v, r 〉€ s ^ v=Undefined => lookup

Num ( i, s)=0

〈 n, a, m, Bool, v, r 〉€ s ^ v=Undefined => lookup

Bool ( i, s)=False

〈 n, a, m, Str, v, r 〉€ s ^ v=Undefined => lookup

Str ( i, s)=”“

VARIATIONS-Conflict Resolution

The function Run is specified to just pick one possible firable rule, or one possible askable question.

Most systems give priority to the rule that was entered first. Require four simple changes:

The domain PROG must be redefined as list (RULE) instead of set (RULE)

The initial-state-generating function F must compile the PROG as a list, replacing the U operator with a ‖.

The function F should produce a list of firable rules instead of a set.

The partial definition of Step for a nonempty set of immediately firable rules must be modified to expect a list of firable rules, and always take the first.

VARIATIONS-Refirable Rules(1/2) The specification of Step shows that a rule

is removed from the program once it has fired, to prevent multiple firings and to provide a guarantee of progress during execution.

However, this could result in a situation in which an application of Step to a state results in no change to that state.

Run may no longer be defined as the least fixed point of Step.

VARIATIONS-Refirable Rules(2/2) Better to provide an explicit definition of R

un stating that Step is repeatedly applied until there are no firable rules and no askable questions.

F(p)s={} ^ @(p)s={} => Run<s, p, i, o>=<s, p, i, o>

F(p)s≠{} ^ @(p)s≠{} => Run<s, p, i, o>=Run(Steps<s, p, i, o>)

CONCLUSION

It is possible to give a complete definition of every detail of the execution of a rule-based expert system program, either for reference or to enable a proof of correctness, or complete verification and validation.

Furthermore, the more subtle variations between different implementations may be clearly described as differences in the semantics.