This section specifies the RIF-PRD constructs that are required, in addition to the [ RIF-PRD condition language] and the [ RIF-PRD action language], to represent, and interchange, complete production rules and rule sets.
In the first part of this section, the syntax that is used to represent production rules and rule sets is presented non-normatively: the normative reference for the XML syntax is the [ XML schema].
In the second part, the normative semantics for RIF-PRD rules and rulesets is specified.
Syntax
The overall structure of the syntax used to represent production rules and rule sets in RIF-PRD is depicted on the following diagram.
The RULE construct is an abstract class: in RIF-PRD instance documents, it is either visible as a ConditionalStatement or as a Forall:
The ConditionalStatement associates an optional CONDITION and one non-empty ordered list of ACTIONS.
*** Difference wrt RIF-BLD: The ConditionalStatement is the Implies construct of RIF-BLD. However, the word "Implies" does not carry the appropriate meaning for RIF-PRD. The proposal is to rename the Implies in RIF-BLD (to ConditionalStatement or whatever other name that is prefered) so that RIF-BLD and RIF-PRD can inherit the same construct from Core? ***
The Forall construct declares one or more Vars, possiblly using the Aggregation construct, and associates them with zero or more CONDITIONs, as patterns that constrain the bindings of the variables, and with one RULE as the formula in its scope.
The RuleSet construct has zero or more constructs of the RULE group associated as rules.
*** Do we need ruleset parameters, etc? ***
The following sections specify each construct separately, grouped by abstract syntactic classes. Each element is given an XML syntax, in the form of a BNF pseudo schema; a presentation syntax, in the form of an EBNF production; and an informal semantics. None of these is normative: the normative XML syntax is given in the [ RIF-PRD XML schema] and the normative semantics is given in the section [ Operational semantics].
RULE
In RIF-PRD, the RULE class of constructs is used to represent rules, that is "if-then" statements, possibly universally quantified.
XML syntax. As an abstract class, RULE is not associated with specific XML markup in RIF-PRD instance documents. It is specified in the normative schema as a substitution group.
*** ...Substitution group or another construct, depending on how we handle extensibility in the XML schema. ***
[ ConditionalStatement | Forall ]
*** Difference wrt RIF-BLD: The CONDITION is optional in a ConditionalStatement, but a list of ACTIONS with a trivially satisfied CONDITION is not the same, conceptually, as a head without a body in a logic program (e.g. it does not belong to the fact base). Thus, the rationale for making the head-without-a-body a different kind of RULE does not apply in the RIF-PRD case. ISSUE: how does Core represent a fact? From the answer to that question depends whether PRD and BLD may differ on this; preferably, they should not differ. ***
Presentation syntax.
RULE ::= ConditionalStatement | Forall
ConditionalStatement
The ConditionalStatement construct is used to represent the conditional statement (that is, the "if-then", or condition-conclusion, or antecedent-consequent pair) that is at the core of a rule.
XML syntax. The ConditionalStatement element contains zero or one if sub-element and one then sub-element:
the optional if element contains an element from the CONDITION class of constructs;
the required then element contains a non-empty list of elements from the ACTION class of constructs. The order of the ACTION constructs in the then element is significant and MUST be preserved.
*** Should we have an "else"-part, in addition to the if-part and the then-part? On the one hand, it is one of the rationale for separating the variable binding patterns CONDITIONs from the if-part CONDITION; on the other hand, what is the support for it among the rule languages RIF-PRD aims to cover? ***
<ConditionalStatement>
<if> CONDITION </if>?
<then>
ACTION
ACTION*
</then>
</ConditionalStatement>
*** Difference wrt RIF-BLD: the content of the then element is specific to RIF-PRD (but PRD and BLD share the structure of the construct). ***
Presentation syntax.
ConditionalStatement ::= (' IF ' CONDITION ' THEN ')? ACTIONS
ACTIONS ::= ACTION (' ; ' ACTION)*
Informal semantics. The ConditionalStatement is used to represent a conditional statement that is true iff:
the statement represented by the CONDITION in the if sub-element ("if"-part) is true and the actions represented by the ACTIONs listed in the then element ("then"-part) have been implemented successfully;
- or the "if"-part is missing and the "then"-part has been implemented successfully;
- or the "if"-part is false.
*** the notion of a truth valuation of ConditionalStatements is used here for compatibility with RIF Core. In a pure production rule context, "is true" could be informally translated by "has been successfully implemented" when applied to a ConditianlStatement ***
Forall
The Forall construct is used to represent universally quantified rules.
In addition to being a construct of the RULE class, Forall is also a construct of the QUANTIFICATION class: it inherits the syntactic features that are common to that class, as specified in [ section QUANTIFICATION].
XML syntax. The Forall element contains:
one or more declare sub-elements, each containing either:
a Var element that represent one of the universally quantified variable;
or, if an universally quantified variable is to be bound to an aggregate value, an Aggregation elements that represents the quantified variable and that specifies how the aggregate value is computed;
exactly one formula sub-element that represents the formula in the scope of the quantifier and that contains an element of the RULE group;
zero or more pattern sub-elements, each containing an element from the CONDITION group of constructs that represent a constraint on the bindings of one of the Vars that are declared by the Forall.
<Forall>
<formula> CONDITION </formula>
<declare>
[ Var | Aggregation ]
</declare>+
<pattern> CONDITION </pattern>*
</Forall>
*** Formula sub-element first to facilitate processing of nested Foralls and fallback to Core ***
*** Difference wrt RIF-BLD: in addition to Aggregation being allowed as the content of the declare element, the Forall in RIF-PRD adds, wrt BLD, the pattern sub-element to associate CONDITIONs to the declared Vars. One of the rationale for the Pattern sub-element is to allow "if-then-else" rules. Both differences are specific to RIF-PRD. ***
Presentation syntax.
Forall ::= ' FORALL ' [ Var | Aggregation ]+ (' SUCH THAT ' CONDITION)* ' ( ' RULE ' ) '
Informal semantics. The Forall construct is used to represent rules that are true iff the RULE content of the formula sub-element is true for all the combinations of bindings of the variables declared by the Forall that verify the CONDITION content of the pattern sub-elements, if any.
*** the notion of a truth valuation of rules and Foralls is used here for compatibility with RIF Core. In a pure production rule context, "is true" could be informally translated by "has been successfully implemented" when applied to a rule or a Forall. ***
RuleSet
The RuleSet construct is used to represent a set of rules that have to be considered together from a semantic or operational viewpoint (e.g. a knowledge base, a rule base, a ruleset).
XML syntax. The RuleSet element contains zero or more rule element. Each rule element contains an element from the RULE group of constructs that represents one of the rules contained in the rule set.
*** Shouldn't that be "at least one rule element"? ***
*** RuleSet parameters? Input/ouput Vars? ***
<RuleSet>
<rule> RULE </rule>*
</RuleSet>
Presentation syntax.
RuleSet ::= RULE*
Informal semantics. The RuleSet construct is used to represent sets of rules that is true iff the RULE content of all its rule sub-elements is true.
Operational semantics
The operational semantics of RULEs and `RuleSets is specified, in RIF-PRD, based on the operational semantics of the condition language, as specified in [ section Operational semantics of the condition language], and of the action language, as specified in [ section Operational semantcsi of action language.
Implementors are responsible for making sure that the RIF-PRD translation of rules and rulesets preserves their native semantics, according to the operational semantics for RIF-PRD RULEs and RuleSets that is specified below, and subject to a consistent translation of the specified data sources.
Conformant implementations MUST translate RULEs and RuleSets retrieved from RIF-PRD in such a way that their native evaluation against the specified data sources preserves their semantics, according to the operational semantics for RIF-PRD RULEs and RuleSets that is specified below, and subject to a consistent translation of the specified data sources.
The following sections specify the normative operational semantics of each construct separately, grouped by abstract syntactic classes.
RULE
A construct of the RULE class does not have an operational semantics if one of its components does not have an operational semantics.
*** What happens when a RULE "does not have an operational semantics in RIF-PRD"? ***
The sections below specifies the operational semantics of the constructs of the RULE class, where they have one.
ConditionalStatement
A ConditionalStatement is true iff any of the following is true:
the CONDITION content of its if sub-element is true and the ACTIONs in its then sub-element have been successfully implemented in the specified order;
it does not have an if sub-element and the ACTIONs in its then sub-element have been successfully implemented in the specified order;
the CONDITION content of its if sub-element is not true.
*** The operational semantics of RIF-PRD associates a truth value to RULEs and RuleSets for compatibility with RIF-Core: should that be made explicit in the text? ***
Forall
A Forall is true iff all its instances are true or it does not have any instance.
The instances of a Forall QUANTIFICATION are as specified in [ section Instances of a formula], where, for the purpose of specifying the accepted bindings of the Vars that are declared by a Forall, the additional conditions mentionned in the [ section Candidate and accepted bindings] are the CONDITIONs containted in the Forall's pattern sub-elements, if any.
The accepted bindings of a Var declared by a Forall are:
all its candidate bindings, as specified in [ section Candidate and accepted bindings], if the Forall does not have any pattern sub-element or if none of the Forall's pattern sub-elements contains the Var; or
those candidate bindings that make true the CONDITION content of all the Forall's pattern sub-elements that contain the Var, possibly subject to the bindings associated to the Forall for Vars declared by enclosing QUANTIFICATIONs.
*** A CONDITION pattern that constrain the binding of a Var cannot contain another Var declared by the same Forall, since the latter is not bound (and the CONDITION, therefore, does not have a semantics). Does that follow from the above specification or should that be specified explicitely? ***
*** The rationale for attaching 'pattern's to the Forall for constraining the bindings of variables instead of having all the conditions conjoined in the if-part is support for if-then-else or even more complex constructs in future versions/extensions of RIF-PRD; and of sequential modes of ruleset evaluation ***
RuleSet
Except if the RULE content of one of its rule sub-elements does not have an operational semantics in RIF-PRD, in which case it does not have an operational semantics in RIF-PRD itself, a RuleSet is true iff:
it does not contain any rule sub-element; or
or the RULE content of all its rule sub-elements is true.
*** What happens when a RuleSet "does not have an operational semantics in RIF-PRD"? ***
The operational semantics of the RuleSet construct is based on the specification of an agenda and of an inference cycle.
Agenda. The Agenda is defined, for the purpose of specifying the operational semantics of a RuleSet, as an ordered list of pairs, each composed of an instance of a RULE and a mark that can be: true or firable.
Inference cycle. The inference cycle is the process that determines the truth value of every instances of the RULE content of each rule sub-element of a RuleSet, and, thus, of the RuleSet itself.
The process is a cyclic rather than a linear one because the implementation of the ACTIONs in the then-part of an instance being fired may change the set of the instances of the RULE content of one or more of the RuleSet's rule sub-elements.
For the purpose of specifying the operational semantics of a RIF-PRD RuleSet, the inference cycle is defined in three steps:
Update agenda: The RULE content of each of the rule sub-elements of the RuleSet are instantiated as specified in [ section Instances of a formula] and [ section Forall], the CONDITION content of the if sub-element of the ConditionalStatement part of all the resulting instances is evaluated, and the Agenda is updated accordingly. To update the Agenda, each instance i resulting from the instantiation is compared with the instance part of the elements in the Agenda:
if there is an element i_a in the Agenda with an instance part that is equal to i and if the CONDITION content of the if sub-element of the ConditionalStatement part of i is false, the element i_a is removed from the Agenda;
if the instance part of no element in the Agenda is equal to i and if the CONDITION content of the if sub-element of the ConditionalStatement part of i is true, a new element is added to the Agenda consisting of i paired with the mark: firable;
The RuleSet is true iff the Agenda contains only elements marked true after it has been updated. The process stops when the RuleSet is true or another ending condition is met.
*** How are "other ending conditions" specified? Are they need in this version of RIF-PRD? ***
Sort agenda: The instances in the Agenda are sorted according to the specified algorithm.
*** Issue: Which agenda-sorting algo? How is it specified? Also see ACTION-378 ***
Fire rules: The first instance marked firable in the sorted Agenda is fired, or all the instances marked firable in the sorted agenda are fired in order, depending on the specified algorithm.
*** Issue: Which rule-firing algo? How is it specified? Any requirement for RIF-PRD to cover more than "forward-chaining" (first instance only is fired) and "sequential" (all fireable instances are fired)? ***
When an instance of a RULE is fired, the ACTIONs contained in the then sub-element of the ConditionalStatement part of the instance are implemented in the specified order with the associated Var bindings, if any. After and if all the ACTIONs have been implemented successfully, the instance is marked true in the Agenda (replacing the firable mark).