This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
hekate:alsvfd [2008/11/20 15:07] ligeza any/null use! |
hekate:alsvfd [2019/06/27 15:49] (current) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== The XTT^2 ALSV(FD) Specification ====== | ====== The XTT^2 ALSV(FD) Specification ====== | ||
| - | **Author**: Grzegorz J. Nalepa, based on the work with Antoni Ligêza | + | **Author**: Grzegorz J. Nalepa, based on the work with Antoni Ligęza |
| **Version**: Draft 2008Q3 | **Version**: Draft 2008Q3 | ||
| + | //Please put bigger remarks/discussusion, to the [[hekatedev:alsvfd|ALSV(FD) development page]]// | ||
| ===== Introduction to Attributive Logics ===== | ===== Introduction to Attributive Logics ===== | ||
| Line 17: | Line 18: | ||
| * [[hekate:bib:hekate_bibliography#gjn2008ruleapps|(gjn2008ruleapps)]] | * [[hekate:bib:hekate_bibliography#gjn2008ruleapps|(gjn2008ruleapps)]] | ||
| * [[hekate:bib:hekate_bibliography#ali2008aaia|(ali2008aaia)]] | * [[hekate:bib:hekate_bibliography#ali2008aaia|(ali2008aaia)]] | ||
| + | * [[hekate:bib:hekate_bibliography#gjn2009flairs-salrules(gjn2009flairs-salrules)]] | ||
| ===== ALSV(FD) ===== | ===== ALSV(FD) ===== | ||
| Line 86: | Line 88: | ||
| \end{table} | \end{table} | ||
| </latex> | </latex> | ||
| + | |||
| + | {{:hekate:salrules-flairs-table1.png|}} | ||
| Table 1: Simple attribute formulas syntax | Table 1: Simple attribute formulas syntax | ||
| Line 118: | Line 122: | ||
| \end{table} | \end{table} | ||
| </latex> | </latex> | ||
| + | |||
| + | {{:hekate:salrules-flairs-table2.png|}} | ||
| Table 2: Generalized attribute formulas syntax | Table 2: Generalized attribute formulas syntax | ||
| Line 232: | Line 238: | ||
| \end{table} | \end{table} | ||
| </latex> | </latex> | ||
| + | |||
| + | {{:hekate:salrules-flairs-table3.png|}} | ||
| + | |||
| Table 3: Inference rules for atomic formulae for simple attributes | Table 3: Inference rules for atomic formulae for simple attributes | ||
| Line 261: | Line 270: | ||
| \end{table*} | \end{table*} | ||
| </latex> | </latex> | ||
| + | {{:hekate:salrules-flairs-table4.png|}} | ||
| + | |||
| Table 4: Inference rules for atomic formulae for generalized attributes | Table 4: Inference rules for atomic formulae for generalized attributes | ||
| Line 307: | Line 318: | ||
| \end{table} | \end{table} | ||
| </latex> | </latex> | ||
| + | |||
| + | {{:hekate:salrules-flairs-table5.png|}} | ||
| + | |||
| Table 5: Inconsistency conditions for pairs of atomic formulae | Table 5: Inconsistency conditions for pairs of atomic formulae | ||
| Line 313: | Line 327: | ||
| The Table can be used for analysis of determinism of the system, i.e. whether satisfaction of precondition of a rule implies that the other rules in the same table cannot be fired. | The Table can be used for analysis of determinism of the system, i.e. whether satisfaction of precondition of a rule implies that the other rules in the same table cannot be fired. | ||
| + | |||
| + | |||
| + | ===== ALSV(FD) and State, State Representation and Inference ===== | ||
| + | |||
| + | |||
| + | When processing information, the current values of attributes form the state of the inference process. The values of attributes can, in general, be modified in the following three ways: | ||
| + | - by an independent, external system, | ||
| + | - by the inference process, and | ||
| + | - as some clock-dependent functions. | ||
| + | The first case concerns attributes which represent some process variables, which are to be incorporated in the inference process, but depend only of the environment and external systems. As such, the variables cannot be directly influenced by the XTT system. Examples of such variables may be the external temperature, the age of a client or the set of foreign languages known by a candidate. Values of such variables are obtained as a result of some measurement or observation process. They are assumed to be put into the inference system via a //blackboard// communication method; in fact they are written directly into the internal memory whenever their values are obtained or changed. | ||
| + | |||
| + | The second case concerns the values of attributes obtained at certain stage of reasoning as the result of the operations performed in RHS of XTT. The new values of the attributes can be: | ||
| + | * asserted to global memory (and hence stored and made available for any components of the system), or | ||
| + | * kept as values of internal process variables. | ||
| + | The first solution is offered mostly for permanent changes; before asserting new values typically and appropriate retract operation is to be performed so as to keep a consistent state. In this way also the history (trajectory) of the system can be stored, provided that each value of an attribute is stored with a temporal index. | ||
| + | The second solution is offered for value passing and calculations which do not require permanent storage. For example, if a calculated value is to be passed to some next XTT component and it is no longer used after, it is not necessary to store it in the global memory. | ||
| + | |||
| + | ==== The State of the System ==== | ||
| + | |||
| + | The current state of the system is considered as a complete set of values of all the attributes in use at a certain instant of time. The concept of the state is similar to the one in dynamic systems and state-machines. The representation of the state should satisfy the following requirements: | ||
| + | - the specification is //internally consistent//, | ||
| + | - the specification is //externally consistent//, | ||
| + | - the specification is //complete//, | ||
| + | - the specification is //deterministic//, | ||
| + | - the specification is //concise//. | ||
| + | The first postulate says that the specification itself cannot be inconsistent at the syntactic level. For example, a simple attribute (one taking a single value) cannot take two different values at the same time. In general, assuming independence of the attributes and no use of explicit negation, each value of an attribute should be specified once. | ||
| + | The second postulate says, that only //true// knowledge (with respect to the external system) can be specified in state. In other words, facts that are syntactically correct but false cannot occur in the state formula. | ||
| + | The third postulate says, that //all// the knowledge true at a certain instant of time should be represented within the state. | ||
| + | The four postulate says that there can be no disjunctive knowledge specification within the state. | ||
| + | Finally, the fifth postulate says that no unnecessary, dependent knowledge should be kept in the state. In databases and most of the knowledge bases this has a practical dimension: only true facts are represented explicitly. | ||
| + | |||
| + | The current values of all the attributes are specified with the contents of the knowledge-base (including current sensor readings, measurements, inputs examination, etc.). From logical point of view it is a formula of the form: | ||
| + | <latex> | ||
| + | $(A_{1}=S_{1})\wedge(A_{2}=S_{2})\wedge \ldots \wedge (A_{n}=S_{n})$ | ||
| + | </latex> | ||
| + | where $S_{i} = d_{i}$ ($d_{i}\in D_{i}$) for simple attributes and $S_{i}= V_{i}$, ($V_{i}\subseteq D_{i}$) for complex. | ||
| + | |||
| + | In order to cover realistic cases some explicit notation for covering unspecified, unknown values is proposed; this is so to deal with the data containing the NULL values imported from a database. | ||
| + | The first case refers to unspecified value of an attribute as a consequence of inappropriateness. A formula of the form | ||
| + | $A=\bot$ | ||
| + | means that the attribute $A$ takes an empty set of values (no value at all) at the current instant of time (or forever) for the object under consideration. For example, the attribute ''Maiden_Name'' or ''The_Year_of_Last_Pregnancy'' for a man is not applicable and hence it takes no value for all men. | ||
| + | %% | ||
| + | The second case refers to a situation that the attribute may be applied to an object, but it takes no value. This will be denoted as //A=\emptyset//. | ||
| + | For example, the formula ''Phone_Number''=//\emptyset// means that the considered person has no phone number. | ||
| + | %% | ||
| + | The third case is for covering the ''NULL'' values present in relational databases. A formula of the form | ||
| + | //A=\mathtt{NULL}// | ||
| + | means that attribute $A$ takes an unspecified value. | ||
| + | |||
| + | |||
| + | ==== 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. | ||
| + | The following tables provide a formal background for preconditions matching and rule-firing procedure: | ||
| + | Tab.~6 | ||
| + | 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. | ||
| + | |||
| + | |||
| + | {{:hekate:salrules-flairs-table6.png|}} | ||
| + | Table 6: Inference principles for firing rules, case of single-valued attributes. | ||
| + | |||
| + | {{:hekate:salrules-flairs-table7.png|}} | ||
| + | |||
| + | Table 7: Inference principles for firing rules, case of general attributes. | ||
| ===== ALSV Rules ===== | ===== ALSV Rules ===== | ||
| Line 371: | Line 452: | ||
| * on the other hand, attribute A unspecified, in the state formula means ''A=NULL'', so we store NULL in state | * 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. | * 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. | ||
