Movatterモバイル変換

RIF Production Rule Dialect (Second Edition)

W3C Recommendation 5 February 2013

This version:

http://www.w3.org/TR/2013/REC-rif-prd-20130205/

Latest version:

http://www.w3.org/TR/rif-prd/

Previous version:

http://www.w3.org/TR/2012/PER-rif-prd-20121211/

Editors:

Christian de Sainte Marie, IBM/ILOG

Gary Hallmark, Oracle

Adrian Paschke, Freie Universitaet Berlin

Please refer to theerrata for this document, which may include some normative corrections.

Acolor-coded version of this document showing changes made since the previous version is also available.

This document is also available in these non-normative formats:PDF version.

See alsotranslations.

Copyright © 2013W3C^® (MIT,ERCIM,Keio,Beihang), All Rights Reserved. W3Cliability,trademark anddocument use rules apply.

Abstract

Status of this Document

May Be Superseded

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 theW3C technical reports index at http://www.w3.org/TR/.

Set of Documents

This document is being published as one of a set of 13 documents:

1. RIF Overview (Second Edition)
2. RIF Use Cases and Requirements (Second Edition)
3. RIF Core Dialect (Second Edition)
4. RIF Basic Logic Dialect (Second Edition)
5. RIF Production Rule Dialect (Second Edition) (this document)
6. RIF Framework for Logic Dialects (Second Edition)
7. RIF Datatypes and Built-Ins 1.0 (Second Edition)
8. RIF RDF and OWL Compatibility (Second Edition)
9. OWL 2 RL in RIF (Second Edition)
10. RIF Combination with XML data (Second Edition)
11. RIF In RDF (Second Edition)
12. RIF Test Cases (Second Edition)
13. RIF Primer (Second Edition)

Document Unchanged

There have been no changes to the body of this document since theprevious version. For details on earlier changes, see thechange log.

Please Send Comments

Please send any comments topublic-rif-comments@w3.org (public archive). Although work on this document by theRule Interchange Format (RIF) Working Group is complete, comments may be addressed in theerrata or in future revisions. Open discussion among developers is welcome atpublic-rif-dev@w3.org (public archive).

Endorsed By W3C

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

Patents

This document was produced by a group operating under the5 February 2004 W3C Patent Policy. W3C maintains apublic list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent.

1 Overview

This document specifies the production rule dialect of the W3C rule interchange format (RIF-PRD), a standard XML serialization format for production rule languages.

The production rule dialect is one of a set of rule interchange dialects that also includes the RIF Core dialect ([RIF-Core]) and the RIF basic logic dialect ([RIF-BLD]).

RIF-Core, the core dialect of the W3C rule interchange format, is designed to support the interchange of definite Horn rules without function symbols ("Datalog"). RIF-Core has both a standard first-order semantics and an operational semantics. Syntactically, RIF-Core has a number of extensions of Datalog:

• frames as in F-logic [KLW95],
• internationalized resource identifiers (or IRIs, defined by [RFC-3987]) as identifiers for concepts, and
• XML Schema datatypes [XML-SCHEMA2].

RIF-Core is based on a rich set of datatypes and built-ins that are aligned with Web-aware rule system implementations [RIF-DTB]. In addition, the RIF RDF and OWL Compatibility document [RIF-RDF-OWL] specifies the syntax and semantics of combinations of RIF-Core, RDF, and OWL documents.

RIF-Core is intended to be the common core of all RIF dialects, and it has been designed,in particular, to be a useful common subset of RIF-BLD and RIF-PRD. RIF-PRD includes and extends RIF-Core, and, therefore, RIF-PRD inherits all RIF-Core features. These features make RIF-PRD a Web-aware (even a semantic Web-aware) language. However, it should be kept in mind that RIF is designed to enable interoperability among rule languages in general, and its uses are not limited to the Web.

This document targets designers and developers of RIF-PRD implementations. A RIF-PRD implementation is a software application that serializes production rules as RIF-PRD XML (producer application) and/or that deserializes RIF-PRD XML documents into production rules (consumer application).

1.1 Production rule interchange

Production rules have anif part, orcondition, and athen part, oraction. The condition is like the condition part of logic rules (as covered by RIF-Core and its basic logic dialect extension, RIF-BLD). Thethen part contains actions. An action can assert facts, modify facts, retract facts, and have other side-effects. In general, an action is different from the conclusion of a logic rule, which contains only a logical statement. However, the conclusion of rules interchanged using RIF-Core can be interpreted, according to RIF-PRD operational semantics, as actions that assert facts in the knowledge base.

Because RIF-PRD is a production rule interchange format, it specifiesan abstract syntax that shares features with concreteproduction rule languages, and it associates the abstract constructs with normative semantics and a normative XML concrete syntax. Annotations (e.g. rule author) are the only constructs in RIF-PRD without a formal semantics.

The abstract syntax is specified in mathematical English, and the abstract syntactic constructs that are defined in the sectionsAbstract Syntax of Conditions,Abstract Syntax of Actions andAbstract Syntax of Rules and Rulesets, are mapped into the concrete XML constructs in the sectionXML syntax. A lightweight notation is used, instead of the XML syntax, to tie the abstract syntax to the specification of the semantics. A more complete presentation syntax is specified using an EBNF inPresentation Syntax. However, only the XML syntax and the associated semantics are normative. The normative XML schema is included inAppendix: XML Schema.

Prefix(ex <http://example.com/2008/prd1#>)(* ex:rule_1 *)Forall ?customer ?purchasesYTD ( If   And( ?customer#ex:Customer           ?customer[ex:purchasesYTD->?purchasesYTD]           External(pred:numeric-greater-than(?purchasesYTD 5000)) ) Then Do( Modify(?customer[ex:status->"Gold"]) ) )

Production rules are statements of programming logic that specify the execution of one or more actions when their conditions are satisfied. Production rules have an operational semantics, that the OMG Production Rule Representation specification [OMG-PRR] summarizes as follows:

1. Match: the rules are instantiated based on the definition of the rule conditions and the current state of the data source;
2. Conflict resolution: a decision algorithm, often calledthe conflict resolution strategy, is applied to select which rule instance will be executed;
3. Act: the state of the data source is changed, by executing the selected rule instance's actions. If a terminal state has not been reached, the control loops back to the first step (Match).

In the sectionOperational semantics of rules and rule sets, the semantics for rules and rule sets is specified, accordingly, as a labeled terminal transition system (PLO04), where state transitions result from executing the action part of instantiated rules. When several rules are found to be executable at the same time, duringthe rule execution process, aconflict resolution strategy is used toselect the rule to execute. The sectionConflict resolution specifies how a conflict resolution strategy can be attached to a rule set. RIF-PRD defines a default conflict resolution strategy.

In the sectionSemantics of condition formulas, the semantics of the condition part of rules in RIF-PRD is specified operationally, in terms of matching substitutions. To emphasize the overlap between the rule conditions of RIF-BLD and RIF-PRD, and to share the same RIF definitions for datatypes and built-ins [RIF-DTB], an alternative, and equivalent, specification of the semantics of rule conditions in RIF-PRD, using a model theory, is provided in the appendixModel-theoretic semantics of RIF-PRD condition formulas.

The semantics of condition formulas and the semantics of rules and rule sets make no assumption regarding how condition formulas are evaluated. In particular, they do not require that condition formula be evaluated using pattern matching. However, RIF-PRD conformance, as defined in the sectionConformance and interoperability, requires only support forsafe rules, that is, forward-chaining rules where the conditions can be evaluated based on pattern matching only.

In the sectionOperational semantics of actions, the semantics of the action part of rules in RIF-PRD is specified using a transition relation between successive states of the data source, represented by ground condition formulas, thus making the link between the model-theoretic semantics of conditions and the operational semantics of rules and rule sets.

The abstract syntax of RIF-PRD documents, and the semantics of the combination of multiple RIF-PRD documents, is specified in the sectionDocument and imports.

In addition to externally specified functions and predicates, and in particular, in addition to the functions and predicates built-ins defined in [RIF-DTB], RIF-PRD supports externally specified actions, and defines one action built-in, as specified in the sectionBuilt-in functions, predicates and actions.

1.2 Running example

The same example rules will be used throughout the document to illustrate the syntax and the semantics of RIF-PRD.

The rules are about the status of customers at a shop, and the discount awarded to them. The rule set contains four rules, to be applied when a customer checks out:

1. Gold rule:A "Silver" customer with a shopping cart worth at least $2,000 is awarded the "Gold" status.
2. Discount rule:"Silver" and "Gold" customers are awarded a 5% discount on the total worth of their shopping cart.
3. New customer and widget rule:A "New" customer who buys a widget is awarded a 10% discount on the total worth of her shopping cart, but she looses any voucher she may have been awarded.
4. Unknown status rule:A message must be printed, identifying any customer whose status is unknown (that is, neither "New", "Bronze", "Silver" or "Gold"), and the customer must be assigned the status: "New".

TheGold rule must be applied first; that is, e.g., a customer with "Silver" status and a shopping cart worth exactly $2,000 should be promoted to "Gold" status, before being given the 5% discount that would disallow the application of theGold rule (since the total worth of his shopping cart would then be only $1,900).

In the remainder of this document, the prefixex1 stands for the fictitious namespace of this example:http://example.com/2009/prd2#.

2 Conditions

This section specifies the syntax and semantics of the condition language of RIF-PRD.

The RIF-PRD condition language specification depends on Section Constants, Symbol Spaces, and Datatypes, in the RIF data types and builtins specification [RIF-DTB].

2.1 Abstract syntax

The alphabet of the RIF-PRD condition language consists of:

• a countably infinite set ofconstant symbolsConst,
• a countably infinite set ofvariable symbolsVar (disjoint fromConst),
• and syntactic constructs to denote:
  • lists,
  • function calls,
  • relations, including equality, class membership and subclass relations
  • conjunction, disjunction and negation,
  • and existential conditions.

For the sake of readability and simplicity, this specification introduces a notation for these constructs. The notation is not intended to be a concrete syntax, so it leaves out many details. The only concrete syntax for RIF-PRD is the XML syntax.

RIF-PRD supports externally defined functions only (including the built-in functions specified in [RIF-DTB]). RIF-PRD, unlikeRIF-BLD, does not support uninterpreted function symbols (sometimes called logically defined functions).

RIF-PRD supports a form of negation. NeitherRIF-Core norRIF-BLD support negation, because logic rule languages use many different and incompatible kinds of negation. See also the RIF framework for logic dialects [RIF-FLD].

2.1.1 Terms

The most basic construct in the RIF-PRD condition language is theterm. RIF-PRD defines several kinds of term:constants,variables,lists andpositional terms.

Definition (Term).

1. Constants and variables. Ift ∈Const ort ∈Var thent is asimple term;
2. List terms. Alist has the formList(t₁ ... t_m), wherem≥0 andt₁, ...,t_m are ground terms, i.e. without variables. A list of the formList() (i.e., a list in whichm=0) is called theempty list;
3. Positional terms. Ift ∈Const andt₁, ...,t_n,n≥0, are terms thent(t₁ ... t_n) is apositional term.
   Here, the constantt represents a function andt₁, ...,t_n represent argument values.   ☐

To emphasize interoperability withRIF-BLD, positional terms may also be written:External(t(t₁...t_n)).

2.1.2 Atomic formulas

Atomic formulas are the basic tests of the RIF-PRD condition language.

Definition (Atomic formula).Anatomic formula can have several different forms and is defined as follows:

1. Positional atomic formulas. Ift ∈Const andt₁, ...,t_n,n≥0, are terms thent(t₁ ... t_n) is apositional atomic formula (or simply anatom)
2. Equality atomic formulas.t = s is anequality atomic formula (or simply anequality), ift ands are terms
3. Class membership atomic formulas.t#s is amembership atomic formula (or simplymembership) ift ands are terms. The termt is theobject and the terms is theclass
4. Subclass atomic formulas.t##s is asubclass atomic formula (or simply asubclass) ift ands are terms
5. Frame atomic formulas.t[p₁->v₁ ... p_n->v_n] is aframe atomic formula (or simply aframe) ift,p₁, ...,p_n,v₁, ...,v_n,n ≥ 0, are terms. The termt is theobject of the frame; thep_i are theproperty orattribute names; and thev_i are the property or attributevalues. In this document, an attribute/value pair is sometimes called aslot
6. Externally defined atomic formulas. Ift is a positional atomic formula thenExternal(t) is anexternally defined atomic formula.   ☐

Class membership, subclass, and frame atomic formulas are used to represent classifications, class hierarchies and object-attribute-value relations.

Externally defined atomic formulas are used, in particular, for representing built-in predicates.

In theRIF-BLD specification, as is common practice in logic languages, atomic formulas are also calledterms.

2.1.3 Formulas

Composite truth-valued constructs are calledformulas, in RIF-PRD.

Note that terms (constants, variables, lists and functions) arenot formulas.

More general formulas are constructed out of atomic formulas with the help of logical connectives.

Definition (Condition formula).Acondition formula can have several different forms and is defined as follows:

1. Atomic formula: Ifφ is an atomic formula then it is also a condition formula.
2. Conjunction: Ifφ₁, ...,φ_n,n ≥ 0, are condition formulas then so isAnd(φ₁ ... φ_n), called aconjunctive formula. As a special case,And() is allowed and is treated as a tautology, i.e., a formula that is always true.
3. Disjunction: Ifφ₁, ...,φ_n,n ≥ 0, are condition formulas then so isOr(φ₁ ... φ_n), called adisjunctive formula. As a special case,Or() is permitted and is treated as a contradiction, i.e., a formula that is always false.
4. Negation: Ifφ is a condition formula, then so isNot(φ), called anegative formula.
5. Existentials: Ifφ is a condition formula and?V₁, ...,?V_n,n>0, are variables thenExists ?V₁ ... ?V_n(φ) is anexistential formula.   ☐

In the definition of a formula, the component formulasφ andφ_i are said to besubformulas of the respective condition formulas that are built using these components.

And( ?customer # ex1:Customer     ?customer[ex1:status->"New"]     Exists ?shoppingCart ?item ( And ( ?customer[ex1:shoppingCart->?shoppingCart]                                        ?shoppingCart[ex1:containsItem->?item]                                        ?item # ex1:Widget) )                                )    )

The functionVar, that maps a term, an atomic formula or a condition formula to the set of its free variables is defined as follows:

• ife ∈Const, thenVar(e) = ∅;
• ife ∈Var, thenVar(e) = {e};
• ife is alist term, thenVar(e) = ∅;
• iff(arg₁...arg_n),n ≥ 0, is a positional term, then,Var(f(arg₁...arg_n) = ∪_i=1...nVar(arg_i);
• ifp(arg₁...arg_n), n ≥ 0, is an atom, then,Var(p(arg₁...arg_n) =Var(External(p(arg₁...arg_n)) = ∪_i=1...nVar(arg_i);
• ift₁ andt₂ are terms, thenVar(t₁ [=|#|##] t₂) =Var(t₁) ∪Var(t₂);
• ifo',k_i,i = 1...n, andv_i,i = 1...n, n ≥ 1, are terms, thenVar(o[k₁->v₁ ... k_n->v_n]) =Var(o) ∪_i=1...nVar(k_i) ∪_i=1...nVar(v_i).
• iff_i,i = 0...n, n ≥ 0, are condition formulas, thenVar([And|Or](f₁...f_n)) = ∪_i=0...nVar(f_i);
• iff is a condition formula, thenVar(Not(f)) =Var(f);
• iff is a condition formula andx_i ∈Var fori = 1...n,n ≥ 1, then,Var(Exists x₁ ... x_n (f)) =Var(f) -{x₁...x_n}.

Definition (Ground formula). A condition formulaφ is aground formula if and only ifVarφ =∅ andφ does not contain any existential subformula.   ☐

In other words, a ground formula does not contain any variable term.

2.1.4 Well-formed formulas

Not all formulas are well-formed in RIF-PRD: 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 the following subsets:

• A subset of individuals. The symbols inConst that belong to the primitive datatypes are required to be individuals;
• A subset for external function symbols;
• A subset of plain predicate symbols;
• A subset for external predicate symbols.

As seen from the following definitions, these subsets are not specified explicitly but, rather, are inferred from the occurrences of the symbols.

Definition (Context of a symbol).Thecontext of an occurrence of a symbol,s∈Const, in a formula,φ, is determined as follows:

• Ifs occurs as a predicate in an atomicsubformula of the forms(...) thens occurs in thecontext of a (plain) predicate symbol;
• Ifs occurs as a predicate in an atomic subformulaExternal(s(...)) thens occurs in thecontext of an external predicate symbol;
• Ifs occurs as a function in a term (which is not a subformula)s(...) (orExternal(s(...))) thens occurs in thecontext of an (external) function symbol;
• Ifs occurs in any other context (e.g. in a frame:s[...],...[s->...], or...[...->s]; or in a positional atom:p(...s...)), it is said to occur as anindividual.   ☐

Definition (Well-formed formula).A formulaφ iswell-formed iff:

• every constant symbol mentioned inφ occurs in exactly onecontext;
• whenever a formula contains a positional term,t (orExternal(t)), or an external atomic formula,External(t),t must be an instance of a schema in the coherent set of external schemas (Section Schemas for Externally Defined Terms in [RIF-DTB]) associated with thelanguage of RIF-PRD;
• ift is an instance of a schema in the coherent set of external schemas associated with the language thent can occur only as an external term or atomic formula.   ☐

Definition (RIF-PRD condition language).TheRIF-PRD condition language consists of the set of all well-formed formulas.   ☐

2.2 Operational semantics of condition formulas

This section specifies the semantics of the condition formulas in a RIF-PRD document.

Informally, a condition formula is evaluated with respect to a state of facts and it issatisfied, ortrue, if and only if:

• it is an atomic condition formula and its variables are bound to individuals such that, when these constants are substituted for the variables, either
  • it matches a fact, or
  • it is implied by some background knowledge, or
  • it is an externally defined predicate, and its evaluation yeldstrue, or
• it is a compound condition formula: conjunction, disjunction, negation or existential; and it is evaluated as expected, based on the truth value of its atomic components.

The semantics is specified in terms of matching substitutions in the sections below. The specification makes no assumption regarding how matching substitutions are determined. In particular, it does not require fromwell-formed condition formulas that they can be evaluated using pattern matching only. However, RIF-PRD requiressafeness fromwell-formed rules, which implies that all the variables in the left-hand side can be bound by pattern matching.

For compatibility with other RIF specifications (in particular, RIF data types and built-ins [RIF-DTB] and RIF RDF and OWL compatibility [RIF-RDF-OWL]), and to make explicit the interoperability with RIF logic dialects (in particular RIF Core [RIF-Core] and RIF-BLD [RIF-BLD]), the semantics of RIF-PRD condition formulas is also specified using model theory, inappendix Model theoretic semantics of RIF-PRD condition formulas.

The two specifications are equivalent and normative.

2.2.1 Matching substitution

LetTerm be the set of the terms in the RIF-PRD condition language (as defined in sectionTerms).

Definition (Substitution). Asubstitution is a finitely non-identical assignment of terms to variables; i.e., a functionσ fromVar toTerm such that the set {x ∈Var |x ≠ σ(x)} is finite. This set is called the domain of σ and denoted byDom(σ). Such a substitution is also written as a set such as σ = {t_i/x_i}_i=1..n whereDom(σ) = {x_i}_i=1..n and σ(x_i) =t_i,i = 1..n.   ☐

Definition (Ground Substitution). Aground substitution is a substitution σ that assigns only ground terms to the variables inDom(σ): ∀x ∈Dom(σ),Var(σ(x)) = ∅   ☐

Because RIF-PRD covers only externally defined interpreted functions, a ground positional term can always be replaced by the (non-positional) ground term to which it evaluates. As a consequence, a ground RIF-PRD formula can always be restricted, without loss of generality, to contain no positional term; that is, to be such that any ground positional terms have been replaced with the non-positional ground terms to which they evaluate. In the remainder of this document, it will always be assumed that a ground condition formula never contains any positional term. As a consequence, a ground substitution never assigns a ground positional term to the variables in its domain.

Ift is a term or a condition formula, and ifσ is a ground substitution such thatVar(t) ∈ Dom(σ),σ(t) denotes the ground term or the ground condition formula obtained by substituting, int:

• σ(x) for allx ∈ Var(t), and
• the externally defined results of interpreting a function with ground arguments, for all externally defined terms.

Definition (Matching substitution). Letψ be a RIF-PRD condition formula; letσ be a ground substitution such thatVar(ψ) ⊆ Dom(σ); and letΦ be a set of ground RIF-PRD atomic formulas.

We say that the ground substitutionσmatchesψ toΦ if and only if one of the following is true:

• ψ is an atomic formula and either
  • σ(ψ) ∈Φ, or
  • ψ is a frame with multiple slots,o[s₁->v₁...s_n->v_n],n > 1, and there is onei, 1≤i≤n, such thatσ matches the conjunctionAnd(o[s_i->v_i] o[s₁->v₁...s_i-1->v_i-1 s_i+1->v_i+1...s_n->v_n] toΦ; or
  • ψ is an equality formula,t₁ = t₂, and either
    • σ(t₁) andσ(t₂) are the same ground term;
    • or the ground termsσ(t₁) andσ(t₂) are list terms with the same lengthn≥0 and, for alli, 0≤i≤n-1, such thatl_1i andl_2i are the ground terms of ranki inσ(t₁) andσ(t₂), respectively, eitherl_1i andl_2i are both constants in symbol spaces that are data types and they have the same value, orl_1i = l_2i ∈Φ,
    • or the ground termsσ(t₁) andσ(t₂) are constants in symbol spaces that are data types and they have the same value; or
  • ψ is a membership formulao # c, and there is a ground termc' such thatσ matches the conjunctionAnd(o#c' c'##c) toΦ, or
  • ψ is an external atomic formula and the external definition mapsσ(ψ) tot (ortrue),
• ψ isNot(f) andσ does not match the condition formulaf toΦ,
• ψ isAnd(f₁ ... f_n) and eithern = 0 or∀ i, 1 ≤ i ≤ n,  σ matchesf_i toΦ,
• ψ isOr(f₁ ... f_n) andn> 0 and ∃i, 1 ≤ i ≤ n, such thatσ matchesf_i toΦ, or
• ψ isExists ?v₁ ... ?v_n (f), and there is a substitutionσ' that extendsσ in such a way thatσ' agrees withσ whereσ is defined, andVar(f) ⊆ Dom(σ'); andσ' matchesf toΦ.   ☐

2.2.2 Condition satisfaction

We define, now, what it means for astate of the fact base to satisfy a condition formula. The satisfaction of condition formulas in a state of the fact base provides formal underpinning to the operational semantics of rule sets interchanged using RIF-PRD.

Definition (State of the fact base). Astate of the fact base,w_Φ, is associated to every set of ground atomic formulas,Φ, that contains no frame with multiple slots and that satisfies all the following conditions:

• for every equality formulat₁ = t₂ ∈Φ, ift₁ andt₂ are, both, constants in symbol spaces that are data types, then they have the same value;
• for every equality formulat₁ = t₂ ∈Φ, eithert₁ is not a constant in a symbol space that is a data type, ort₂ is not a list term;
• for every pair of constantsc₁ andc₂, ifc₁ = c₂ ∈Φ, thenc₂ = c₁ ∈Φ;
• for every triple of constantsc₁,c₂ andc₃, ifc₁ = c₂ ∈Φ andc₂ = c₃ ∈Φ, thenc₁ = c₃ ∈Φ;
• for all triple of constantsc₁, c₂,c₃, ifc₁##c₂ ∈ Φ andc₂##c₃ ∈ Φ, thenc₁##c₃ ∈ Φ.

We say thatw_Φ isrepresented byΦ; or, equivalently, by the conjunction of all the ground atomic formulas inΦ.   ☐

Each ground atomic formula inΦ represents a singlefact, and, often, the ground atomic formulas, themselves, are calledfacts, as well. Notice that the restriction thatΦ can contain only single slot frames, in the definition of astate of the fact base is not a limitation: given the definition of amatching substitution, a frame with multiple slots is only syntactic shorthand for the semantically equivalent conjunction of single slot frames.

Definition (Condition satisfaction). A RIF-PRD condition formulaψ issatisfied in a state of the fact base,w, if and only ifw is represented by a set of ground atomic formulasΦ, and there is a ground substitutionσ that matchesψ toΦ.   ☐

Alternative, but equivalent, definitions of a state of the fact base and of the satisfaction of a condition are given in theappendix Model theoretic semantics of RIF-PRD condition formulas: they provide the formal link between the model theory of RIF-PRD condition formulas and the operational semantics of RIF-PRD documents.

3 Actions

This section specifies the syntax and semantics of the RIF-PRDaction language. The conclusion of a production rule is often called theaction part, thethen part, or theright-hand side, orRHS.

The RIF-PRD action language is used to add, delete and modify facts in the fact base.As a rule interchange format, RIF-PRD does not make any assumption regarding the nature of the data sources that the producer or the consumer of a RIF-PRD document uses (e.g. a rule engine's working memory, an external data base, etc). As a consequence, the syntax of the actions that RIF-PRD supports are defined with respect to the RIF-PRD condition formulas that represent the facts that the actions affect.In the same way, the semantics of the actions is specified in terms of how their execution affects the evaluation of rule conditions.

3.1 Abstract syntax

The alphabet of the RIF-PRD action language includes symbols to denote:

• the assertion of a fact represented by a positional atom, a frame, or a membership atomic formula,
• the retraction of a fact represented by a positional atom or a frame,
• the retraction of all the facts about the values of a given slot of a given frame object,
• the addition of a new frame object,
• the removal of a frame object and the retraction of all the facts about it, represented by the corresponding frame and class membership atomic formulas,
• the replacement of all the values of an object's attribute by a single, new value,
• the execution of an externally defined action, and
• a sequence of these actions, including the declaration of local variables and a mechanism to bind a local variable to a frame slot value or a new frame object.

3.1.1 Actions

The RIF-PRD action language includes constructs for actions that are atomic, from a transactional point of view, and constructs that represent compounds of atomic actions. Action constructs take constructs from the RIF-PRD condition language as their arguments.

Definition (Atomic action). Anatomic action is a construct that represents an atomic transaction. An atomic action can have several different forms and is defined as follows:

1. Assert simple fact: Ifφ is apositional atom, a single slotframe or amembership atomic formula in the RIF-PRD condition language, thenAssert(φ) is an atomic action.φ is called thetarget of the action.
2. Retract simple fact: Ifφ is apositional atom or a single slotframe in the RIF-PRD condition language, thenRetract(φ) is an atomic action.φ is called thetarget of the action.
3. Retract all slot values: Ifo ands are terms in the RIF-PRD condition language, thenRetract(o s) is an atomic action. The pair(o, s) is called thetarget of the action.
4. Retract object: Ift is aterm in the RIF-PRD condition language, thenRetract(t) is an atomic action.t is called thetarget of the action.
5. Execute: ifφ is apositional atom in the RIF-PRD condition language, thenExecute(φ) is an atomic action.φ is called thetarget of the action.   ☐

Definition (Compound action). Acompound action is a construct that can be replaced equivalently by a pre-defined, and fixed, sequence of atomic actions. In RIF-PRD, a compound action can have three different forms, defined as follows:

1. Assert compound fact: Ifφ is aframe with multiple slots:φ =o[s₁->v₁...s_n->v_n],n > 1; thenAssert(φ) is a compound action, defined by the sequenceAssert(o[s₁->v₁]) ... Assert(o[s_n->v_n]).φ is called thetarget of the action.
2. Retract compound fact: Ifφ is aframe with multiple slots:φ =o[s₁->v₁...s_n->v_n],n > 1; thenRetract(φ) is a compound action, defined by the sequenceRetract(o[s₁->v₁]) ... Retract(o[s_n->v_n]).φ is called thetarget of the action.
3. Modify fact: ifφ is aframe in the RIF-PRD condition language:φ =o[s₁->v₁...s_n->v_n],n > 0; thenModify(φ) is a compound action, defined by the sequence:Retract(o s₁) ...Retract(o s_n), followed byAssert(φ).φ is called thetarget of the action.   ☐

Definition (Action). Aaction is either anatomic action or acompound action.   ☐

Definition (Ground action). An action with targett is aground action if and only if

• t is an atomic formula andVar(t) = ∅;
• ort = (o, s) is a pair of terms andVar(o) =Var(s) = ∅.

  ☐

3.1.2 Action blocks

Theaction block is the top level construct to represent the conclusions of RIF-PRD rules. An action block contains a non-empty sequence ofactions. It may also includeaction variable declarations.

Theaction variable declaration construct is used to declare variables that are local to the action block, calledaction variables, and to assign them a value within the action block.

Definition (Action variable declaration). Anaction variable declaration is a pair,(v p) made of anaction variable,v, and anaction variable binding (or, simply,binding),p, wherep has one of two forms:

1. frame object declaration: if the action variable,v, is to be assigned the identifier of a new frame, then the action variable binding is aframe object declaration:New(). In that case, the notation for the action variable declaration is:(?o New());
2. frame slot value: if the action variable,v, is to be assigned the value of a slot of a ground frame, then the action variable binding is a frame:p = o[s->v], whereo is a term that represents the identifier of the ground frame ands is a term that represents the name of the slot. The associated notation is:(?value o[s->?value]).   ☐

Definition (Action block). If(v₁ p₁), ..., (v_n p_n),n ≥ 0, are action variable declarations, and ifa₁, ..., a_m,m ≥ 1, areactions, thenDo((v₁ p₁) ... (v_n p_n) a₁ ... a_m) denotes anaction block.   ☐

Do( (?oldValue ?shoppingCart[ex1:value->?oldValue])    Modify( ?shoppingCart[ex1:value->func:numeric-multiply(?oldValue 0.90)] ) )

3.1.3 Well-formed action blocks

Not all action blocks are well-formed in RIF-PRD:

• one and only one action variable binding can assign a value to each action variable, and
• the assertion of a membership atomic formula is meaningful only if it is about a frame object that is created in the same action block.

The notion of well-formedness, alreadydefined for condition formulas, is extended to actions, action variable declarations and action blocks.

Definition (Well-formed action). Anactionα iswell-formed if and only if one of the following is true:

• α is anAssert and its target is a well-formed atom, a well-formed frame or a well-formed membership atomic formula,
• α is aRetract with one single argument and its target is a well-formed term or a well-formed atom or a well-formed frame atomic formula,
• α is aRetract with two arguments:o ands, and both are well-formed terms,
• α is aModify and its target is a well-formed frame, or
• α is anExecute and its content is an instance of the coherent set of external schemas (Section Schemas for Externally Defined Terms in RIF data types and builtins [RIF-DTB]) associated with the RIF-PRD language (sectionBuilt-in functions, predicates and actions).   ☐

Definition (Well-formed action variable declaration). An action variable declaration(?vp) iswell-formed if and only if one of the following is true:

• the action variable binding,p, is the declaration of a new frame object:p = New(), or
• the action variable binding,p, is a well formed frame atomic formula,p = o[a₁->t₁...a_n->t_n], n ≥ 1, and the action variable,v occurs in the position of a slot value, and nowhere else, that is:v ∈ {t₁ ... t_n} andv ∉ Var(o) ∪ Var(a₁) ∪ ... ∪ Var(a_n) and ∀t_i, eitherv = t_i orv ∉ Var(t_i).   ☐

For the definition of a well-formed action block, the functionVar(f), that has beendefined for condition formulas, is extended to actions and frame object declarations as follows:

• iff is an action with targett andt is an atomic formula, thenVar(f) = Var(t);
• iff is an action with targett andt is a pair,(o, s) of terms, thenVar(f) = Var(o) ∪ Var(s);
• iff is a frame object declaration,New(), thenVar(f) = ∅.

Definition (Well-formed action block). An action block iswell-formed if and only if all of the following are true:

• all the action variable declarations, if any, are well-formed,
• each action variable, if any, is assigned a value by one and only one action variable binding, that is: ifb₁ =(v₁ p₁) andb₂ =(v₂ p₂) are two action variable declarations in the action block with different bindings:p₁ ≠ p₂, thenv₁ ≠ v₂,
• in addition, the action variable declarations, if any, are partially ordered by the ordering defined as follows: ifb₁ =(v₁ p₁) andb₂ =(v₂ p₂) are two action variable declarations in the action block, thenb₁ < b₂ if and only ifv₁ ∈ Var(p₂),
• all the actions in the action block are well-formed actions, and
• if an action in the action block asserts a membership atomic formula,Assert(t₁ # t₂), then the object term in the membership atomic formula,t₁, is an action variable that is declared in the action block and the action variable binding is aframe object declaration.   ☐

Definition (RIF-PRD action language). TheRIF-PRD action language consists of the set of all the well-formed action blocks.   ☐

3.2 Operational semantics of atomic actions

This section specifies the semantics of the atomic actions in a RIF-PRD document.

The effect of the ground atomic actions in the RIF-PRD action language is to modify the state of the fact base, in such a way that it changes the set of conditions that are satisfied before and after each atomic action is performed.

As a consequence, the semantics of the ground atomic actions in the RIF-PRD action language determines a relation, called theRIF-PRD transition relation: →_RIF-PRD ⊆W ×L ×W, whereW denotes the set of all the states of the fact base, and whereL denotes the set of all the ground atomic actions in the RIF-PRD action language.

The semantics of a compound action follows directly from the semantics of the atomic actions that compose it.

Individual states of the fact base are represented by sets of ground atomic formulas (SectionSatisfaction of a condition). In the following, the operational semantics of RIF-PRD actions, rules, and rule sets is specified by describing the changes they induce in the fact base.

Definition (RIF-PRD transition relation). The semantics of RIF-PRD atomic actions is specified by thetransition relation →_RIF-PRD ⊆W ×L ×W.(w,α, w') ∈ →_RIF-PRD if and only ifw ∈W,w'∈W,α is a ground atomic action, and one of the following is true, whereΦ is a set of ground atomic formulas that representsw andΦ' is a set of ground atomic formulas that representw':

1. α isAssert(φ), where φ is a ground atomic formula, andΦ' = Φ ∪ {φ};
2. α isRetract(φ), where φ is a ground atomic formula, andΦ' = Φ \ {φ};
3. α isRetract(o s), whereo ands are constants, andΦ' = (Φ \ {o[s->v] | for all the values ofv});
4. α isRetract(o), whereo is a constant, andΦ' = Φ \ {o[s->v] | for all the values of termss andv} - {o#c | for all the values of termc};
5. α isExecute(φ), where φ is a ground atomic builtin action, andΦ' = Φ.   ☐

Rule 1 says that all the atomic condition formulas that were satisfied before an assertion will be satisfied after, and that, in addition, the atomic condition formulas that are satisfied by the asserted ground formula will be satisfied after the assertion. No other atomic condition formula will be satisfied after the execution of the action.

Rule 2 says that all the atomic condition formulas that were satisfied before a retraction will be satisfied after, except if they are satisfied only by the retracted fact. No other atomic condition formula will be satisfied after the execution of the action.

Rule 3 says that all the condition formulas that were satisfied before the retraction of all the values of a given slot of a given object will be satisfied after, except if they are satisfied only by one of the frame formulas about the object and the slot that are the target of the action, or a conjunction of such formulas. No other condition formula will be satisfied after the execution of the action.

Rule 4 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. No other condition formula will be satisfied after the execution of the action.

Rule 5 says that all the condition formulas that were satisfied before the execution of an action builtin will be satisfied after. No other condition formula will be satisfied after the execution of the action.

4 Production rules and rule sets

This section specifies the syntax and semantics of RIF-PRD rules and rule sets.

4.1 Abstract syntax

The alphabet of the RIF-PRD rule language includes the alphabets of theRIF-PRD condition language and theRIF-PRD action language and adds symbols for:

• combining a condition and an action block into a rule,
• declaring (some) variables that are free in a ruleR, specifying their bindings, and combining them withR into a new ruleR' (with fewer free variables),
• grouping rules and associating specific operational semantics to groups of rules.

4.1.1 Rules

Definition (Rule). Arule can be one of:

• anunconditional action block,
• aconditional action block: ifcondition is a formula in the RIF-PRD condition language, and ifaction is a well-formed action block, thenIf condition, Then action is a rule,
• arule with variable declaration: if?v₁ ... ?v_n,n ≥ 1, are variables;p₁ ... p_m,m ≥ 1, are condition formulas (calledpatterns), andrule is a rule, thenForall ?v₁...?v_n such that (p₁...p_m) (rule) is a rule.   ☐

Forall ?customer such that And( ?customer # ex1:Customer                                ?customer[ex1:status->"Silver"] )  (Forall ?shoppingCart such that And( ?shoppingCart # ex1:ShoppingCart                                      ?customer[ex1:shoppingCart->?shoppingCart] )     (If Exists ?value (And( ?shoppingCart[ex1:value->?value]                             pred:numeric-greater-than-or-equal(?value 2000))      Then Do( Modify( ?customer[ex1:status->"Gold"] ) ) )

The functionVar(f), that has beendefined for condition formulas andextended to actions, is further extended to rules, as follows:

• iff is an action block that declares action variables?v₁ ... ?v_n,n ≥ 0, and that contains actionsa₁ ... a_m,m ≥ 1, thenVar(f) =∪_{1 ≤ i ≤ m} Var(a_i) \ {?v₁ ... ?v_n};
• iff is a conditional action block wherec is the condition formula anda is the action block, thenVar(f) = Var(c) ∪ Var(a);
• iff is a quantified rule where?v₁ ... ?v_n,n > 0, are the declared variables;p₁ ... p_m,m ≥ 0, are the patterns, andr is the rule, thenVar(f) = (Var(r) ∪ Var(p₁) ∪ ... ∪ Var(p_m)) \ {?v₁ ... ?v_n}.

4.1.2 Groups

As was already mentioned in theOverview, production rules have an operational semantics that can be described in terms of matching rules against states of the fact base, selecting rule instances to be executed, and executing rule instances' actions to transition to new states of the fact base.

When production rules are interchanged, the intended rule instance selection strategy, often called theconflict resolution strategy, needs to be interchanged along with the rules. In RIF-PRD, thegroup construct is used to group sets of rules and to associate them with a conflict resolution strategy. Many production rule systems use priorities associated with rules as part of their conflict resolution strategy. In RIF-PRD, the group is also used to carry the priority information that may be associated with the interchanged rules.

Definition (Group). Agroup consists of a, possibly empty, set of rules and groups, associated with a conflict resolution strategy and, a priority. Ifstrategy is an IRI that identifies a conflict resolution strategy, ifpriority is an integer, and if eachrg_j,0 ≤ j ≤ n, is either a rule or a group, then any of the following represents a group:

• Group (rg₀ ... rg_n),n ≥ 0;
• Group strategy (rg₀ ... rg_n),n ≥ 0;
• Group priority (rg₀ ... rg_n),n ≥ 0;
• Group strategy priority (rg₀ ... rg_n),n ≥ 0.

If a conflict resolution strategy is not explicitly attached to a group, the strategy defaults torif:forwardChaining (specified below, insection Conflict resolution).   ☐

4.1.3 Safeness

The definitions in this section are unchanged from the definitions in the section Safeness in [RIF-Core], except for the definition ofRIF-PRD rule safeness, that is extended from the definition ofRIF-Core rule safeness. The definitions are reproduced for the reader's convenience.

Intuitively, safeness of rules guarantees that all the variables in a rule can be bound, using pattern matching only, before they are used, in a test or in an action.

To define safeness, we need to define, first, the notion ofbinding patterns for externally defined functions and predicates, as well as under what conditions variables are consideredbound.

Definition (Binding pattern). (from [RIF-Core])Binding patterns for externally defined functions and predicates are lists of the form (p₁,...,p_n), such thatp_i=b orp_i=u, for1 ≤ i ≤ n:b stands for a "bound" andu stands for an "unbound" argument.   ☐

Each external function or predicate has an associated list ofvalid binding patterns. We define here the binding patterns valid for the functions and predicates defined in [RIF-DTB].

Every function or predicatef defined in [RIF-DTB] has a valid binding pattern for each of its schemas with only the symbolb such that its length is the number of arguments in the schema. In addition,

• the external predicatepred:iri-string has the valid binding patterns (b,u) and (u,b) and
• the external predicatepred:list-contains has the valid binding pattern (b,u).

The functions and predicates defined in [RIF-DTB] have no other valid binding patterns.

To keep the definitions concise and intuitive, boundedness and safeness are defined, in [RIF-Core], for condition formulas in disjunctive normal form, that can be existentially quantified themselves, but that contain, otherwise, no existential sub-formula. The definitions apply to any valid RIF-Core condition formula, because they can always, in principle, be put in that form, by applying the following syntactic transforms, in sequence:

1. iff contains existential sub-formulas, all the quantified variables are renamed, if necessary, and given a name that is unique inf, and the scope of the quantifiers is extended tof. Assume, for instance, thatf has an existential sub-formula,sf =Exists v₁...v_n (sf'), n ≥ 1, such that the namesv₁...v_n do not occur inf outside ofsf. After the transform,f becomesExists v₁...v_n (f'), wheref' isf withsf replaced bysf'. The transform is applied iteratively to all the existential sub-formulas inf;
2. the (possibly existentially quantified) resulting formula is rewritten in disjunctive normal form ([Mendelson97], p. 30).

In RIF-PRD, the definitions apply to conditions formulas in the same form as in [RIF-Core], with the exception that, in the disjunctive normal form, negated sub-formulas can be atomic formulas or existential formulas: in the latter case, the existentially quantified formula must be, itself, in disjunctive normal form, and contain no further existential sub-formulas. The definitions apply to any valid RIF-PRD condition formula, because they can always, in principle, be put in that form, by applying the above syntactic transform, modified as follows to take negation into account:

• if the condition formula under consideration,f, contains negative sub-formulas, existential formulas that occur inside a negated formula are handled as if they were atomic formulas, with respect to the two processing steps. Extending the scope of an existential quantifier beyond a negation would require its transformation into an universal quantifier, and universal formulas are not part of RIF-PRD condition language;
• in addition, the two pre-processing steps are applied, separately, to these existentially quantified formulas, to be able to determine the status of the existentially quantified variables with respect to boundedness.

Definition (Boundedness). (from [RIF-Core]) An external termExternal(f(t₁,...,t_n)) isbound in a condition formula, if and only iff has a valid binding pattern (p₁,...,p_n) and, for allj, 1 ≤ j ≤ n, such thatp_j=b,t_j is bound in the formula.

A variable,v, isbound in an atomic formula,a, if and only if

• a is neither an equality nor an external predicate, andv occurs as an argument ina;
• orv is bound in the conjunctive formulaf =And(a).

A variable,v, isbound in a conjunction formula,f =And(c₁...c_n), n ≥ 1, if and only if, either

• v is bound in at least one of the conjuncts;
• orv occurs as thej-th argument in a conjunct,c_i, that is an externally defined predicate, and thej-th position in a binding pattern that is associated withc_i isu, and all the arguments that occur, inc_i, in positions with valueb in the same binding pattern are bound inf' =And(c₁...c_i-1 c_i+1...c_n);
• orv occurs in a conjunct,c_i, that is an equality formula, andv occurs as the term on one side of the equality, and the term on the other side of the equality is bound inf' =And(c₁...c_i-1 c_i+1...c_n).

A variable,v, isbound in a disjunction formula, if and only ifv is bound in every disjunct where it occurs;

A variable,v, isbound in an existential formula,Exists v₁,...,v_n (f'),n ≥ 1, if and only ifv is bound inf'.   ☐

Notice that the variables,v₁,...,v_n, that are existentially quantified in an existential formulaf =Exists v₁,...,v_n (f'), are bound in any formula,F, that containsf as a sub-formula, if and only if they are bound inf, since they do not exist outside off.

Definition (Variable safeness). (from [RIF-Core]) A variable,v, issafe in a condition formula,f, if and only if

• f is an atomic formula andf is not an equality formula in which both terms are variables andv occurs inf;
• orf is a conjunction, ,f =And(c₁...c_n), n ≥ 1, andv is safe in at least one conjunct inf, orv occurs in a conjunct,c_i, that is an equality formula in which both terms are variables, andv occurs as the term on one side of the equality, and the variable on the other side of the equality is safe inf' =And(c₁...c_i-1 c_i+1...c_n);
• orf is a disjunction, andv is safe in every disjunct;
• orf is an existential formula,f =Exists v₁,...,v_n (f'), n ≥ 1, andv is safe inf'.   ☐

Notice that the two definitions, above, are not extended for negation and, followingly, that an universally quantified (rule) variable is never bound or safe in a condition formula as a consequence of occurring in a negative formula.

The definition ofrule safeness is replaced by the following one, that extends the one for RIF-Core rules.

Definition (RIF-PRD rule safeness). A RIF-PRD rule,r, issafe if and only if

• r is an unconditional action block, andVar(r) = ∅;
• orr is a conditional action block,If C Then A, and all the variables inVar(A) are safe inC, and all the variables inVar(r) are bound inC;
• orr is a rule with variable declaration,∀ v₁...v_n such that p₁...p_m (r'),n ≥ 1, m ≥ 0, and either
  • r' is an unconditional action block,A, and the conditional action blockIf And(p₁...p_m) Then A is safe;
  • orr' is a conditional action block,If C Then A, and the conditional action blockIf And(C p₁...p_m) Then A is safe;
  • orr' is a rule with variable declaration,∀ v'₁...v'_n' such that p'₁...p'_m' (r"),n' ≥ 1, m' ≥ 0, and the rule with variable declaration∀ v₁...v_n v'₁...v'_n' such that p₁...p_m p'₁...p'_m' (r"), is safe.   ☐

Definition (Group safeness). (from [RIF-Core]) A group,Group (s₁...s_n),n ≥ 0, issafe if and only if

• it is empty, that is,n = 0;
• ors₁ and ... ands_n are safe.   ☐

4.1.4 Well-formed rules and groups

Iff is a rule,Var(f) is the set of the free variables inf.

Definition (Well-formed rule). A rule,r, is awell-formed rule if and only if either

• r is an unconditionalwell-formed action block,a,
• orr is a conditional action block where the condition formula,c, is awell-formed condition formula, and the action block,a, is awell-formed action block,
• orr is a quantified rule (with or without patterns),Forall V [such that P](r'), and
  • each of the patterns,p_i ∈ P = {p₁,...,p_n},n ≥ 0, is awell-formed condition formula,
  • and the quantified rule,r', is a well-formed rule.   ☐

Definition (Well-formed group). A group iswell-formed group if and only if it issafe and it contains only well-formed groups,g₁...g_n, n ≥ 0, and well-formed rules,r₁...r_m, m ≥ 0, such thatVar(r_i) = ∅ for alli, 0 ≤ i ≤ m.   ☐

The variables that are universally quantified in a rule are sometimes calledrule variables in the remainder of this document, to distinguish them from the action variables and from the existentially quantified variables. The functionCVar, that maps a rule to the set of its rule variables is defined as follows:

• ifr is a conditional or unconditional action block,CVar(r) = ∅
• ifr is a rule with variable declaration,Forall ?v₁...?v_n (r'),CVar(r) = CVar(r') ∪ {?v₁...?v_n}.

The set of the well-formed groups contains all the production rule sets that can be meaningfully interchanged using RIF-PRD.

4.2 Operational semantics of rules and rule sets

4.2.1 Motivation and example

As mentioned in theOverview, the description of a production rule system as a transition system is used to specify the semantics of production rules and rule sets interchanged using RIF-PRD.

The intuition of describing a production rule system as a transition system is that, given a set of production rulesRS and a fact basew₀, the rules inRS that are satisfied, in some sense, inw₀ determine an actiona₁, whose execution results in a new fact basew₁; the rules inRS that are satisfied inw₁ determine an actiona₂ to execute inw₁, and so on, until the system reaches a final state and stops. The result is the fact basew_n when the system stops.

(* ex1:CheckoutRuleset *)Group rif:forwardChaining (  (* ex1:GoldRule *)  Group 10 (    Forall ?customer such that (And( ?customer # ex1:Customer                                     ?customer[ex1:status->"Silver"] ) )      (Forall ?shoppingCart such that (?customer[ex1:shoppingCart->?shoppingCart])         (If Exists ?value (And( ?shoppingCart[ex1:value->?value]                                 pred:numeric-greater-than-or-equal(?value 2000))          Then Do( Modify( ?customer[ex1:status->"Gold"] ) ) ) )  (* ex1:DiscountRule *)  Group (    Forall ?customer such that (And( ?customer # ex1:Customer ) )      (If Or (?customer[ex1:status->"Silver"]              ?customer[ex1:status->"Gold"] )       Then Do( (?s ?customer[ex1:shoppingCart->?s])                (?v ?s[ex1:value->?v])                Modify( ?s[ex1:value->func:numeric-multiply(?v 0.95)] ) ) ) )

4.2.2 Rules normalization

A rule,R, whose condition, rewritten in disjunctive normal form as described insection Safeness, consists of more than one disjunct, is equivalent, logically as well as operationally, to a set (or conjunction) of rules that have, all, the same conclusion asR, and each rule has one of the disjuncts as its condition: the ruleR: If C₁ Or ... Or C_n Then A is equivalent to the set of rules{r_i=0..n| r_i: If C_i Then A}.

Without loss of generality, and to keep the specification as simple and intuitive as possible, the operational semantics of production rules and rule sets is specified, in the following sections, for rules and rule sets that have been normalized as follows:

1. All the rules are rewritten in disjunctive normal form as described insection Safeness;
2. Each rule is replaced by agroup of rules
   • with the same priority as the rule it replaces,
   • that contains as many rules as the condition of the original rule in disjunctive normal form contains disjuncts,
   • where the condition, in each rule in the group is one of the disjunct in the condition of the original rule,
   • and where all the rules in the group have a different condition and the same action part as the original rule.

In the same way, without loss of generality, and to keep the specification as simple and intuitive as possible, the operational semantics of production rules and rule sets is specified, in the following sections, for rules and rule sets where all thecompound actions have been replaced by the equivalent sequences ofatomic actions.

4.2.3 Definitions and notational conventions

Formally, a production rule system is defined as a labeled terminal transition system (e.g.PLO04), for the purpose of specifying the semantics of a RIF-PRDrule orgroup of rules.

Definition (labeled terminal transition system): A labeled terminal transition system is a structure {C,L, →,T}, where

• C is a set of elements,c, called configurations, or states;
• L is a set of elements,a, called labels, or actions;
• → ⊆ C × L × C is the transition relation, that is: (c, a, c') ∈ → iff there is a transition labeleda from the statec to the statec'. In the case of a production rule system: in the statec of the fact base, the execution of actiona causes a transition to state thec' of the fact base;
• T ⊆ C is the set of final states, that is, the set of all the statesc from which there are no transitions: T = {c ∈ C | ∀a ∈ L, ∀c' ∈ C, (c, a, c') ∉ →}.   ☐

For many purposes, a representation of the states of the fact base is an appropriate representation of the states of a production rule system seen as a transition system. However, the most widely used conflict resolution strategies require information about the history of the system, in particular with respect to the rule instances that have been selected for execution in previous states. Therefore, each state of the transition system used to represent a production rule system must keep a memory of the previous states and of the rule instances that where selected and that triggered the transition in those states.

Here, arule instance is defined as the result of the substitution of constants for all the rule variables in a rule.

LetR denote the set of all the rules in the rule language under consideration.

Definition (Rule instance). Given a rule,r ∈ R, and aground substitution, σ, such thatCVar(r) ⊆ Dom(σ), whereCVar(r) denotes the set of the rule variables inr, the result,ri = σ(r), of the substitution of the constantσ(?x) for each variable?x ∈ CVar(r) is arule instance (or, simply, aninstance) ofr.  ☐

Given a rule instanceri, letrule(ri) identify the rule from whichri is derived by substitution of constants for the rule variables, and letsubstitution(ri) denote the substitution by whichri is derived fromrule(ri).

In the following, two rule instancesri₁ andri₂ of a same ruler will be considereddifferent if and only ifsubstitution(ri₁) andsubstitution(ri₂) substitute a different constant for at least one of the rule variables inCVar(r).

A rule instance,ri, is said to match a state of a fact base,w, if its defining substitution,substitution(ri), matches the RIF-PRD condition formula that represents the condition of the instantiated rule,rule(ri), to the set of ground atomic formulas that represents the state of factsw.

LetW denote the set of all the possible states of a fact base.

Definition (Matching rule instance). Given a rule instance,ri, and a state of the fact base,w ∈ W,ri is said tomatchw if and only if one of the following is true:

• rule(ri) is anunconditional action block;
• rule(ri) is aconditional action block:If condition, Then action, andsubstitution(ri)matches the condition formulacondition to the set of ground atomic condition formulas that representsw;
• rule(ri) is arule with variable declaration:Forall ?v₁...?v_n (p₁...p_m) (r'),n ≥ 0,m ≥ 0, andsubstitution(ri)matches each of the condition formulasp_i,0 ≤ i ≤ m, to the set of ground atomic condition formulas that representsw, and the rule instanceri' matchesw, whererule(ri') = r' andsubstitution(ri') = substitution(ri).   ☐

Definition (Action instance). Given a state of the fact base,w ∈ W, given a rule instance,ri, of a rule in a rule set,RS, and given the action block in the action part of the rulerule(ri):Do((v₁ p₁)...(v_n p_n) a₁...a_m),n ≥ 0,m ≥ 1, where the(v_i p_i),0 ≤ i ≤ n, represent theaction variable declarations and thea_j,1 ≤ j ≤ m, represent the sequence of atomic actions in the action block; ifri matchesw, the substitutionσ = substitution(ri) is extended to the action variablesv₁...v_n, n ≥ 0, in the following way:

• if the binding,p_i, associated tov_i, in the action variable declaration, is the declaration of a new frame object:(v_iNew()), thenσ(v_i) = c_new, wherec_new is a constant of typerif:IRI that does not occur in any of the ground atomic formulas inw;
• ifv_i is assigned the value of a frame's slot by the action variable declaration:(v_io[s->v_i]), thenσ(v_i) is a ground term such that the substitution σmatches the frame formulao[s->v_i] tow.

The sequence of ground atomic actions that is the result of substituting a constant for each variable in the atomic actions of the action blockof the rule instance,ri, according to the extended substitution, is theaction instance associated tori.   ☐

Letactions(ri) denote the action instance that is associated to a rule instanceri. By extension, given an ordered set of rule instances,ori,actions(ori) denotes the sequence of ground atomic actions that is the concatenation, preserving the order inori, of the action instances associated to the rule instances inori.

Notice that RIF-PRD does not specify semantics for the case where there is nomatching substitution for the binding frame formulao[s->v_i] in an action variable declaration(v_i o[s->v_i]). Indeed, although the rule might be valid from an interchange viewpoint, applying it in a context where objecto has no value for attributes is applying it outside the domain where it is meaningful, and the specification of the context where an otherwise valid RIF-PRD rule is validly applicable is out of the scope of RIF-PRD.

The components of the states of a production rule system seen as a transition system can now be defined more precisely. To avoid confusion between the states of the fact base and the states of the transition system, the latter will be calledproduction rule system states.

Definition (Production rule system state). Aproduction rule system state (or, simply, asystem state) is either asystem cycle state or asystem transitional state. Every production rule system state,s, cycle or transitional, is characterized by

• a state of the fact base,facts(s);
• ifs is not the current state, an ordered set of rule instances,picked(s), defined as follows:
  • ifs is a system cycle state,picked(s) is the ordered set of rule instances picked by the conflict resolution strategy, among the set of all the rule instances that matchedfacts(s);
  • ifs is a system transitional state,picked(s) is the empty set;
• ifs is not the initial state, a previous system state,previous(s), defined as follows: given a system cycle state,s_c, and given the sequence of system transitional states,s₁,...,s_n,n ≥ 0, such that the execution of the first ground atomic action inaction(picked(s_c)) transitioned the system froms_c tos₁ and ... and then-th ground atomic action inaction(picked(s_c)) transitioned the system froms_n-1 tos_n, thenprevious(s) = s_n if and only if the(n+1)-th ground atomic action inaction(picked(s_c)) transitioned the system froms_n tos.  ☐

In the following, we will writeprevious(s) = NIL to denote that a system states is the initial state.

Definition (Conflict set). Given a rule set,RS ⊆ R, and a system state,s, theconflict set determined byRS ins is the set,conflictSet(RS, s) of all the different instances of the rules inRS that match the state of the fact base,facts(s) ∈ W.   ☐

The rule instances that are in the conflict set are, sometimes, said to befireable.

In each non-final cycle state,s, of a production rule system, a subset,picked(s), of the rule instances in the conflict set is selected and ordered; their action parts are instantiated, and the resulting sequence of ground atomic actions is executed. This is sometimes called:firing the selected instances.

4.2.4 Operational semantics of a production rule system

All the elements that are required to define a production rule system as alabeled terminal transition system have now been defined.

Definition (RIF-PRD Production Rule System). ARIF-PRD production rule system is defined as a labeled terminal transition systemPRS = {S, A, →_PRS, T}, where :

• S is a set of system states, called thesystem cycle states;
• A is a set of transition labels, where each transition label is a sequence of ground RIF-PRD atomic actions;
• The transition relation →_PRS ⊆S ×A ×S, is defined as follows:
  ∀ (s,a,s') ∈S ×A ×S, (s,a,s') ∈ →_PRS if and only if all of the following hold:
  1. (facts(s), a, facts(s')) ∈ →^*_RIF-PRD, where →^*_RIF-PRD denotes the transitive closure of the transition relation →_RIF-PRD that is determined by the specification of the semantics of the atomic actions supported by RIF-PRD;
  2. a = actions(picked(s));
• T ⊆ S, a set of final system states.   ☐

Intuitively, the first condition in the definition of the transition relation →_PRS states that a production rule system can transition from one system cycle state to another only if the state of facts in the latter system cycle state can be reached from the state of facts in the former by performing a sequence of ground atomic actions supported by RIF-PRD, according to thesemantics of the atomic actions.

The second condition states that the allowed paths out of any given system cycle state are determined only by how rule instances arepicked for execution, from the conflict set, by the conflict resolution strategy.

The execution of a rule set,RS, in a state,w, of a fact base, may result in zero, one or more final state of the fact base,w' = facts(s'), depending on the conflict resolution strategy and the set of final system states.

Therefore, the behavior of aRIF-PRD production rule system also depends on:

1. the conflict resolution strategy, that is, how rule instances are precisely selected for execution from the rule instances that match a given state of the fact base, and
2. how the setT of final system states is precisely defined.

4.2.5 Conflict resolution

The process of selecting one or morerule instances from theconflict set for firing is often called:conflict resolution.

In RIF-PRD the conflict resolution algorithm (or conflict resolutionstrategy) 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 RIF-PRD specification, a single conflict resolution strategy is specified normatively: it is denoted by the keywordrif:forwardChaining (a constant of typerif:IRI), because it accounts for a common conflict resolution strategy used in most forward-chaining production rule systems. That conflict resolution strategy selects a single rule instance for execution.

Future versions of the RIF-PRD specification may specify normatively the intended conflict resolution strategies to be attached to additional keywords. In addition, RIF-PRD documents may include non-standard keywords: it is the responsibility of the producers and consumers of such document to agree on the intended conflict resolution strategies that are denoted by such non-standard keywords. Future or non-standard conflict resolution strategies may select an ordered set of rule instances for execution, instead of a single one: the functionspicked andactions, in the previous section, have been defined to take this case into account.

Conflict resolution strategy:rif:forwardChaining

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):

• Refraction. The essential idea ofrefraction is that a given instance of a rule must not be fired more than once as long as the reasons that made it eligible for firing hold. In other terms, if an instance has been fired in a given state of the system, it is no longer eligible for firing as long as it satisfies the states of facts associated to all the subsequent system states (cycle and transitional);
• Priority. The rule instances are ordered by priority of the instantiated rules, and only the rule instances with the highest priority are eligible for firing;
• Recency. the rule instances are ordered by the number of consecutive system states, cycle and transitional, in which they have been in the conflict set, and only the most recently fireable ones are eligible for firing. Note that the recency rule, used alone, results in depth-first processing.

Many existing production rule systems implement also some kind offire the most specific rule first strategy, in combination with the above. However, whereas they agree on the definition of refraction and the priority or recency ordering, existing production rule systems vary widely on the precise definition of the specificity ordering. As a consequence, rule instance specificity was not included in the basic conflict resolution strategy that RIF-PRD specifies normatively.

The RIF-PRD keywordrif:forwardChaining denotes the common conflict resolution strategy that can be summarized as follows:given a conflict set

1. Refraction is applied to the conflict set, that is, all the refracted rule instances are removed from further consideration;
2. The remaining rule instances are ordered by decreasing priority, and only the rule instances with the highest priority are kept for further consideration;
3. The remaining rule instances are ordered by decreasing recency, and only the most recent rule instances are kept for further consideration;
4. Any remaining tie is broken is some way, and a single rule instance is kept for firing.

As specified earlier,picked(s) denotes the ordered list of the rule instances that were picked in a system state,s. Under the conflict resolution strategy denoted byrif:forwardChaining, for any given system cycle state,s, the list denoted bypicked(s) contains a single rule instance. By definition, ifs is asystem transitional state,picked(s) is the empty set.

Given a system state,s, a rule set,RS, and a rule instance,ri ∈conflictSet(RS, s), letrecency(ri, s) denote the number of system states befores, in whichri has been continuously a matching instance: ifs is the current system state,recency(ri, s) provides a measure of the recency of the rule instanceri.recency(ri, s) is specified recursively as follows:

• ifprevious(s) = NIL, thenrecency(ri, s) = 1;
• else ifri ∈ conflictSet(RS, previous(s)), thenrecency(ri, s) = 1 + recency(ri, previous(s));
• else,recency(ri, s) = 1.

In the same way, given a rule instance,ri, and a system state,s, letlastPicked(ri, s) denote the number of system states befores, sinceri has been last fired.lastPicked(ri, s) is specified recursively as follows:

• ifprevious(s) = NIL, thenlastPicked(ri, s) = 1;
• else ifri ∈ picked(previous(s)), thenlastPicked(ri, s) = 1;
• else,lastPicked(ri, s) = 1 + lastPicked(ri, previous(s)).

Given a rule instance,ri, letpriority(ri) denote the priority that is associated torule(ri), or zero, if no priority is associated torule(ri). Ifrule(ri) is inside nestedGroups,priority(ri) denotes the priority that is associated with the innermostGroup to which a priority is explicitly associated, or zero.

Document (  Prefix( ex2 <http://example.com/2009/prd3#> )  (* ex2:ExampleRuleSet *)  Group (    (* ex2:Rule_1 *) Forall ...    (* ex2:HighPriorityRules *)    Group 10 (      (* ex2:Rule_2 *) Forall ...      (* ex2:Rule_3 *)       Group 9 (Forall ... ) )    (* ex2:NoPriorityRules *)    Group (      (* ex2:Rule_4 *) Forall ...      (* ex2:Rule_5 *) Forall ... ) )

Given a set of rule instances,cs, the conflict resolution strategyrif:forwardChaining can now be described with the help of four rules, whereri andri' are rule instances:

1. Refraction rule: ifri ∈ cs andlastPicked(ri, s) < recency(ri, s), thencs = cs - ri;
2. Priority rule: ifri ∈ cs andri' ∈ cs andpriority(ri) < priority(ri'), thencs = cs - ri;
3. Recency rule: ifri ∈ cs andri' ∈ cs andrecency(ri, s) > recency(ri', s), thencs = cs - ri;
4. Tie-break rule: ifri ∈ cs, thencs = {ri}. RIF-PRD does not specify the tie-break rule more precisely: how a single instance is selected from the remaining set is implementation specific.

Therefraction rule removes the instances that have been in the conflict set in all the system states at least since they were last fired; thepriority rule removes the instances such that there is at least one instance with a higher priority; therecency rule removes the instances such that there is at least one instance that is more recent; and thetie-break rule keeps one rule from the set.

To select the singleton rule instance,picked(s), to be fired in a system state,s, given a rule set,RS, the conflict resolution strategy denoted by the keywordrif:forwardChaining consists of the following sequence of steps:

1. initializepicked(s) with the conflict set, that a rule setRS determines in a system states:picked(s) = conflictSet(RS, s);
2. apply therefraction rule to all the rule instances inpicked(s);
3. then apply thepriority rule to all the remaining instances inpicked(s);
4. then apply therecency rule to all the remaining instances inpicked(s);
5. then apply thetie-break rule to the remaing instance inpicked(s);
6. returnpicked(s).

4.2.6 Halting test

By default, a system state is final, given a rule set,RS, and a conflict resolution strategy,LS, if there is no rule instance available for firing after application of the conflict resolution strategy.

For the conflict resolution strategy identified by the RIF-PRD keywordrif:forwardChaining, a system state,s, isfinal given a rule set,RS if and only if the remaining conflict set is empty after application of therefraction rule to all the rule instances inconflictSet(RS, s). In particular, all the system states,s, such thatconflictSet(RS, s) = ∅ are final.

5 Document and imports

This section specifies the structure of a RIF-PRD document and its semantics when it includes import directives.

5.1 Abstract syntax

In addition to the language of conditions, actions, and rules, RIF-PRD provides a construct to denote the import of a RIF or non-RIF document. Import enables the modular interchange of RIF documents, and the interchange of combinations of multiple RIF and non-RIF documents.

5.1.1 Import directive

Definition (Import directive). Animport directive consists of:

• an IRI, thelocator, that identifies and locates the document to be imported, and
• an optional second IRI that identifies theprofile of the import.   ☐

RIF-PRD gives meaning to one-argument import directives only. Such directives can be used to import other RIF-PRD and RIF-Core documents. Two-argument import directives are provided to enable import of other types of documents, and their semantics is covered by other specifications. For example, the syntax and semantics of the import of RDF and OWL documents, and their combination with a RIF document, is specified in [RIF-RDF-OWL].

5.1.2 RIF-PRD document

Definition (RIF-PRD document). A RIF-PRDdocument consists of zero or more import directives, and zero or onegroup.   ☐

Definition (Imported document). A document is said to bedirectly imported by a RIF document,D, if and only if it is identified by the locator IRI in an import directive inD. A document is said to beimported by a RIF document,D, if it is directly imported byD, or if it is imported, directly or not, by a RIF document that is directly imported byD.   ☐

Definition (Document safeness). (from [RIF-Core]) A document issafe if and only if it

• it contains a safe group, or no group at all,
• and all the documents that it imports are safe.   ☐

5.1.3 Well-formed documents

Definition (Conflict resolution strategy associated with a document). Aconflict resolution strategy is associated with a RIF-PRD document,D, if and only if

• it is explicitly or implicitly attached to the top-level group inD, or
• it is explicitly or implicitly attached to the top-level group in a RIF-PRD document that is imported byD.   ☐

Definition (Well-formed RIF-PRD document). A RIF-PRD document,D, iswell-formed if and only if it satisfies all the following conditions:

• the locator IRI provided by all the import directives inD, if any, identify well-formed RIF-PRD documents,
• D contains a well-formed group or no group at all,
• D has only one associated conflict resolution strategy (that is, all the conflict resolution strategies that can be associated with it are the same), and
• every non-rif:local constant that occurs inD or in one of the documents imported byD, occurs in the same context inD and in all the documents imported byD.   ☐

The last condition in the above definition makes the intent behind therif:local constants clear: occurrences of such constants in different documents can be interpreted differently even if they have the same name. Therefore, each document can choose the names for therif:local constants freely and without regard to the names of such constants used in the imported documents.

5.2 Operational semantics of RIF-PRD documents

The semantics of awell-formed RIF-PRD document that contains no import directive is the semantics of the rule set that is represented by the top-level group in the document, evaluated with theconflict resolution strategy that is associated to the document, and the default halting test, as specified above, insection Halting test.

The semantics of awell-formed RIF-PRD document,D, that imports thewell-formed RIF-PRD documentsD₁, ...,D_n,n ≥ 1, is the semantics of the rule set that is the union of the rule sets represented by the top-level groups inD and the imported documents, with therif:local constants renamed to ensure that the same symbol does not occur in two different component rule sets, and evaluated with theconflict resolution strategy that is associated to the document, and thedefault halting test.

6 Built-in functions, predicates and actions

In addition to externally specified functions and predicates, and in particular, in addition to the functions and predicates built-ins defined in [RIF-DTB], RIF-PRD supports externally specified actions, and defines action built-ins.

The syntax and semantics of action built-ins are specified like for the other buit-ins, as described in the section Syntax and Semantics of Built-ins in [RIF-DTB]. However, their formal semantics is trivial: action built-ins behave like predicates that are always true, since action built-ins, in RIF-PRD, MUST NOT affect the semantics of the rules.

Although they must not affect the semantics of the rules, action built-ins may have other side effects.

RIF action built-ins are defined in the namespace:http://www.w3.org/2007/rif-builtin-action#. In this document, we will use the prefix:act: to denote the RIF action built-ins namespace.

6.1 Built-in actions

6.1.1 act:print

• Schema:

  (?arg; act:print(?arg))

• Domains:

  The value space of the single argument isxs:string.

• Mapping:

  Whens belongs to its domain,I_truth οI_External( ?arg; act:print(?arg) )(s) =t.

  If an argument value is outside of its domain, the truth value of the function is left unspecified.

• Side effects:

  The value of the argument MUST be printed to an output stream, to be determined by the user implementation.

7 Conformance and interoperability

7.1 Semantics-preserving transformations

RIF-PRD conformance is described partially in terms of semantics-preserving transformations.

The intuitive idea is that, for any initial state of facts, the conformant consumer of a conformant RIF-PRD document must reach at least one of the final state of facts intended by the conformant producer of the document, and that it must never reach any final state of facts that was not intended by the producer. That is:

• a conformant RIF-PRD producer,P, must translate any rule set from its own rule language,L_P, into RIF-PRD, in such a way that, for any possible initial state of the fact base, the RIF-PRD translation of the rule set must never produce, according to the semantics specified in this document, a final state of the fact base that would not be a possible result of the execution of the rule set according to the semantics ofL_P (where the state of the facts base are meant to be represented inL_P or in RIF-PRD as appropriate), and
• a conformant RIF-PRD consumer,C, must translate any rule set from a RIF-PRD document into a rule set in its own language,L_C, in such a way that, for any possible initial state of the fact base, the translation inL_C of the rule set, must never produce, according to the semantics ofL_C, a final state of the fact base that would not be a possible result of the execution of the rule set according to the semantics specified in this document (where the state of the facts base are meant to be represented inL_C or in RIF-PRD as appropriate).

Let Τ be a set of datatypes and symbol spaces that includes the datatypes specified in [RIF-DTB] and the symbol spacesrif:iri andrif:local. Suppose also that Ε is a set of external predicates and functions that includes the built-ins listed in [RIF-DTB] and in thesection Built-in actions. We say that a ruler is aRIF-PRD_Τ,Ε rule if and only if

• r is awell-formed RIF-PRD rule,
• all the datatypes and symbol spaces used inr are in Τ, and
• all the externally defined functions and predicates used inr are in Ε.

Suppose, further, that C is a set of conflict resolution strategies that includes the one specified insection Conflict resolution, and that H is a set of halting tests that includes the one specified insection Halting test: we say that a rule set ,R, is aRIF-PRD_Τ,Ε,C,H rule set if and only if

• R contains onlyRIF-PRD_Τ,Ε rules,
• the conflict resolution strategy that is associated toR is in C, and
• the halting test that is associated toR is in H.

Given aRIF-PRD_Τ,Ε,C,H rule set,R, an initial state of the fact base,w, a conflict resolution strategyc ∈ C and a halting testh ∈ H, letF_R,w,c,h denote the set of all the sets,f, of RIF-PRD ground atomic formulas that represent final states of the fact base,w', according to theoperational semantics of a RIF-PRD production rule system, that is:f ∈ F_R,w,c,h if and only if there is a state,s', of the system, such thatEval(R, c, h, w) →^*_PRS s' andw' = facts(s') andf is a representation ofw'.

In addition, given a rule language,L, a rule set expressed inL,R_L, a conflict resolution strategy,c, a halting test,h, and an initial state of the fact base,w, letF_{L,RL, c, h, w} denote the set of all the formulas inL that represent a final state of the fact base that anL processor can possibly reach.

Definition (Semantics preserving mapping).

• A mapping from aRIF-PRD_Τ,Ε,C,H,R, to a rule set,R_L, expressed in a languageL, issemantics-preserving if and only if, for any initial state of the fact base,w, conflict resolution strategy,c, and halting test,h, it also maps eachL formula inF_{L,RL, c, h, w} onto a set of RIF-PRD ground formulas inF_R,w,c,h;
• A mapping from a rule set,R_L, expressed in a languageL, to aRIF-PRD_Τ,Ε,C,H,R, issemantics-preserving if an only if, for any initial state of the fact base,w, conflict resolution strategy,c, and halting test,h, it also maps each set of ground RIF-PRD atomic formulas inF_R,w,c,h onto anL formula inF_{L,RL, c, h, w}.   ☐

7.2 Conformance Clauses

Definition (RIF-PRD conformance).

• A RIF processor is aconformantRIF-PRD_Τ,Ε,C,Hconsumer iff it implements asemantics-preserving mapping from the set of allsafeRIF-PRD_Τ,Ε,C,H rule sets to the languageL of the processor;
• A RIF processor is aconformantRIF-PRD_Τ,Ε,C,Hproducer iff it implements asemantics-preserving mapping from a subset of the languageL of the processor to a set ofsafeRIF-PRD_Τ,Ε,C,H rule sets;
• Anadmissible document is an XML document that conforms to all the syntactic constraints of RIF-PRD, including ones that cannot be checked by an XML Schema validator;
• Aconformant RIF-PRD consumer is a conformant RIF-PRD_Τ,Ε,C,H consumer in which Τ consists only of the symbol spaces and datatypes, Ε consists only of the externally defined functions and predicates, C consists only of the conflict resolution strategies, and H consists only of halting tests that are required by RIF-PRD. The required symbol spaces arerif:iri andrif:local, and the datatypes and externally defined terms (built-ins) are the ones specified in [RIF-DTB] and in thesection Built-in actions. The required conflict resolution strategy is the one that is identified asrif:forwardChaining, as specified insection Conflict resolution; and the required halting test is the one specified insection Halting test. A conformant RIF-PRD consumer must reject any document containing features it does not support.
• Aconformant RIF-PRD producer is a conformant RIF-PRD_Τ,Ε,C,H producer which produces documents that include only the symbol spaces, datatypes, externals, conflict resolution strategies and halting tests that are required by RIF-PRD.   ☐

In addition, conformant RIF-PRD producers and consumers SHOULD preserve annotations.

7.3 Interoperability

[RIF-Core] is specified as a specialization of RIF-PRD: all valid [RIF-Core] documents are valid RIF-PRD documents and must be accepted by any conformant RIF-PRD consumer.

Conversely, it is desirable that any valid RIF-PRD document that uses only abstract syntax that is defined in [RIF-Core] be a valid [RIF-Core] document as well. For some abstract constructs that are defined in both RIF-Core and RIF-PRD, RIF-PRD defines alternative XML syntax that is not valid RIF-Core XML syntax. For example, anaction block that contains noaction variable declaration and onlyassert atomic actions can be expressed in RIF-PRD using the XML elementsDo orAnd. Only the latter option is valid RIF-Core XML syntax.

To maximize interoperability with RIF-Core and its non-RIF-PRD extensions, a conformant RIF-PRD consumer SHOULD produce valid [RIF-Core] documents whenever possible. Specifically, a conformant RIF-PRD producer SHOULD use only valid [RIF-Core] XML syntax to serialize a rule set that satisfies all of the following:

• the conflict resolution strategy is effectively equivalent to the stratagy that RIF-PRD identifies by the IRIrif:forwardChaining,
• nocondition formula contains a negation, in any rule in the rule set,
• no rule in the rule set has anaction block that contains anaction variable declaration, and
• in all the rules in the rule set, theaction block contains onlyassert atomic actions.

When processing a rule set that satisfies all the above conditions, a RIF-PRD producer is guaranteed to produce a valid [RIF-Core] XML document by applying the following rules recursively:

1. Remove redundant information. Thebehavior role element and all its sub-elements should be omitted in the RIF-PRD XML document;
2. Remove nested rule variable declarations. If therule inside arule with variable delcaration,r₁, is also arule with variable declaration,r₂, all the rule variable delarations and all the patterns that occur inr₁ should be added to the rule variable declarations and the patterns that occur inr₂, and, after the transform,r₁ should be replaced byr₂, in the rule set. If the names of some variables declared inr₁ are the same as the names of some variables declared inr₂, the former names must be changed prior to the transform.;
3. Remove patterns. If a pattern occurs in arule with variable declaration,r₁:
   • if therule insider₁ is aunconditional action block,r₂,r₂ should be transformed into aconditional action block, where the condition is the pattern, and the pattern should be removed fromr₁,
   • if therule insider₁ is aconditional action block,r₂, the formula that represents the condition inr₂ should be replaced by the conjunction of that formula and the formula that represents the pattern, and the pattern should be removed fromr₁;
4. Convert action blocks. The action block, in each rule, should be replaced by a conjunction, and, inside the conjunction, eachassert action should be replaced by its target atomic formula.

R: Forall ?customer such that (And( ?customer # ex1:Customer                                    ?customer[status->"Silver"] ) )      (Forall ?shoppingCart such that (?customer[shoppingCart->?shoppingCart])         (If Exists ?value (And( ?shoppingCart[value->?value]                                 pred:numeric-greater-than-or-equal(?value 2000))          Then Do( Assert(ex1:Foo(?customer))                   Assert(ex1:Bar(?shoppingCart)) ) ) )

<Forall>   <declare><Var>?customer</Var></declare>   <declare><Var>?shoppingCart</Var></declare>   <formula>      <Implies>         <if>            <And>               <formula>   <!-- first pattern -->                  <And>                     <formula><Member> ... </Member></formula>                     <formula><Frame> ... </Frame></formula>                  </And>               </formula>               <formula>   <!-- second pattern -->                  <Member> ... </Member>               </formula>               <formula>   <!-- original existential condition -->                  ...               </formula>           </And>        </if>        <then>           <And>              <formula>   <!-- serialization of ex1:Foo(?customer) -->                 ...              </formula>              <formula>   <!-- serialization of ex1:Bar(?shoppingCart) -->                 ...              </formula>        </then>     </Implies>  </formula></Forall>

8 XML Syntax

This section specifies the concrete XML syntax of RIF-PRD. The concrete syntax is derived from the abstract syntax defined in sections 2.1, 3.1 and 4.1 using simple mappings. The semantics of the concrete syntax is the same as the semantics of the abstract syntax.

8.1 Notational conventions

8.1.1 Namespaces

Throughout this document, thexsd: prefix stands for the XML Schema namespace URIhttp://www.w3.org/2001/XMLSchema#, therdf: prefix stands forhttp://www.w3.org/1999/02/22-rdf-syntax-ns#, andrif: stands for the URI of the RIF namespace,http://www.w3.org/2007/rif#.

Syntax such asxsd:string should be understood as a compact URI [CURIE] -- a macro that expands to a concatenation of the character sequence denoted by the prefixxsd and the stringstring. The compact URI notation is used for brevity only, andxsd:string should be understood, in this document, as an abbreviation forhttp://www.w3.org/2001/XMLSchema#string.

8.1.2 BNF pseudo-schemas

The XML syntax of RIF-PRD is specified for each component as a pseudo-schema, as part of the description of the component. The pseudo-schemas use BNF-style 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 pseudo-schema -->    <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>

8.1.3 Syntactic components

Three kinds of syntactic components are used to specify RIF-PRD:

• Abstract classes are defined only by their subclasses: they are not visible in the XML markup and can be thought of as extension points. In this document, abstract constructs will be denoted with all-uppercase names;
• Concrete classes have a concrete definition, and they are associated with specific XML markup. In this document, concrete constructs will be denoted with CamelCase names with leading capital letter;
• Properties, orroles, define how two classes relate to each other. They have concrete definitions and are associated with specific XML markup. In this document, properties will be denoted with camelCase names with leading smallcase letter.

8.2 Relative IRIs and XML base

Relative IRIs are allowed in RIF-PRD XML syntax, anywhere IRIs are allowed, including constant types, symbol spaces, location, and profile. The attributexml:base [XML-Base] is used to make them absolute.

8.3 Conditions

This section specifies the XML constructs that are used in RIF-PRD to serializecondition formulas.

8.3.1 TERM

TheTERM class of constructs is used to serializeterms, be theysimple terms, that is, constants and variables; lists; orpositional terms, the latter being, per the definition of awell-formed formula, representations of externally defined functions.

As an abstract class,TERM is not associated with specific XML markup in RIF-PRD instance documents.

    [Const |Var |List |External ]

8.3.1.1 Const

In RIF, theConst element is used to serialize aconstant.

TheConst element has a requiredtype attribute and an optionalxml:lang attribute:

• The value of thetype attribute is the identifier of theConst symbol space. It must be arif:iri;
• Thexml:lang attribute, as defined by2.12 Language Identification ofXML 1.0 or its successor specifications in the W3C recommendation track, is optionally used to identify the language for the presentation of theConst to the user. It is allowed only in association with constants of the typerdf:plainLiteral. A compliant implementation MUST ignore thexml:lang attribute if the type of theConst is notrdf:plainLiteral.

The content of theConst element is the constant's literal, which can be any Unicode character string.

    <Const type=rif:iri [xml:lang=xsd:language]? >Any Unicode string    </Const>

<Const type="xsd:integer">2000</Const>

<Const type="rif:iri">   http://example.com/2009/prd2#Customer</Const>

8.3.1.2 Var

In RIF, theVar element is used to serialize avariable.

The content of theVar element is the variable's name, serialized as anNCName.

    <Var>xsd:NCName </Var>

8.3.1.3 List

In RIF, theList element is used to serialize alist.

TheList element contains an optionalitems element, that contains one or moreTERMs (without variables) that serialize the elements of the list. The order of the sub-elements is significant and MUST be preserved. This is emphasized by the fixed value"yes" of the mandatory attributeordered in theitems element.

    <List>      <items ordered="yes">GROUNDTERM+ </items>?    </List>

<List>  <items ordered="yes">    <Const type="xsd:string> New </Const>    <Const type="xsd:string> Bronze </Const>    <Const type="xsd:string> Silver </Const>    <Const type="xsd:string> Gold </Const>  </items></List>

<List></List>

8.3.1.4 External

As aTERM, theExternal element is used to serialize apositional term. In RIF-PRD, a positional term represents always a call to an externally defined function, e.g. a built-in, a user-defined function, a query to an external data source, etc.

TheExternal element contains onecontent element, which in turn contains oneExpr element that contains oneop element, followed zero or oneargs element:

• TheExternal and thecontent elements ensure compatibility with the RIF Basic Logic Dialect [RIF-BLD] that allows non-evaluated (that is, logic) functions to be serialized using anExpr element alone;
• The content of theop element must be aConst. When theExternal is aTERM, the content of theop element serializes a constant symbol of typerif:iri that must uniquely identify the externally defined function to be applied to theargs TERMs;
• The optionalargs element contains one or more constructs from theTERM abstract class. Theargs element is used to serialize the arguments of apositional term. The order of theargs sub-elements is, therefore, significant and MUST be preserved. This is emphasized by the required value"yes" of the attributeordered.

    <External>       <content>          <Expr>             <op>Const </op>             <args ordered="yes">TERM+ </args>?          </Expr>       </content>    </External>

<External>   <content>      <Expr>             <op> <Const type="rif:iri"> http://www.w3.org/2007/rif-builtin-function#numeric-multiply </Const> </op>         <args ordered="yes">             <Var> ?value </Var>            <Const type="xsd:decimal"> 0.9 </Const>         </args>      </Expr>   </content></External>

8.3.2 ATOMIC

TheATOMIC class is used to serializeatomic formulas: positional atoms, equality, membership and subclass atomic formulas, frame atomic formulas and externally defined atomic formulas.

As an abstract class,ATOMIC is not associated with specific XML markup in RIF-PRD instance documents.

    [Atom |Equal |Member |Subclass |Frame |External ]

8.3.2.1 Atom

In RIF, theAtom element is used to serialize apositional atomic formula.

TheAtom element contains oneop element, followed by zero or oneargs element:

• The content of theop element must be aConst. It serializes the predicate symbol (the name of a relation);
• The optionalargs element contains one or more constructs from theTERM abstract class. Theargs element is used to serialize the arguments of apositional atomic formula. The order of thearg's sub-elements is, therefore, significant and MUST be preserved. This is emphasized by the required value"yes" of the attributeordered.

    <Atom>       <op>Const </op>       <args ordered="yes">TERM+ </args>?    </Atom>

<Atom>   <op>      <Const type="rif:iri">         http://example.com/2009/prd2#gold      </Const>   </op>   <args ordered="yes">      <Var> ?customer </Var>   </args></Atom>

8.3.2.2 Equal

In RIF, theEqual element is used to serializeequality atomic formulas.

TheEqual element must contain oneleft sub-element and oneright sub-element. The content of theleft andright elements must be a construct from theTERM abstract class, that serialize the terms of the equality. The order of the sub-elements is not significant.

    <Equal>       <left>TERM </left>       <right>TERM </right>    </Equal>

8.3.2.3 Member

In RIF, theMember element is used to serializemembership atomic formulas.

TheMember element contains two required sub-elements:

• theinstance elements must be a construct from theTERM abstract class that serializes the reference to the object;
• theclass element must be a construct from theTERM abstract class that serializes the reference to the class.

    <Member>       <instance>TERM </instance>       <class>TERM </class>    </Member>

<Member>   <instance> <Var> ?customer </Var> </instance>   <class>      <Const type="rif:iri">         http://example.com/2009/prd2#Customer      </Const>   </class></Member>

8.3.2.4 Subclass

In RIF, theSubclass element is used to serializesubclass atomic formulas.

TheSubclass element contains two required sub-elements:

• thesub element must be a construct from theTERM abstract class that serializes the reference to the sub-class;
• thesuper elements must be a construct from theTERM abstract class that serializes the reference to the super-class.

    <Subclass>       <sub>TERM </sub>       <super>TERM </super>    </Subclass>

8.3.2.5 Frame

In RIF, theFrame element is used to serializeframe atomic formulas.

Accordingly, aFrame element must contain:

• anobject element, that contains an element of theTERM abstract class that serializes the reference to the frame's object;
• zero to manyslot elements, each serializing an attribute-value pair as a pair of elements of theTERM abstract class, the first one that serializes the name of the attribute (or property); the second that serializes the attribute's value. The order of theslot's sub-elements is significant and MUST be preserved. This is emphasized by the required value"yes" of the required attributeordered.

    <Frame>       <object>TERM </object>       <slot ordered="yes">TERMTERM </slot>*    </Frame>

<Frame>   <object> <Var> ?customer </Var> </object>   <slot ordered="yes">       <Const type="rif:iri">         http://example.com/2009/prd2#status      </Const>      <Const type="xsd:string> Gold </Const>   </slot></Frame>

8.3.2.6 External

In RIF-PRD, theExternal element is also used to serialize anexternally defined atomic formula, in addition toserializing externally defined functions.

When it is anATOMIC (as opposed to aTERM; that is, in particular, when it appears in a place where anATOMIC is expected, and not aTERM), theExternal element contains onecontent element that contains oneAtom element. TheAtom element serializes theexternally defined atom properly said.

TheopConst in theAtom element must be a symbol of typerif:iri that must uniquely identify the externally defined predicate to be applied to theargs TERMs.

    <External>       <content>Atom       </content>    </External>

<External>   <content>      <Atom>             <op> <Const type="rif:iri"> http://www.w3.org/2007/rif-builtin-predicate#numeric-greater-than-or-equal </Const> </op>         <args ordered="yes">            <Var> ?value </Var>            <Const type="xsd:integer"> 2000 </Const>         </args>      </Atom>   </content></External>

8.3.3 FORMULA

TheFORMULA class is used to serializecondition formulas, that is, atomic formulas, conjunctions, disjunctions, negations and existentials.

As an abstract class,FORMULA is not associated with specific XML markup in RIF-PRD instance documents.

    [ATOMIC |And |Or |INeg |Exists ]

8.3.3.1 ATOMIC

Anatomic formula is serialized using a singleATOMIC statement. See specification ofATOMIC, above.

8.3.3.2 And

Aconjunction is serialized using theAnd element.

TheAnd element contains zero or moreformula sub-elements, each containing an element of theFORMULA group, that serializes one of the conjuncts.

    <And>       <formula>FORMULA </formula>*    </And>

8.3.3.3 Or

Adisjunction is serialized using theOr element.

TheOr element contains zero or moreformula sub-elements, each containing an element of theFORMULA group, that serializes one of the disjuncts.

    <Or>       <formula>FORMULA </formula>*    </Or>

8.3.3.4 INeg

The kind ofnegation that is used in RIF-PRD is serialized using theINeg element.

TheINeg element contains exactly oneformula sub-element. Theformula element contains an element of theFORMULA group, that serializes the negated statement.

    <INeg>       <formula>FORMULA </formula>    </INeg>

8.3.3.5 Exists

Anexistentially quantified formula is serialized using theExists element.

TheExists element contains:

• one or moredeclare sub-elements, each containing oneVar element that serializes one of the existentially quantified variables;
• exactly one requiredformula sub-element that contains an element from theFORMULA abstract class, that serializes the formula in the scope of the quantifier.

    <Exists>       <declare>Var </declare>+       <formula>FORMULA </formula>    </Exists>

<Exists>   <declare> <Var> ?value </Var> </declare>   <formula>      <And>         <Frame>            <object> <Var> ?shoppingCart </Var> </object>            <slot ordered="yes">                <Const type="rif:iri">                  http://example.com/2009/prd2#value               </Const>               <Var> ?value </Var>            </slot>         </Frame>         <External>            <content>               <Atom>                      <op> <Const type="rif:iri"> http://www.w3.org/2007/rif-builtin-predicate#numeric-greater-than-or-equal </Const> </op>                  <args ordered="yes">                     <Var> ?value </Var>                     <Const type="xsd:integer"> 2000 </Const>                  </args>               </Atom>            </content>         </External>      </And>   </formula></Exists>

8.4 Actions

This section specifies the XML syntax that is used to serialize the action part of a rule supported by RIF-PRD.

8.4.1 ACTION

TheACTION class of elements is used to serialize theactions:assert,retract,modify andexecute.

As an abstract class,ACTION is not associated with specific XML markup in RIF-PRD instance documents.

    [Assert |Retract |Modify |Execute ]

8.4.1.1 Assert

Anatomic assertion action is serialized using theAssert element.

TheAssert element has onetarget sub-element that contains anAtom, aFrame or aMember element that represents the target of the action.

    <Assert>         <target> [Atom |Frame |Member ] </target>    </Assert>

8.4.1.2 Retract

TheRetract construct is used to serializeretract atomic actions.

TheRetract element has onetarget sub-element that contains anAtom, aFrame, aTERM, or a pair ofTERM constructs that represent the target of the action. Thetarget element has an optional attribute,ordered, that MUST be present when the element contains twoTERM sub-elements: the order of the sub-elements is significant and MUST be preserved. This is emphasized by the required value "yes" of the attribute.

    <Retract>       <target ordered="yes"?>           [Atom |Frame |TERM |TERM TERM ]       </target>    </Retract>

8.4.1.3 Modify

Acompound modification is serialized using theModify element.

TheModify element has onetarget sub-element that contains oneFrame that represents the target of the action.

    <Modify>         <target>Frame </target>    </Modify>

<Modify>   <target>      <Frame>         <object>            <Var> ?customer </Var>         </object>         <slot ordered="yes">            <Const type="rif:iri"> http://example.com/2009/prd2#status </Const>            <Const type="xsd:string"> Gold </Const>         </slot>      </Frame>   </target></Modify>

<Retract>   <target ordered="yes">      <Var> ?customer </Var>      <Const type="rif:iri"> http://example.com/2009/prd2#status </Const>   </target></Retract><Assert>   <target>      <Frame>         <object>            <Var> ?customer </Var>         </object>         <slot ordered="yes">            <Const type="rif:iri"> http://example.com/2009/prd2#status </Const>            <Const type="xsd:string"> Gold </Const>         </slot>      </Frame>   </target></Assert>

8.4.1.4 Execute

Theexecution of an externally defined action is serialized using theExecute element.

TheExecute element has onetarget sub-element that contains anAtom, that represents the externally defined action to be executed.

TheopConst in theAtom element must be a symbol of typerif:iri that must uniquely identify theexternally defined action to be applied to theargs TERMs.

    <Execute>         <target>Atom </target>    </Execute>

<Execute>  <target>    <Atom>      <op>        <Constant type="rif:iri"> http://www.w3.org/2007/rif-builtin-action#print </Const>      </op>      <args ordered="yes">        <External>          <content>            <Expr>              <op>                <Constant type="rif:iri"> http://www.w3.org/2007/rif-builtin-function#concat </Const>              </op>              <args ordered="yes">                <Const type="xsd:string> New customer: </Const> ?customer              </args>            </Expr>          </content>        </External>      </args>    </Atom>  </target></Execute>

8.4.2 ACTION_BLOCK

TheACTION_BLOCK class of constructs is used to represent theconclusion, or action part, of a production rule serialized using RIF-PRD.

If action variables are declared in the action part of a rule, or if someactions are not assertions, the conclusion must be serialized as a fullaction block, using theDo element. However, simple action blocks that contain only one or more assert actions SHOULD be serialized like the conclusions of logic rules usingRIF-Core orRIF-BLD, that is, as a single assertedAtom orFrame, or as a conjunction of the asserted facts, using theAnd element.

In the latter case, to conform with thedefinition of an action block well-formedness, the formulas that serialize the individual conjuncts MUST be atomicAtoms and/orFrames.

As an abstract class,ACTION_BLOCK is not associated with specific XML markup in RIF-PRD instance documents.

    [Do |And |Atom |Frame ]

8.4.2.1 New

TheNew element is used to serialize the construct used to create a new frame identifer, in anaction variable declaration.

TheNew element is always empty.

    <New />

8.4.2.2 Do

Anaction block is serialized using theDo element.

ADo element contains:

• zero or moreactionVar sub-elements, each of them used to serialize oneaction variable declaration. Accordingly, anactionVar element must contain aVar sub-element, that serializes the declared variable; followed by the serialization of anaction variable binding, that assigns an initial value to the declared variable, that is: either aframe or the empty elementNew;
• oneactions sub-element that serializes the sequence of actions in the action block, and that contains, accordingly, a sequence of one or more sub-elements of theACTION class. The order of the actions is significant, and the order MUST be preserved, as emphasized by the requiredordered="yes" attribute.

    <Do>       <actionVar ordered="yes">Var          [New |Frame ]       </actionVar>*       <actions ordered="yes">ACTION+       </actions>    </Do>

<Do>   <actionVar ordered="yes">      <Var>?voucher</Var>      <New />   </actionVar>   <actions  ordered="yes">      <Assert>         <target>            <Member>               <instance><Var>?voucher</Var></instance>               <class>                  <Const type="rif:iri">http://example.com/2009/prd2#Voucher</Const>               </class>            </Member>         </target>      </Assert>      <Assert>         <target>            <Frame>               <object><Var>?voucher</Var></object>               <slot ordered="yes">                  <Const type="rif:iri">http://example.com/2009/prd2#value</Const>                  <Const type="xsd:integer">5</Const>               </slot>            </Frame>         </target>      </Assert>      <Assert>         <target>            <Frame>               <object><Var>?customer</Var></object>               <slot ordered="yes">                  <Const type="rif:iri">http://example.com/2009/prd2#voucher</Const>                  <Var>?voucher</Var>               </slot>            </Frame>         </target>      </Assert>   </actions></Do>

8.5 Rules and Groups

This section specifies the XML constructs that are used, in RIR-PRD, to serializerules andgroups.

8.5.1 RULE

In RIF-PRD, theRULE class of constructs is used to serializerules, 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 RIF-PRD instance documents.

    [Implies |Forall |ACTION_BLOCK ]

8.5.1.1 ACTION_BLOCK

Anunconditional action block is serialized, in RIF-PRD XML, using theACTION_BLOCK class of construct.

8.5.1.2 Implies

Conditional actions are serialized, in RIF-PRD, using the XML elementImplies.

TheImplies element contains anif sub-element and athen sub-element:

• the requiredif element contains an element from theFORMULA class of constructs, that serializes the condition of the rule;
• the requiredthen element contains one element from theACTION_BLOCK class of constructs, that serializes its conclusion.

    <Implies>       <if>FORMULA </if>       <then>ACTION_BLOCK </then>    </Implies>

8.5.1.3 Forall

TheForall construct is used, in RIF-PRD, to representrules with bound variables.

TheForall element contains:

• one or moredeclare sub-elements, each containing oneVar element that represents one of the declared rule variables;
• zero or morepattern sub-elements, each containing one element from theFORMULA group of constructs, that serializes onepattern;
• exactly oneformula sub-element that serializes the formula in the scope of the variables binding, and that contains an element of theRULE group.

    <Forall>       <declare>Var </declare>+       <pattern>FORMULA </pattern>*       <formula>RULE </formula>    </Forall>

<Forall>   <declare><Var>?customer</Var></declare>   <pattern>      <And>         <formula><Member> ... </Member></formula>         <formula><Frame> ... </Frame></formula>      </And>   </pattern>   <formula>      <Forall>         <declare><Var>?shoppingCart</Var></declare>         <pattern><Member> ... </Member></pattern>         <formula>            <Implies> ... </Implies>         </formula>      </Forall>   </formula></Forall>

8.5.2 Group

TheGroup construct is used to serialize agroup.

TheGroup element has zero or onebehavior sub-element and zero or moresentence sub-elements:

• thebehavior element contains
  • zero or oneConflictResolution sub-element that contains exactly one IRI. The IRI identifies the conflict resolution strategy that is associated with theGroup;
  • zero or onePriority sub-element that contains exactly one signed integer between -10,000 and 10,000. The integer associates a priority with theGroup's sentences;
• asentence element contains either aGroup element or an element of theRULE abstract class of constructs.

    <Group>       <behavior>          <ConflictResolution>xsd:anyURI </ConflictResolution>?          <Priority>-10,000 ≤ xsd:int ≤ 10,000 </Priority>?       </behavior>?       <sentence> [RULE |Group ] </sentence>*    </Group>

8.6 Document and directives

8.6.1 Import

TheImport directive is used to serialize the reference to an RDF graph, an OWL ontology or another RIF document to be combined with a RIF document. TheImport directive is inherited from [RIF-Core]. The abstract syntax and semantics of RDF graph and OWL ontology imports are specified in [RIF-RDF-OWL].

TheImport directive contains:

• exactly onelocation sub-element, that contains an IRI, that serializes the location of the RDF or OWL document to be combined with the RIF document;
• zero or oneprofile sub-element, that contains an IRI. The admitted values for that constant and their semantics are listed in the section Profiles of Imports, in [RIF-RDF-OWL].

    <Import>       <location>xsd:anyURI </location>       <profile>xsd:anyURI </profile>?    </Import>

8.6.2 Document

TheDocument is the root element of any RIF-PRD instance document.

TheDocument contains zero or moredirective sub-elements, each containing anImport directive, and zero or onepayload sub-element, that must contain aGroup element.

    <Document>       <directive>Import </directive>*       <payload>Group </payload>?    </Document>

The semantics of a document that imports RDF and/or OWL documents is specified in [RIF-RDF-OWL] and [RIF-BLD]. The semantics of a document that does not import other documents is the semantics of the rule set that is serialised by theGroup in thedocument'spayload sub-element, if any.

8.7 Constructs carrying no semantics

8.7.1 Annotation

Annotations can be associated with any concrete class element in RIF-PRD: those are the elements with a CamelCase tagname starting with an upper-case character:

    CLASSELT = [TERM |ATOMIC |FORMULA |ACTION |ACTION_BLOCK |New |RULE |Group |Document |Import ]

An identifier can be associated to any instance element of the abstractCLASSELT class of constructs, as an optionalid sub-element that MUST contain aConst of typerif:iri.

Annotations can be included in any instance of a concrete class element using themeta sub-element.

TheFrame construct is used to serialize annotations: the content of theFrame'sobject sub-element identifies the object to which the annotation is associated:, and theFrame'sslots represent the annotation properly said as property-value pairs.

If all the annotations are related to the same object, themeta element can contain a singleFrame sub-element. If annotations related to several different objects need be serialized, themeta role element can contain anAnd element with zero or moreformula sub-elements, each containing oneFrame element, that serializes the annotations relative to one identified object.

   <any concrete element in CLASSELT>       <id>Const </id>?       <meta>          [Frame             |            <And>               <formula>Frame </formula>*            </And>          ]       </meta>?other CLASSELT content    </any concrete element in CLASSELT>

Notice that the content of themeta sub-element of an instance of a RIF-PRD class element is not necessarily associated to that same instance element: only the content of theobject sub-element of theFrame that represents the annotations specifies what the annotations are about, not where it is included in the instance RIF document.

It is suggested to use Dublin Core, RDFS, and OWL properties for annotations, along the lines ofhttp://www.w3.org/TR/owl-ref/#Annotations -- specifically owl:versionInfo, rdfs:label, rdfs:comment, rdfs:seeAlso, rdfs:isDefinedBy, dc:creator, dc:description, dc:date, and foaf:maker.

<Document>  <payload>    <Group>      <id><Const type="rif:iri">http://example.com/2009/prd2#CheckoutRuleSet</Const></id>      <meta>        <Frame>          <object><Const type="rif:iri">http://example.com/2009/prd2#CheckoutRuleSet</Const></object>          <slot ordered="yes">            <Const type="rif:iri">http://dublincore.org/documents/dcmi-namespace/#creator</Const>            <Const type="xsd:string>W3C RIF WG</Const>          </slot>          <slot>            <Const type="rif:iri">http://dublincore.org/documents/dcmi-namespace/#description</Const>            <Const type="xsd:string">Running example rule set from the RIF-PRD specification</Const>          </slot>        </Frame>      </meta>      <behavior> ... </behavior>      <sentence>        <Group>          <id><Const type="rif:iri">http://example.com/2009/prd2#GoldRule</Const></id>          <behavior> ... </behavior>          <sentence><Forall> ... </Forall></sentence>        </Group>      </sentence>      <sentence>        <Group>          <id><Const type="rif:iri">http://example.com/2009/prd2#DiscountRule</Const></id>          <sentence><Forall> ... </Forall></sentence>        </Group>      </sentence>    </Group>  </payload></Document>

9 Presentation syntax (Informative)

To make it easier to read, a non-normative, lightweight notation was introduced to complement the mathematical English specification of the abstract syntax and the semantics of RIF-PRD. This section specifies a presentation syntax for RIF-PRD, that extends that notation. The presentation syntax is not normative. However, it may help implementers by providing a more succinct overview of RIF-PRD syntax.

The EBNF for the RIF-PRD presentation syntax is given as follows. For convenience of reading we show the entire EBNF in its four parts (rules, conditions, actions, and annotations).

Rule Language:

  Document       ::= IRIMETA? 'Document' '(' Base? Prefix* Import* Group? ')'  Base           ::= 'Base' '(' ANGLEBRACKIRI ')'  Prefix         ::= 'Prefix' '(' Name ANGLEBRACKIRI ')'  Import         ::= IRIMETA? 'Import' '(' LOCATOR PROFILE? ')'  Group          ::= IRIMETA? 'Group' Strategy? Priority? '(' (RULE | Group)* ')'  Strategy       ::= Const  Priority       ::= Const  RULE           ::= (IRIMETA? 'Forall' Var+ (' such that ' FORMULA+)?  '(' RULE ')') | CLAUSE  CLAUSE         ::= Implies | ACTION_BLOCK   Implies        ::= IRIMETA? 'If' FORMULA 'Then' ACTION_BLOCK  LOCATOR        ::= ANGLEBRACKIRI  PROFILE        ::= ANGLEBRACKIRI

Action Language:

  ACTION  ::= IRIMETA? (Assert | Retract | Modify | Execute )  Assert         ::= 'Assert' '(' IRIMETA? (Atom | Frame | Member) ')'  Retract        ::= 'Retract' '(' ( IRIMETA? (Atom | Frame) | TERM | TERM TERM ) ')'  Modify         ::= 'Modify'  '(' IRIMETA? Frame ')'  Execute        ::= 'Execute' '(' IRIMETA? Atom ')'   ACTION_BLOCK   ::= IRIMETA? ('Do (' ('(' IRIMETA? Var IRIMETA? (Frame | 'New()') ')')* ACTION+  ')' |                     'And (' ( IRIMETA? (Atom | Frame) )* ')' | Atom | Frame)

Condition Language:

  FORMULA        ::= IRIMETA? 'And' '(' FORMULA* ')' |                     IRIMETA? 'Or' '(' FORMULA* ')' |                     IRIMETA? 'Exists' (IRIMETA? Var)+ '(' FORMULA ')' |                     ATOMIC |                     IRIMETA? NEGATEDFORMULA  |                     IRIMETA? Equal |                     IRIMETA? Member |                     IRIMETA? Subclass |                      IRIMETA? 'External' '(' IRIMETA? Atom ')'  ATOMIC         ::= IRIMETA? (Atom | Frame)  Atom           ::= UNITERM  UNITERM        ::= (IRIMETA? Const) '(' (TERM* ')'  GROUNDUNITERM  ::= (IRIMETA? Const) '(' (GROUNDTERM* ')'  NEGATEDFORMULA ::= 'Not' '(' FORMULA ')' | 'INeg' '(' FORMULA ')'   Equal          ::= TERM '=' TERM  Member         ::= TERM '#' TERM  Subclass       ::= TERM '##' TERM  Frame          ::= TERM '[' (TERM '->' TERM)* ']'  TERM           ::= IRIMETA? (Const | Var | List | 'External' '(' Expr ')')  GROUNDTERM     ::= IRIMETA? (Const | List | 'External' '(' GROUNDUNITERM ')')  Expr           ::= UNITERM  List           ::= 'List' '(' GROUNDTERM* ')'  Const          ::= '"' UNICODESTRING '"^^' SYMSPACE | CONSTSHORT  Var            ::= '?' Name  Name           ::= NCName  SYMSPACE       ::= ANGLEBRACKIRI | CURIE

Annotations:

  IRIMETA        ::= '(*' IRICONST? (Frame | 'And' '(' Frame* ')')? '*)'

A NEGATEDFORMULA can be written using eitherNot orINeg.INeg is short forinflationary negation and is preferred over 'Not' to avoid ambiguity about the semantics of the negation.

The RIF-PRD presentation syntax does not commit to any particular vocabulary and permits arbitrary Unicode strings in constant symbols, argument names, and variables. Constant symbols can have this form:"UNICODESTRING"^^SYMSPACE, whereSYMSPACE is anANGLEBRACKIRI orCURIE that represents the identifier of the symbol space of the constant, andUNICODESTRING is a Unicode string from the lexical space of that symbol space.ANGLEBRACKIRI andCURIE are defined in the section Shortcuts for Constants in RIF's Presentation Syntax in [RIF-DTB]. Constant symbols can also have several shortcut forms, which are represented by the non-terminalCONSTSHORT. These shortcuts are also defined in the same section of [RIF-DTB]. One of them is theCURIE shortcut, which is extensively used in the examples in this document.Names are XMLNCNames. Variables are composed ofNCName symbols prefixed with a?-sign.

Document(Prefix( ex1 <http://example.com/2009/prd2> )(* ex1:CheckoutRuleset *)Group  (  (* ex1:GoldRule *)  Group  (    Forall ?customer such that And(?customer # ex1:Customer                                   ?customer[ex1:status -> "Silver"])      (Forall ?shoppingCart such that ?customer[ex1:shoppingCart -> ?shoppingCart]         (If Exists ?value (And(?shoppingCart[ex1:value -> ?value]                                External(pred:numeric-greater-than-or-equal(?value 2000))))          Then Do(Modify(?customer[ex1:status -> "Gold"])))))  (* ex1:DiscountRule *)  Group (    Forall ?customer such that ?customer # ex1:Customer      (If Or( ?customer[ex1:status -> "Silver"]              ?customer[ex1:status -> "Gold"])       Then Do ((?s ?customer[ex1:shoppingCart ->  ?s])                (?v ?s[ex1:value -> ?v])                Modify(?s [ex1:value -> External(func:numeric-multiply (?v 0.95))]))))  (* ex1:NewCustomerAndWidgetRule *)  Group (    Forall ?customer such that And(?customer # ex1:Customer                                    ?customer[ex1:status -> "New"] )      (If Exists ?shoppingCart ?item                 (And(?customer[ex1:shoppingCart -> ?shoppingCart]                      ?shoppingCart[ex1:containsItem -> ?item]                      ?item # ex1:Widget ) )       Then Do( (?s ?customer[ex1:shoppingCart -> ?s])                (?val ?s[ex1:value -> ?val])                Retract(?customer ex1:voucher)                Modify(?s[ex1:value -> External(func:numeric-multiply(?val 0.90))]))))  (* ex1:UnknownStatusRule *)  Group (    Forall ?customer such that ?customer # ex1:Customer      (If Not(Exists ?status                     (And(?customer[ex1:status -> ?status]                          External(pred:list-contains(List("New" "Bronze" "Silver" "Gold") ?status)) )))       Then Do( Execute(act:print(External(func:concat("New customer: " ?customer))))                Assert(?customer[ex1:status -> "New"])))) ))

10 Acknowledgements

This document is the product of the Rules Interchange Format (RIF) Working Group (see below) whose members deserve recognition for their time and commitment. The editors extend special thanks to Harold Boley and Changhai Ke for their thorough reviews and insightful discussions; the working group chairs, Chris Welty and Christian de Sainte Marie, for their invaluable technical help and inspirational leadership; and W3C staff contact Sandro Hawke, a constant source of ideas, help, and feedback.

The regular attendees at meetings of the Rule Interchange Format (RIF) Working Group at the time of the publication were:Adrian Paschke (Freie Universitaet Berlin), Axel Polleres (DERI),Chris Welty (IBM), Christian de Sainte Marie (IBM), Dave Reynolds (HP), Gary Hallmark (ORACLE), Harold Boley (NRC), Jos de Bruijn (FUB),Leora Morgenstern (IBM), Michael Kifer (Stony Brook), Mike Dean (BBN), Sandro Hawke (W3C/MIT), andStella Mitchell (IBM).

11 References

11.1 Normative references

[OMG-PRR]

Production Rule Representation (PRR), OMG specification, version 1.0, 2007.

[RDF-CONCEPTS]

Resource Description Framework (RDF): Concepts and Abstract Syntax, Klyne G., Carroll J. (Editors), W3C Recommendation, 10 February 2004,http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/. Latest version available athttp://www.w3.org/TR/rdf-concepts/.

[RDF-SCHEMA]

RDF Vocabulary Description Language 1.0: RDF Schema, Brian McBride, Editor, W3C Recommendation 10 February 2004,http://www.w3.org/TR/2004/REC-rdf-schema-20040210/. Latest version available athttp://www.w3.org/TR/rdf-schema/.

[RFC-3066]

RFC 3066 - Tags for the Identification of Languages, H. Alvestrand, IETF, January 2001, athttp://www.ietf.org/rfc/rfc3066.

[RFC-3987]

RFC 3987 - Internationalized Resource Identifiers (IRIs), M. Duerst and M. Suignard, IETF, January 2005,http://www.ietf.org/rfc/rfc3987.txt.

[RIF-BLD]

RIF Basic Logic Dialect (Second Edition) Harold Boley, Michael Kifer, eds. W3C Recommendation, 5 February 2013,http://www.w3.org/TR/2013/REC-rif-bld-20130205/. Latest version available athttp://www.w3.org/TR/rif-bld/.

[RIF-Core]

RIF Core Dialect (Second Edition) Harold Boley, Gary Hallmark, Michael Kifer, Adrian Paschke, Axel Polleres, Dave Reynolds, eds. W3C Recommendation, 5 February 2013,http://www.w3.org/TR/2013/REC-rif-core-20130205/. Latest version available athttp://www.w3.org/TR/rif-core/.

[RIF-DTB]

RIF Datatypes and Built-Ins 1.0 (Second Edition) Axel Polleres, Harold Boley, Michael Kifer, eds. W3C Recommendation, 5 February 2013,http://www.w3.org/TR/2013/REC-rif-dtb-20130205/. Latest version available athttp://www.w3.org/TR/rif-dtb/.

[RIF-FLD]

RIF Framework for Logic Dialects (Second Edition) Harold Boley, Michael Kifer, eds. W3C Recommendation, 5 February 2013,http://www.w3.org/TR/2013/REC-rif-fld-20130205/. Latest version available athttp://www.w3.org/TR/rif-fld/.

[RIF-RDF-OWL]

RIF RDF and OWL Compatibility (Second Edition) Jos de Bruijn, Chris Welty, eds. W3C Recommendation, 5 February 2013,http://www.w3.org/TR/2013/REC-rif-rdf-owl-20130205/. Latest version available athttp://www.w3.org/TR/rif-rdf-owl/.

[XDM]

XQuery 1.0 and XPath 2.0 Data Model (XDM), W3C Recommendation, World Wide Web Consortium, 23 January 2007. This version ishttp://www.w3.org/TR/2007/REC-xpath-datamodel-20070123/. Latest version available athttp://www.w3.org/TR/xpath-datamodel/.

[XML-Base]

XML Base (second edition), W3C Recommendation, World Wide Web Consortium, 28 January 2009,http://www.w3.org/TR/2009/REC-xmlbase-20090128/. Latest version available athttp://www.w3.org/TR/xmlbase/.

[XML-SCHEMA2]

XML Schema Part 2: Datatypes Second Edition, W3C Recommendation, World Wide Web Consortium, 28 October 2004,http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. Latest version available athttp://www.w3.org/TR/xmlschema-2/.

[XPath-Functions]

XQuery 1.0 and XPath 2.0 Functions and Operators, W3C Recommendation, World Wide Web Consortium, 23 January 2007,http://www.w3.org/TR/2007/REC-xpath-functions-20070123/. Latest version available athttp://www.w3.org/TR/xpath-functions/.

11.2 Informational references

[CIR04]

Production Systems and Rete Algorithm Formalisation, Cirstea H., Kirchner C., Moossen M., Moreau P.-E. Rapport de recherche n° inria-00280938 - version 1 (2004).

[CURIE]

CURIE Syntax 1.0, S. McCarron, M. Birbeck, Editors, W3C Working Group Note, 16 December 2010,http://www.w3.org/TR/2010/NOTE-curie-20101216 . Latest version available athttp://www.w3.org/TR/curie.

[Enderton01]

A Mathematical Introduction to Logic, Second Edition, H. B. Enderton. Academic Press, 2001.

[FIT02]

Fixpoint Semantics for Logic Programming: A Survey, Melvin Fitting, Theoretical Computer Science. Vol. 278, no. 1-2, pp. 25-51. 6 May 2002.

[HAK07]

Data Models as Constraint Systems: A Key to the Semantic Web, Hassan Ait-Kaci, Constraint Programming Letters, 1:33--88, 2007.

[KLW95]

Logical foundations of object-oriented and frame-based languages, M. Kifer, G. Lausen, J. Wu. Journal of ACM, July 1995, pp. 741--843.

[Mendelson97]

Introduction to Mathematical Logic, Fourth Edition, E. Mendelson. Chapman & Hall, 1997.

[PLO04]

A Structural Approach to Operational Semantics, Gordon D. Plotkin, Journal of Logic and Algebraic Programming, Volumes 60-61, Pages 17-139 (July - December 2004).

12 Appendix: Model-theoretic semantics of RIF-PRD condition formulas

This appendix provides an alternative specification of theSemantics of condition formulas, and it is also normative.

This alternative specification is provided for the convenience of the reader, for compatibility with other RIF specifications, such as [RIF-DTB] and [RIF-RDF-OWL], and to make explicit the interoperability with RIF logic dialects, in particular [RIF-Core] and [RIF-BLD].

12.1 Semantic structures

The key concept in a model-theoretic semantics of a logic language is the notion of a semantic structure [Enderton01, Mendelson97].

Definition (Semantic structure).Asemantic structure,I, is a tuple of the form<TV,DTS,D,D_ind,D_func,I_C,I_V,I_list,I_P,I_frame,I_sub,I_isa,I₌,I_external,I_truth>. HereD is a non-empty set of elements called theHerbrand domain ofI, that is, the set of all ground terms which can be formed by using the elements ofConst.D_ind,D_func are nonempty subsets ofD.D_ind is used to interpret the elements ofConst that are individuals andD_func is used to interpret the elements ofConst that are function symbols.Const denotes the set of all constant symbols andVar the set of all variable symbols.TV denotes the set of truth values that the semantic structure uses andDTS is a set of identifiers for primitive datatypes (please refer to Section Datatypes in the RIF data types and builtins specification [RIF-DTB] for the semantics of datatypes).

As far as the assignment of a standard meaning to formulas in the RIF-PRD condition language is concerned, the setTV of truth values consists of just two values,t andf.

The other components ofI aretotal mappings defined as follows:

1. I_C mapsConst toD.

   This mapping interprets constant symbols. In addition:

   • If a constant,c ∈ Const,is anindividual then it is required thatI_C(c) ∈ D_ind.
   • Ifc ∈ Const, is afunction symbol then it is required thatI_C(c) ∈ D_func.
2. I_V mapsVar toD_ind.

   This mapping interprets variable symbols.

3. I_list :D_ind^* →D_ind is used to interpret lists.

   In addition, this mapping is required to satisfy the following conditions:

   • I_list is an injective one-to-one function.
   • I_list(D_ind) is disjoint from the value spaces of all data types inDTS.
4. I_P mapsD to functionsD*_ind →D (hereD*_ind is a set of all sequences of any finite length over the domainD_ind).

   This mapping interprets positional terms atoms.

5. I_frame mapsD_ind to total functions of the formSetOfFiniteBags(D_ind ×D_ind) →D.

   This mapping interprets frame terms. An argument,d ?D_ind, toI_frame represents an object and the finite bag {<a1,v1>, ..., <ak,vk>} represents a bag of attribute-value pairs ford. We will see shortly howI_frame is used to determine the truth valuation of frame terms.

   Bags (multi-sets) are used here because the order of the attribute/value pairs in a frame is immaterial and pairs may repeat. Such repetitions arise naturally when variables are instantiated with constants. For instance,o[?A->?B ?C->?D] becomeso[a->b a->b] if variables?A and?C are instantiated with the symbola while?B and?D are instantiated withb. (We shall see later thato[a->b a->b] is equivalent too[a->b].)

6. I_sub gives meaning to the subclass relationship. It is a mapping of the formD_ind ×D_ind →D.

   The operator## is required to be transitive, i.e.,c1 ## c2 andc2 ## c3 must implyc1 ## c3. This is ensured by a restriction in SectionInterpretation of condition formulas;

7. I_isa gives meaning to class membership. It is a mapping of the formD_ind ×D_ind →D.

   The relationships# and## are required to have the usual property that all members of a subclass are also members of the superclass, i.e.,o # cl andcl ## scl must implyo # scl. This is ensured by a restriction in SectionInterpretation of condition formulas;

8. I₌ is a mapping of the formD_ind ×D_ind →D.

   It gives meaning to the equality operator.

9. I_truth is a mapping of the formD →TV.

   It is used to define truth valuation for formulas.

10. I_external is a mapping from the coherent set of schemas for externally defined functions to total functionsD* →D. For each external schemaσ = (?X₁ ... ?X_n; τ) in the coherent set of external schemas associated with the language,I_external(σ) is a function of the formDⁿ →D.

    For every external schema,σ, associated with the language,I_external(σ) is assumed to be specified externally in some document (hence the nameexternal schema). In particular, ifσ is a schema of a RIF built-in predicate, function or action,I_external(σ) is specified so that:

    • Ifσ is a schema of a built-in function thenI_external(σ) must be the function defined in [RIF-DTB];
    • Ifσ is a schema of a built-in predicate thenI_truth ο(I_external(σ)) (the composition ofI_truth andI_external(σ), a truth-valued function) must be as specified in [RIF-DTB];
    • Ifσ is a schema of a built-in action thenI_truth ο(I_external(σ)) (the composition ofI_truth andI_external(σ), a truth-valued function) must be as specified in thesection Built-in actions in this document.

For convenience, we also define the following mappingI from terms toD:

• I(k) =I_C(k), ifk is a symbol inConst;
• I(?v) =I_V(?v), if?v is a variable inVar;
• For list terms, the mapping is defined as follows:
  • I(List( )) =I_list(<>). Here<> denotes an empty list of elements ofD_ind. (Note that the domain ofI_list isD_ind^*, soD_ind⁰ is an empty list of elements ofD_ind.)
  • I(List(t₁ ...t_n)) =I_list(I(t₁), ...,I(t_n)), ifn>0.
• I(p(t₁ ... t_n)) =I_P(I(p))(I(t₁),...,I(t_n));
• I(o[a₁->v₁ ... a_k->v_k]) =I_frame(I(o))({<I(a₁),I(v₁)>, ..., <I(a_n),I(v_n)>})
  Here {...} denotes a bag of attribute/value pairs.
• I(c1##c2) =I_sub(I(c1),I(c2));
• I(o#c) =I_isa(I(o),I(c));
• I(x=y) =I₌(I(x),I(y));
• I(External(t)) =I_external(σ)(I(s₁), ...,I(s_n)), ift is an instance of the external schemaσ = (?X₁ ... ?X_n; τ) by substitution?X₁/s₁ ... ?X_n/s₁.
  Note that, by definition,External(t) is well-formed only ift is an instance of an external schema. Furthermore, by the definition of coherent sets of external schemas,t can be an instance of at most one such schema, soI(External(t)) is well-defined.

The effect of datatypes. The setDTS must include the datatypes described in Section Primitive Datatypes of the RIF data types and builtins specification [RIF-DTB].

The datatype identifiers inDTS impose the following restrictions. Givendt ∈DTS, letLS_dt denote the lexical space ofdt,VS_dt denote its value space, andL_dt:LS_dt →VS_dt the lexical-to-value-space mapping (for the definitions of these concepts, see Section Primitive Datatypes of the RIF data types and builtins specification [RIF-DTB]. Then the following must hold:

• VS_dt ⊆D_ind; and
• For each constant"lit"^^dt such thatlit ∈LS_dt,I_C("lit"^^dt) =L_dt(lit).

That is,I_C must map the constants of a datatypedt in accordance withL_dt.

RIF-PRD does not impose restrictions onI_C for constants in symbol spaces that are not datatypes included inDTS.   ☐

12.2 Interpretation of condition formulas

This section defines how a semantic structure,I, determinesthe truth valueTVal_I(φ) of a condition formula,φ.

We define a mapping,TVal_I, from the set of all condition formulas toTV. Note that the definition implies thatTVal_I(φ) is definedonly if the setDTS of the datatypes ofI includes all the datatypes mentioned inφ andI_external is defined on all externally defined functions and predicates inφ.

Definition (Truth valuation).Truth valuation for well-formed condition formulas in RIF-PRD is determined using the following function, denotedTVal_I:

• Positional atomic formulas:TVal_I(r(t₁ ... t_n)) =I_truth(I(r(t₁ ... t_n)));
• Equality:TVal_I(x = y) =I_truth(I(x = y)).
  To ensure that equality has precisely the expected properties, it is required that:
  • I_truth(I(x = y)) =t ifI(x) =I(y) and thatI_truth(I(x = y)) =f otherwise. This is tantamount to saying thatTVal_I(x = y) =t iffI(x) =I(y);
• Subclass:TVal_I(sc ## cl) =I_truth(I(sc ## cl)).
  To ensure that the operator## is transitive, i.e.,c1 ## c2 andc2 ## c3 implyc1 ## c3, the following is required:
  • For allc1,c2,c3 ∈D,   ifTVal_I(c1 ## c2) =TVal_I(c2 ## c3) = t   thenTVal_I(c1 ## c3) = t;
• Membership:TVal_I(o # cl) =I_truth(I(o # cl)).
  To ensure that all members of a subclass are also members of the superclass, i.e.,o # cl andcl ## scl implieso # scl, the following is required:
  • For allo,cl,scl ∈D,   ifTVal_I(o # cl) =TVal_I(cl ## scl) =t   then  TVal_I(o # scl) = t;
• Frame:TVal_I(o[a₁->v₁ ... a_k->v_k]) =I_truth(I(o[a₁->v₁ ... a_k->v_k])).
  Since the bag of attribute/value pairs represents the conjunctions of all the pairs, the following is required, ifk > 0:
  • TVal_I(o[a₁->v₁ ... a_k->v_k]) =t if and only ifTVal_I(o[a₁->v₁]) = ... =TVal_I(o[a_k->v_k]) =t;
• Externally defined atomic formula:TVal_I(External(t)) =I_truth(I_external(σ)(I(s₁), ...,I(s_n))), ift is an atomic formula that is an instance of the external schemaσ = (?X₁ ... ?X_n; τ) by substitution?X₁/s₁ ... ?X_n/s₁.
  Note that, by definition,External(t) is well-formed only ift is an instance of an external schema. Furthermore, by the definition of coherent sets of external schemas,t can be an instance of at most one such schema, soI(External(t)) is well-defined;
• Conjunction:TVal_I(And(c₁ ... c_n)) =t if and only ifTVal_I(c₁) = ... =TVal_I(c_n) =t. Otherwise,TVal_I(And(c₁ ... c_n)) =f.
  The empty conjunction is treated as a tautology, soTVal_I(And()) =t;
• Disjunction:TVal_I(Or(c₁ ... c_n)) =f if and only ifTVal_I(c₁) = ... =TVal_I(c_n) =f. Otherwise,TVal_I(Or(c₁ ... c_n)) =t.
  The empty disjunction is treated as a contradiction, soTVal_I(Or()) =f;
• Negation:TVal_I(Not(c)) =f if and only ifTVal_I(c) =t. Otherwise,TVal_I(Not(c)) =t;
• Existence:TVal_I(Exists ?v₁ ... ?v_n (φ)) =t if and only if for someI*, described below,TVal_I*(φ) =t.
  HereI* is a semantic structure of the form <TV,DTS,D,D_ind,D_func,I_C,I*_V,I_list,I_P,I_frame,I_sub,I_isa,I₌,I_external,I_truth>, which is exactly likeI, except that the mappingI*_V, is used instead ofI_V.  I*_V is defined to coincide withI_V on all variables except, possibly, on?v₁,...,?v_n.   ☐

12.3 Condition satisfaction

We define, now, what it means for astate of the fact base to satisfy a condition formula. The satisfaction of condition formulas in a state of the fact base provides formal underpinning to the operational semantics of rule sets interchanged using RIF-PRD.

Definition (Models).A semantic structureI is amodel of a condition formula,φ, written asI |= φ, iffTVal_I(φ) =t.   ☐

Definition (Herbrand interpretation). Given a non-empty set of constants,Const, theHerbrand domain is the set of all the ground terms that can be formed using the elements ofConst, and theHerbrand base is the set of all the well-formed ground atomic formulas that can be formed with the elements in the Herbrand domain.

A semantic structure,I, is aHerbrand interpretation, if the set of all the ground formulas which are true with respect toI (that is, of whichI is a model), is a subset of the corresponding Herbrand base,B_I.   ☐

In RIF-PRD, the semantics of condition formulas is defined with respect to semantic structures where the domain,D is the Herbrand domain that is determined by the set of all the constants,Const; that is, with respect to Herbrand interpretations.

Definition (State of the fact base). To every Herbrand interpretationI, we associate astate of the fact base,w_I, that is represented by the subset of the Herbrand base that contains exactly the ground atomic formulas of whichI is a model; or, equivalently, by the conjunction of all these ground atomic formulas.   ☐

Definition (Condition satisfaction). A RIF-PRD condition formulaφ issatisfied in a state of the fact base,w_I, if and only ifI is a model ofφ.   ☐

At the syntactic level, the interpretation of the variables by a valuation functionI_V is realized by asubstitution. As a consequence, a ground substitutionσmatches a condition formulaψ to a set of ground atomic formulasΦ if and only ifσ realizes the valuation functionI_V of a semantics structureI that is a model ofψ andΦ is a representation of a state of the fact base,w_I (as definedabove), that is associated toI; that is, if and only ifψ is satisfied inw_I (as definedabove).

This provides the formal link between thesatisfaction of a condition formula, as defined above, and amatching substitution, and, followingly, between the alternative definitions of a state of facts and the satisfaction of a condition, here and insection Semantics of condition formulas.

13 Appendix: XML schema

The RIF-PRD XML Schema is specified below as a redefinition and an extension of the RIF-Core XML Schema [RIF-Core] and is also available athttp://www.w3.org/2010/rif-schema/prd/.

<?xml version="1.0" encoding="UTF-8"?><xs:schema    targetNamespace="http://www.w3.org/2007/rif#"    xmlns:xs="http://www.w3.org/2001/XMLSchema"    xmlns:xml="http://www.w3.org/XML/1998/namespace"    xmlns="http://www.w3.org/2007/rif#"    elementFormDefault="qualified"><xs:import namespace='http://www.w3.org/XML/1998/namespace'           schemaLocation='http://www.w3.org/2001/xml.xsd'/><!-- ================================================== --><!-- Redefine some elements in the Core Conditions      --><!-- Extension of the choice                            --><!-- ================================================== -->   <xs:group name="ATOMIC">      <xs:choice>         <xs:element ref="Atom"/>         <xs:element ref="Frame"/>         <xs:element ref="Member"/>         <xs:element ref="Equal"/>         <xs:element ref="Subclass"/> <!-- Subclass is not in RIF-Core -->         <xs:element name="External" type="External-FORMULA.type"/>      </xs:choice>   </xs:group>   <xs:group name="FORMULA">      <xs:choice>         <xs:group   ref="ATOMIC"/>          <xs:element ref="And"/>         <xs:element ref="Or"/>         <xs:element ref="Exists"/>         <xs:element ref="INeg"/> <!-- INeg is nt in RIF-Core -->      </xs:choice>   </xs:group><!-- ================================================== --><!-- Additional elements to the Core Condition schema   --><!-- ================================================== -->   <xs:element name="Subclass"><!--                                                    --><!--     <Subclass>                                     --><!--        <sub> TERM </sub>                           --><!--        <super> TERM </super>                       --><!--     </Subclass>                                    --><!--                                                    -->      <xs:complexType>         <xs:sequence>            <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>            <xs:element name="sub">               <xs:complexType>                  <xs:group ref="TERM" minOccurs="1" maxOccurs="1"/>               </xs:complexType>            </xs:element>            <xs:element name="super">               <xs:complexType>                  <xs:group ref="TERM" minOccurs="1" maxOccurs="1"/>               </xs:complexType>            </xs:element>         </xs:sequence>      </xs:complexType>   </xs:element>   <xs:element name="INeg"><!--                                                    --><!--     <INeg>                                         --><!--        <formula> FORMULA </formula>                --><!--     </INeg>                                        --><!--                                                    -->      <xs:complexType>        <xs:sequence>          <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>          <xs:element ref="formula" minOccurs="1" maxOccurs="1"/>        </xs:sequence>      </xs:complexType>   </xs:element><!-- ============================================ --><!-- CoreCond.xsd starts here                     --><!-- ============================================ -->  <xs:complexType name="External-FORMULA.type">    <!-- sensitive to FORMULA (Atom) context-->    <xs:sequence>      <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>      <xs:element name="content" type="content-FORMULA.type"/>    </xs:sequence>  </xs:complexType>    <xs:complexType name="content-FORMULA.type">    <!-- sensitive to FORMULA (Atom) context-->    <xs:sequence>      <xs:element ref="Atom"/>    </xs:sequence>  </xs:complexType>   <xs:element name="And">    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="formula" minOccurs="0" maxOccurs="unbounded"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="Or">    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="formula" minOccurs="0" maxOccurs="unbounded"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="Exists">    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="declare" minOccurs="1" maxOccurs="unbounded"/>        <xs:element ref="formula"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="formula">    <xs:complexType>      <xs:sequence>        <xs:group ref="FORMULA"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="declare">    <xs:complexType>      <xs:sequence>        <xs:element ref="Var"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="Atom">    <!--  Atom           ::= UNITERM    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="UNITERM"/>      </xs:sequence>    </xs:complexType>  </xs:element>      <xs:group name="UNITERM">    <!--  UNITERM        ::= Const '(' (TERM* ')'    -->    <xs:sequence>      <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>      <xs:element ref="op"/>      <xs:element name="args" type="args-UNITERM.type" minOccurs="0" maxOccurs="1"/>    </xs:sequence>  </xs:group>   <xs:group name="GROUNDUNITERM">    <!-- sensitive to ground terms  GROUNDUNITERM        ::= Const '(' (GROUNDTERM* ')'    -->    <xs:sequence>      <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>      <xs:element ref="op"/>      <xs:element name="args" type="args-GROUNDUNITERM.type" minOccurs="0" maxOccurs="1"/>    </xs:sequence>  </xs:group>  <xs:element name="op">    <xs:complexType>      <xs:sequence>        <xs:element ref="Const"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:complexType name="args-UNITERM.type">    <!-- sensitive to UNITERM (TERM) context-->    <xs:sequence>      <xs:group ref="TERM" minOccurs="1" maxOccurs="unbounded"/>    </xs:sequence>    <xs:attribute name="ordered" type="xs:string" fixed="yes"/>  </xs:complexType>  <xs:complexType name="args-GROUNDUNITERM.type">    <!-- sensitive to GROUNDUNITERM (TERM) context-->    <xs:sequence>      <xs:group ref="GROUNDTERM" minOccurs="1" maxOccurs="unbounded"/>    </xs:sequence>    <xs:attribute name="ordered" type="xs:string" fixed="yes"/>  </xs:complexType>  <xs:element name="Equal">    <!--  Equal          ::= TERM '=' ( TERM | IRIMETA? 'External' '(' Expr ')' )    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="left"/>        <xs:element ref="right"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="left">    <xs:complexType>      <xs:sequence>        <xs:group ref="TERM"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="right">    <xs:complexType>        <xs:group ref="TERM"/>    </xs:complexType>  </xs:element>   <xs:element name="Member">    <!--  Member         ::= TERM '#' TERM    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="instance"/>        <xs:element ref="class"/>      </xs:sequence>    </xs:complexType>  </xs:element>  <xs:element name="instance">    <xs:complexType>      <xs:sequence>        <xs:group ref="TERM"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="class">    <xs:complexType>      <xs:sequence>        <xs:group ref="TERM"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="Frame">    <!--  Frame          ::= TERM '[' (TERM '->' TERM)* ']'    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="object"/>        <xs:element name="slot" type="slot-Frame.type" minOccurs="0" maxOccurs="unbounded"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="object">    <xs:complexType>      <xs:sequence>        <xs:group ref="TERM"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:complexType name="slot-Frame.type">    <!-- sensitive to Frame (TERM) context-->    <xs:sequence>      <xs:group ref="TERM"/>      <xs:group ref="TERM"/>    </xs:sequence>    <xs:attribute name="ordered" type="xs:string" fixed="yes"/>  </xs:complexType>   <xs:group name="TERM">      <!--  TERM           ::= IRIMETA? (Const | Var | External | List )    -->      <xs:choice>         <xs:element ref="Const"/>         <xs:element ref="Var"/>         <xs:element name="External" type="External-TERM.type"/>         <xs:element ref="List"/>      </xs:choice>  </xs:group>  <xs:group name="GROUNDTERM">      <!--  GROUNDTERM           ::= IRIMETA? (Const | List | 'External' '(' 'Expr' '(' GROUNDUNITERM ')' ')')    -->      <xs:choice>         <xs:element ref="Const"/>         <xs:element ref="List"/>         <xs:element name="External" type="External-GROUNDUNITERM.type"/>      </xs:choice>  </xs:group>    <xs:element name="List">    <!--      List           ::= 'List' '(' GROUNDTERM* ')'    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>         <xs:element name="items">           <xs:complexType>             <xs:sequence>              <xs:group ref="GROUNDTERM" minOccurs="0" maxOccurs="unbounded"/>            </xs:sequence>            <xs:attribute name="ordered" type="xs:string" fixed="yes"/>          </xs:complexType>        </xs:element>       </xs:sequence>    </xs:complexType>  </xs:element>     <xs:complexType name="External-TERM.type">    <!-- sensitive to TERM (Expr) context-->    <xs:sequence>      <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>      <xs:element name="content" type="content-TERM.type"/>    </xs:sequence>  </xs:complexType>    <xs:complexType name="External-GROUNDUNITERM.type">    <!-- sensitive to GROUNDTERM (Expr) context-->    <xs:sequence>      <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>      <xs:element name="content" type="content-GROUNDUNITERM.type"/>    </xs:sequence>  </xs:complexType>  <xs:complexType name="content-TERM.type">    <!-- sensitive to TERM (Expr) context-->    <xs:sequence>      <xs:element ref="Expr"/>    </xs:sequence>  </xs:complexType>      <xs:complexType name="content-GROUNDUNITERM.type">    <!-- sensitive to GROUNDTERM (Expr) context-->    <xs:sequence>      <xs:element name="Expr" type="content-GROUNDEXPR.type"/>    </xs:sequence>  </xs:complexType>  <xs:complexType name="content-GROUNDEXPR.type">    <!-- sensitive to GROUNDEXPR context-->    <xs:sequence>      <xs:group ref="GROUNDUNITERM"/>    </xs:sequence>  </xs:complexType>  <xs:element name="Expr">    <!--  Expr           ::= Const '(' (TERM | IRIMETA? 'External' '(' Expr ')')* ')'    -->    <xs:complexType>      <xs:sequence>        <xs:element ref="op"/>        <xs:element name="args" type="args-Expr.type" minOccurs="0" maxOccurs="1"/>      </xs:sequence>    </xs:complexType>  </xs:element>  <xs:complexType name="args-Expr.type">    <!-- sensitive to Expr (TERM) context-->    <xs:choice minOccurs="1" maxOccurs="unbounded">      <xs:group ref="TERM"/>    </xs:choice>    <xs:attribute name="ordered" type="xs:string" fixed="yes"/>  </xs:complexType>  <xs:element name="Const">    <!--  Const          ::= '"' UNICODESTRING '"^^' SYMSPACE | CONSTSHORT    -->    <xs:complexType mixed="true">      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>      </xs:sequence>      <xs:attribute name="type" type="xs:anyURI" use="required"/>      <xs:attribute ref="xml:lang"/>    </xs:complexType>  </xs:element>   <xs:element name="Var">    <!--  Var            ::= '?' NCName    -->    <xs:complexType mixed="true">      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:group name="IRIMETA">    <!--  IRIMETA   ::= '(*' IRICONST? (Frame | 'And' '(' Frame* ')')? '*)'    -->    <xs:sequence>      <xs:element ref="id" minOccurs="0" maxOccurs="1"/>      <xs:element ref="meta" minOccurs="0" maxOccurs="1"/>    </xs:sequence>  </xs:group>   <xs:element name="id">    <xs:complexType>      <xs:sequence>        <xs:element name="Const" type="IRICONST.type"/>   <!-- type="&rif;iri" -->      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="meta">    <xs:complexType>     <xs:choice>       <xs:element ref="Frame"/>       <xs:element name="And" type="And-meta.type"/>     </xs:choice>    </xs:complexType>  </xs:element>    <xs:complexType name="And-meta.type">  <!-- sensitive to meta (Frame) context-->    <xs:sequence>      <xs:element name="formula" type="formula-meta.type" minOccurs="0" maxOccurs="unbounded"/>    </xs:sequence>  </xs:complexType>   <xs:complexType name="formula-meta.type">    <!-- sensitive to meta (Frame) context-->    <xs:sequence>      <xs:element ref="Frame"/>    </xs:sequence>  </xs:complexType>    <xs:complexType name="IRICONST.type" mixed="true">    <!-- sensitive to location/id context-->    <xs:sequence/>    <xs:attribute name="type" type="xs:anyURI" use="required" fixed="http://www.w3.org/2007/rif#iri"/>  </xs:complexType><!-- ============================================ --><!-- Definition of the actions (not in RIF-Core)  --><!-- ============================================ -->   <xs:element name="New">    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:group name="INITIALIZATION">      <xs:choice>         <xs:element ref="New"/>         <xs:element ref="Frame"/>      </xs:choice>   </xs:group>   <xs:element name="Do"><!--                                                    --><!--     <Do>                                           --><!--        <actionVar ordered="yes">                   --><!--          Var                                       --><!--          INITIALIZATION                            --><!--        </actionVar>*                               --><!--        <actions ordered="yes">                     --><!--          ACTION+                            --><!--        </actions>                                  --><!--     </Do>                                          --><!--                                                    -->      <xs:complexType>         <xs:sequence>            <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>            <xs:element name="actionVar" minOccurs="0" maxOccurs="unbounded">               <xs:complexType>                  <xs:sequence>                     <xs:element ref="Var" minOccurs="1" maxOccurs="1"/>                     <xs:group ref="INITIALIZATION" minOccurs="1" maxOccurs="1"/>                  </xs:sequence>                  <xs:attribute name="ordered" type="xs:string" fixed="yes"/>               </xs:complexType>            </xs:element>            <xs:element name="actions" minOccurs="1" maxOccurs="1">               <xs:complexType>                  <xs:sequence>                     <xs:group ref="ACTION" minOccurs="1" maxOccurs="unbounded"/>                  </xs:sequence>                  <xs:attribute name="ordered" type="xs:string" fixed="yes"/>               </xs:complexType>            </xs:element>         </xs:sequence>      </xs:complexType>   </xs:element>   <xs:group name="ACTION">      <xs:choice>         <xs:element ref="Assert"/>         <xs:element ref="Retract"/>         <xs:element ref="Modify"/>         <xs:element ref="Execute"/>      </xs:choice>   </xs:group>   <xs:element name="Assert"><!--                                                    --><!--     <Assert>                                       --><!--        <target> [ Atom                             --><!--                 | Frame                            --><!--                 | Member ]                         --><!--        </target>                                   --><!--     </Assert>                                      --><!--                                                    -->      <xs:complexType>         <xs:sequence>            <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>            <xs:element name="target" minOccurs="1" maxOccurs="1">               <xs:complexType>                  <xs:choice>                     <xs:element ref="Atom"/>                     <xs:element ref="Frame"/>                     <xs:element ref="Member"/>                  </xs:choice>               </xs:complexType>    </xs:element> </xs:sequence>     </xs:complexType>   </xs:element>   <xs:element name="Retract"><!--                                                    --><!--     <Retract>                                      --><!--        <target ordered="yes"?>                     --><!--           [ Atom                                   --><!--             | Frame                                --><!--             | TERM                                 --><!--             | TERM TERM ]                          --><!--        </target>                                   --><!--     </Assert>                                      --><!--                                                    -->      <xs:complexType>         <xs:sequence>            <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>            <xs:element name="target" minOccurs="1" maxOccurs="1">               <xs:complexType>                  <xs:choice>                     <xs:element ref="Atom"/>                     <xs:element ref="Frame"/>                     <xs:group ref="TERM"/>                     <xs:sequence>                        <xs:group ref="TERM"/>                        <xs:group ref="TERM"/>                     </xs:sequence>                  </xs:choice>                  <xs:attribute name="ordered" type="xs:string" fixed="yes"/>               </xs:complexType>            </xs:element>         </xs:sequence>      </xs:complexType>   </xs:element>   <xs:element name="Modify"><!--                                                    --><!--     <Modify>                                       --><!--        <target> Frame </target>                    --><!--     </Modify>                                      --><!--                                                    -->     <xs:complexType>      <xs:sequence>       <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>       <xs:element name="target" minOccurs="1" maxOccurs="1">        <xs:complexType>         <xs:sequence>          <xs:element ref="Frame"/>         </xs:sequence>          </xs:complexType>       </xs:element>      </xs:sequence>      </xs:complexType>              </xs:element>      <xs:element name="Execute"><!--                                                    --><!--     <Execute>                                      --><!--        <target> Atom </target>                     --><!--     </Execute>                                     --><!--                                                    -->     <xs:complexType>      <xs:sequence>       <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>       <xs:element name="target" minOccurs="1" maxOccurs="1">        <xs:complexType>         <xs:sequence>          <xs:element ref="Atom"/>         </xs:sequence>          </xs:complexType>       </xs:element>      </xs:sequence>      </xs:complexType>              </xs:element>    <!-- ================================================== --><!-- Redefine Group related Core construct              --><!-- ================================================== -->   <xs:complexType name="Group-contents">      <xs:sequence>         <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>         <xs:element ref="behavior" minOccurs="0" maxOccurs="1"/>                     <!-- behavior in not in RIF-Core -->         <xs:element ref="sentence" minOccurs="0" maxOccurs="unbounded"/>                </xs:sequence>   </xs:complexType><!-- ================================================== --><!-- Group related addition                             --><!-- ================================================== -->   <xs:element name="behavior"><!--                                                    --><!--     <behavior>                                     --><!--        <ConflictResolution>                        --><!--           xsd:anyURI                               --><!--        <ConflictResolution>?                       --><!--        <Priority>                                  --><!--           -10,000 ≤ xsd:int ≤ 10,000         --><!--        </Priority>?                                --><!--     </behavior>                                    --><!--                                                    -->      <xs:complexType>         <xs:sequence>            <xs:element name="ConflictResolution" minOccurs="0" maxOccurs="1" type="xs:anyURI"/>            <xs:element name="Priority" minOccurs="0" maxOccurs="1">               <xs:simpleType>                  <xs:restriction base="xs:int">                     <xs:minInclusive value="-10000"/>                     <xs:maxInclusive value="10000"/>                  </xs:restriction>               </xs:simpleType>            </xs:element>         </xs:sequence>      </xs:complexType>   </xs:element><!-- ================================================== --><!-- Redefine rule related Core constructs              --><!-- ================================================== -->  <xs:group name="RULE">    <!--   RULE      ::= (IRIMETA? 'Forall' Var+ (' such that ' FORMULA+)?  '(' RULE ')') | CLAUSE    -->    <xs:choice>       <xs:element name="Forall" type="Forall-premises"/>       <xs:group   ref="CLAUSE"/>     </xs:choice>  </xs:group>  <xs:complexType name="Forall-premises">    <xs:sequence>      <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>      <xs:element ref="declare" minOccurs="1" maxOccurs="unbounded"/>      <xs:element name="pattern" minOccurs="0" maxOccurs="unbounded">        <xs:complexType>          <xs:sequence>            <xs:group ref="FORMULA"/>          </xs:sequence>        </xs:complexType>      </xs:element>       <!-- different from formula in And, Or and Exists -->      <xs:element name="formula">        <xs:complexType>          <xs:group ref="RULE"/>        </xs:complexType>      </xs:element>    </xs:sequence>  </xs:complexType>  <xs:group name="CLAUSE">      <!--  CLAUSE   ::= Implies | ACTION_BLOCK    -->    <xs:choice>      <xs:element ref="Implies"/>      <xs:group ref="ACTION_BLOCK"/>     </xs:choice>  </xs:group>   <xs:complexType name="then-part">            <xs:group ref="ACTION_BLOCK" minOccurs="1" maxOccurs="1"/>   </xs:complexType><!-- ================================================== --><!-- Rule related additions                             --><!-- ================================================== -->    <xs:group name="ACTION_BLOCK">    <!--   ACTION_BLOCK   ::= 'Do (' (Var (Frame | 'New'))* ACTION+  ')' |                     'And (' (Atom | Frame)* ')' | Atom | Frame     -->                       <xs:choice>     <xs:element  ref="Do"/>     <xs:element  name="And" type="And-then.type"/>     <xs:element  ref="Atom"/>     <xs:element  ref="Frame"/>    </xs:choice>  </xs:group><!-- ================================================== --><!-- CoreRule.xsd starts here                           --><!-- ================================================== -->   <xs:element name="Document">    <!--  Document  ::= IRIMETA? 'Document' '(' Base? Prefix* Import* Group? ')'    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="directive" minOccurs="0" maxOccurs="unbounded"/>        <xs:element ref="payload" minOccurs="0" maxOccurs="1"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="directive">    <!--  Base and Prefix represented directly in XML    -->    <xs:complexType>      <xs:sequence>        <xs:element ref="Import"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="payload">    <xs:complexType>      <xs:sequence>        <xs:element name="Group" type="Group-contents"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="Import">    <!--  Import    ::= IRIMETA? 'Import' '(' IRICONST PROFILE? ')'    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>         <xs:element ref="location"/>        <xs:element ref="profile" minOccurs="0" maxOccurs="1"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="location" type="xs:anyURI"/>   <xs:element name="profile" type="xs:anyURI"/>  <xs:element name="sentence">   <xs:complexType>     <xs:choice>       <xs:element name="Group" type="Group-contents"/>       <xs:group ref="RULE"/>       </xs:choice>   </xs:complexType>  </xs:element>        <xs:element name="Implies">    <!--  Implies   ::= IRIMETA? ATOMIC  ':-' FORMULA    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="if"/>        <xs:element name="then" type="then-part"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="if">    <xs:complexType>      <xs:sequence>        <xs:group ref="FORMULA"/>      </xs:sequence>    </xs:complexType>  </xs:element>  <xs:complexType name="And-then.type">    <!-- sensitive to then (And) context-->    <xs:sequence>      <xs:element name="formula" type="formula-then.type" minOccurs="0" maxOccurs="unbounded"/>    </xs:sequence>  </xs:complexType>   <xs:complexType name="formula-then.type">    <!-- sensitive to then (And) context-->    <xs:choice>     <xs:element  ref="Atom"/>     <xs:element  ref="Frame"/>    </xs:choice>  </xs:complexType> </xs:schema>