RIF Production Rule Dialect

1 Overview

1.1 Introduction

Editor's Note: General introduction to be developed. 1.2 Overview of RIFThis document specifies the production rule dialect TBD 1.2.1 RIF-PRD as anof the W3C rule interchange format (RIF-PRD). It is mostly intended for production rules Editor's Note: Overviewthe designers of PRD and its semantics to be developed 1.2.2RIF-PRD implementations.

As a Web language To make RIF dialects suitable as Webcommon XML serialisation format for many production rule languages, RIF supportsRIF-PRD specifies an XML Schema primitive data typessyntax for the most widely used features (section [ Syntax]), and some other data types. In addition, RIF promotesthe use of Internationalized Resource Identifiers (or IRI s) RFC 3987operational semantics that RIF-PRD constructs are intended to referrepresent (section [ Operational semantics]). Production rules are rules where the part that describes the consequence of condition being satisfied specifies actions rather than logical statements. Production rules, in general, are not amenable to individuals, predicates,a model theory and, followingly, the intended semantics of rules and functions.set of rules serialized as RIF-PRD is specified operationally, in this document.

Editor's Note: DoesThis still make sense? 1.2.3 Compatibility with other RIF dialects TBD 1.2.4 Syntaxes Inworking draft specifies the RIF-PRD serialisation of a set of core constructs only. Future versions of this document wewill introduce three related but distinct representations for RIF-PRD components: 1.2.4.1 XML syntax This syntax isextend the normative XML serializationset of RIF-PRD. It is meant, and has been designed,RIF-PRD constructs to work as a common XML serialisation for manycover the most widely used features of production rule languages. Three kinds of syntactic components are used to specify RIF-PRD: Abstract classes are defined only by their subclasses: they not visible inThe XML markup and can be thought of as extension points. In this document, abstract constructs willworking group seeks feedback on what features should be denoted with all-uppercase names; Concrete classes have a concrete definitionsupported by RIF-PRD and they are associated with specific XML markup. In this document, concretewhat constructs will be denoted with CamelCase names with leading capital letter; Properties ,should or roles , define how two classes relateshould not be required from conformant RIF-PRD implementations.

As a RIF dialect, RIF-PRD has also been designed to each other. They have concrete definitions and are associated with specific XML markup.maximise inter-operability between rule languages over the World Wide Web. In this document, properties will be denoted with camelCase names with leading smallcase letter;draft, this is achieved by sharing the same XML syntax is specifiedfor each component as a pseudo-schemas, as part ofthe descriptionsubset of RIF documents where the component. The pseudo-schemas use BNF-style conventionssemantics intended 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 assigneda value which corresponds to their type, as definedproduction ruleset serialised in the normative schema. Elements are conventionally assigned a value which is the nameproduction rule dialect of RIF, RIF-PRD, and the syntactic class of their content, as definedsemantics intended for a logic rule base serialised 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 > The BNF-like pseudo schema are not normative: the XML schema is normative. 1.2.4.2 Presentation syntax A presentation syntax is also specified, to allow a more easily readable presetationbasic logic dialect of RIF-PRD language fragments (such as examples etc).RIF, RIF-BLD, agree. The presentation syntaxcorrespondance between RIF-PRD and RIF-BLD is used mainlydetailled in [ Appendix: Compatibility with RIF-BLD].

Editor's Note: Future versions of this working draft will draw on other RIF documents to specifymaximise inter-operability with othe rule languages, most noticeably the intended semantics of RIF-PRD rulesets. It is non normative. 1.2.4.3 Structural diagramRIF data types and builtins specification (RIF-DTB) and the overall structure ofRIF extensibility framework (currently being specified by the syntax of RIF-PRD isworking group; see also presented as an UML-like diagram in appendix [ XXX].the diagram provides an overview of RIF-PRD syntactic classes and shows atRIF framework for logic dialects (RIF-FLD) that specifies a glance how they relate to each others. 1.3 Overview of this document TBD 1.3.1framework for designing RIF logic dialects).

1.2 Notational conventions

1.2.1 Namespaces

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

1.2.2 BNF pseudo-schemas

The Hen Handler developed a very sophisticated program to grow feeble chicks intoXML syntax of RIF-PRD is specified for each component as a pseudo-schemas, 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>

1.3 Running example

Jim the Hen Handler developed a very sophisticated program to grow feeble chicks into deliciously plump chickens for a minimal cost. Jim publishes his method on his Web site www.juicychicken.org. Since he is still experimenting to improve his method, the rules to follow change quite often, and Jim decided to publish them in RIF as well, so that his followers can easily, even automatically, implement the very latest version.

Jim's latest addition to his knowledge base is the following advice:

Except on Tuesdays, every potato owned by a chicken gets mashed, and the daily grain allowance of every chicken that owns a potato is increased by 10%, if the chicken is older than 8 months, the potato's weight (in decigrams) is more than half the chicken's age (in months), and there is no fox in the hen house. Do not forget to delete the mashed potatoes from the ownership table!

Jim calls it the "Chicken and Mashed Potatoes", or CMP, rule. Rephrased in a more "rule-like" form, the rule could read like:

Rule ChickensAndMashedPotatoes:

Forall ?c, where ?c is a chicken and the age of ?c in months is > 8;

Forall ?p, where ?p is a potato, ?p is owned by ?c, and the weight in decigrams of ?p > (age of ?c)/2;

If today is not Tuesday, and there is no fox in the hen house

Then mash ?p, increase the grain allowance of ?c by 10%, and remove the couple (?c, ?p) from the ownership relation.

The CMP rule is a production rule: that is, when the rule is implemented and the condition is satisfied, the consequence is that some actions are executed (mashing potatoes, modifying a chicken's regime, managing ownership relations etc). Therefore, it is best interchanged using the production rule dialect of RIF, and Jim the Hen Handler's method, and especially his "chicken and mashed potatoes" rule and components thereof, will be used as a running example in this document.

To make sure that his rules can be implemented unambiguously, Jim (the Hen Handler, not the chicken) published a data model (e.g., an XML schema) that identifies Chicken and Potato as two classes of objects:

• instances of Chicken represent individual chickens. They have a property called age that represents the chicken's age in months as an xs:decimal and a property called allowance that represent the chicken's daily grain allowance as an xs:integer;
• instances of Potato represent individual potatoes. They have a property called weight that represents the potato's weight in decigram as an xs:decimal.

Jim further specifies:

• a data type DayOfTheWeek that specifies the days of the week as a subset of xs:string
• a binary predicate owns(?o ?i) that denotes the ownership relation between owner ?o and owned item ?i;
• a nullary function today() that returns the day of the week as a DayOfTheWeek;
• a boolean fox sensor foxAlarm() that returns true if and only if the fox is in the hen house;
• and a command mash(?i), which execution results in the physical item that is denoted by ?i being reduced to a soft pulpy state by beating or pressure (and removed from the instances of its class, as a consequence).

All these (types and names) are defined in Jim's namespace, which is represented in this document by the prefix jim:.

2 Syntax

2.1 Condition LanguageIn this section specifies thedocument, three related but distinct representations for RIF-PRD components are introduced:

• XML syntax. This syntax that is used to represent the different boolean expressions that can be found in production rules. The languageis calledthe languagenormative XML serialization of conditions , becauseRIF-PRD. It extends the language of conditions of [ RIF-Core], that determines what can appearis meant, and has been designed, to work as a condition in acommon XML serialisation for many production rule supported by RIF-Core. The language plays a similar rolelanguages. It is specified in RIF-PRD.the most basic constructfollowing subsection using textual descriptions and BNF pseudo-schemas. A normative XML schema will also be provided in RIF isfuture versions of the TERMdocument.
• Presentation syntax. The TERM is an abstract construct, concretly visible, in RIF-PRD, as a Const ,A Var or an External . The ATOMICpresentation syntax is the basic building blockalso specified, to allow a more easily readable presetation of RIF. ATOMIC is an abstract class: it is visible inRIF-PRD language fragments (such as either an Atom , an Equal , a Member , a Subclass or a Frame . Each kind of ATOMICexamples etc). The presentation syntax is a composition of TERM s.non normative.
• Structural diagram. The next level of constructs are assembliesoverall structure of ATOMIC s. Together,the various kindssyntax of assemblies form the abstract construct FORMULA .RIF-PRD knows six kinds of FORMULA s: the single ATOMIC , the External lly evaluated atomic relation, and the recursively specified And , Or , Naf and Exists . The following sections specify each construct separately, grouped by abstract syntactic classes. Each elementis given an XML syntax, in the form ofalso presented as an informative BNF pseudo schema: the normative XML syntax is givenUML-like diagram in theappendix [ RIF-PRD XML schema]. 2.1.1 TERMStructural diagram]. The TERM classdiagram provides an overview of constructs is used to represent constants, variablesRIF-PRD syntactic classes and the applicationshows at a glance how they relate to each others. It is provided for informative purposes only.

Three kinds of function symbolssyntactic components are used to other TERM s. As anspecify RIF-PRD:

2.1 Condition Language

This section specifies the Const constructXML syntax that is used to represent a constant. The Const element has a required type attribute and an optional xml:lang attribute:the value ofdifferent boolean expressions that can be found in production rules. The type attributelanguage is called the name of the Const type. It must be an absolute IRI;condition language by reference to the xml:lang attribute,condition longuage of [ RIF-BLD], that determines what can appear as defineda condition in a rule supported by 2.12RIF-BLD. The language Identification of XML 1.0 or its successor specificationsplays a similar role in RIF-PRD and both dialects share the W3C recommandation track, is optionally used to identifysame construct everywhere they agree on the language forsemantics.

The presentation ofmost basic construct in RIF is the Const toTERM. The user. ItTERM is allowed onlyan abstract construct, concretly visible, in association with constants of the type rif:text .RIF-PRD, as a compliant implementation MUST ignoreConst, a Var or an External.

The xml:lang attribute ifATOMIC is the typebasic building block of the ConstRIF. ATOMIC is not rif:textan abstract class: it is visible in RIF-PRD as either an Atom, an Equal, a Member, a Subclass or a Frame. Each kind of ATOMIC is a composition of TERMs.

The contentnext level of constructs are assemblies of ATOMICs. Together, the Const element isvarious kinds of assemblies form the constant's symbol, which can be any Unicode character string. Editor's Note:abstract construct FORMULA. RIF-PRD knows six kinds of FORMULAs: the single ATOMIC, the Externallly evaluated Atom or should constant litterals be limited to xs: NormalizedString instead? <Const type=" IRI " [xml:lang=" xs:language "]? > Any Unicode string </Const>Frame, and the recursively specified And, Or, NmNot and Exists.

The following sections specify each construct separately, grouped by abstract syntactic classes.

Editor's Note: The following (until and exclusing examples,RIF-PRD condition language is still under discussion. Future version of this document will be revised basedspecify additional constructs to increase the expressive coverage of RIF-PRD, and the precise syntax of some constructs may change. The working group seeks feedback on which additional constructs and/or which extension of specified constructs would be most useful to add.

2.1.1 TERM

The contentTERM class of DTB document. Constant types. RIF-PRD conformant implementations MUST supportconstructs is used to represent constants, variables and the following builtin constant types: xsd:long ( http://www.w3.org/2001/XMLSchema#long ),application of function symbols to other TERMs.

As defined in the documentan abstract class, TERM is not associated with specific XML Schemamarkup in RIF-PRD instance documents. It is specified in the normative schema as a substitution group.

    [ Const | Var | External ]

2.1.1.1 Const

In RIF, the Const construct is used to represent a constant.

The Const element has a required type attribute and an optional xml:lang attribute:

2.1.1.2 Var

In RIF, the Var construct is used to represent variables.

The content of the Var element is the variable's name, represented as an Unicode character string.

     Editor's Note: Shouldn't variable's names rather be limited to be, e.g. xs:NMTOKEN?<Var>  xs:NMTOKENany Unicode string </Var>

Editor's Note: Or should Var have a type attribute (and we could, maybe, get rid of the Member construct)? Editor's Note: Difference wrt RIF-BLD: RIF-BLD says only that a Var element contains a VARNAME. However, most implemented rule languages enforce some syntactic restrictions on the name of variables and requiring all RIF implementations to support any Unicode string as VARNAMEs might be an additional burden with little benefits associated. This is a proposed alternative: whatever the decision, BLD and PRD should use the same definition.2.1.1.3 External

As a TERM, an External element is used to represent an evaluated function. Editor's Note: builtinexternally specified function, evaluatede.g. a builtin, a user-defined function, or fixed interpretation function... need consistent terminology (Gary)a query to an external data source...

The External element contains one content element, which in turn contains one Expr element that contains one op</tt>op element, followed by zero or more arg elements:

• The content and Expr element ensure compatibility with [ RIF Basic Logic Dialect], that allows non-evaluated (that is, logic) functions to be represented by an Expr element;
• The content of the op element must be a construct from the TERM abstract class.Const. When the External is a TERM, the content of the op element represents a function symbol;
• Editor's Note: Or should the op element be restricted to contain a Const element only?The content of the arg elements must be constructs from the TERM abstract class. The order of the arg elements is significant and MUST be preserved.

    <External>
       <content>
          <Expr>
             <op>  TERMConst </op>
             <arg> TERM </arg>*
          </Expr>
       </content>
    </External>

Editor's Note: Difference wrt RIF-BLD: This version of the PRD draft does not use named argument UNITERMs. Editor's Note: Difference wrt RIF-BLD: Since PRD does not have logical function (non-External Expr, in BLD), it could be a good case for fallbacks to replace, in PRD, the <External><content><Expr> cascade by a single equivalent <Function> element.Builtin functions. RIF-PRD specifies a subset of XPath/XQuery Functions and Operators [X F&O] that any conformant RIF-PRD implementation MUST support. The RIF-PRD builtin functions are listed in the [ Data Type and Builtins] document.

Editor's Note: TBC how to reference non-builtin evaluated functionsThe op TERMop Const must represent a constant symbol of type rif:iri that must uniquely identify the evaluated function to be applied to the arg TERMs. It can be one of the builtin functions specified for RIF-PRD, or it can be application specific. In the latter case, it is the responsibility of the producers and consumers of RIF-PRD rulesets that reference non-builtin functions to agree on their semantics.

Examples.

a. The first example below shows one way to represent, in RIF-PRD, the sum of integer 1 and variable ?X, where the addition conforms to the specification of the builtin fn:numeric-add.

2.1.2 ATOMIC

The ATOMIC class is used to represent atomic truth-valued statements. RIF-PRD covers rule languages in which the truth values of atomic statements can only be "true" or "false": that is, ATOMICs represent boolean statements. Dialects extending RIF-PRD may support additional truth values.

As an abstract class, ATOMIC is not associated with specific XML markup in RIF-PRD instance documents. It is specified in the normative schema as a substitution group.

     Editor's Note: ...Substitution group or another construct, depending on how we handle extensibility in the XML schema.[ Atom | Equal | Member | Subclass | Frame ]

2.1.2.1 Atom

In RIF, the Atom element is used to represent a relation (or predicate).

The Atom element contains one op element, followed by zero or more arg arguments:

• The content of the op element must be an element of the TERM class of construct.a Const. It represents the predicate symbol (the name of a relation);
• The content of the arg elements must be constructs from the TERM abstract class. The order of the arg elements is significant and MUST be preserved.

    <Atom>
       <op>  TERMConst </op>
       <arg> TERM </arg>*
    </Atom>

Editor's Note: Difference wrt RIF-BLD: Not sure what is the support for relational atoms where the predicate would not be a constant, among production rule languages: should op be restricted to be a Const ? Depending on the answer, it might make sense for PRD to differ from BLD here. The benefits and drawbacks (e.g. wrt the definition of Core) have to be weighted. Editor's Note: Difference wrt RIF-BLD: Named arguments Atoms are not included in this draft.Example. The example below shows the RIF XML representation of the predicate owns(?c ?p), where the predicate symbol owns'owns is defined in the example namespace denoted by the prefix jim:.

<Atom>
   <op> <Const type="rif:iri"> jim:owns </Const> </op>
   <arg> <Var> ?c </Var> </arg>
   <arg> <Var> ?p </Var> </arg>
</Atom>

2.1.2.2 Equal

In RIF, Equal is used to represent equality relations.

The Equal element must contain two unordered side elements. The content of each side element must be a construct from the TERM abstract class. The order of the side elements is not significant and must not be preserved.

    <Equal>
       <side> TERM </side>
       <side> TERM </side>
    </Equal>

2.1.2.3 Member

In RIF, the Member element is used to represent membership relations.

The Member element contains two unordered sub-elements:

• the objectinstance elements must be a construct from the TERM abstract class. It is required;
• the class element must be a construct from the TERM abstract class. It is required as well.

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

Editor's Note: Difference wrt RIF-BLD: object and class make more sense to me as the roles in a membership relation than BLD's lower and upper . But, as noticed earlier, the discussion about naming is still to be had, and I do not care that much about label's names anyway... This is a proposed alternative: whatever the decision, BLD and PRD should use the same definition.Example. The example below shows the RIF XML representation of a bollean expression that tests whether the individual denoted by the variable ?c is a member of the class Chicken that is defined in the example namespace denoted by the prefix jim:.

<Member>
    <object><instance> <Var> ?c </Var>  </object></instance>
   <class> <Const type="rif:iri"> jim:Chicken </Const> </class>
</Member>

2.1.2.4 Subclass

In RIF, the Subclass element is used to represent class inclusion relations.

The Subclass element contains unordered two sub-elements:

• the subClasssub element must be a construct from the TERM abstract class. It is required;
• the classsuper elements must be a construct from the TERM abstract class. It is required.

    <Subclass>
        <subClass><sub> TERM  </subClass> <class></sub>
       <super> TERM  </class></super>
    </Subclass>

Editor's Note: Difference wrt RIF-BLD: BLD's lower and upper make more sense. I kept class for the upper element for consistency with the Member element, and subClass seemmed to make more sense, associated with class than lower would. But, again, I am not religious about tags. This is a proposed alternative: whatever the decision, BLD and PRD should use the same definition.2.1.2.5 Frame

In RIF, the Frame construct is used to represent relations that hold between an individual, also called an object, and the values of some its properties or attributes: that is, object-attribute-value triples.

Accordingly, a Frame element must contain:

• an object element, that contains an element of the TERM abstract class, the content of which represents the individual;
• zero to many slot elements, each containing a Prop element that represents an attribute-value pair as:
  • a key element that contains an element of the TERM abstract class that represents the name of the attribute (or property);
  • a val element, that contains an element of the TERM abstract class, the content of which represents the attribute's value.

    <Frame>
       <object> TERM </object>
       <slot> Prop </slot>*
    </Frame>

    <Prop>
       <key> TERM </key>
       <val> TERM </val>
    </Prop>

Example. The example below shows the RIF XML syntax of an expression that states that the object denoted by the variable ?c has the value denoted by the variable ?a for the property Chicken/age that is defined in the example namespace.

<Frame>
   <object> <Var> ?c </Var> </object>
   <slot> 
      <Prop>
         <key> <Const type="rif:iri"> jim:Chicken/age </Const> </key>
         <val> <Var> ?a </Var> </val>
      </Prop>
   </slot>*
</Frame>

Editor's Note: UsedThe example uses an XPath style for the key. This has toHow externally specified data models and their elements should be discussed, of course.referenced is still under discussion (see [ ISSUE-XXX]).

2.1.3 FORMULA

The FORMULA class is used to represent any truth-valued statement, atomic or not, that is allowed in the condition part of a rule covered by RIF-PRD. In rule languages covered by RIF-PRD, the truth values of statements can be "true" or "false": that is, FORMULAs can only represent boolean statements.

Dialects extending RIF-PRD may support additional truth values.

As an abstract class, FORMULA is not associated with specific XML markup in RIF-PRD instance documents. It is specified in the normative schema as a substitution group.

     Editor's Note: ...Substitution group or another construct, depending on how we handle extensibility in the XML schema.[ ATOMIC | External | And | Or | NmNot | Exists ]

Editor's Note: Difference wrt RIF-BLD: a RIF-PRD without a construct for closed-world negation would not make mush sense; hence the addition, wrt BLD, of the non-monotonic (inflationary) negation NmNot construct. This construct is specific to PRD.2.1.3.1 ATOMIC

A FORMULA can be a single ATOMIC statement. See specification of [ ATOMIC], above.

2.1.3.2 External

In RIF-PRD, an External represents an evaluatedexternally specified predicate when it is a FORMULA (as opposed to a TERM; that is, in particular, when it appears in a place where a FORMULA is required, and not a TERM).

The External element contains one content element that contains one Atom element:

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

Builtin predicates. RIF-PRD specifies a subset of XPath/XQuery Functions and Operators [X F&O] that any conformant RIF-PRD implementation MUST support. The RIF-PRD builtin predicates are listed in the[the [ Data Types and Builtins] document.

Editor's Note: TBC how to reference non-builtin evaluated predicatesThe op TERMop Const in the Atom element must representbe a constantsymbol of type rif:iri that must uniquely identify the evaluated predicate to be applied to the arg TERMs. It can be one of the builtin predicates specified for RIF-PRD, or it can be application specific. In the latter case, it is up to the producers and consumers of RIF-PRD rulesets that reference non-builtin predicates to agree on their semantics.

2.1.3.3 And

A FORMULA can represent the conjunction of zero of more statements, each of them represented by a FORMULA. This is represented by the And construct.

The And element contains zero or more formula elements, each containing an element of the FORMULA group.

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

2.1.3.4 Or

A FORMULA can represent the disjunction of zero of more statements, each of them represented by a FORMULA. This is represented by the Or construct.

The Or element contains zero or more formula elements, each containing an element of the FORMULA group.

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

2.1.3.5 NmNot

A FORMULA can represent the non-monotonic negation of a statement, itself represented by a FORMULA: this is represenetd by the NmNot construct.

The NnNot element contains exactly one formula element. The formula element contains an element of the FORMULA group, that represents the negated statement.

    <NnNot>
       <formula> FORMULA </formula>
    </NmNot>

Editor's Note: Difference wrt RIF-BLD: that construct is specific to RIF-PRD. I used a different name form the two kinds of negations specified in FLD (Not and Naf) for fear of snippers: naming remains to be discussed, anyway.2.1.3.6 Exists

In RIF, the Exists construct is used to represent an existentially quantified FORMULA.

The Exists element contains:

• one or more declare sub-elements, each containing a Var element that represents one of the existentially quantified variables;
• exactly one required formula sub-element that contains an element from the FORMULA abstract class: the FORMULA represents the formula in the scope of the quantifier.

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

Example. The example below shows the RIF XML representation of a boolean expression that tests whether the chicken denoted by variable ?c is older than 8 months, by testing the existence of a value, denoted by variable ?a, that is both the age of ?c, as represented by a Frame as in example XX, and greater than 8, as represented by an External ATOMIC as in example YY.

<Exists>
   <declare> <Var> ?a </Var> </declare>
   <formula>
      <And>
         <Frame>
            <object> <Var> ?c </Var> </object>
            <slot> 
               <Prop>
                  <key> <Const type="rif:iri"> jim:Chicken/age </Const> </key>
                  <val> <Var> ?a </Var> </val>
               </Prop>
            </slot>*
         </Frame>
         <External>
            <content>
               <Atom>    
                  <op> <Const type="rif:iri"> op:numeric-greater-than </Const> </op>
                  <arg> <Var> ?a </Var> </arg>
                  <arg>  <Const type="xsd:decimal"> 8 </Const> </arg>
               </Atom>
            </content>
         </External>
      </And>
   </formula>
</Exists>

2.2 Actions

This section specifies the XML syntax that is used in RIF-PRD to represent what can appear in the action part of a rule supported by RIF-PRD.

Editor's Note: Difference wrt RIF-BLD: all the constructs in this section are specific to RIF-PRD.

Editor's Note: What about truth maintenance capabilities in many PR systems?

RIF-PRD defines one single abstract class for actions: ACTION, that is realised by five concrete constructs:

• the Assert, RemoveRetract and Update constructs are associated with an ATOMIC that represents the target of the eponym actions;
• the Execute construct is associated with a TERM that identifies the operation to be executed, and zero or more TERMs that represent the arguments with which the operation is to be executed;
• the Assign construct is associated with a Frame that represents the target object and slot, as well as the new value to be assigned.

Editor's Note: Should other actions be considered in RIF-PRD? Esp., do we need some basic programatic constructs, such as a loop?

2.2.1 ACTION

The ACTION class of constructs is used to represent the individual actions in the action part of a production rule represented in RIF-PRD.

This version of RIF-PRD covers five ACTIONs: Assert, RemoveRetract, Update, Execute and Assign.

As an abstract class, ACTION is not associated with specific XML markup in RIF-PRD instance documents. It is specified in the normative schema as a substitution group.

Editor's Note: ...Substitution group or another construct, depending on how we handle extensibility in the XML schema.

    [ Assert |  RemoveRetract  | Update  | Execute  | Assign ]

2.2.1.1 Assert

The Assert construct is used to represent actions that result in asserting an atomic statement.

The Assert element has one target sub-element that contains a construct from the ATOMIC group, which represents the atomic statement to be asserted on implementing the action. The Equal construct is not allowed as the target of an Assert

Editor's Note: Are there other restrictions on the kind of ATOMIC that can be Assert-ed? Shall we allow Member and Subclass ATOMICs to be Assert-ed? Or should we make no restriction: the assertion of an Equal might be well-formed, after all; its assertion might have unexpected results, but is that RIF's concern?

Editor's Note: Issues: ATOMIC might not be the right way to represent the target anyway: what about the case where a new individual has to be created? Use, by convention, the assertion of an anonymous frame (that is, a frame where the object is the name of a class, not an individual)?

Editor's Note: Or remove the Assert construct and interpret an ATOMIC as an ACTION as an assert? That would improve PRD/BLD/Core compatibility at the synatctic level. What would be the drawbacks?

    <Assert>
       <target> ATOMIC </target>
    </Assert>

2.2.1.2 RemoveRetract

The RemoveRetract construct is used to represent actions that result in negating an atomic statement.

The RemoveRetract element has one target sub-element that contains a construct from the ATOMIC group that represents the atomic statement to be removed on implementing the action.

Editor's Note: Are there any restriction on the kind of ATOMIC that can be removed? E.g. what would it mean to remove an Equal? Should we allow a Member or a Subclass ATOMIC to be Remove-ed?Retract-ed?

Editor's Note: Issue: ATOMIC might not be the right way to represent the target anyway: e.g. how to RemoveRetract an individual (if empty Frames are not allowed)?

     <Remove><Retract>
       <target> ATOMIC </target>
     </Remove></Retract>

Editor's Note: Issue: How to removereatrct multiple facts at once? E.g. RemoveRetract-ing an individual: use empty frames (if allowed) as a convention?

Example. The example below shows the RIF XML representation of an action that updates the chicken-potato ownership table by removing the predicate that states that the chicken denoted by variable ?c owns the potato denoted by variable ?p. The predicate is represented as in example XX.

 <Remove><Retract>
   <target>
      <Atom>
         <op> <Const type="rif:iri"> jim:owns </Const> </op>
         <arg> <Var> ?c </Var> </arg>
         <arg> <Var> ?p </Var> </arg>
      </Atom>
   </target>
 </Remove></Retract>

2.2.1.3 Update

The Update construct is used to represent actions that result in updating an atomic statement.

The Update element has one target sub-element that contains a construct from the ATOMIC group that represents the atomic statement to be updated on implementing the action.

    <Update>
       <target> ATOMIC </target>
    </Update>

From the specification of OMG PRR-OCL [ PRR]: "Some operations modify the state of objects and others do not. If the modified objects are in the scope of the engine, the engine must be notified that the objects state has been modified to be able to compute the list of eligible rules. It is not possible from the operation call to determine automatically what objects will be modified so it may be necessary in the rule to explicitly notify the engine."

Editor's Note: Issues: The Update as an action is specific to some rule engine technologies or implementations (e.g. RETE-based). Since it is required by such implementations only because of the opaque nature of the Execute actions with respect to the modification of ATOMICs, and since the specification of the procedural attachments to be Execute-ed requires a specific interchange channel anyway (as builtins or depending on an out-of-band agreement), should not the information relevant to any ATOMIC impacted by an Execute-ed procedure, and thus to required updates for engines that use them, rather be interchanged as part of the specification of said procedures? And Update not be covered by RIF-PRD, as a consequence?

2.2.1.4 Execute

The Execute is used to represent actions that result in the execution of a procedural attachment.

The Execute element has one op sub-element that represents the symbol of the procedural attachement to be executed on implementing the action, followed by zero or more arg sub-elements that represent its arguments:

• The content of the op element must be a construct of the TERM abstract class;

Editor's Note: Or should the op element be restricted to a Const instead?

• The content of the arg elements must be constructs from the TERM abstract class. The order of the arg elements is significant and MUST be preserved.

Review comment from Adrian
Or use the External construct instead (AdrianP)? But how about (i) the ambiguity with fixed interprestation predicates; (ii) asserted ATOMICs if we remove the Assert construct?

    <Execute>
       <op> TERM </op>
       <arg> TERM </arg>*
    </Execute>

Builtin operations.

   TBD 

Editor's Note: Should RIF-PRD have builtin executable operations (e.g. print etc) or should they be left to be the application specific?

Example. The example below shows the RIF-PRD XML representation of the action which execution results in the physical potato denoted by variable ?p being mashed, following the specification of the mash action in the example namespace denoted by the prefix jim:.

<Execute>
   <op> <Const type="rif:iri"> jim:mash </Const> </op>
   <arg> <Var> ?p </Var> </arg>
</Execute>

2.2.1.5 Assign

The Assign construct is used to represent actions that result in a value being assigned to a property of an individual.

The Assign element has one target sub-element that contains a Frame that represents an object-attribute-value, where the "value" has to be assigned to the "attribute" of the "object" on implementing the action.

Editor's Note: Or reuse the Equal construct (AdranP)? But that would be with a different semantics

Editor's Note: How will values be assigned to parameters (if and once we add them)?

    <Assign>
       <target> Frame </target>
    </Assign>

Example. The example below shows the RIF-PRD XML represnetation of the action that increases by 10% the value of the daily grain allowance of the chicken denoted by ?c.

<Assign>
   <target>
      <Frame>
         <object> <Var> ?c </Var> </object>
         <slot> 
            <Prop>
               <key> <Const type="rif:iri"> jim:Chicken/allowance </Const> </key>
               <val> ????Would need to declare a variable to compute 110% of its value??? </val>
            </Prop>
         </slot>*
      </Frame>
   </target>
</Assign>

Editor's Note: Really needs to define a standard syntax for getters and setters for properties, not just accessors à la Frame...

2.3 Production Rules

This section specifies the RIF-PRD constructs that are required, in addition to the [ RIF-PRD condition language] and the [ RIF-PRD action language], to represent, and interchange, complete production rules and rule sets.

The RULE construct is an abstract class: in RIF-PRD instance documents, it is either visible as a ConditionalStatement or as a Forall:

• The ConditionalStatement associates an optional FORMULA and one non-empty ordered list of ACTIONS.

Editor's Note: Difference wrt RIF-BLD: The ConditionalStatement is the Implies construct of RIF-BLD. However, the word "Implies" does not carry the appropriate meaning for RIF-PRD. The proposal is to rename the Implies in RIF-BLD (to ConditionalStatement or whatever other name that is prefered) so that RIF-BLD and RIF-PRD can inherit the same construct from Core?

• The Forall construct declares one or more Vars, and associates them with zero or more FORMULAs, as patterns that constrain the bindings of the variables, and with one RULE as the formula in its scope.

The RuleSet construct has zero or more constructs of the RULE group associated as rules.

Editor's Note: Do we need ruleset parameters, etc?

The following sections specify each construct separately, grouped by abstract syntactic classes. Each element is given an XML syntax, in the form of an informative BNF pseudo schema: the normative XML syntax is given in the [ RIF-PRD XML schema].

2.3.1 RULE

In RIF-PRD, the RULE class of constructs is used to represent rules, that is "if-then" statements, possibly universally quantified.

As an abstract class, RULE is not associated with specific XML markup in RIF-PRD instance documents. It is specified in the normative schema as a substitution group.

Editor's Note: ...Substitution group or another construct, depending on how we handle extensibility in the XML schema.

    [ ConditionalStatement | Forall ]

2.3.1.1 ConditionalStatement

The ConditionalStatement construct is used to represent the conditional statement (that is, the "if-then", or condition-conclusion, or antecedent-consequent pair) that is at the core of a rule.

The ConditionalStatement element contains zero or one if sub-element and one then sub-element:

• the optional if element contains an element from the FORMULA class of constructs, that represents the condition of the rule;
• the required then element contains a non-empty list of elements from the ACTION class of constructs. The order of the ACTION constructs in the then element is significant and MUST be preserved.

Editor's Note: Should we have an "else"-part, in addition to the if-part and the then-part? On the one hand, it is one of the rationale for separating the variable binding patterns FORMULAe from the if-part FORMULA; on the other hand, what is the support for it among the rule languages RIF-PRD aims to cover?

    <ConditionalStatement>
       <if> FORMULA </if>?
       <then>
          ACTION
          ACTION*
        </then>
     </ConditionalStatement>

Editor's Note: Difference wrt RIF-BLD: the content of the then element is specific to RIF-PRD (but PRD and BLD share the structure of the construct).

2.3.1.2 Forall

The Forall construct is used to represent universally quantified rules.

The Forall element contains:

• one or more declare sub-elements, each containing a Var element that represent one of the universally quantified variable;
• exactly one formula sub-element that represents the formula in the scope of the quantifier and that contains an element of the RULE group;
• zero or more pattern sub-elements, each containing an element from the FORMULA group of constructs that represent a constraint on the bindings of one of the Vars that are declared by the Forall.

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

Editor's Note: Difference wrt RIF-BLD: the Forall in RIF-PRD adds, wrt BLD, the pattern sub-element to associate FORMULAs to the declared Vars. One of the rationale for the Pattern sub-element is to allow "if-then-else" rules. Both differences are specific to RIF-PRD.

Example. The exmaple below shows the RIF-PRD XML representation of a simplified version of the CMP rule that reads: except on Tuesdays, every potato thet belongs to a chicken is mashed, and the ownership table is updated, or

Forall ?c, where ?c is a jim:Chicken
Forall ?p, where ?p is a jim:Potato and owns(?c ?p)
If Not( jim:today() equal "Tueday"
Then mash(?p) and remove (?c ?p) from the ownership table.

Some tags and content are emphasized (bold-face) for readibility in the XML fragment below. . The complete RIF-PRD XML representation of the CMP rule can be found in [ appendix XXX].

<Forall>
   <declare> <Var> ?c </Var> </declare>
   <pattern>
      <Member>
         <object> <Var> ?c </Var> </object>
         <class> <Const type="rif:iri"> jim:Chicken </Const> </class>
      </Member>
   </pattern>
   <formula>
      <Forall>
         <declare> <Var> ?p </Var> </declare>+
         <pattern>
            <And>
               <Member>
                  <object> <Var> ?p </Var> </object>
                  <class> <Const type="rif:iri"> jim:Potato </Const> </class>
               </Member>
               <Atom>
                  <op> <Const type="rif:iri"> jim:owns </Const> </op>
                  <arg> <Var> ?c </Var> </arg>
                  <arg> <Var> ?p </Var> </arg>
               </Atom>
            </And>
         </pattern>
         <formula>
            <ConditionalStatement>
               <if>
                  &lt:NmNot>
                     <formula>
                        <Equal>
                           <side>
                              <External>
                                 <content>
                                    <Expr>    
                                       <op> <Const type="rif:iri"> jim:today </Const> </op>
                                    </Expr>
                                 </content>
                              </External>
                           </side>
                              <Const type="jim:DayOfTheWeek"> Tuesday </Const>
                           <side>
                           </side>
                        </Equal>
                     </formula>
                  </NmNot>
               </if>
               <then>
                  <Execute>
                     <op> <Const type="rif:iri"> jim:mash </Const> </op>
                     <arg> <Var> ?p </Var> </arg>
                  </Execute>
                  < RemoveRetract>
                     <target>
                        <Atom>
                           <op> <Const type="rif:iri"> jim:owns </Const> </op>
                           <arg> <Var> ?c </Var> </arg>
                           <arg> <Var> ?p </Var> </arg>
                        </Atom>
                     </target>
                   </Remove></Retract>
               </then>
            </ConditionalStatement>
         </formula>
      </Forall>
   </formula>
</Forall>

2.3.2 RuleSet

The RuleSet construct is used to represent a set of rules that have to be considered together from a semantic or operational viewpoint (e.g. a knowledge base, a rule base, a ruleset).

The RuleSet element contains zero or more rule element. Each rule element contains an element from the RULE group of constructs that represents one of the rules contained in the rule set.

Editor's Note: Shouldn't that be "at least one rule element"?

2.4 Grouping and metadata

TBD

2.5 Presentation syntax

This section specifies a presentation syntax for RIF-PRD. The presentation syntax is not normative: its main purpose is to help make the normative specification of the semantics easier to read.

The presentation syntax is specified by the following EBNF, directly in terms of names of the XML elements specified in the previous sections (and, normatively, in the [ XML schema for RIF-PRD]. Where elements with the same name are used in different context with different content, which would lead to ambiguous productions, the ambiguous name has been appended to a disambiguating, context-specific prefix: namely, the name of the containing element. Specifically, the target role in the Assign production (and element) has been renamed assign_target to differenciate it from the target role of other ACTION elements, and the formula role in the Forall production has been renamed forall_formula.

TERM                       ::= Const | Var | External
Const                   ::= LITERAL '^^' type ('@' xml:lang)?
LITERAL         ::= any Unicode string
type                    ::= IRI
xml:lang                ::= xs:language
Var                     ::= xs:NMTOKEN
External                ::= ' External( ' op ' ( ' arg* ' )) '
op                      ::= TERM
arg                     ::= TERM

ATOMIC                     ::= Atom | Equal | Member | Subclass | Frame
Atom                    ::= op ' ( ' arg* ' ) '
Equal                   ::= side ' = ' side
side                    ::= TERM
Member                  ::= object ' # ' class
object                  ::= TERM
class                   ::= TERM
Subclass                ::= subClass ' ## ' class
subClass                ::= TERM
Frame                   ::= object ' [ ' (key ' -> ' val)* ' ] '
key                     ::= TERM
val                     ::= TERM

FORMULA            ::= ATOMIC | External | And | Or | Naf | Exists
And                     ::= 'AND ( ' formula* ' ) '
formula         ::= FORMULA
Or                      ::= 'OR ( ' formula* ' ) '
NmNot                   ::= ' NOT ( ' formula ' ) '
Exists                  ::= ' Exists ' declare+ ' ( ' formula ' ) '
declare         ::= Var

ACTION                     ::= Assert |  RemoveRetract | Update | Execute | Assign
Assert                  ::= ' ASSERT ( ' target ' ) '
target                  ::= ATOMIC
 RemoveRetract         ::= '  REMOVERETRACT ( ' target ' ) '
Update                  ::= ' UPDATE ( ' target ' ) '
Execute         ::= ' EXECUTE { ' op  ' ( ' arg* ' ) } '
Assign                  ::= ' SET ( ' assign_target ' ] ) '
assign_target           ::= Frame

RULE                       ::= ConditionalStatement | Forall
ConditionalStatement    ::= (' IF ' if ' THEN ')? then
if                      ::= FORMULA
then                    ::= ACTION (' ; ' ACTION)*
Forall                  ::= ' Forall ' declare+ (' SUCH THAT ' pattern)* ' ( ' forall_formula ' ) '
pattern         ::= FORMULA
forall_formula          ::= RULE

RuleSet         ::= 'RULESET ( ' rule* ' ) '
rule                    ::= RULE

Example. The example below shows the RIF-PRD presentation syntax for the simplified version of the CMP rule shown in example XX. The RIF-PRD presentation syntax for the complete CMP rule is shows in [ appendix XX].

FORALL ?c SUCH THAT ?c#jim:Chicken^^rif:iri
  ( FORALL ?p SUCH THAT AND( ?p#jim:Potato^^rif:iri jim:owns^^rif:iri(?c ?p))
      ( IF NOT( jim:today^^rif:iri() = "Tuesday"^^jim:DayOfTheWeek )
        THEN EXECUTE( jim:mash^^rif:iri(?p) );
              REMOVE(RETRACT ( jim:owns^^rif:iri(?c ?p) )
      )
  )

3 Operational semantics

3.1 Introduction

3.2 Definitions

3.3 Operational semantics of actions

The transition relation →_RIF-PRD ⊆ P(W) × L × P(W) is defined as follows:

• ∀ w ⊆ P(W), w + ASSERT(f) →_RIF-PRD w' = w ∪ {f};
• ∀ w ⊆ P(W), w + REMOVE(f)RETRACT(f) →_RIF-PRD w' = w - f;
• ∀ w ⊆ P(W), w + UPDATE(f) →_RIF-PRD w' = TBD;
• ∀ w ⊆ P(W), w + EXECUTE(f) →_RIF-PRD w' = TBD;
• ∀ w ⊆ P(W), w + ASSIGN(f) →_RIF-PRD w' = TBD;

The intended semantics of the actions that can be represented in RIF-PRD is completely specified by the definition of the labelled transition system {P(W), L, →_RIF-PRD}.

Editor's Note: The definition of W would need to be modified if we wanted to cover non-ground facts as well, but the definition of the relation would remain essentially the same.

The relation →^*_RIF-PRD ⊆ P(W) × S(L) × P(W) denote the transitive closure of the transition relation →_RIF-PRD.

3.4 Operational semantics of rule sets

Assuming a function INSTANTIATE : P(W) × P(R) ×A R →RIF-PRD production rule system is defined as a R , that,labelled terminal transition system: given a rule set of facts, a set of rules, and an agenda, returns an agenda,RS ⊆ R, let ΓC_RS ⊆ W × S(Inst(RS)) × P(Inst(RS)) be a set of configurations, where a configuration is a triple γc = (w, a, INSTANTIATE(w, a, RS))ri_c, whereh), such that w ⊆ W is a set of facts, ari_c ∈ AS(Inst(RS)) is an agenda, andordered instance of RS ⊆ R, and h ∈ P(Inst(RS)) is a rule set.an instance of RS. Given a configuration γc = (w, a, a γ )ri_c, h), let w(γ)facts(c) denote the first element, the set of facts w; let history(γ)instance(c) denote the second element, the input agenda aordered ruleset instance, ri_c; and let agenda(γ)history(c) denote the third element, the new agenda, a γ , produced by INSTANTIATEset of rule instances h.

Assuming two more functions: PICK : Γ RS × P(R) → S(L) × P(Inst(R)) , that, givenThe idea is that a configuration andconfiguration, c, is made of a set of rules, returns an ordered listset, w, of ground actions andFORMULAe that represent a setstate of rule instances; FINAL : Γ RS × P(R) → {true, false}facts; the set, ri_c, that, given a configurationof all the instances of the rules in the considered ruleset RS that are satisfied, in some sense to be further specified, in that state of fact; and a setset, h of rules, returns true or false ; The idea isrule instances that PICK returnsrepresent a part of the sequencehistory of actionsthe system, in that it collects the inputrule set is intendedinstances that determined some of the actions that led to produce inthe inputpresent configuration, and that have been satisfied, in the same sense as well asbefore, in all the setstates of rule instances that determinedfacts that sequence of actions.have been traversed since. In the same way, FINAL is meant to return true ifthe input configuration is intended to be final, givenorder among the inputrule set, and false otherwise.instances, in ri_c, represents another part of the system's history: the longer a rule instance has been continuously satisfied by the states of facts of the traversed configurations, in terms of number of configurations, the farther it is in the ordering. These elements of the history of the system are relevant when selecting the next transition.

Let updateAgendafurther assume three functions:

• INSTANTIATE: A RP(W) × P(Inst(R))P(R) → A RP(Inst(R)), a functionthat, given an agendaa set of facts, w and a set rsinstof rule instances, marks as fired , in arules, RS, returns the set of all the ruleinstances that belong to rsinst : update(a, rinst) = {(ri, mark) | ((ri, m') ∈ a) and (mark = fired, if ri ∈ rsinst; or mark = m' otherwise )} . Editor's Note: What is the appropriate presentation for the "case" definitionof the value of markrules in RS that are satisfied in w, in the definitiona sense that is determined by the specification of updateAgenda ?the function;
• PICK: C_RS × S({priority, recency, all}) → P(Inst(R)), that, given a configuration, c, and a selection strategy, returns the ordered subset, ori ⊆ instance(c), selected according to the input strategy, of the rule instances that determine the ordered list of ground actions to be implemented, that is, the sequence of transitions to be executed from the input configuration;
• FINAL: C_RS × P(R) → {true, false}, that, given a configuration and a set of rules, returns true or false, depending on whether or not the configuration is terminal.

Let mergeInstances: S(Inst(R)) × P(Inst(R)) → S(Inst(R)), be a helper function that, given an ordered set of rule instances, ori, and an unordered set of rule instances, ri, returns ri, ordered in such a way that the order of ori is preserved among all the rule instances in ri ∩ ori, and the rule instances in ri - ori come first in the order.

Let extractActions: S(Inst(R)) → S(L), be another helper function that, given an ordered set, ori, of rule instances, returns the sequence of ACTIONs that is the concatenation, preserving the order in ori, of the sequences of ground actions determined by each of the rule instances in ori.

Given a ruleset RS and a selection strategy LS, a RIF-PRD production rule system is defined as a labelled terminal transition system where: ΓPRS_RS,LS = {C_RS, S(L), →_RS, T_RS}, where :

• C_RS is the set of configurations;
• S(L) is the set of labels;
• The transition relation →_RS ⊆ ΓC_RS × S(L) × ΓC_RS, is defined as follows:
  ∀ (γ,(c, s, γ')c' ) ∈ ΓC_RS × S(L) × ΓC_RS, (γ,(c, s, γ')c' ) ∈ →_RS if and only if all of the following hold:
  1. PICK(γ, RS)s = (s, pickedInst)extractACTIONS(PICK(c, LS))
  2. and (w(γ),(facts(c), s, w(γ'))facts(c')) ∈ →^*_RIF-PRD
  3. and a(γ')instance(c') = updateAgenda(agenda(γ), pickedInst)mergeInstances(instance(c), INSTANTIATE(w, RS))
  4. and γhistory(c') = (history(c) ∩ instance(c)) ∪ PICK(c, LS)
  5. and c ∉ T_RS
• A configuration γc is final iff FINAL(γ,FINAL(c, RS) = true: T_RS = {γ{c ∈ ΓC_RS | FINAL(γ,FINAL(c, RS) = true}.

Intuitively, the conditions 1 and 2in the definition of the transition relation →_RS sayguarantees that there must be a path, according toonly the relation → RIF-PRDspecification of the function PICK and the selection strategy determine which are the allowed transition paths out of a given configuration, and condition 2 guarantees that specifiesall transitions are compliant with the semantics of the individual actions, leading fromas specified the setrelation →_RIF-PRD. Condition 3 guarantees that the instance component of facts w = w(γ) toany reachable configuration contains all the setinstances of facts w' = w(γ') ,the rules in RS that implementsare satisfied in the sequence sconfiguration's state of actions returned by PICKfacts, ordered in configuration γ . Rule 3the appropriate way. Condition 4 means that the systems keeps a memory of the rule instances which action part has been executed.executed, and that have been been part of the instances returned by INSTANTIATE in all the configurations that have been since traversed. And condition 5 guarantees that the system halts as soon as it encounters a terminal configuration.

Or, using →^*_RS to denote the transitive closure of the transition relation:

Given the specification of PRS_RS,LS, the intended operational semantics of a production ruleset represented by a RIF-PRD RuleSet RS is, therefore,is completely specified by the specification of the three functions INSTANTIATE, PICK and FINAL.

Editor's Note: to be developed: explain, by reference to the usual description of a PRS as a match-resolve conflict-fire cycle, why 3 functions instead of only PICK and final if empty pick.3.4.1 Rules instantiation: INSTANTIATE

3.4.2 Instances selection: PICK

Editor's Note: This section is still under discussion (see [ ISSUE-XX]). This version of RIF-PRD specifies five elementary strategies, a way of combining them, and a default combination. Future working drafts may specify different and/or additional elementary strategies, and no or a different default. The Working Group seeks feedback on which instances selection strategies and which combinations of strategies should be supported by RIF-PRD and/or required from RIF-PRD implementations; and which strategy or combination should be the default, if any.

A rule instance determines a sequences of ground actions, by application of facts, w , against which the rule is evaluated;the agenda, a , that containsassociated substitution to the memory ofvariables in the systemACTIONs in termsthe then component of which rules werethe instantiated already, andrule. The decision to implement the sequence of actions determined by whichthat a rule instance determines is often called: firing the rule instance.

Most implementations of production rule languages select the rule instances where implemented already;to be fired, and, therefore, the rule, r ,sequence of actions to be instantiated;implemented, based on one or a combination of the substitution, σ , that is under evaluation asfollowing strategies (under these or other, idiosyncratic names; and possibly instantiating r in such a way that its condition matches w ;combined with additional, idiosyncratic rules):

• No-repetition. The set, Σ , ofno-repetition strategy excludes from the candidate substitutionsselection of fireable rule instances, any rule instance that are still to be evaluated, including σ ; andhas already been fired, unless the instances accumulator, acc ,instantiation environment has significantly changed since the actions have been last implemented. This is usually taken to mean that relatesthere has been at least one configuration where the identifier, id ,state of facts did not satisfy the instantiated rule, r , torule instance, in the setsense determined by the specification of the substitutions that haveINSTANTIATE function, since the rule instance has been evaluatedlast fired;
• Priority. The rule instances are ordered by priority of the instantiated rules, and only the rule instances with respect to whichthe conditionhighest priority are selected. This requires that a priority be associated with the RIF-PRD representation of r is known to match w . Ineach rule;
• Recency. the definitionrule instances are ordered by how long a rule instance has been continuously satisfied by the states of facts of the transition relation,traversed configurations, and only the most recent ones are selected.
• Random. A singleton rule instance is selected at random;
• All-at-once. All the firstrule says that, ifinstances are selected, and they are fired in the rule r toorder's sequence.

Let fireableINSTANCES: S(Inst(R)) × P(Inst(R)) × {no-repeat, priority, recency, random, all} → S(Inst(R)) be instantiated is represented bya RIF-PRD Forall that declaresfunction that, given an ordered set, ori, of candidate rule instances, a setset, h, of variables {x i } constrained byexcluded rule instances, and a setkeyword, k, indicative of patterns Pan single selection strategy, return a subset fri ⊆ ori, selected and if there is a substitution θ that agrees with σ on allordered according to the variables that are free in P , except possibly onstrategy indicated by k. The variables in {x i } , such that P matcheskeywords "no-repeat"" and "all" indicate, respectively, the no-repetition and all-at-once selection strategies, and the set of facts w with respect to θ , then,other keywords indicate each the instantiation ofstrategy by the RIF-PRD RULE thatsame name.