1. Formal Semantics for Rule-Based Systems 報告者：黃怡玲 指導教授：丁德榮

2. 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.

3. 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.

4. 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

5. A Simple Rule-Based System(1/2) The semantic system is constructed around a simple but representatve system.  A formal description of just one hypothetical rule-based language;limited. A program in this hypothetical system consists of  a collection of rules  their associated declarations.

6. 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 〉 ……………………

7. 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.

8. 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

9. 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” 〉

10. Semantics-Domains(3/3) Val=undefined  is Num (x) ≡ x€Realˇx=Undefined  is Bool (x) ≡ x€{True,False}ˇx=Undefined  is Str (x) ≡ x€Stringˇx=Undefined rule= ╳ ╳ 。

11. Semantics- Evaluation Function E defines the result of this evaluation. It is not possible for the evaluation of any expression to result 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 as a precursor to the firing of a rule. V and D determine whether a rule may be considered for firing, and E makes the final determination of firability and aids in the calculation of the effects of any rule that is fired.

12. 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.

13. 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.

14. 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.

15. 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.

16. Semantics-I nitial State(1/2) F: 〈 prog 〉╳ STATE ╳ PROG → STATE ╳ PROG F(empty) s,p = 〈 s,p 〉 F(IF c: 〈 cond 〉 a: 〈 acts 〉 BECAUSE r: 〈 exp1 〉 pp: 〈 prog 〉 ) s,p = F(pp) s,(p ∪ { }) F(a: m: t: n: pp: ) s,p = if €s F(pp) [s ∪ { }],p otherwise

17. Semantics-I nitial State(2/2) F(a: m: t: n: =e: pp: ) s,p = if €s if D t (e) {} =False F(pp) [s ∪ { }],p otherwise

18. 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 state  The program under execution  The user input yet to be read  The output so far produced

19. 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.

20. VARIATIONS-Evaluation of Logical Expressions(2/2) Full evaluation may be specified through some 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.

21. 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.

22. VARIATIONS-Undefined Vaiables (2/2) 〈 n, a, m, t, v, r 〉 €s ^ v ≠Undefined => lookup t ( 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)=”“

23. 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.

24. 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.

25. VARIATIONS-Refirable Rules(2/2) Better to provide an explicit definition of Run stating that Step is repeatedly applied until there are no firable rules and no askable questions. F(p) s ={} ^ @(p) s ={} => Run = F(p) s ≠{} ^ @(p) s ≠{} => Run =Run(Steps )

26. 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.