Copyright © 2008 W3C^{®} (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document specifies RIFPRD, a Rule Interchange Format (RIF) dialect to enable the interchange of production rules.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is being published as one of a set of 5 documents:
The Rule Interchange Format (RIF) Working Group seeks public feedback on these Working Drafts. Please send your comments to publicrifcomments@w3.org (public archive). If possible, please offer specific changes to the text that would address your concern. You may also wish to check the Wiki Version of this document for internalreview comments and changes being drafted which may address your concerns.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Contents

This document specifies the production rule dialect of the W3C rule interchange format (RIFPRD), a common XML serialisation format for many production rule languages.
Production rules are rules with an "if" part and a "then" part. The "if" part, also called a "condition", is like the condition part of logic rules (as covered by the basic logic dialect of the W3C rule interchange format, RIFBLD). The "then" part of production rules may contain actions, unlike the conclusion of logic rules that may contain only a logical statement. Actions can modify the facts, not only the knowledge base; and they can have other sideeffects.
Example 1.1. «A customer becomes a "Gold" customer as soon as his cumulative purchases during the current year top $5000»; «Customers that become "Gold" customers must be notified immediately, and a golden customer card will be printed and sent to them within one week»; «For shopping carts worth more than $1000, "Gold" customers receive an additional discount of 10% of the total amount», are all examples of production rules.
As a production rule interchange format, RIFPRD specifies an abstract syntax that is shared by many concrete production rule languages for the most widely used features, and associates each abstract construct with normative semantics (section 2, Abstract syntax and Semantics) and a normative XML concrete syntax (section 3, XML syntax).
Production rules are statements of programming logic that specify the execution of one or more actions in the case that their conditions are satisfied. Production rules therefore have an operational semantic (formalizing state changes, e.g., on the basis of a state transition system formalism). The OMG Production Rule Representation specification [PRR] summarizes it as follows:
In the section Operational semantics of rules and rule sets, the semantics for rules and rule sets is specified, accordingly, as a label terminal transition system [ref Plotkin].
However, as a RIF dialect, RIFPRD has also been designed to maximize interoperability between rule languages over the World Wide Web. In RIF, this is achieved by sharing the same syntax for constructs that have the same semantics across multiple dialects. As a consequence, RIFPRD shares most of the syntax for rule conditions with RIFBLD, and the semantics associated to the syntactic constructs used for representing the condition part of rules in RIFPRD is specified, in the section Semantics of conditions, in terms of a model theory, as it is in the specification of RIFBLD as well. In addition to emphasizing the similarity between the two dialects, it allows them to share the same definition for data types and builtins by reference to the RIF data types and builtins specification.
In the section Operational semantics of actions, the semantics associated with the constructs used to represent the action part of rules in RIFPRD is specified in terms of a transition relation between successive states of the data source, as defined by the condition formulae that they entail, thus making the link between the modeltheoretic semantics of conditions and the operational semantics of rules and rulesets.
The abstract syntax is specified in mathematical english, and the abstract syntactic constructs defined in section 2, Abstract syntax and Semantics, are mapped one to one onto the concrete XML syntax in section 3, XML syntax. A lightweight notation is also defined along with the abstract syntax, to allow for a humanfriendlier specification of the semantics. A more complete presentation syntax is specified using an EBNF in section 4. However, only the XML syntax and the associated semantics are normative. A normative XML schema will also be provided in future versions of the document;
Example 1.2. In RIFPRD presentation syntax, the first rule in example 1.1. might be represented as follows:
Prefix(ex1 http://rif.example.com/2008/prd#) (* ex1:rule_1 *) Forall ?customer ?purchasesYTD ( If And( ?customer#ex1:Customer ?customer[ex1:purchasesYTD>?purchasesYTD] External(pred:numericgreaterthan(?purchasesYTD 5000))) Then ex1:Gold(?customer) )
RIFPRD and RIFBLD share more than part of their condition language, and whole RIF documents have the same syntax and the same intended meaning in both dialects. The correspondence between RIFPRD and RIFBLD is detailed in Appendix: Compatibility with RIFBLD.
This document is mostly intended for the designers and developers of RIFPRD implementations, that is, applications that serialize production rules as RIFPRD XML (producer applications) and/or that deserialize RIFPRD XML documents into production rules (consumer applications).
This section specifies the language of the rule conditions that can be serialized using RIFPRD, by specifying:
Note to the reader: this section depends on Section Constants, Symbol Spaces, and Datatypes of [RIFDTB].
For a production rule language to be able to interchange rules using RIFPRD, its alphabet for expressing the condition parts of a rule must, at the abstract syntax level, consist of:
For the sake of readibility and simplicity, this specification introduces a notation for these constructs. That notation is not intended to be a concrete syntax and it leaves out many details that are not needed for its purpose: the only concrete syntax for RIFPRD is the XML syntax.
Notice that the production rule systems for which RIFPRD aims to provide a common XML serialization use only externally specified functions, e.g. builtins. This is one of two points where the syntaxes for conditions in RIFPRD and RIFBLD differ, since RIFBLD specifies, in addition, a construct for serializing the logic functions that logic languages also use.
The second point of difference between the syntaxes for conditions in RIFPRD and RIFBLD is that, unlike RIFPRD, RIFBLD does not specify a construct for negation. This is because logic rule languages use many different kinds of negations, none of them prevalent enough to justify inclusion in the basic logic dialect of RIF (see also the RIF framework for logic dialects).
The most basic construct that can be serialized using RIFPRD is the term. RIFPRD provides for the representation and interchange of several kinds of terms: constants, variables, positional terms and terms with named arguments
Definition (Term).
The atomic truthvalued constructs that can be serialized using RIFPRD are called atomics.
Definition (Atomic). An atomic can have several different forms and is defined as follows:
Note that not only predicates, but also frame atomics can be externally defined. Therefore, external information sources can be modeled in an objectoriented way via frames. For instance, External("http://example.com/acme"^^rif:iri["http://example.com/mycompany/president"^^rif:iri(?Year) > ?Pres]) could be a representation of an externally defined method "http://example.com/mycompany/president"^^rif:iri in an external object "http://example.com/acme"^^rif:iri. ☐
Observe that the argument names of frames, p_{1}, ..., p_{n}, are terms and so, as a special case, can be variables. In contrast, atoms with named arguments can use only the symbols from ArgNames to represent their argument names. They cannot be constants from Const or variables from Var.
Note that atomics are sometimes also called terms, e.g. in the realm of logic languages: the specification of RIFBLD, in particular, follows that usage. The abstract syntactic elements that are called terms in this specification, are called basic terms in the specification of RIFBLD.
Composite truthvalued constructs that can be serialized using RIFPRD are called formulas.
Any atomic is also an atomic formula.
Note that terms (constants, variables and functions) are not formulas.
More general formulas are constructed out of the atomic formulas with the help of logical connectives.
Definition (Condition formula). A condition formula can have several different forms and is defined as follows:
In the definition of a formula, the component formulas φ and φ_{i} are said to be subformulas of the respective condition formulas that are built using these components.
The function Var(e) that maps a term, atomic or formula e to the set of its free variables is defined as follows:
Definition (Ground formula). A condition formula φ is a ground formula if and only if Varφ = {} and φ does not contain any existential subformula.
In other words, a ground formula does not contain any variable term.
The specification of RIFPRD does not assign a standard meaning to all the formulas that can be serialized using its concrete XML syntax: formulas that can be meaningfully serialized are called wellformed. Not all formulas are wellformed with respect to RIFPRD: it is required that no constant appear in more than one context. What this means precisely is explained below.
The set of all constant symbols, Const, is partitioned into several subsets as follows:
Each predicate and function symbol has precisely one arity. For positional predicate and function symbols, an arity is a nonnegative integer that tells how many arguments the symbol can take. For symbols that take named arguments, an arity is a set {s_{1} ... s_{k}} of argument names (s_{i} ∈ ArgNames) that are allowed for that symbol.
An important point is that neither the above partitioning of constant symbols nor the arity are specified explicitly. Instead, the arity of a symbol and its type is determined by the context in which the symbol is used.
Definition (Context of a symbol). The context of an occurrence of a symbol, s∈Const, in a formula, φ, is determined as follows:
Definition (Wellformed formula). A formula φ is wellformed iff:
Definition (RIFPRD condition language). The RIFPRD condition language consists of the set of all wellformed formulas that can be serialized using the RIFPRD XML syntax.
This section specifies the intended semantics of the condition formulas in a RIFPRD document.
For compatibility with other RIF specifications (in particular, RIF data types and builtins), and to make the interoperability with RIF logic dialects (in particular RIFCore and RIFBLD), the intended semantics for RIFPRD condition formulas is specified in terms of a model theory.
The key concept in a modeltheoretic semantics of a logic language is the notion of a semantic structure [Enderton01, Mendelson97].
Definition (Semantic structure). A semantic structure, I, is a tuple of the form <TV, DTS, D, D_{ind}, I_{C}, I_{V}, I_{P}, I_{NP}, I_{frame}, I_{sub}, I_{isa}, I_{=}, I_{external}, I_{truth}>. Here D is a nonempty set of elements called the domain of I, and D_{ind} is a nonempty subset of D. D_{ind} is used to interpret the elements of Const that are individuals. As before, Const denotes the set of all constant symbols and Var the set of all variable symbols. TV denotes the set of truth values that the semantic structure uses and DTS is a set of identifiers for primitive datatypes (please refer to Section Datatypes of [RIFDTB] for the semantics of datatypes).
As far as the assignement of a standard meaning to formulas in the RIFPRD condition language is concerned, the set TV of truth values consists of just two values, t and f.
The other components of I are total mappings defined as follows:
For convenience, we also define the following mapping I from terms to D:
The effect of datatypes. The set DTS must include the datatypes described in Section Primitive Datatypes of [RIFDTB].
The datatype identifiers in DTS impose the following restrictions. Given dt ∈ DTS, let LS_{dt} denote the lexical space of dt, VS_{dt} denote its value space, and L_{dt}: LS_{dt} → VS_{dt} the lexicaltovaluespace mapping (for the definitions of these concepts, see Section Primitive Datatypes of [RIFDTB]. Then the following must hold:
That is, I_{C} must map the constants of a datatype dt in accordance with L_{dt}.
RIFPRD does not impose restrictions on I_{C} for constants in symbol spaces that are not datatypes included in DTS.
This section defines how a semantic structure, I, determines the truth value TVal_{I}(φ) of a condition formula, φ.
We define a mapping, TVal_{I}, from the set of all condition formulas to TV. Note that the definition implies that TVal_{I}(φ) is defined only if the set DTS of the datatypes of I includes all the datatypes mentioned in φ and I_{external} is defined on all externally defined functions and predicates in φ.
Definition (Truth valuation). Truth valuation for wellformed condition formulas in RIFPRD is determined using the following function, denoted TVal_{I}:
We now define what it means for a set of ground formulas to satisfy a condition formula. The satisfaction of condition formulas by a set of ground formulas provides formal underpinning to the operational semantics of rulesets interchanged using RIFPRD.
Definition
(Models). A semantic structure I is a
model of a condition formula, φ, written as
I = φ, iff
TVal_{I}(φ) = t.
Definition (Logical entailment). Let φ and ψ be formulas. We say that φ entails ψ, written as φ = ψ, if and only if for every semantic structure, I, for which both TVal_{I}(φ) and TVal_{I}(ψ) are defined, I = φ implies I = ψ.
By extension, in this document, a set of formulas, Φ = {φ_{1}, ..., φ_{n}}, n ≥ 1, is said to entail a formula ψ, written as Φ = ψ, if and only if for every semantic structure, I, for which TVal_{I}(φ_{0}), ..., TVal_{I}(φ_{n}), and TVal_{I}(ψ) are defined, I = φ_{0} and ... and I = φ_{n} implies I = ψ.
Definition (Condition Satisfaction). Let Φ = {φ_{1}, ..., φ_{m}}, m ≥ 1, be a set of ground formulas and ψ be a condition formula. We say that Φ satisfies ψ if and only if, for every semantic structure I that is a model of all the ground formulas φ_{i} in Φ: I = φ_{i}, i= 1..m, there is at least one semantic structure I* such that:
In other words, a set of ground formulas Φ = {φ_{1}, ..., φ_{m}}_{m ≥ 1} satisfies a condition formula ψ iff Φ = Exists ?v_{0} ... ?v_{n} (ψ), where {?v_{0}, ..., ?v_{n}}_{n ≥ 0} = Var(ψ).
At the syntactic level, the interpretation of the variables by a valuation function I_{V} is realized by a substitution. The matching substitution of constants to variables, as defined below, provides the formal link between the modeltheoretic semantics of condition formulas and the operational semantics of rule sets in RIFPRD.
Let Term be the set of the terms in the RIFPRD condition language (as defined in section Terms).
Definition (Substitution). A substitution is a finitely nonidentical assignment of terms to variables; i.e., a function σ from Var to Term such that the set {x ∈ Var  x ≠ σ(x)} is finite. This set is called the domain of σ and denoted by Dom(σ). Such a substitution is also written as a set such as σ = {t_{i}/x_{i}}_{i=0..n} where Dom(σ) = {x_{i}}_{i=0..n} and σ(x_{i}) = t_{i}, i = 0..,n.
Definition (Ground Substitution). A ground substitution is a substitution σ that assigns only constants to the variables in Dom(σ): ∀ x ∈ Dom(σ), σ(x) ∈ Const.
Definition (Matching Substitution). Let ψ be a condition formula; let σ be a ground substitution for the free variables of ψ, that is, such that: Var(ψ) ⊆ Dom(σ); and let Φ be a set of ground formulas that satisfies ψ. We say that σ is matching Ψ to Φ (or simply, matching, when there is no ambiguity with respect to Ψ and Φ) if an only if, for every semantic structure I that is a model of all the ground formulas φ_{i} in Φ, there is at least one semantic structure I*, such that:
In the definition of a matching substitution, conditions 1 and 2 are the same as in the definition of Condition Satisfaction, and they guarantee that the Φconsistency of a substitution for the free variables in ψ is defined with respect to the same semantic structures that make Φ satisfy ψ. Condition 3 guarantees that Φ = ψ[σ], where ψ[σ] denotes the ground condition formula obtained by substituting σ(?x) for every occurence of ?x in ψ, for every variable ?x in Var(ψ).
In other words, a formula ψ matches a ground formula And(φ_{1}, ..., φ_{n}), n > 0, with respect to a ground substitution σ, in the usual sense of pattern matching algorithms, e.g. [REFERENCE], if and only if σ is a matching substitution for the free variables of ψ with respect to the set of ground formulas Φ = {φ_{1}, ..., φ_{n}}.
This section specifies the actions that can be serialized using RIFPRD, by specifying:
(See also: Proposed modified abstract syntax and semantics for option 3)
For a production rule language to be able to interchange rules using RIFPRD, its alphabet for expressing the action part of a rule must, at the abstract syntax level, consist of syntactic constructs to denote:
Editor's Note: ... and/or others. We are especially interested in feedback about actions that cannot be decomposed into a sequence of the above.
For the sake of readability and simplicity, this specification introduces a nonnormative notation for these constructs. That notation is not intended to be a concrete syntax and it leaves out many details that are not needed for its purpose. The only normative concrete syntax for RIFPRD is the XML syntax.
Atomic action constructs take constructs from the RIFPRD condition language as their arguments.
Definition (Atomic action). An atomic action can have several different forms and is defined as follows:
Action variable bindings provide a limited mechanism to initialize local action variables. Action variables may be bound to newly created frame objects or to slot values of frames.
Definition (Action variable binding). An action variable binding can have two forms and is defined as follows:
A sequence of zero or more variables followed by a sequence of zero or more action variable bindings followed by a sequence of one or more atomic actions is called an action block.
Definition (Action block). If v_{1}, ..., v_{n1}, n_{1} ≥ 0, are variables (sometimes called action variables) and b_{1}, ..., b_{n2}, n_{2} ≥ 0, are action variable bindings and a_{1}, ..., a_{n3}, n_{3} ≥ 1, are atomic actions,
Definition (Wellformed action block). An action block is wellformed if and only if:
Definition (Ground atomic action). An atomic action with target t is a ground atomic action (or, simply, a ground action) if and only if Var(t) ⊆ bv, where bv is the set of variables declared in an enclosing action block, if any.
If the then part of a rule consists of a single action Assert(φ) then that action is written as simply φ.
If the then part of a rule consists of the action block Do(Assert(φ_{1}) ... Assert(φ_{n})), n ≥ 2, then that action block is written as simply And(φ_{1} ... φ_{n}).
Definition (Wellformed action). An action α is wellformed if and only if:
Definition (RIFPRD action language). The RIFPRD action language consists of the set of all the wellformed actions.
This section specifies the intended semantics of the actions in a RIFPRD document.
The effect intended of the ground actions in the RIFPRD action language is to change the set of conditions that are satisfied before and after each action is implemented.
As a consequence, the intended semantics of the ground actions in the RIFPRD action language determines a relation, called the RIFPRD transition relation: →_{RIFPRD} ⊆ P(W) × L × P(W), where W denotes the set of all the ground condition formulas in the RIFPRD condition languages; where P(W) denotes the power set of W; and where L denotes the set of all the ground atomic actions in the RIFPRD action language.
Definition (RIFPRD transition relation). The intended semantics of RIFPRD actions is completely specified by the transition relation →_{RIFPRD} ⊆ P(W) × L × P(W). (w, α, w') ∈ →_{RIFPRD} if and only if w ∈ W, w' ∈ W, and one of the following is true:
Rule 1 says that all the condition formulas that were satisfied before an assertion will be satisfied after, and that the condition formulas that are satisfied by the asserted ground formula will be satisfied after the assertion.
Rule 2 says that all the condition formulas that were satisfied before a retraction will be satisfied after, except if they are satisfied only by the retracted fact.
Rule 3 says that all the condition formulas that were satisfied before the removal of a frame object will be satisfied after, except if they are satisfied only by one of the frame or membership formulas about the removed object or a conjunction of such formulas.
Rule 4 says that the effect of a block of actions is the effect of executing each action one after the other.
This section specifies the rules and rulesets that can be serialized using RIFPRD, by specifying:
In addition, this section specifies additional concrete XML syntax for wrapping a ruleset in a RIFPRD document and for adding metadata to elements in a RIFPRD document.
For a production rule language to be able to interchange rules using RIFPRD, in addition to the RIFPRD condition and action languages, its alphabet must, at the abstract syntax level, contain syntactic constructs:
For the sake of readability and simplicity, this specification introduces a notation for these constructs. That notation is not intended to be a concrete syntax and it leaves out many details that are not needed for its purpose: the only concrete syntax for RIFPRD is the XML syntax.
Definition (Rule). A rule can be either:
A rule If condition, Then action can be equivalently noted action : condition, that is, using RIFBLD logic programming notation. Indeed, the normative XML syntax is the same for a conditional assertion in RIFBLD and for a conditional action in RIFPRD. The use of RIFBLD notation is especially useful if the condition formula, condition, contains no negation, and if action is an atomic conclusion or a conclusion block, to emphasize that such a rule has the same semantics in RIFPRD and RIFBLD.
Notice that the notation for a rule with bound variables uses the keyword Forall for the same reasons, that is, to emphasize the overlap with RIFBLD. Indeed, although Forall does not indicate the universal quantification of the declared variables, in RIFPRD, but merely that the execution of the rule must be considered for all their bindings as constrained by the binding patterns, the semantics of a RIFPRD rule with bound variables and the semantics of a RIFBLD universally quantified rule coincide whenever they have the same RIF XML syntax.
Definition (Group). If strategy denotes a conflict resolution strategy, if priority is an integer, and if each rg_{j}, 0 ≤ j ≤ n, is either a rule or a group, then any of the following is a group:
The function Var(f), that has been defined for condition formulae and extended to actions, is further extended to rules, as follows:
Definition (Wellformed rule). A rule, r, is a wellformed rule if and only if it contains no free variable, that is, Var(r) = 0, and either:
Definition (Wellformed group). A wellformed group is either a group that contains only wellformed rules and wellformed groups, or a group that contains no rule or group (an empty group).
The set of the wellformed groups contains all the production rulesets that can be meaningfully interchanged using RIFPRD.
For the purpose of specifying the semantics of a RIFPRD rule or group of rules, a production rule system PRS is defined as a labeled terminal transition system (e.g. PLO04).
Definition (labeled terminal transition system): A labeled terminal transition system is a structure {C, L, →, T}, where
A labeled transition system is a structure {C, L, →} (without a set T of final states).
The idea of describing a PRS as a labeled terminal transition system is that, given a set of production rules RS and a set of facts w_{0}, the rules in RS that are satisfied, in some sense, in w_{0} determine an action a_{1}, which execution results in a new set of facts w_{1}; the rules in RS that are satisfied in w_{1} determine an action a_{2} to execute in w_{1}, and so on, until the system reaches a final state and stops. The result is the set of facts w_{n} when the system stops.
Example 3.1. Judicael, one follower of Joe the Hen Public's method, has four chickens, Joe, Jack, Joe and Julia, that own three potatoes (BigPotato, SmallPotato, UglyPotato) among them:
That is the initial set of facts w_{0}. Paula's rule set contains one single rule, that is, Joe's CMP rule:
(* joe:ChickenAndMashedPotatoes *) Forall ?chicken ?potato ?allowance ?age ?weight ( Do( Execute(joe:mash(?potato)) Retract(?chicken[joe:allowance>?allowance]) ?chicken[joe:allowance>External(func:numericmultiply(?allowance 1.1))] Retract(joe:owns(?chicken ?potato)) ) : And( ?chicken#joe:Chicken ?chicken[joe:age>?age joe:allowance>?allowance] External(pred:numericgreaterthan(?age, 8)) ?potato#joe:Potato ?potato[joe:weight>?weight] joe:owns(?chicken ?potato) External(pred:numericgreaterthan(?weight External(func:numericdivide(?age 2)))) External(pred:stringnotequals(External(joe:today()), "Tuesday")) Not(External(joe:foxAlarm())) ))
When the rule is applied to w_{0}:
Suppose that Judicael's implementation of today() returns Monday and that the foxAlarm() is false when the CMP rule is applied: the condition is satisfied, and the actions in the conclusion are executed with BigPotato substituted for ?potato, Joe substituted for ?chicken, and 10 substituted for ?allowance. This results in the following changes in the set of facts:
The resulting set of facts w_{1} is thus:
When the CMP rule in applied to w_{1}, the first External predicate still selects {Joe/?chicken, Jack/?chicken, Julia/?chicken} as possible values for variable ?chicken, but the joe:own relation and the second External predicate do not select any possible substitution for the couple (?chicken, ?potato) anymore: the rule cannot be satisfied, and the system, having detected a final state, stops.
The result of the execution of the system is w_{1}.
In the remainder of this section, as in the section on the operational semantics of actions, W denotes the set of all the ground condition formulas in the RIFPRD condition languages, and L denotes the set of all the ground atomic actions in the RIFPRD action language. In addition, LC denotes the set of the formulas in the RIFPRD condition language, and R denotes the set of all the rules in the RIFPRD rule language. Finally, given a set X, P(X) will denote the power set of X and S(X), the set of all the finite sequences of elements of X.
For the purpose of this section, an instance of a rule, r ∈ R, is defined as a couple (r^{id}, σ), where r^{id} uniquely identifies r and σ is a ground substitution such that Var(r) ⊆ Dom(σ). Given a rule instance ri = (r^{id}, σ), rule(ri) denotes the rule that is uniquely identified by r^{id}, and substitution(ri) denotes σ.
Similarly, an instance of a rule set RS is a set of rule instances ri_{i}, where ∀ i, rule(ri_{i}) ∈ RS. Given a rule set RS, Inst(RS) denotes the set of all the possible instances of RS.
A RIFPRD production rule system is defined as a labelled terminal transition system: given a rule set RS ⊆ R, let C_{RS} ⊆ P(W) × S(Inst(RS)) be a set of states, where a state is a pair c = (w, ri_{c}), such that w ⊆ W is a set of facts, and ri_{c} ∈ S(Inst(RS)) is an ordered instance of RS. Given a state c = (w, ri_{c}), let facts(c) denote the first element, the set of facts w; and let picked(c) denote the second element, the ordered ruleset instance, ri_{c}.
The idea is that a state, c, is made of a set, w, of ground FORMULAe that represent a state of facts; and of the ordered list, ri_{c}, of all the instances of the rules in the considered ruleset RS that are fired, in some sense to be further specified, in that state of facts.
Further, let H_{RS} ⊆ S(C_{RS}) be a set of histories, where a history, h, is an ordered list of states c_{i}: h = (c_{n}...c_{1}), n≥ 0. Given a history, h ∈ H_{RS}, current(h) will be used to denote the first element of h and history(h) will be used to denote h minus current(h): if h = (c_{n}...c_{1}), n≥ 1, current(h) denotes c_{n} and history(h) denotes the ordered list (c_{n1}...c_{1}), n≥ 1. If h = () is the empty list, current(h) = history(h) = ∅.
The idea is that a history, h, represents the stack of the states that have been successively traversed by a production rule system, in the current run, from its initial state to the current state: current(h) represents the current state of the system; history(h) represents its history, that is, the states of facts that held and the instances that were fired in the previous cycles, ordered from most recent to initial.
Let further assume three functions:
Let extractActions: S(Inst(R)) → S(L), be a helper function that, given an ordered set, ori, of rule instances, returns the sequence of ACTIONs that is the concatenation, preserving the order in ori, of the sequences of ground actions determined by each of the rule instances in ori.
Editor's Note: extractActions is underdefined. Need be fixed at some point.
Given a ruleset RS and the associated conflict resolution strategy LS, a RIFPRD production rule system is defined as a labelled terminal transition system PRS_{RS,LS} = {H_{RS}, S(L), →_{RS,LS}, T_{RS,LS}}, where :
Intuitively, the first condition in the definition of the transition relation →_{RS,LS} says that a RIFPRD production rule system can transition from one history to another only if the implementation of the actions picked in the current state of the former history produce the state of facts in the current state of the latter, according to the semantics of the individual actions, as specified in the relation →_{RIFPRD}. Condition 2 guarantees that only the selection strategy and the specification of the function PICK determine which are the allowed transition paths out of a given state. And condition 3 guarantees that the system halts as soon as it encounters a terminal state.
The input function is defined as:Or, using →^{*}_{RS,LS} to denote the transitive closure of the transition relation:
Given the specification of PRS_{RS,LS}, the intended operational semantics of a production ruleset represented by a RIFPRD Group RS is completely specified by the specification of the three functions INSTANTIATE, PICK and FINAL.
The evaluation of the function INSTANTIATE corresponds to the step that is often called matching in the description of production rule systems (e.g. PRR07). Given a collection of rules, it considers all possible ground rule instances, obtained by assigning ground terms to the variables occuring in them. Its semantics is defined, in accordance with the semantics of the RIFPRD condition language.
Let ExtractCONDITIONS: R → LC be a function that, given a rule, r ∈ R, returns a wellformed condition formula defined recursively as follows:
Let InstantiateRULE: P(W) × R → P(Inst(R)), be a function that, given a set of facts w ∈ W and a rule r ∈ R, returns the set, ir ⊆ Inst(R), of all the instances of r that are satisfied in w, where a rule instance ri = (r^{id}, σ) satisfies a set of fact w if and only if σ matches ExtractCONDITIONS(rule(r^{id})) to w.
The evaluation of the function INSTANTIATE(w, RS), where w ⊆ W and RS ⊆ R, can now be specified as a simple terminal transition system where:
The input function is defined as:
The output function is defined as:
Example 3.4. TBD
A rule instance determines a sequences of ground actions, by application of the associated substitution to the variables in the ACTIONs in the then component of the instantiated rule. The decision to implement the sequence of actions that a rule instance determines is often called: firing the rule instance.
More than one rule from a rule set may be instantiated in a given state of facts, and, for a given rule, there may be several different instances. The set of all the rule instances that are satisfied in a given state is often called: the conflict set; and the process of selecting one or more rule instances from the conflict set for firing is often called: conflict resolution.
In RIFPRD the conflict resolution algorithm (or conflict resolution strategy) that is intended for a set of rules is denoted by a keyword or a set of keywords that is attached to the rule set. In this version of the RIFPRD specification, a single conflict resolution strategy is specified normatively: it is denoted by the RIFPRD keyword rif:standardForward, for it accounts for a common conflict resolution strategy used in most forwardchaining production rule systems.
Editor's Note: Name of the standard CR strategy to be discussed and agreed upon... standardForward used here as a placeholder.
Future versions of the RIFPRD specification may specify normatively the intended conflict resolution strategies to be attached to additional keywords. In addition, RIFPRD documents may include nonstandard keywords: it is the responsability of the producers and consumers of such document to agree on the intended conflict resolution strategies that are denoted by such nonstandard keywords.
Most existing production rule systems implement conflict resolution algorithms that are a combination of the following elements (under these or other, idiosyncratic names; and possibly combined with additional, idiosyncratic rules):
The RIFPRD keyword rif:standardForward denotes the common conflict resolution strategy that can be summarized as follows: given a conflict set, as returned by the function INSTANTIATE
Accordingly, given a state of fact, w ∈ W, a history, h ∈ H_{RS}, and a rule set RS, the function PICK(w, h, RS, rif:standardForward) returns a list that contain a single rule instance, selected from the conflict set generated by INTANTIATE(w, RS) as specified below.
As specified earlier, picked(c) denotes the ordered list of the rule instances that were picked in state c. Under the conflict resolution strategy denoted by rif:standardForward, the list denoted by picked(c) contains a single rule instance, for any given state, c.
For the purpose of this specification, an extended test, ∈_{inst}, is specified for the membership of a rule instance in a set of rule instances: given a rule instance, ri ∈ Inst(RS), and a set of rule instance, RI ⊆ Inst(RS), ri ∈_{inst} RI if and only if there is a rule instance, ri' ∈ RI such that rule(ri) = rule(ri') and, for each variable ?v ∈ Var(rule(ri)), σ(?v) = σ'(?v), where σ = substitution(ri) and σ' = substitution(ri').
Furthermore, let recency: Inst(RS) × H_{RS} → N, where N denotes the set of the positive integers, be an integer function that, given a rule instance, ri, and a history, h, returns the number of states in h, starting from the first one, in which ri is continuously satisfied: if h is the history of the current state, recency(ri, h) provides a measure of the recency of the rule instance ri. The function is specified recursively as follows: for all rule instances ri ∈ Inst(RS), and forall history h ∈ H_{RS},
And let lastPicked: Inst(RS) × H_{RS} → N, where N denotes the set of the positive integers, be an integer function that, given a rule instance, ri, and a history, h, returns the number of states in h, starting from the first one, since ri has been last fired. The function is specified recursively as follows: for all rule instances ri ∈ Inst(RS), and forall history h ∈ H_{RS},
Finally, given a rule instance, ri ∈ Inst(RS), let priority(ri) denote the priority that is associated to rule(ri) in RS, or zero, if no priority is associated to rule(ri) in RS. If rule(ri) is inside nested Groups in RS, priority(ri) denotes the priority that is associated with the innermost Group to which a priority is explicitely associated, or zero.
Given a state of facts, w ∈ W, a history, h ∈ H_{RS}, and a rule set, RS, PICK(w, h, RS, rif:standardForward ) can now be defined with the help of a terminal transition system {A, →_{sF}, T_{sF}}, where:
where keepOneFrom breaks any remaining tie by removing arbirarily all the elements but one from its argument list.
Editor's Note: This section is still under discussion (see ISSUE65). This version specifies a single, default halting test: future version of this draft may specify additional halting tests, and/or a different default. The Working Group seeks feedback on which halting tests and which combinations of tests should be supported by RIFPRD and/or required from RIFPRD implementations; and which halting test should be the default, if any.
By default, the specification for a terminal state that is intended for a set of production rules, when no halting test is explicitely associated to its representation as a RIFPRD Ruleset, is when no rule instance is fireable: this is the case when INSTANTIATE returns an empty set of rule instances, or when all the rule instances that are satisfied in the state, according to the semantics of INSTANTIATE, have already been fired in a state that has not since changed significantly. That latter condition guarantees, in particular, that the system halts when it reaches a fixpoint.
Formally, ∀ RS ⊆ R, ∀ c ∈ C_{RS}, PICK(c, RS) = true if and only if instance(c)  history(c) = ∅. Otherwise, PICK(c, RS) = false.
This section specifies a common concrete XML syntax to serialize any production rule set written in a language that share the abstract syntax speicifed in section 4.1, provided that its intended semantics agrees with the semantics that is described in section 4.2.
In the following, after the notational conventions are introduced, we specify the RIFPRD XML constructs that carry a normative semantics with respect to the intended interpretation of the interchanged rules. They are specified with respect to the abstract syntax, and their specification is structured according to the specification of the abstract syntax in sections 2.1, 3.1 and 4.1.
The root element of any RIF XML document, Document and other XML constructs that do not carry a normative semantics with respect to the intended interpretation of the interchanged rules are specified in the last subsection.
Throughout this document, the xsd: prefix stands for the XML Schema namespace URI http://www.w3.org/2001/XMLSchema#, the rdf: prefix stands for http://www.w3.org/1999/02/22rdfsyntaxns#, and rif: stands for the URI of the RIF namespace, http://www.w3.org/2007/rif#.
Syntax such as xsd:string should be understood as a compact URI (CURIE)  a macro that expands to a concatenation of the character sequence denoted by the prefix xsd and the string string. The compact URI notation is used for brevity only, and xsd:string should be understood, in this document, as an abbreviation for http://www.w3.org/2001/XMLSchema#string.
The XML syntax of RIFPRD is specified for each component as a pseudoschema, as part of the description of the component. The pseudoschemas use BNFstyle conventions for attributes and elements: "?" denotes optionality (i.e. zero or one occurrences), "*" denotes zero or more occurrences, "+" one or more occurrences, "[" and "]" are used to form groups, and "" represents choice. Attributes are conventionally assigned a value which corresponds to their type, as defined in the normative schema. Elements are conventionally assigned a value which is the name of the syntactic class of their content, as defined in the normative schema.
<! sample pseudoschema > <defined_element required_attribute_of_type_string="xs:string" optional_attribute_of_type_int="xs:int"? > <required_element /> <optional_element />? <one_or_more_of_these_elements />+ [ <choice_1 />  <choice_2 /> ]* </defined_element>
Three kinds of syntactic components are used to specify RIFPRD:
This section specifies the XML constructs that are used in RIFPRD to serialize condition formulae.
The TERM class of constructs is used to serialize terms, be they simple terms, that is, constants and variables; or positional terms or terms with named arguments, both being, per the definition of a wellformed formula, representations of externally defined functions.
As an abstract class, TERM is not associated with specific XML markup in RIFPRD instance documents.
[ Const  Var  External ]
In RIF, the Const element is used to serialize a constant.
The Const element has a required type attribute and an optional xml:lang attribute:
The content of the Const element is the constant's litteral, which can be any Unicode character string.
<Const type=xsd:anyURI [xml:lang=xsd:language]? > Any Unicode string </Const>
\{\{EdNotetext=The case of nonstandard data types, that is, of constants that do not belong or cannot be cast in one of RIF builtin types for interchange purposes, is still under discussion in the WG. The WG seeks feedback on whether they should be allowed and why.\}\}
Example 2.1. In each of the examples below, a constant is first described, followed by its serialization in RIFPRD XML syntax.
a. A constant with builtin type xsd:integer and value 123:
<Const type="xsd:integer">123</Const>
b. A constant which symbol today is defined in Joe the Hen Public's namespace http://rif.examples.com/2008/joe#. The type of the constant is rif:iri:
<Const type="rif:iri"> http://rif.examples.com/2008/joe#today </Const>
c. A constant with symbol BigPotato that is local to the set of rules where it appears (e.g. a RuleSet specific to Paula's farm). The type of the constant is rif:local:
<Const type="rif:local">BigPotato</Const>
d. A constant with nonbuiltin type xsd:int and value 123:
<Const type="xsd:int">123</Const>
In RIF, the Var element is used to serialize a variable.
The content of the Var element is the variable's name, serialized as an Unicode character string.
<Var> any Unicode string </Var>
Example 2.2. The example below shows the XML serialization of a reference to a variable named: ?chicken.
<Var> chicken <Var>
As a TERM, the External element is used to serialize a positional term or a term with named arguments. In RIFPRD, a positional or a namedargument term represents always a call to an externally specified function, e.g. a builtin, a userdefined function, a query to an external data source...
The External element contains one content element, which in turn contains one Expr element that contains one op element, followed zero or one args element or zero of more slot elements:
<External> <content> <Expr> <op> Const </op> [ <args rif:ordered="yes"> TERM* </args>?  <slot rif:ordered="yes"> <Name> Any Unicode string </Name> TERM <slot>* ] </Expr> </content> </External>
Editor's Note: The slotted, or named arguments form of the External TERM construct is still under discussion (see also ISSUE68). The working group seeks feedback on whether or not it should be included in PRD.
Example 2.3.
a. The first example below shows one way to serialize, in RIFPRD, the sum of integer 1 and a variable ?x, where the addition conforms to the specification of the builtin fn:numericadd.
The prefix fn is associated with the namespace http://www.w3.org/2007/rifbuiltinfunction#.
<External> <content> <Expr> <op> <Const type="rif:iri"> fn:numericadd </Const> </op> <args rif:ordered="yes"> <Const type="xsd:integer"> 1 </Const> <Var> x </Var> </args> </Expr> </content> </External>
b. Another example, that shows the RIF XML serialization of a call to the applicationspecific nullary function today(), which symbol is defined in the example's namespace http://rif.examples.com/2008/joe#:
<External> <content> <Expr> <op> <Const type="rif:iri"> http://rif.examples.com/2008/joe#today </Const> </op> </Expr> </content> </External>
The ATOMIC class is used to serialize atomics: positional and namedarguments atoms, equality, membership and subclass atomics, frame atomics and externally defined atomics..
As an abstract class, ATOMIC is not associated with specific XML markup in RIFPRD instance documents.
[ Atom  Equal  Member  Subclass  Frame  External ]
In RIF, the Atom element is used to serialize a positional atomics or an atomic with named arguments.
The Atom element contains one op element, followed by zero or one args element or zero or more slot arguments:
<Atom> <op> Const </op> [ <args rif:ordered="yes"> TERM* </args>?  <slot rif:ordered="yes"> <Name> Any Unicode string </Name> TERM <slot>* ] </Atom>
Editor's Note: The slotted, or named arguments form of the Atom construct is still under discussion (see also ISSUE68). The working group seeks feedback on whether or not it should be included in PRD.
Example 2.4. The example below shows the RIF XML serialization of the positional atomicsowns(?c ?p), where the predicate symbol owns is defined in the example namespace http://rif.examples.com/2008/joe#.
<Atom> <op> <Const type="rif:iri"> http://rif.examples.com/2008/joe#owns </Const> </op> <args rif:ordered="yes"> <Var> c </Var> <Var> p </Var> </args> </Atom>
In RIF, the Equal element is used to serialize equality atomics.
The Equal element must contain one left subelement and one right subelement. The content of the left and right elements must be a construct from the TERM abstract class. The order of the subelements is not significant.
<Equal> <left> TERM </left> <right> TERM </right> </Equal>
In RIF, the Member element is used to serialize membership atomics.
The Member element contains two unordered subelements:
<Member> <instance> TERM </instance> <class> TERM </class> </Member>
Example 2.5. The example below shows the RIF XML serialization of a boolean expression that tests whether the individual denoted by the variable ?c is a member of the class Chicken that is defined in the example namespace http://rif.examples.com/2008/joe#.
<Member> <instance> <Var> c </Var> </instance> <class> <Const type="rif:iri"> http://rif.examples.com/2008/joe#Chicken </Const> </class> </Member>
In RIF, the Subclass element is used to serialize subclass atomics.
The Subclass element contains two unordered subelements:
<Subclass> <sub> TERM </sub> <super> TERM </super> </Subclass>
In RIF, the Frame element is used to serialize frame atomics.
Accordingly, a Frame element must contain:
<Frame> <object> TERM </object> <slot rif:ordered="yes"> TERM TERM </slot>* </Frame>
Example 2.6. The example below shows the RIF XML syntax that serializes an expression that states that the object denoted by the variable ?c has the value denoted by the variable ?a for the property Chicken/age that is defined in the example namespace http://rif.examples.com/2008/joe#.
<Frame> <object> <Var> c </Var> </object> <slot rif:ordered="yes"> <Const type="rif:iri"> ttp://rif.examples.com/2008/joe#Chicken/age </Const> <Var> a </Var> </slot> </Frame>
Editor's Note: The example uses an XPath style for the key. How externally specified data models and their elements should be referenced is still under discussion (see ISSUE37).
In RIFPRD, the External element is also used to serialize an externally defined atomic.
When it is a ATOMIC (as opposed to a TERM; that is, in particular, when it appears in a place where an ATOMIC is expected, and not a TERM), the External element contains one content element that contains one Atom element. The Atom element serializes the externally defined atom properly said:
<External> <content> Atom </content> </External>
The op Const in the Atom element must be a symbol of type rif:iri that must uniquely identify the externally defined predicate to be applied to the args TERMs. It can be one of the builtin predicates specified for RIF dialects, as listed in section List of RIF Builtin Predicates and Functions of the RIF data types and builtins document, or it can be application specific. In the latter case, it is up to the producers and consumers of RIFPRD rulesets that reference nonbuiltin predicates to agree on their semantics.
Example 2.7. The example below shows the RIF XML serialization of an externally defined atomic that tests whether the value denoted by the variable named ?a (e.g. the age of a chicken) is greater than the integer value 8, where the test is intended to behave like the builtin predicate op:numericgreaterthan as specified in XQuery 1.0 and XPath 2.0 Functions and Operators.
In the example, the prefix op: is associated with the namespace http://www.w3.org/2007/rifbuiltinpredicate#.
<External> <content> <Atom> <op> <Const type="rif:iri"> op:numericgreaterthan </Const> </op> <args rif:ordered="yes"> <Var> ?a </Var> <Const type="xsd:decimal"> 8 </Const> </args> </Atom> </content> </External>
The FORMULA class is used to serialize condition formulas, that is, atomic formulas, conjunctions, disjunctions, negations and existentials.
As an abstract class, FORMULA is not associated with specific XML markup in RIFPRD instance documents.
[ ATOMIC  And  Or  NmNot  Exists ]
An atomic formula is serialized using a single ATOMIC statement. See specification of ATOMIC, above.
A conjunction is serialized using the And element.
The And element contains zero or more formula subelements, each containing an element of the FORMULA group.
<And> <formula> FORMULA </formula>* </And>
A disjunction is serialized using the Or element.
The Or element contains zero or more formula subelements, each containing an element of the FORMULA group.
<Or> <formula> FORMULA </formula>* </Or>
A negation is serialized using the NmNot element.
The NnNot element contains exactly one formula subelement. The formula element contains an element of the FORMULA group, that serializes the negated statement.
<NmNot> <formula> FORMULA </formula> </NmNot>
Editor's Note: The name of that construct may change, including the tag of the XML element.
An existentially quantified formula is serialized using the Exists element.
The Exists element contains:
<Exists> <declare> Var </declare>+ <formula> FORMULA </formula> </Exists>
Example 2.8. The example below shows the RIF XML serialization of a boolean expression that tests whether the chicken denoted by variable ?c is older than 8 months, by testing the existence of a value, denoted by variable ?a, that is both the age of ?c, as serialized as a Frame element, as in example 2.6, and greater than 8, as serialized as an External ATOMIC, as in example 2.7.
<Exists> <declare> <Var> a </Var> </declare> <formula> <And> <Frame> <object> <Var> c </Var> </object> <slot rif:ordered="yes"> <Const type="rif:iri"> http://rif.examples.com/2008/joe#Chicken/age </Const> <Var> a </Var> </slot> </Frame> <External> <content> <Atom> <op> <Const type="rif:iri"> op:numericgreaterthan </Const> </op> <args rif:ordered="yes"> <Var> a </Var> <Const type="xsd:decimal"> 8 </Const> </args> </Atom> </content> </External> </And> </formula> </Exists>
This section specifies the XML syntax that is used to serialize the action part of a rule supported by RIFPRD.
The ACTION class of constructs is used to represent the actions in the action part of a production rule.
As an abstract class, ACTION is not associated with specific XML markup in RIFPRD instance documents.
[ ATOMIC_CONCLUSION  ATOMIC_ACTION  ACTION_BLOCK  CONCLUSION_BLOCK ]
The ATOMIC_CONCLUSION class of constructs is used to represent the targets of the Assert construct and is also used for compatibility with RIFCore.
[ Atom  Frame  Member  Subclass ]
The ATOMIC_ACTION class of constructs is used to represent the primitive actions assert and retract.
[ Assert  Retract ]
An Assert construct is used to represent actions that result in asserting an ATOMIC_CONCLUSION.
<Assert> <target> ATOMIC_CONCLUSION </target> </Assert>
The Retract construct is used to represent actions that result in removing facts from working memory.
An Atom, a Frame, or a frame object may be retracted. A frame object is denoted using a TERM. A frame object is retracted by removing it from the Member relation and removing all its Frames.
The Retract element has one target subelement that contains an Atom, a Frame, or a TERM construct that represents the facts to be removed on implementing the action.
<Retract> <target> [ Atom  Frame  TERM ] </target> </Retract>
Example 2.10. The example below shows the RIF XML representation of an action that updates the chickenpotato ownership table by removing the predicate that states that the chicken denoted by variable ?c owns the potato denoted by variable ?p. The predicate is represented as in example 2.4.
<Retract> <target> <Atom> <op> <Const type="rif:iri"> http://rif.examples.com/2008/joe#owns </Const> </op> <args rif:ordered="yes"> <Var> c </Var> <Var> p </Var> </args> </Atom> </target> </Retract>
An ACTION_BLOCK construct is used to represent optional local variables and their bindings plus several ATOMIC_ACTIONs.
<Do rif:ordered="yes"> <declare> Var </declare>* <binding> [ New  Frame ] </binding>* <action> ATOMIC_ACTION </action>+ </Do>
The New construct is used to create a new frame object.
The New element has an instance subelement that contains a Var. A new object is created and bound to the instance variable.
<New> <instance> Var </instance>? </New>
Example
2.9. The example below shows the RIF XML representation of an
action block that asserts a new 100 decigram potato.
<Do rif:ordered="yes"> <declare><Var>p</Var></declare> <binding> <New> <instance><Var>p</Var></instance> </New> </binding> <action> <Assert> <target> <Member> <instance><Var>p</Var></instance> <class> <Const type="rif:iri">http://rif.examples.com/2008/joe#Potato</Const> </class> </Member> </target> </Assert> </action> <action> <Assert> <target> <Frame> <object><Var>p</Var></object> <slot rif:ordered="yes"> <Const type="rif:iri">http://rif.examples.com/2008/joe#weight</Const> <Const type="xsd:decimal">100</Const> </slot> </Frame> </target> </Assert> </action> </Do>
A CONCLUSION_BLOCK construct is used to represent several ATOMIC_CONCLUSIONs in a way that is compatible with RIFCore.
<And> <formula> ATOMIC_CONCLUSION </formula>+ </And>
This section specifies the XML constructs that are used, in RIRPRD, to serialize rules and groups.
In RIFPRD, the RULE class of constructs is used to serialize rules, that is, unconditional as well as conditional actions, or rules with bound variables.
As an abstract class, RULE is not associated with specific XML markup in RIFPRD instance documents.
[ Implies  Forall  ACTION ]
An unconditional action block is serialized, in RIFPRD XML, using the ACTION class of construct.
Editor's Note: To be updated based according ot the uptodate version of the XML syntax for actions.
Conditional actions are serialized, in RIFPRD, using the XML element Implies.
The Implies element contains an optional if subelement and a then subelement:
Editor's Note: To be updated based according ot the uptodate version of the XML syntax for actions.
<Implies> <if> FORMULA </if>? <then rif:ordered="yes"> ACTION ACTION* </then> </Implies>
The Forall construct is used, in RIFPRD, to represent rules with bound variables.
The Forall element contains:
<Forall> <declare> Var </declare>+ <pattern> FORMULA </pattern>* <formula> RULE </formula> </Forall>
Editor's Note: Nested Foralls make explicit the scope of the declared variables, and, thus, impose an order on the evaluation of the pattern and if FORMULAe in a rule. That ordering and the use of patterns to constrain the binding of variables may be of practical significance for some production rule systems, but they are irrelevant with respect to the intended semantics of the rules being interchanged (although they would be relevant if RIFPRD was to be extended to support some kind of "else" or "case" construct). In addition, RIFBLD does not allow nested Forall and does not support the association of contraining patterns to declared variables. The working group seeks feedback regarding whether nested Forall and constrainting pattern should be supported in RIFPRD, to the cost of reducing the interoperability with RIFBLD.
Example 2.10. The example below shows how the CMP rule extract: "if a chicken owns a potato and ..." could be serialized using a binding pattern FORMULA:
<Forall> <declare><Var>chicken</Var></declare> <formula> <Forall> <declare><Var>potato</Var></declare> <pattern> <External> <content> <Atom> <Const type="rif:iri"> http://rif.examples.com/2008/joe#owns </Const> <Args rif:ordered="yes"> <Var>chicken</Var> <Var>potato</Var> </Args> </Atom> </content> </External> </pattern> <formula> ... </formula> </Forall> </formula> </Forall>
The Group construct is used to serialize a group.
The Group element has zero or one behavior subelement and zero or more sentence subelements:
<Group> <behavior> <ConflictResolution> xsd:anyURI </ConflictResolution>? <Priority> 10,000 ≤ xsd:int ≤ 10,000 </Priority>? </behavior>? <sentence> [ RULE  Group ] </sentence>* </Group>
The Document is the root element in a RIFPRD instance document.
The Document contains zero or one payload subelement, that must contain a Group element.
<Document> <payload> Group </payload>? </Document>
Metadata can be associated with any concrete class element in RIFPRD: those are the elements with a CamelCase tagname starting with an uppercase character:
CLASSELT = [ TERM  ATOMIC  FORMULA  ACTION  RULE  Group  Document ]
An identifier can be associated to any instance element of the abstract CLASSELT class of constructs, as an optional id subelement that MUST contain a Const of type rif:local or rif:iri.
Metadata can be included in any instance of a concrete class element using the meta subelement.
The RIFPRD Frame construct is used to serialize metadata: the content of the Frame's object subelement identifies the object to which the metadata is associated:, and the Frame's slots represent the metadata properly said as propertyvalue pairs.
If the all the metadata is related to the same object, the meta element can contain a single Frame subelement. If metadata related to several different objects need be serialized, the meta role element can contain an And element with zero or more formula subelements, each containing one Frame element.
<CLASSELT> <id> Const </id>? <meta> [ Frame  <And> <formula> Frame </formula>* </And> ] </meta>? other CLASSELT content </CLASSELT>
Notice that the content of the meta subelement of an instance of a RIFPRD class element is not necessarily associated to that same instance element: only the content of the object subelement of the Frame that represents the metadata specifies what the metadata is about, not where it is included in the instance RIF document.
It is suggested to use Dublin Core, RDFS, and OWL properties for metadata, along the lines of http://www.w3.org/TR/owlref/#Annotations  specifically owl:versionInfo, rdfs:label, rdfs:comment, rdfs:seeAlso, rdfs:isDefinedBy, dc:creator, dc:description, dc:date, and foaf:maker.
Example 2.11. TBC
This section specifies a presentation syntax for RIFPRD. The presentation syntax is not normative: its main purpose is to help make the normative specification of the semantics easier to read.
The presentation syntax is designed to be very close to RIFBLD. A line by line comparison of the EBNF will show these few differences:
It is intended that the syntax and semantics of RIFBLD and RIFPRD are the same when the rule conclusion contains a only Atoms and Frames, "Not" is not used, and logical functions are not used.
The following EBNF is from RIFBLD, with lines prefixed with ! indicating a change for RIFPRD:
FORMULA ::= 'And' '(' FORMULA* ')'  'Or' '(' FORMULA* ')'  'Exists' Var+ '(' FORMULA ')'  ATOMIC  'External' '(' Atom  Frame ')'  ! 'Not' '(' FORMULA ')' ATOMIC ::= Atom  Equal  Member  Subclass  Frame Atom ::= UNITERM UNITERM ::= Const '(' (TERM* < (Name '>' TERM)*) ')' Equal ::= TERM ' = ' TERM Member ::= TERM '#' TERM Subclass ::= TERM '##' TERM Frame ::= TERM '[' (TERM '>' TERM)* ']' ! TERM ::= Const  Var  'External' '(' Expr ')' Expr ::= UNITERM Var ::= '?' UNICODESTRING
The following EBNF is taken from RIFDTB and is unchanged for PRD. Its purpose is to provide shortcuts for constants.
ANGLEBRACKIRI ::= '<' IRI_REF '>' STRING ::= '"' UNICODESTRING '"' CURIE ::= PNAME_LN  PNAME_NS → see RIFDTB Const ::= STRING '^^'ANGLEBRACKIRI  STRING '^^' CURIE  ANGLEBRACKIRI → shortcut for rif:iri  CURIE → shortcut for rif:iri  STRING → shortcut for xsd:string  NumericLiteral → shortcut for xsd:integer,xsd:decimal,xsd:double  '_' LocalName → shortcut for rif:local
The following EBNF is from RIFBLD and defines rules, groups of rules, and the containing document. Changed lines are prefixed with !. Metadata can be associated with Document, Group, and RULE constructs.
! Document ::= IRIMETA? 'Document' '(' Group? ')' Group ::= IRIMETA? 'Group' '(' (RULE  Group)* ')' ! RULE ::= (IRIMETA? 'Forall' Var+ '(' Implies ')')  Implies  INITIAL_FACT ! INITIAL_FACT ::= ASSERT  Member ! Implies ::= IRIMETA? ACTION ':' FORMULA IRIMETA ::= '(*' Const? (Frame  'And' '(' Frame* ')')? '*)' IRI ::= UNICODESTRING Profile ::= UNICODESTRING
Finally, the following EBNF describes the syntax of PRD actions.
ACTION ::= ATOMIC_CONCLUSION  ATOMIC_ACTION  ACTION_BLOCK  CONCLUSION_BLOCK ATOMIC_CONCLUSION ::= Atom  Frame  Member  Subclass ATOMIC_ACTION ::= Assert  Retract Assert ::= 'Assert' '(' ATOMIC_CONCLUSION ')' Retract ::= 'Retract' '(' Atom  Frame  TERM ')' ACTION_BLOCK ::= 'Do' Var* '(' ( ACTION_VAR_BINDING+ ';' )? ATOMIC_ACTION+ ')' ACTION_VAR_BINDING ::= New  Frame New ::= 'New' '(' Var ')' CONCLUSION_BLOCK ::= 'And' '(' ATOMIC_CONCLUSION ATOMIC_CONCLUSION+ ')'
TBD
RIFPRD and RIFBLD share essentially the same presentation syntax and XML syntax.
The syntactic differences between the two dialects are summarized below:
Below is a complete, construct by construct, comparison table of RIFPRD and RIFBLD presentation and XML syntaxes. A construct is tagged "BLD" or "PRD" if it is specific to the dialect, or tagged "Core" if it is common to both.
Editor's Note: RIFCore will be equal to or included in the intersection of RIFPRD and RIFBLD. The exact scope of RIFCore is still under discussion. Until RIFCore is specified more precisely, this document assumes that it will be equal to the intersection of RIFPRD and RIFBLD.
Presentation syntax  XML syntax  

TERM ::=  
BLD 
[Const  Var  Expr  External] 

PRD 
[Const  Var  External] 

Const ::=  
Core 
'"' UNICODESTRING '"^^' SYMSPACE 
<Const type=xsd:anyURI [xml:lang=xsd:language]? > Any Unicode string </Const> 
Var ::=  
Core 
'?' Any Unicode string 
<Var> Any Unicode string </Var> 
Expr ::=  
BLD 
Const '(' (TERM*  (Name '>' TERM)*) ')' 
<Expr> <op> Const </op> [ <args rif:ordered="yes"> TERM* </args>?  <slot rif:ordered="yes"> <Name> Any Unicode string </Name> TERM </slot>* ] </Expr> 
PRD 
Undefined except when wrapped in an External (as TERM), as follows. 

External (as TERM) ::=  
Core 
'External' '(' Expr ')' 
<External> <content> Expr </content> </External> 
ATOMIC ::=  
Core 
[Atom  Equal  Member  Subclass  Frame] 

Atom ::=  
Core 
Const '(' (TERM*  (Name '>' TERM)*) ')' 
<Atom> <op> Const </op> [ <args rif:ordered="yes"> TERM* </args>?  <slot rif:ordered="yes"> <Name> Any Unicode string </Name> TERM </slot>* ] </Atom> 
Equal ::=  
Core 
TERM = TERM 
<Equal> <left> TERM </left> <right> TERM </right> </Equal> 
Member ::=  
Core 
TERM # TERM 
<Member> <instance> TERM </instance> <class> TERM </class> </Member> 
Subclass ::=  
Core 
TERM ## TERM 
<Subclass> <sub> TERM </sub> <super> TERM </super> </Subclass> 
Frame ::=  
Core 
TERM ' [ ' (TERM ' > ' TERM)* ' ] ' 
<Frame> <object> TERM </object> <slot rif:ordered="yes"> TERM TERM </slot>* </Frame> 
FORMULA ::=  
BLD 
[ATOMIC  External  And  Or  Exists] 

PRD 
[ATOMIC  External  And  Or  NmNot  Exists] 

External (as FORMULA) ::=  
Core 
'External '(' [Atom  Frame] ')' 
<External> <content> [ Atom  Frame ] </content> </External> 
And ::=  
Core 
'And' '(' FORMULA* ')' 
<And> <formula> FORMULA </formula>* </And> 
Or ::=  
Core 
'Or' '(' FORMULA* ')' 
<Or> <formula> FORMULA </formula>* </Or> 
NmNot ::=  
BLD 
Undefined 

PRD 
'Not' '(' FORMULA ')' 
<NmNot> <formula> FORMULA </formula> </NmNot> 
Exists ::=  
Core 
'Exists' Var+ '(' FORMULA ')' 
<Exists> <declare> Var </declare>+ <formula> FORMULA </formula> </Exists> 
ACTION ::=  
BLD 
Undefined 

PRD 
[ ASSERT  Retract ] 

ASSERT ::=  
BLD 
Undefined 

PRD 
[ Atom  Frame ] 

Retract ::=  
BLD 
Undefined 

PRD 
'Retract' '(' Atom  Frame ' ) ' 
<Retract> <target> [ Atom  Frame ] </target> </Retract> 
RULE ::=  
BLD 
[ Forall  Implies  ATOMIC ] 

PRD 
[ Forall  Implies  ACTION ] 

Forall ::=  
BLD 
' Forall ' Var+ ' ( ' [Implies  ATOMIC] ' ) ' 
<Forall> <declare> Var </declare>+ <formula> [Implies  ATOMIC ] </formula> </Forall> 
PRD 
' Forall ' Var+ (' ( ' FORMULA ' ) ')* ' ( ' RULE ' ) ' 
<Forall> <declare> Var </declare>+ <pattern> FORMULA </pattern>* <formula> RULE </formula> </Forall> 
Implies ::=  
BLD 
(ATOMIC  'And' '(' ATOMIC* ')') ':' FORMULA 
<Implies> <if> FORMULA </if> <then> [ ATOMIC  <And> <formula> ATOMIC </formula>* </And> ] </then> </Implies> 
PRD 
(ACTION  'Do' '(' ACTION* ')') ':' FORMULA 
<Implies> <if> FORMULA </if> <then> ACTION ACTION* </then> </Implies> 
Group ::=  
Core 
METADATA? 'Group' '(' ([RULE  Group])* ')' 
<Group> <sentence> [ RULE  Group ] </sentence>* </Group> 
Import ::=  
BLD 
'Import' '(' IRI Profile? ')' 
<Import> <location>lAny Unicode string</location> <profile><Profile>Any Unicode String_{1}</Profile></profile> </Import> 
PRD 
Undefined in this version of the draft 

Document ::=  
BLD 
METADATA? 'Document' '(' [Import  Prefix  Base]* Group? ')' 
<Document> <directive> [ Import  Prefix  Base]* </directive> <payload> Group </payload>? </Document> 
PRD 
METADATA? 'Document' '(' Group? ')' 
<Document> <payload> Group </payload>? </Document> 
METADATA ::=  
Core 
'(*' Const? (Frame  'And' '(' Frame* ')')? '*)' 
<AnyClassTag> <id> Const </declare>? <meta> [ Frame  <And> <formula> Frame </formula> </And> ] </meta>? other content of AnyClassTag </AnyClassTag> 
The intended semantics of any RIF XML document which is both a syntactically valid RIFPRD document and a syntactically valid RIFBLD document is the same whether it is considered a RIFPRD or a RIFBLD document. For any input set of facts, the set of rules contained in the document must produce the same output set of facts whether it is consumed as a RIFPRD or a RIFBLD document.
Proof. TBC