Różnice między wybraną wersją a wersją aktualną.
| Both sides previous revision Poprzednia wersja Nowa wersja | Poprzednia wersja | ||
|
pl:miw:2009:present:alsvfd [2009/05/24 23:07] jsi08 |
pl:miw:2009:present:alsvfd [2019/06/27 15:50] (aktualna) |
||
|---|---|---|---|
| Linia 194: | Linia 194: | ||
| ===== State and rule firing ===== | ===== State and rule firing ===== | ||
| - | In order to fire a rule all the precondition facts defining its LHS must be true within the current state. The verification procedure consists in matching these fact against the state specification. A separate procedure concerns simple (single-valued) attributes, and a separate one is applied in case of complex attributes. | + | * In order to fire a rule all the precondition facts defining its LHS must be true within the current state. |
| - | The following tables provide a formal background for preconditions matching and rule-firing procedure: | + | * The verification procedure consists in matching these fact against the state specification. |
| - | Tab.~6 | + | * A separate procedure concerns simple (single-valued) attributes, and a separate one is applied in case of complex attributes. |
| - | defines when a precondition of the form //A\propto d// is satisfied with respect to given state, | + | |
| - | and | + | |
| - | Tab.~7 | + | |
| - | defines the principles for matching precondition defined with set-valued attributes against the state formula. | + | |
| + | ===== State and rule firing ===== | ||
| {{:hekate:salrules-flairs-table6.png|}} | {{:hekate:salrules-flairs-table6.png|}} | ||
| - | Table 6: Inference principles for firing rules, case of single-valued attributes. | + | |
| + | ===== State and rule firing ===== | ||
| {{:hekate:salrules-flairs-table7.png|}} | {{:hekate:salrules-flairs-table7.png|}} | ||
| - | |||
| - | Table 7: Inference principles for firing rules, case of general attributes. | ||
| ===== ALSV Rules ===== | ===== ALSV Rules ===== | ||
| + | * ALSV(FD) has been introduced with practical applications for rule languages in mind. | ||
| + | * In fact, the primary aim of the presented language is to extend the notational possibilities and expressive power of the XTT-based tabular rule-based systems. | ||
| + | * An important extension consist in allowing for explicit specification of one of the symbols eq, neq, in, notin, subset, supset, sim, notsim, with an argument in the table. | ||
| - | ALSV(FD) has been introduced with practical applications for rule languages in mind. | + | ===== Rule Format ===== |
| - | In fact, the primary aim of the presented language is to extend the notational possibilities and expressive power of the XTT-based tabular rule-based systems. | + | |
| - | An important extension consist in allowing for explicit specification of one of the symbols | + | |
| - | eq, | + | |
| - | neq, | + | |
| - | in, | + | |
| - | notin, | + | |
| - | subset, | + | |
| - | supset, | + | |
| - | sim, | + | |
| - | notsim, | + | |
| - | with an argument in the table. | + | |
| - | + | ||
| - | ==== Rule Format ==== | + | |
| Consider a set of //n// attributes | Consider a set of //n// attributes | ||
| Linia 238: | Linia 223: | ||
| and RHS is the right-hand side of the rule covering conclusion and perhaps the retract and assert definitions if necessary. | and RHS is the right-hand side of the rule covering conclusion and perhaps the retract and assert definitions if necessary. | ||
| - | ==== Rule Firing ==== | + | ===== Rule Firing ===== |
| The current values of all the attributes are specified with the contents of the knowledge-base (including current sensor readings, measurements, inputs examination, etc.). | The current values of all the attributes are specified with the contents of the knowledge-base (including current sensor readings, measurements, inputs examination, etc.). | ||
| Linia 256: | Linia 241: | ||
| for complex. | for complex. | ||
| - | ==== ANY and NULL ==== | + | ===== ANY and NULL ===== |
| - | In case the value of A_i is unspecified we shall write A_i = NULL (a database convention). | + | * In case the value of A_i is unspecified we shall write A_i = NULL (a database convention). |
| - | + | * Following a Prolog convention and logic, a //ANY// attribute value is possible in comparison (see''_'' in Prolog). | |
| - | Following a Prolog convention and logic, a //ANY// attribute value is possible in comparison (see''_'' in Prolog). | + | * The semantics can be: "any value", "not important", etc. |
| - | + | * The solution: | |
| - | The semantics can be: "any value", "not important", etc. | + | * in preconditions, we can only use //ANY//, i.e. an atom such as ''A=_'' can be specified, meaning "any value", "all possible values of the attribute", "we don't care" |
| - | + | * on the other hand, attribute A unspecified, in the state formula means ''A=NULL'', so we store NULL in state | |
| - | The solution: | + | * here we come to an inference rule: ''A=NULL'' ==> ''A=_''. Seems to be valid... This rules should be optionally disabled/enabled in the inference engine. |
| - | * in preconditions, we can only use //ANY//, i.e. an atom such as ''A=_'' can be specified, meaning "any value", "all possible values of the attribute", "we don't care" | + | |
| - | * on the other hand, attribute A unspecified, in the state formula means ''A=NULL'', so we store NULL in state | + | |
| - | * here we come to an inference rule: ''A=NULL'' ==> ''A=_''. Seems to be valid... This rules should be optionally disabled/enabled in the inference engine. | + | |
| - | + | ||
| - | FIXME It seems, we could have three types of NULL-like values: Not-applicable, Potentially-applicable but taking no value empty/no-defined, Applicabe-and-takin-value but unknown. | + | |
