RIF Production Rule Dialect

W3C Editor's Draft 22 September 2008

This version:

http://www.w3.org/2005/rules/wg/draft/ED-rif-prd-20080922/

Latest editor's draft:

http://www.w3.org/2005/rules/wg/draft/rif-prd/

Previous version:

http://www.w3.org/2005/rules/wg/draft/ED-rif-prd-20080730/ (color-coded diff)

Editors:

Christian de Sainte Marie, ILOG

Adrian Paschke, Technical University Dresden

Gary Hallmark, Oracle

---

Copyright © 2008 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document 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 the W3C technical reports index at http://www.w3.org/TR/.

Set of Documents

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

1. RIF Use Cases and Requirements
2. RIF Core
3. RIF Basic Logic Dialect
4. RIF Framework for Logic Dialects
5. RIF RDF and OWL Compatibility
6. RIF Datatypes and Built-Ins 1.0
7. RIF Production Rule Dialect (this document)
8. RIF Test Cases

Please Comment By 2008-09-25

The Rule Interchange Format (RIF) Working Group seeks public feedback on these Working Drafts. Please send your comments to public-rif-comments@w3.org (public archive). If possible, please offer specific changes to the text that would address your concern. You may also wish to check the Wiki Version of this document for internal-review comments and changes being drafted which may address your concerns.

No Endorsement

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Patents

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document specifies the production rule dialect of the W3C rule interchange format (RIF-PRD). Production rules are rules with an "if" part and a "then" part. The "if" part, also called a "condition", is like the condition part of logic rules (as covered by the basic logic dialect of the W3C rule interchange format, RIF-BLD). The "then" part of production rules may contain actions, unlike the conclusion of logic rules that may contain only a logical statement. Actions can modify the knowledge base and have other side-effects.

Example 1.1. A customer becomes a "Gold" customer as soon as his cumulative purchases during the current year top $5000; Customers that become "Gold" customers must be notified immediately, and a golden customer card will be printed and sent to them within one week; For shopping carts worth more than $1000, "Gold" customers receive an additional discount of 10% of the total amount are all examples of production rules.

As a common XML serialisation format for many production rule languages, RIF-PRD specifies an XML syntax for the most widely used features (section 2 - Syntax), and the operational semantics that RIF-PRD constructs are intended to represent (section 3 - Operational semantics).

This document is mostly intended for the designers and developers of RIF-PRD implementations, that is, applications that serialize production rules as RIF-PRD XML (producer applications) and/or that deserialize RIF-PRD XML documents into production rules (consumer applications).

Editor's Note: This working draft specifies the RIF-PRD serialisation of a set of core constructs only. Future versions of this document will extend the set of RIF-PRD constructs to cover the most widely used features of production rule languages. The working group seeks feedback on what features should be supported by RIF-PRD and what constructs should or should not be required from conformant RIF-PRD implementations.

As a RIF dialect, RIF-PRD has also been designed to maximize interoperability between rule languages over the World Wide Web. In this draft, this is achieved by sharing the same syntax for the subset of RIF documents where the semantics intended for a production ruleset serialized in RIF-PRD, and the semantics intended for a logic rule base serialized in the basic logic dialect of RIF, RIF-BLD, agree. The correspondence between RIF-PRD and RIF-BLD is detailed in Appendix: Compatibility with RIF-BLD.

Editor's Note: Future versions of this working draft will draw on other RIF documents to maximize interoperability with other rule languages, most noticeably the RIF data types and builtins specification, RIF-DTB, and the RIF extensibility framework (currently being specified by the working group; see also the RIF framework for logic dialects, RIF-FLD, that specifies a framework for designing RIF logic dialects).

In the section 2, two related but distinct syntaxes for RIF-PRD components are introduced:

• XML syntax. This syntax is the normative XML serialization of RIF-PRD. It is meant, and has been designed, to work as a common XML serialisation for many production rule languages. It is also meant, and has been designed, to work as a common XML serialisation for production rule languages and logic rule languages, wherever they agree on the semantics: as a consequence, RIF-PRD and RIF-BLD share the same XML syntax wherever they agree on the semantics. The XML syntax is specified using textual descriptions and BNF pseudo-schemas. A normative XML schema will also be provided in future versions of the document;
• Presentation syntax. A presentation syntax is also specified, to allow a more easily readable presentation of RIF-PRD language fragments (such as examples etc). To make the overlap between RIF-PRD and RIF-BLD visible, RIF-PRD re-uses the presentation syntax of RIF-BLD wherever they share the same XML syntax (and agree on the semantics). The presentation syntax is non normative.

Example 1.2. In RIF-PRD presentation syntax, the first rule in example 1.1. might be represented as follows:

Prefix(ex1 http://rif.example.com/2008/prd#)
(* ex1:rule_1 *)
Forall ?customer ?purchasesYTD (
  ex1:Gold(?customer)
  :-
  And(
    ?customer#ex1:Customer
    ?customer[ex1:purchasesYTD->?purchasesYTD]
    pred:numeric-greater-than(?purchasesYTD 5000) ))

Editor's Note: As a consequence of the re-use of RIF-BLD presentation syntax, examples and fragments written in RIF-PRD non-normative presentation syntax may have an unfamiliar look to production rules developers and users. The working group seeks feedback on this issue as well.

The overall structure of the syntax of RIF-PRD is also presented as an UML-like diagram in appendix: UML-like diagram of RIF-PRD syntax. The diagram provides an overview of RIF-PRD syntactic classes and shows at a glance how they relate to each others. It is provided for informative purposes only.

In the section 3, the intended semantics for RIF-PRD constructs is specified normatively. As can be seen from the examples above, production rules, in general, are not logic rules, and they are not amenable to a model theory: followingly, the intended semantics of rules and set of rules serialized as RIF-PRD is specified operationally, in this document. The compatibility with the model theoretic semantics of RIF-BLD for the contructs they share is explained and proven in appendix: Compatibility with RIF-BLD.

Syntax such as xsd:string should be understood as a compact URI (CURIE) -- a macro that expands to a concatenation of the character sequence denoted by the prefix xsd and the string string. The compact URI notation is used for brevity only, and xsd:string should be understood, in this document, as an abbreviation for http://www.w3.org/2001/XMLSchema#string.

<!-- 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 CMP rule might be rephrased in RIF-PRD non-normative presentation syntax as follows:

 (* joe:ChickenAndMashedPotatoes *)
    // The identifier of the rule is the IRI "joe:ChickenAndMashedPotatoes"
 Forall ?chicken ?potato ?allowance ?age ?weight (
    // The Forall construct is used to declare the rule variables: "?chicken" etc
   Do(  // Rule actions list
        Execute(joe:mash(?potato))
        // The first action is to mash the potato that is bound to variable ?potato
        Retract(?chicken[joe:allowance->?allowance]) 
        ?chicken[joe:allowance->External(func:numeric-multiply(?allowance 1.1))]
        // The value of the "allowance" property of the chicken that is bound to ?chicken
        // is increased by 10%
        Retract(joe:owns(?chicken ?potato)) )
   :-   // IF
   And( // Rule conditions
        ?chicken#joe:Chicken 
        // The object bound to ?chicken is a "Chicken" as specified in Joe's object model
        ?chicken[joe:age->?age joe:allowance->?allowance]
        // The value of the "age" property of the "Chicken" object bound to ?chicken is 
        // equal to the value bound to the variable ?age, and the values of the "allowance"
        // property is equal to the value bound to ?allowance
        External(pred:numeric-greater-than(?age 8))
        // The value bound to ?age is greater than 8, where the function "numeric-grater-than"
        // is specified by RIF-PRD and must be supported by all implementations
        ?potato#joe:Potato 
        ?potato[joe:weight->?weight]
        joe:owns(?chicken ?potato)
        External(pred:numeric-greater-than(?weight External(func:numeric-divide(?age 2))))
        External(pred:string-not-equal(External(joe:today()) "Tuesday"))
        Not(External(joe:foxAlarm())) ))
      

To make sure that his rules can be implemented unambiguously, Joe 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 xsd:decimal and a property called allowance that represent the chicken's daily grain allowance as an xsd:integer;
• instances of Potato represent individual potatoes. They have a property called weight that represents the potato's weight in decigram as an xsd:decimal.

Joe further specifies:

• 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 xsd:string;
• 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 in the corresponding logical object being removed from the instances of its class, as a consequence).

All these (types and names) are defined in Joe's namespace http://rif.examples.com/2008/joe#.

The assumption is that a system that consumes a RIF document published by Joe knows how to map Joe's published data model and specification of predicates and functions to/from its own underlying data representation. What a consumer is expected to do when this is not the case is still under discussion and will be specified as a conformance clause in a future version of this document.

This section specifies the XML syntax for serializing the rule conditions and the rule actions, as well as complete production rules, groups of rules and formulae, and any accompanying metadata. Finally, RIF-PRD presentation syntax is specified.

This section specifies the XML syntax that is used to serialize, in RIF-PRD, the different boolean expressions that can be found in production rules. That syntax is sometimes called the condition language, by reference to the condition language of RIF-BLD, which determines what conditions in a logic rule can be represented in RIF-BLD. It plays a similar role in RIF-PRD and, to maximize interoperability, the two dialects share the same constructs everywhere they agree on the semantics.

The most basic construct in RIF is the TERM. The TERM is an abstract construct, concretely visible, in RIF-PRD, as a Const, a Var or an External.

The ATOMIC is the basic building block of RIF. ATOMIC is an 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 next level of constructs are assemblies of ATOMICs. Together, the various kinds of assemblies form the abstract construct FORMULA. RIF-PRD knows six kinds of FORMULAs: the single ATOMIC, the Externally evaluated Atom or 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: Future version of this document will specify 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.

    [ Const | Var | External ]

• The value of the type attribute is the identifier of the Const symbol space. It must belong to the type xsd:anyURI;
• The xml:lang attribute, as defined by 2.12 Language Identification of XML 1.0 or its successor specifications in the W3C recommendation track, is optionally used to identify the language for the presentation of the Const to the user. It is allowed only in association with constants of the type rif:text. A compliant implementation MUST ignore the xml:lang attribute if the type of the Const is not rif:text.

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

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

Constant types. RIF requires that all dialects include the following builtin constant types. Rule sets that are exchanged through RIF can use additional symbol spaces.

• xs:string (http://www.w3.org/2001/XMLSchema#string)
• xs:time (http://www.w3.org/2001/XMLSchema#time)
• xs:date (http://www.w3.org/2001/XMLSchema#date)
• xs:dateTime (http://www.w3.org/2001/XMLSchema#dateTime)
• xs:double (http://www.w3.org/2001/XMLSchema#double)
• xs:integer (http://www.w3.org/2001/XMLSchema#integer)
• xs:decimal (http://www.w3.org/2001/XMLSchema#decimal)

  The lexical spaces of the above symbol spaces are defined in the document [XML-SCHEMA2].

• xs:dayTimeDuration (http://www.w3.org/2001/XMLSchema#dayTimeDuration)
• xs:yearMonthDuration (http://www.w3.org/2001/XMLSchema#yearMonthDuration)

  These two symbol spaces represent two subtypes of the XML Schema data type xs:duration with well-defined value spaces, since xs:duration does not have a well-defined value space (this may be corrected in later revisions of XML Schema data types, in which case the revised data type would be suitable for RIF DTB). The lexical spaces of the above symbol spaces are defined in the document [XDM].

• rdf:XMLLiteral (http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral).

  This symbol space represents XML content. The lexical space of rdf:XMLLiteral is defined in the document [RDF-CONCEPTS].

• rif:text (http://www.w3.org/2007/rif#text, for text strings with language tags attached).

  This symbol space represents text strings with a language tag attached. The lexical space of rif:text is the set of all Unicode strings of the form ...@LANG, i.e., strings that end with @LANG where LANG is a language identifier as defined in [RFC-3066].

• rif:iri (http://www.w3.org/2007/rif#iri, for internationalized resource identifiers or IRIs).

  Constants in this symbol space are intended to be used in a way similar to RDF resources [RDF-SCHEMA]. The lexical space consists of all absolute IRIs as specified in [RFC-3987]; it is unrelated to the XML primitive type anyURI. A rif:iri constant must be interpreted as a reference to one and the same object regardless of the context in which that constant occurs.

• rif:local (http://www.w3.org/2007/rif#local, for constant symbols that are not visible outside of the RIF document in which they occur).

  Constants in this symbol space are local to the RIF documents in which they occur. This means that occurrences of the same rif:local constant in different documents are viewed as unrelated distinct constants, but occurrences of the same rif:local constant in the same document must refer to the same object. The lexical space of rif:local is the same as the lexical space of xs:string.

Editor's Note: The list of builtin constant types may be modified in future versions of this document, based on the content of future versions of the RIF data types and builtins document, RIF-DTB.

Editor's Note: The case of non-standard data types, that is, of constants that do not belong or cannot be cast in one of RIF builtin types for interchange purposes, is still under discussion in the WG. The WG seeks feedback on whether they should be allowed and why.

Symbols with an ill-formed lexical part. Constants that are represented in RIF in one of the aforesaid builtin types must be well-formed, i.e., their representation must belong to the lexical space associated with the type. For instance, 123^^xsd:long (that is, <Const type="xsd:long">123</Const>) has a correct lexical part, since 123 belongs to the lexical space of the data type xsd:long. In contrast, abc^^xsd:long (<Const type="xsd:long">abc</Const>) is ill-formed, as it does not have a correct lexical part. A compliant RIF-PRD translator MUST reject ill-formed symbols.

Example 2.1. In each of the examples below, a constant is first described, followed by its representation in RIF-PRD XML syntax.

a. A constant with builtin type xsd:integer and value 123:

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

b. A constant which symbol today is defined in Joe the Hen Public's namespace http://rif.examples.com/2008/joe#. The type of the constant is rif:iri:

<Const type="rif:iri">
   http://rif.examples.com/2008/joe#today
</Const>

c. A constant with symbol BigPotato that is local to the set of rules where it appears (e.g. a RuleSet specific to Paula's farm). The type of the constant is rif:local:

<Const type="rif:local">BigPotato</Const>

d. A constant with non-builtin type xsd:int and value 123:

<Const type="xsd:int">123</Const>

    <Var> any Unicode string </Var>

Notice that the content of the Var element is the Unicode string chicken: in the RIF presentation syntax, the ?-prefix is used as a syntactic marker to denote a variable identifier, but RIF leaves it to the implementations to use whatever prefix they choose or require, if any.

<Var> chicken <Var>

• The content and Expr element ensure compatibility with the RIF Basic Logic Dialect, RIF-BLD, that allows non-evaluated (that is, logic) functions to be represented by an Expr element;
• The content of the op element must be a Const. When the External is a TERM, the content of the op element represents a function symbol;
• The optional args element contains zero or more constructs from the TERM abstract class. The order of the args sub-elements is significant and MUST be preserved. This is emphasized by the required value "yes" of the required attribute rif:ordered;
• Each optional slot element contains one required Name sub-element, that contains an Unicode string that represents the slot key, and a required TERM that represents its value.

    <External>
       <content>
          <Expr>
             <op> Const </op>
             [ <args rif:ordered="yes"> TERM* </args>?
               |
               <slot rif:ordered="yes">
                  <Name> Any Unicode string </Name>
                  TERM
               <slot>* ]
          </Expr>
       </content>
    </External>

Editor's Note: The slotted, or named arguments form of the External TERM construct is still under discussion (see also ISSUE-68). The working group seeks feedback on whether or not it should be included in PRD.

Builtin functions. RIF-PRD specifies a subset of XPath/XQuery Functions and Operators (XPath-Functions) that any conformant RIF-PRD implementation MUST support. The RIF-PRD builtin functions are listed in the Data Type and Builtins document.

The op Const must represent a constant symbol of type rif:iri that must uniquely identify the evaluated function to be applied to the args 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.

Example 2.3.

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

The prefix fn is associated with the namespace http://www.w3.org/2007/rif-builtin-function#.

<External>
   <content>
      <Expr>    
         <op> <Const type="rif:iri"> fn:numeric-add </Const> </op>
         <args rif:ordered="yes"> 
            <Const type="xsd:integer"> 1 </Const>
            <Var> x </Var>
         </args>
      </Expr>
   </content>
</External>

b. Another example, that shows the RIF XML representation of a call to the application-specific nullary function today(), which symbol is defined in the example's namespace http://rif.examples.com/2008/joe#:

<External>
   <content>
      <Expr>    
         <op>
            <Const type="rif:iri">
               http://rif.examples.com/2008/joe#today
            </Const>
         </op>
      </Expr>
   </content>
</External>

    [ Atom | Equal | Member | Subclass | Frame ]

    <Atom>
       <op> Const </op>
       [ <args rif:ordered="yes"> TERM* </args>?
         |
         <slot rif:ordered="yes">
            <Name> Any Unicode string </Name>
            TERM
         <slot>* ]
    </Atom>

Editor's Note: The slotted, or named arguments form of the Atom construct is still under discussion (see also ISSUE-68). The working group seeks feedback on whether or not it should be included in PRD.

Example 2.4. The example below shows the RIF XML representation of the predicate owns(?c ?p), where the predicate symbol owns is defined in the example namespace http://rif.examples.com/2008/joe#.

<Atom>
   <op>
      <Const type="rif:iri">
         http://rif.examples.com/2008/joe#owns
      </Const>
   </op>
   <args rif:ordered="yes">
      <Var> c </Var>
      <Var> p </Var>
   </args>
</Atom>

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

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

Example 2.5. The example below shows the RIF XML representation of a boolean expression that tests whether the individual denoted by the variable ?c is a member of the class Chicken that is defined in the example namespace http://rif.examples.com/2008/joe#.

<Member>
   <instance> <Var> c </Var> </instance>
   <class>
      <Const type="rif:iri">
         http://rif.examples.com/2008/joe#Chicken
      </Const>
   </class>
</Member>

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

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

Example 2.6. 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 http://rif.examples.com/2008/joe#.

<Frame>
   <object> <Var> c </Var> </object>
   <slot rif:ordered="yes"> 
      <Const type="rif:iri">
         ttp://rif.examples.com/2008/joe#Chicken/age
      </Const>
      <Var> a </Var>
   </slot>
</Frame>

Editor's Note: The example uses an XPath style for the key. How externally specified data models and their elements should be referenced is still under discussion (see ISSUE-37).

    [ ATOMIC | External | And | Or | NmNot | Exists ]

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

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

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

The op Const in the Atom element must be a symbol of type rif:iri that must uniquely identify the evaluated predicate to be applied to the args 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.

Example 2.7. The example below shows the RIF XML representation of a boolean expression that tests whether the value denoted by variable ?a (e.g. the age of a chicken) is greater than the integer value 8, where the test is intended to behave like the builtin predicate op:numeric-greater-than as specified in XQuery 1.0 and XPath 2.0 Functions and Operators.

In the example, the prefix op: is associated with the namespace http://www.w3.org/2007/rif-builtin-predicate#.

<External>
   <content>
      <Atom>    
         <op> <Const type="rif:iri"> op:numeric-greater-than </Const> </op>
         <args rif:ordered="yes">
            <Var> a </Var>
            <Const type="xsd:decimal"> 8 </Const>
         </args>
      </Atom>
   </content>
</External>

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

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

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

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

Example 2.8. 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 2.6, and greater than 8, as represented by an External ATOMIC as in example 2.7.

<Exists>
   <declare> <Var> a </Var> </declare>
   <formula>
      <And>
         <Frame>
            <object> <Var> c </Var> </object>
            <slot rif:ordered="yes"> 
               <Const type="rif:iri">
                  http://rif.examples.com/2008/joe#Chicken/age
               </Const>
               <Var> a </Var>
            </slot>
         </Frame>
         <External>
            <content>
               <Atom>    
                  <op> <Const type="rif:iri"> op:numeric-greater-than </Const> </op>
                  <args rif:ordered="yes">
                     <Var> a </Var>
                     <Const type="xsd:decimal"> 8 </Const>
                  </args>
               </Atom>
            </content>
         </External>
      </And>
   </formula>
</Exists>

Editor's Note: This section is still under discussion in the working group (see ISSUE-62). The working group considers adding an Assign action to represent the modification of the value of an attribute in a fact represented by a Frame, and an Execute action to represent the execution of an arbitrary, externally specified procedure. The working group seeks feedback regarding the proposed syntax for the currently specified actions, as well as regarding which constructs for serializing individual actions should be supported by RIF-PRD and/or required from RIF-PRD implementations.

    [ ASSERT | New | Retract | ACTION_BLOCK    ]

For compatibility with RIF-BLD, ASSERT is not associated with specific XML markup in RIF-PRD instance documents, and it is represented only as the target Atom or Frame.

    [ Atom | Frame ]

Editor's Note: The working group seeks feedback regarding whether a specific XML element, Assert, modeled after the Retract element, below, should be used to serialize assertions, instead, to the price of reducing the interoperability with RIF-BLD.

    <New>
       <instance> Var </instance>?
       <class> Const </class>
    </New>

<New>
  <class>
    <Const type="rif:iri">http://rif.examples.com/2008/joe#Potato</Const>
  </class>
</New>

    <Retract>
       <target> [ Atom | Frame | TERM ] </target>
    </Retract>

Example 2.10. 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 2.4.

<Retract>
   <target>
      <Atom>
         <op>
            <Const type="rif:iri">
               http://rif.examples.com/2008/joe#owns
            </Const>
         </op>
         <args rif:ordered="yes">
            <Var> c </Var>
            <Var> p </Var>
         </args>
      </Atom>
   </target>
</Retract>

An ACTION_BLOCK construct is used to represent an ordered list of ACTIONs. There are two kinds of ACTION_BLOCK. One uses a restricted And construct for compatibility with RIF-BLD. The other uses a Do construct that is specific to RIF-PRD and permits local variables to be declared.

    [ And | Do ]

    <And>
       <formula> ASSERT </formula>*
    </And>

    <Do>
       <declare> Var </declare>*
       <action> ACTION </action>*
    </Do>

Example 2.11. The example below shows the RIF XML representation of an action block that asserts a new 100 decigram potato.

<Do rif:ordered="yes">
  <declare><Var>p</Var></declare>
  <New>
    <instance><Var>p</Var></instance>
    <class>
      <Const type="rif:iri">http://rif.examples.com/2008/joe#Potato</Const>
    </class>
  </New>
  <Frame>
    <object><Var>p</Var></object>
    <slot rif:ordered="yes">
      <Const type="rif:iri">http://rif.examples.com/2008/joe#weight</Const>
      <Const type="xsd:decimal">100</Const>
    </slot>
  </Frame>
</Do>

This section specifies the RIF-PRD constructs that are required, in addition to the ones specified in the sections on Conditions and Actions, to serialize, 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 Implies, as a Forall, or as a single ACTIONS:

• The Implies associates one optional condition FORMULA and one non-empty ordered list of ACTIONS.
• 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.

Editor's Note: This version of the draft does not specify a specific construct to serialize a ruleset in RIF-PRD: the generic Group construct can be used for that purpose - as specified in the next section, Groupings and metadata. Future versions of this draft may specify a specific-purpose construct, especially if semantically significant information has to be associated to rulesets (e.g. parameters etc). The working group seeks feedback on this (see also ISSUE-63).

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

    [ Implies | Forall | ACTION ]

    <Implies>
       <if> FORMULA </if>?
       <then rif:ordered="yes">
          ACTION
          ACTION*
        </then>
     </Implies>

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

Editor's Note: Nested Foralls make explicit the scope of the declared variables, and, thus, impose an order on the evaluation of the pattern and if FORMULAe in a rule. That ordering and the use of patterns to constrain the binding of variables may be of practical significance for some production rule systems, but they are irrelevant with respect to the intended semantics of the rules being interchanged (although they would be relevant if RIF-PRD was to be extended to support some kind of "else" or "case" construct). In addition, RIF-BLD does not allow nested Forall and does not support the association of contraining patterns to declared variables. The working group seeks feedback regarding whether nested Forall and constrainting pattern should be supported in RIF-PRD, to the cost of reducing the interoperability with RIF-BLD.

Example 2.10. The example below shows how the CMP rule extract: "if a chicken owns a potato and ..." could be serialized using a binding pattern FORMULA:

<Forall>
   <declare><Var>chicken</Var></declare>
   <formula>
      <Forall>
         <declare><Var>potato</Var></declare>
         <pattern>
            <External>
               <content>
                  <Atom>
                     <Const type="rif:iri">
                        http://rif.examples.com/2008/joe#owns
                     </Const>
                     <Args rif:ordered="yes">
                        <Var>chicken</Var>
                        <Var>potato</Var>
                     </Args>
                  </Atom>
               </content>
            </External>
         </pattern>
         <formula>
            ...
         </formula>
      </Forall>
   </formula>
</Forall>

    <Group>
       <sentence> [ RULE | Group ] </sentence>*
    </Group>

    <Document>
       <payload> Group </payload>?
    </Document>

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

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

It is suggested to use Dublin Core, RDFS, and OWL properties for metadata, along the lines of http://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.

Example 2.11. TBC

The presentation syntax is designed to be very close to RIF-BLD. A line by line comparison of the EBNF will show these few differences:

1. the addition of Not
2. the removal of Expr, the syntactic class of logical functions,
3. the replacement of ATOMIC in rule conclusions with ACTION, and the addition of Do(ACTION*) and And(ASSERT*) instead of And(ATOMIC*) in rule conclusions.
4. definition of ASSERT, New, and Retract actions.

It is intended that the syntax and semantics of RIF-BLD and RIF-PRD are the same when the rule conclusion contains a single Atom or Frame, Not is not used, and logical functions are not used.

The following EBNF is from RIF-BLD, with lines prefixed with ! indicating a change for RIF-PRD:

  FORMULA        ::= 'And' '(' FORMULA* ')' |
                     'Or' '(' FORMULA* ')' |
                     'Exists' Var+ '(' FORMULA ')' |
                     ATOMIC |
                     'External' '(' Atom | Frame ')' |
!                    'Not' '(' FORMULA ')'
  ATOMIC         ::= Atom | Equal | Member | Subclass | Frame
  Atom           ::= UNITERM
  UNITERM        ::= Const '(' (TERM* <| (Name '->' TERM)*) ')'
  Equal          ::= TERM ' = ' TERM
  Member         ::= TERM '#' TERM
  Subclass       ::= TERM '##' TERM
  Frame          ::= TERM '[' (TERM '->' TERM)* ']'
! TERM           ::= Const | Var | 'External' '(' Expr ')'
  Expr           ::= UNITERM
  Var            ::= '?' UNICODESTRING

The following EBNF is taken from RIF-DTB and is unchanged for PRD. Its purpose is to provide shortcuts for constants.

  ANGLEBRACKIRI  ::= '<' IRI_REF '>'
  STRING         ::= '"' UNICODESTRING '"'
  CURIE          ::=  PNAME_LN | PNAME_NS   → see RIF-DTB
  Const          ::= STRING '^^'ANGLEBRACKIRI
                   | STRING '^^' CURIE
                   | ANGLEBRACKIRI     → shortcut for rif:iri
                   | CURIE             → shortcut for rif:iri
                   | STRING            → shortcut for xsd:string
                   | NumericLiteral    → shortcut for xsd:integer,xsd:decimal,xsd:double
                   | '_' LocalName     → shortcut for rif:local

The following EBNF is from RIF-BLD and defines rules, groups of rules, and the containing document. Changed lines are prefixed with !. Metadata can be associated with Document, Group, and RULE constructs.

! Document  ::= IRIMETA? 'Document' '('  Group? ')'
  Group     ::= IRIMETA? 'Group' '(' (RULE | Group)* ')'
! RULE      ::= (IRIMETA? 'Forall' Var+ ('(' FORMULA '))* '(' RULE ')') | CLAUSE
! CLAUSE    ::= Implies | ACTION
! Implies   ::= IRIMETA? (ACTION | 'Do' '(' ACTION* ')') ':-' FORMULA
  IRIMETA   ::= '(*' Const? (Frame | 'And' '(' Frame* ')')? '*)'
  IRI       ::= UNICODESTRING
  Profile   ::= UNICODESTRING

Finally, the following EBNF describes the syntax of PRD actions.

  ACTION    ::= ASSERT | Retract | New | ACTION_BLOCK
  ASSERT    ::= Atom | Frame
  New       ::= 'New' ( Var '#' )? Const
  Retract   ::= 'Retract' '(' Atom | Frame | TERM ')'
  ACTION_BLOCK ::= 'And' '(' ASSERT+ ')' | 'Do' Var* '(' ACTION* ')'

For the purpose of specifying the semantics of a RIF-PRD RuleSet, a production rule system PRS is defined as a labeled terminal transition system (e.g. PLO04).

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

• C is a set of elements, c, called configurations;
• L is a set of elements, a, called actions (or labels);
• → ⊆ C × L × C is the transition relation, that is: (c, a, c' ) ∈ → iff there is a transition labelled a from the configuration c to the configuration c' or, more appropriately in the case of a PRS, the execution of action a in the configuration c causes a transition to configuration c' . We note: c + a → c' or c ^a→ c';
• T ⊆ C is the set of final configurations, that is, the set of all the configurations c from which there are no transitions: T = {c ∈ C | ∀ a ∈ L, ∀ c' ∈ C, (c, a, c' ) ∉ →}.

A labeled transition system is a structure {C, L, →} (without a set T of final configurations).

The idea of describing a PRS as a labeled terminal transition system is that, given a set of production rules RS and a set of facts w₀, the rules in RS that are satisfied, in some sense, in w₀ determine an action a₁, which execution results in a new set of facts w₁; the rules in RS that are satisfied in w₁ determine an action a₂ to execute in w₁, and so on, until the system reaches a final configuration and stops. The result is the set of facts w_n when the system stops.

Example 3.1. Judicael, one follower of Joe the Hen Public's method, has four chickens, Joe, Jack, Joe and Julia, that own three potatoes (BigPotato, SmallPotato, UglyPotato) among them:

• Joe (daily grain allowance = 10) is 12 months old, Jack (daily grain allowance = 12) is 9 months old, Joe (daily grain allowance = 6) is 6 months old and Julia (daily grain allowance = 14) is 10 months old;
• BigPotato weights 70g, SmallPotato weights 10g, UglyPotato weights 50g;
• Joe owns BigPotato, Jack and Woof own SmallPotato jointly (Woof is the farm's dog. It inherited joint ownership of SmallPotato from its aunt Georgette) and Joe owns UglyPotato.

That is the initial set of facts w₀. Paula's rule set contains one single rule, that is, Joe's CMP rule:

(* joe:ChickenAndMashedPotatoes *)
Forall ?chicken ?potato ?allowance ?age ?weight (
  Do( Execute(joe:mash(?potato)) 
      Retract(?chicken[joe:allowance->?allowance])
      ?chicken[joe:allowance->External(func:numeric-multiply(?allowance 1.1))]
      Retract(joe:owns(?chicken ?potato)) )
  :-
  And( ?chicken#joe:Chicken 
       ?chicken[joe:age->?age joe:allowance->?allowance]
       External(pred:numeric-greater-than(?age, 8))
       ?potato#joe:Potato 
       ?potato[joe:weight->?weight]
       joe:owns(?chicken ?potato)
       External(pred:numeric-greater-than(?weight External(func:numeric-divide(?age 2))))
       External(pred:string-not-equals(External(joe:today()), "Tuesday"))
       Not(External(joe:foxAlarm())) ))

When the rule is applied to w₀:

• the first 3 conjuncts select {Joe/?chicken, Jack/?chicken, Julia/?chicken} as possible values for variable ?chicken (Joe is too young);
• conjuncts 4-7 select {(Joe/?chicken, BigPotato/?potato)} as the only possible substitution for the variables ?chicken and ?potato (UglyPotato does not belong to either Joe, Jack or Julia and SmallPotato is too small);

Suppose that Judicael's implementation of today() returns Monday and that the foxAlarm() is false when the CMP rule is applied: the condition is satisfied, and the actions in the conclusion are executed with BigPotato substituted for ?potato, Joe substituted for ?chicken, and 10 substituted for ?allowance. This results in the following changes in the set of facts:

• BigPotato is mashed (and removed from the list of potatoes to be considered in future applications of the CMP rule);
• the daily grain allowance of Joe is now 11;
• Joe does not own a potato anymore.

The resulting set of facts w₁ is thus:

• Joe (daily grain allowance = 11) is 12 months old, Jack (daily grain allowance = 12) is 9 months old, Joe (daily grain allowance = 6) is 6 months old and Julia (daily grain allowance = 14) is 10 months old;
• SmallPotato weights 10g, UglyPotato weights 50g;
• Jack and Woof own SmallPotato jointly and Joe owns UglyPotato.

When the CMP rule in applied to w₁, the first External predicate still selects {Joe/?chicken, Jack/?chicken, Julia/?chicken} as possible values for variable ?chicken, but the joe:own relation and the second External predicate do not select any possible substitution for the couple (?chicken, ?potato) anymore: the rule cannot be satisfied, and the system, having detected a final configuration, stops.

The result of the execution of the system is w₁.

• DTS a set of symbols for primitive datatypes (please refer to Section Datatypes)
• Pred a countably infinite set of symbols called predicates where ''Pred ∈ Const.
• a countably infinite set of frame symbols Frame where ''Frame ∈ Const.
• Act a countably infinite set of symbols called actions where ''Act ∈ {ASSERT, RETRACT}.
• a set of symols =, #, ##, External denoting equality, membership, subclass and external built-in functions and predicates
• a countably infinite set of constant symbols Const.
• a countably infinite set of argument names, ArgNames called named arguments (disjoint from Const)
• a function arity where
  • for each predicate P_i ∈ Pred, arity(P_i) is a non-zero natural number called arity of P_i
  • for each frame F_i ∈ Frame, arity(F_i) is a non-zero natural number called arity of F_i
  • for each action A_i(t) ∈ Act where t is a predicate of frame, arity(A_i(t)) is a non-zero natural number arity(t) called arity of A_i(t)
  • for =, arity(=) = 2
  • for #, arity(#) = 2
  • for ##, arity(##) = 2
  • for each External(t) where t is an external built-in function or predicate, arity(External(t)) is a non-zero natural number arity(t) called arity of the external function or predicate t.
• a function type that associates with each predicate, frame, built-in function, or constant a datatype, such as a primitive type from DTS as follows
  • if P_i ∈ Pred is a predicate of arity k, then type(P_i) = <dt₁, ...,dt_k> where each dt_j ∈ DTS.
  • if F_i ∈ Frame is a frame of arity k, then type(F_i) = <dt₁, ...,dt_k> where each dt_j ∈ DTS.
  • if A_i(t) ∈ Act is an action of arity k, then type(A_i(t)) = type(t) = <dt₁, ...,dt_k> where each dt_j ∈ DTS.
  • if LHS = RHS is an equality function where LHS is the left hand side of the function and RHS is the right hand side, then type(LHS = RHS) = (type(LHS) = type(RHS))
  • if t#s is a class-membership function, then type(t#s) = (type(t) # type(s))
  • if t##s is a subclass function, then type(t##s) = (type(t) ## type(s))
  • if External(t) is a external built-in predicate or function, then
    • type(External(t)) = type(t) = <dt₁, ...,dt_k> where each dt_j ∈ DTS, if t is an external predicate of arity k
    • type(External(t)) is a k+1 tuple of datatypes from DTS defining the datatypes both of the domain and range of t, if t is an external function of arity k

Editor's Note: Or do we even want to associate a type to frames and actions itself (not just the arguments), i.e. the type of a frame object, the type of an action function?.

• • if C_i ∈ Const'' is a constant, then type(C_i)= dt gives the primitive data type dt of C_i

Definition (alphabet). The alphabet of the presentation language of RIF-PRD consists of

• the signature PRD = < DTS, Pred, Frame, Act, =, #, ##, External, Const, ArgNames, arity, type >
• a countably infinite set of variable symbols Var (disjoint from Const)
• connective symbols And, Or, ¬ (negation), and :-
• quantifiers Exists and Forall
• the symbols Import, Prefix, and Base
• the symbols Group and Document
• the auxiliary symbols (, ), [, ], <, >, and ^^

Definition (rule instance): An instance of a rule r is a pair (r^id, σ), where r^id uniquely identifies r and σ is a ground substitution such that Var(r) ⊆ Dom(σ). Given a rule r, id(r) denotes r^id, the unique identifier of r; given a rule instance ri = (r^id, σ), rule(ri) denotes the rule that is uniquely identified by r^id.

Definition (ruleset instance): an instance of a rule set RS is a set of rule instances ri_i, where ∀ i, rule(ri_i) ∈ RS. Given a rule set RS, Inst(RS) denotes the set of all the possible instances of all the rules in RS.

Let W be the set of ground formulas that can be represented in RIF-PRD, defined as follows:

• if p ∈ Const is the symbol of an externally specified predicate and t_i ∈ Term_Σ for i = 1..n, then External(p(t₁ ... t_n)) ∈ W;
• if p ∈ Const is neither the symbol of an externally specified predicate nor the symbol of an externally specified function, and t_i ∈ Term_Σ for i = 1..n, then p(t₁ ... t_n) ∈ W</sub>;
• if t₁ ∈ Term_Σ and t₂ ∈ Term_Σ, then t₁ = t₂ ∈ W;
• if t₁ ∈ Term_Σ and t₂ ∈ Term_Σ, then t₁ # t₂ ∈ W;
• if t₁ ∈ Term_Σ and t₂ ∈ Term_Σ, then t₁ ## t₂ ∈ W;
• if o ∈ Term_Σ, k_i ∈ Term_Σ for i = 1..n, and v_i ∈ Term_Σ for i = 1..n, then o[k₁->v₁ ... k_n->v_n] ∈ W;
• if f_i ∈ W for i = 1..n, then AND(f₁ ... f_n) and OR(f₁ ... f_n) are ground formulas;
• if f ∈ W, then NOT(f) ∈ W;
• if f ∈ W and x_i ∈ Var for i = 1..n, then, ∀ n ≥ 1, Exists x₁ .. x_n (f) ∈ W. By convention, a ground formula Exists x₁ .. x_n (f) is always replaced by the semantically equivalent ground formula f.

Let L be the set of the atomic ground actions that can be represented in RIF-PRD:

• if a ∈ W is a ground Atom , then a ∈ L and Retract(a) ∈ L.
• if a ∈ W is a ground Frame , then a ∈ L and Retract(a) ∈ L.
• if c ∈ W is a Const , then New ?o # c ∈ L, where ?o must be declared in an enclosing Do action block.
• if o ∈ W is a Const , then Retract(o) ∈ L.

Editor's Note: The definition of L is subject to change as the ACTION constructs are still under discussion.

Finally, let R be the set of all the rules that can be represented in RIF-PRD.

In this document, given a set X, P(X) denotes the power set of X, and S(X) denotes the set of the ordered lists of elements of X.

Given an expression f and a set of ground instances w, Eval(f, w) denotes the set of ground formulae that results of evaluating f in the context of w. The expression, f, is evaluated as a black-box: any side-effect of the evaluation, on w or otherwise, depends only on the specification of the semantics of f.

In accordance with the general semantics of the RIF framework described in [RIF-FLD] the truth values and interpretations in RIF-PRD are defined as follows:

Definition (truth values) The set TV of truth values in RIF-PRD consists of just two values, t and f.

Definition (semantic structure) Let PRD be a signature. I is a semantic structure for PRD if I = <TV, DTS, D, D_ind, I_C, I_V, I_frame, I_sub, 'I_isa, I₌, I_external, I_truth> consists of the following.

D is a non-empty set of elements called the domain of I. D_ind is a nonempty subsets of D. D_ind is used to interpret the elements of Const of PRD that are individuals. TV denotes the set of truth values that the semantic structure uses and DTS of PRD is set of identifiers for primitive datatypes.

The other components of I are total mappings defined as follows:

1. I_C maps Const to D.

   This mapping interprets constant symbols: I_C(c) ∈ D_ind

2. I_V maps Var to D_ind.

   This mapping interprets variable symbols.

3. I_frame maps D_ind to total functions of the form SetOfFiniteBags(D_ind × D_ind) → D.

   This mapping interprets frame terms. An argument, d ∈ D_ind, to I_frame represents an object and the finite bag {<a1,v1>, ..., <ak,vk>} represents a bag of attribute-value pairs for d. We will see shortly how I_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: o[a->b a->b]. Such repetitions arise naturally when variables are instantiated with constants. For instance, o[?A->?B ?C->?D] becomes o[a->b a->b] if variables ?A and ?C are instantiated with the symbol a and ?B, ?D with b.

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

   The operator ## is required to be transitive, i.e., c1 ## c2 and c2 ## c3 must imply c1 ## c3. This is ensured by a restriction in Section Interpretation of Formulas.

5. I_isa gives meaning to class membership. It is a mapping of the form D_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 and cl ## scl must imply o # scl. This is ensured by a restriction in Section Interpretation of Formulas.

6. I₌ is a mapping of the form D_ind × D_ind → D.

   It gives meaning to the equality operator.

7. I_truth is a mapping of the form D → TV.

   It is used to define truth valuation for formulas.

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

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

   • If σ is a schema of a built-in function then I_external(σ) must be the function defined in the aforesaid document.
   • If σ is a schema of a built-in predicate then I_truth ο (I_external(σ)) (the composition of I_truth and I_external(σ), a truth-valued function) must be as specified in [RIF-DTB].

For convenience, we also define the following mapping I from terms to D:

• I(k) = I_C(k), if k is a symbol in Const
• I(?v) = I_V(?v), if ?v is a variable in Var
• 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)), if t 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 if t 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, so I(External(t)) is well-defined.

The effect of datatypes. The set DTS must include the datatypes described in Section Primitive Datatypes of [RIF-DTB].

The datatype identifiers in DTS impose the following restrictions. Given dt ∈ DTS, let LS_dt denote the lexical space of dt, VS_dt denote its value space, and L_dt: LS_dt → VS_dt the lexical-to-value-space mapping (for the definitions of these concepts, see Section Primitive Datatypes of [RIF-DTB]. Then the following must hold:

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

That is, I_C must map the constants of a datatype dt in accordance with L_dt.

RIF-PRD does not impose restrictions on I_C for constants in symbol spaces that are not datatypes included in DTS.   ☐

Editor's Note: The operational semantics of actions in RIF-PRD is still under discussion (see ISSUE-66). It will evolve as the semantics to be associated with the actions that are already specified is refined, in particular with respect to the creation and delation of objects; and as new ACTION constructs are added. The working group seeks feedback regarding what operational semantics would be most usefully associated with RIF-PRD ACTION constructs.

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

1. ∀ w ⊆ P(W), w + a →_RIF-PRD w' = w ∪ {a} if a is an Atom or a Frame;
2. ∀ w ⊆ P(W), w + New ?o # c →_RIF-PRD w' = w ∪ {o#c} if c is a Const &isin w and o is a Const not in w;
3. ∀ w ⊆ P(W), w + Retract(a) →_RIF-PRD w' = w\a if a is an Atom or a Frame;
4. ∀ w ⊆ P(W), w + Retract(o) →_RIF-PRD w' = w\{o#?c ∪ o[?k->?v]} if o is a Const and ?c, ?k, and ?v are free variables (i.e. they match any Const);

Rule 1 specifies that the Assert construct should be used when the intended action is to add a fact to a set of ground facts w. Rule 2 specifies that the Retract construct should be used when the intended action is to remove a fact from w, instead.

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}.

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

The evaluation of the function INSTANTIATE corresponds to the step that is often called matching in the description of production rule systems (e.g. PRR07). Given a collection of rules, it considers all possible ground rule instances, obtained by assigning ground terms to the variables occuring in them. Its semantics is defined in accordance with the semantics of the condition language of the RIF logic framework in terms of assignment into the universe of a structure of the PRD language and a satisfaction relation for instantiated rules.

Definition (Assignment): Let PRD be the language of PRD, Var its countable set of variables, and I a structure for PRD. An assignment is a function σ from Var (or a subset of Var) into the universe of I. The assignmment function is given by a ground substitution as defined below.

In PRD the assignment function additionally needs to consider the binding patterns defined by the FORALL quantifier, that is it assigns a value to each variable in such a way all constraints imposed by the binding patterns are satisfied by these values. Such an assignment is called consistent.

Definition (Consistent Assignment): Let Var be a set of variables, D the non-empty domain of possible values for the variables, P the set of binding patterns, and C as set of constraints. Each constraint C_i ∈ C involves the set of variables X ⊆ Var from a binding pattern P_i ∈ P and specifies the allowable combinations of assigned values P_i[σ]. An assignment σ: Var -> D satisfies a constraint C_i iff ∀ X_j ∈ X ⊆ Var: σ(X_j) ∈ P_i[σ]. An assignment that satisfies all constraints C is called a consistent assignment.

For assigning terms to variables a substitution is defined as follows (e.g. HAK07):

Definition (substitution): A substitution is a finitely non-identical assignment of terms to variables; i.e., a function σ from Var to Term such that the set {x ∈ Var | x ≠ σ(x)} is finite. This set is called the domain of σ and denoted by Dom(σ). Such a substitution is also written as a set such as σ = {t_i/x_i}_i=1..n where Dom(σ) = {x_i}_i=1..n and σ(x_i) = t_i for i = 1 to n.

Given X, a set of variables, and σ, a substitution such that X ⊆ Dom(σ), σ_X denotes, in this document, the restriction of σ to the variables in X: σ_X = {σ(x)/x | x ∈ X}.

Let Term_Σ be the set of ground terms (that can be represented in RIF-PRD), defined as follows:

• if c ∈ Const, then c ∈ Term_Σ;
• if f ∈ Const is the symbol of an externally specified function and t_i ∈ Term_Σ for i = 1..n, then External(f(t₁ ... t_n)) ∈ Term_Σ.

Definition (ground substitution): A ground substitution is a substitution σ such that ∀ x ∈ Dom(σ), σ(x) ∈ Term_Σ.

The function Var(e) that maps a RIF-PRD element e to the set of its free or universally quantified variables is defined as follows:

• if e ∈ Const, then Var(e) = {};
• if e ∈ Var, then Var(e) = {e};
• if p ∈ Term and arg_i ∈ Term, for i = 0..n, then, Var(p(arg_i) = Var(p) ∪_i=0..n Var(arg_i);
• if p ∈ Term and arg_i ∈ Term, for i = 0..n, then, Var(External(p(arg_i)) = Var(p) ∪_i=0..n Var(arg_i);
• if t₁ ∈ Term and t₂ ∈ Term, then Var(t₁ [=|#|##] t₂) = Var(t₁) ∪ Var(t₂);
• if o ∈ Term, k_i ∈ Term for i = 1..n, and v_i ∈ Term for i = 1..n, then Var(o[k₁->v₁ ... k_n->v_n]) = Var(o) ∪_i=1..n Var(k_i) ∪_i=1..n Var(v_i);
• if f_i are RIF-PRD FORMULAs for i = 0..n, then Var([AND|OR|NOT](f_i)) = ∪_i=0..n Var(f_i);
• if f is a RIF-PRD FORMULA and x_i ∈ Var for i = 1..n, then, Var(Exists x₁ .. x_n (f)) = Var(f) - {x_i}.
• if a is a RIF-PRD ATOMIC, then Var([ASSERT|RETRACT](a)) = Var(a);
• if f is a RIF-PRD FORMULA and a_i, i = 1..n are RIF-PRD ACTIONs, then Var(IF f THEN a₁ ... a_n) = Var(f) ∪_i=1..n Var(a_i);
• if r is a RIF-PRD RULE, x_i ∈ Var for i = 1..n, and p_j, j = 0..m, are RIF-PRD FORMULAs, then Var(Forall x₁ ... x_n SUCH THAT p_j (r)) = Var(r) ∪_j=1..m Var(p_j);
• if r_i, i = 0..n, are RIF-PRD RULEs, then Var(RULESET(r_i)) = ∪_i=1..n Var(r_i).

Definition (Satisfaction): A RIF-PRD Formula φ is satisfied (is true) in the structure I of PRD under assignment σ, written as I |= φ[σ], if there is an consistent assignment σ to I. The inductive requirements of the satisfaction relation |= are:

• I |= φ[σ] for any ATOMIC formula φ of the form p(t₁,..,t_n) iff {σ(t₁),..,σ(t_n)} ∈ I(φ)
• I |= External(φ)[σ] for any EXTERNAL formula External(φ) of the form External(f(t₁,..,t_n)) iff I |= External(f(σ(t₁),..,σ(t_n))) (evaluates to true)
• I |= ¬ φ[σ] iff it is not the case that I |= φ[σ]
• I |= And(φ₁ ... φ_n)[σ] iff I |= φ₁[σ], ... ,I |= φ_n[σ]
• I |= Or(φ₁ ... φ_n)[σ] iff I |= φ₁[σ] _v ... _v I |= φ_n[σ]
• I |= Exists ?V(φ)[σ] iff there exsits some assignment σ* such that
  • for every variable ?X different from ?V σ*(?X) = σ(?X)
  • σ*(?V) is defined, and
  • I |= φ[σ*]
• I |= ∀ ?V(φ)[σ] iff for any assignment σ* I |= φ[σ*], where
  • for every variable ?X different from ?V σ*(?X) = σ(?X)
  • σ*(?V) is defined
• I |= φ[σ], where φ is a RIF-PRD Rule ψ :- τ consisting of a condition formula τ and an action formula ψ, iff I |= τ[σ] then I |= ψ[σ]

Editor's Note: Note, that :- might change to =>

Definition (Pattern Matching): Given a set w ⊆ W of ground RIF-PRD ATOMICs and a RIF-PRD FORMULA φ, φ is said to match w and an assignment σ, iff I |= φ[σ(w)].

All possible instantiation of a RIF-PRD formula φ are obtained by substituting each variable ?X_i ∈ Var of φ with the value of σ(?X_i) from the matching facts w ∈ W.

Editor's Note: This section is still under discussion (see ISSUE-64). 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 the associated substitution to the variables in the ACTIONs in the then component of the instantiated rule. The decision to implement the sequence of actions that a rule instance determines is often called: firing the rule instance.

Most implementations of production rule languages select the rule instances to be fired, and, therefore, the sequence of actions to be implemented, based on one or a combination of the following strategies (under these or other, idiosyncratic names; and possibly combined with additional, idiosyncratic rules):

• No-repetition. The no-repetition strategy excludes from the selection of fireable rule instances, any rule instance that has already been fired, unless the instantiation environment has significantly changed since the actions have been last implemented. This is usually taken to mean that there has been at least one configuration where the state of facts did not satisfy the rule instance, in the sense determined by the specification of the INSTANTIATE function, since the rule instance has been last fired;
• Priority. The rule instances are ordered by priority of the instantiated rules, and only the rule instances with the highest priority are selected. This requires that a priority be associated with the RIF-PRD representation of each rule;
• Recency. the rule instances are ordered by how long a rule instance has been continuously satisfied by the states of facts of the traversed configurations, and only the most recent ones are selected.
• Random. A singleton rule instance is selected at random;
• All-at-once. All the rule instances are selected, and they are fired in the order's sequence.

Let fireableINSTANCES: S(Inst(R)) × P(Inst(R)) × {no-repeat, priority, recency, random, all} → S(Inst(R)) be a function that, given an ordered set, ori, of candidate rule instances, a set, h, of excluded rule instances, and a keyword, k, indicative of an single selection strategy, return a subset fri ⊆ ori, selected and ordered according to the strategy indicated by k. The keywords "no-repeat"" and "all" indicate, respectively, the no-repetition and all-at-once selection strategies, and the other keywords indicate each the strategy by the same name.

The function fireableINSTANCES is precisely specified in the next subsection.

The function PICK(c, LS) can be specified with the help of a terminal transition system where:

• a configuration is a triple (LS, ori, c) ⊆ S{priority, recency, all} × S(Inst(RS)) × C_RS;
• the transition relation is completely specified by the following two rules:
  1. if s = "all", then (sLS', ori, c) → (∅, ori, c)
  2. if s ≠ "all", then (sLS', ori, c) → (LS', fireableINSTANCES(ori, history(c), s), c)
• a configurations (LS, ori, c) is final if and only if LS = ∅.

Intuitively, the strategy for the selection of the rule instances to be fired that is intended for the set of rules represented by a RIF-PRD Ruleset, is :

1. starting from the ordered set returned by INSTANTIATE in the configuration, to remove the instances that were already fired, as listed in the configuration's history. That is, the no-repetition strategy is always applied first;
2. successive subsets of instances are selected per the sequence of selection strategies keywords associated with the Ruleset;
3. and, finally, a single rule instance is selected at random from the resulting subset. That is, the random strategy is always applied at the end of the selection process.

Editor's Note: This section is still under discussion (see ISSUE-65). This version specifies a single, default halting test: future version of this draft may specify additional halting tests, and/or a different default. The Working Group seeks feedback on which halting tests and which combinations of tests should be supported by RIF-PRD and/or required from RIF-PRD implementations; and which halting test should be the default, if any.

By default, the specification for a terminal configuration that is intended for a set of production rules, when no halting test is explicitely associated to its representation as a RIF-PRD Ruleset, is when no rule instance is fireable: this is the case when INSTANTIATE returns an empty set of rule instances, or when all the rule instances that are satisfied in the configuration, according to the semantics of INSTANTIATE, have already been fired in a configuration that has not since changed significantly. That latter condition guarantees, in particular, that the system halts when it reaches a fixpoint.

Formally, ∀ RS ⊆ R, ∀ c ∈ C_RS, PICK(c, RS) = true if and only if instance(c) - history(c) = ∅. Otherwise, PICK(c, RS) = false.

[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 - A compact syntax for expressing URIs, W3C note 27 October 2005, M. Birbeck (ed.).

[HAK07]

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

[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).

[PRR07]

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 at http://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 at http://www.w3.org/TR/rdf-schema/.

[RFC-3066]

RFC 3066 - Tags for the Identification of Languages, H. Alvestrand, IETF, January 2001, http://www.isi.edu/in-notes/rfc3066.txt.

[RFC-3987]

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

[XDM]

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

[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 at http://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 at http://www.w3.org/TR/xpath-functions/.

RIF-PRD and RIF-BLD share essentially the same presentation syntax and XML syntax.

The syntactic differences between the two dialects are summarized below:

• RIF-BLD allows logic and externally specified, fixed-interpretation functions as TERM, whereas RIF-PRD accepts only externally specified functions;
• RIF-BLD allows ATOMIC or And(ATOMIC*) in rule conclusions, whereas RIF-PRD allows ACTION or Do(ACTION*). In RIF-PRD it is not possible to conclude equality or class membership.
• RIF-PRD allows Not(FORMULA), which RIF-BLD does not accept;
• RIF-PRD defines ASSERT and Retract actions that are not allowed in RIF-BLD.

Below is a complete, construct by construct, comparison table of RIF-PRD and RIF-BLD presentation and XML syntaxes. A construct is tagged "BLD" or "PRD" if it is specific to the dialect, or tagged "Core" if it is common to both.

Editor's Note: RIF-Core will be equal to or included in the intersection of RIF-PRD and RIF-BLD. The exact scope of RIF-Core is still under discussion. Until RIF-Core is specified more precisely, this document assumes that it will be equal to the intersection of RIF-PRD and RIF-BLD.

[Const | Var | Expr | External]

[Const | Var | External]

'"' UNICODESTRING '"^^' SYMSPACE

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

'?' Any Unicode string

<Var>
   Any Unicode string
</Var>

Const '(' (TERM* | (Name '->' TERM)*) ')'

<Expr>
   <op> Const </op>
   [
    <args rif:ordered="yes"> TERM* </args>?
    |
    <slot rif:ordered="yes">
       <Name> Any Unicode string </Name>
       TERM
    </slot>*
   ]
</Expr>

Undefined except when wrapped in an External (as TERM), as follows.

'External' '(' Expr ')'

<External>
   <content>
      Expr
   </content>
</External>

[Atom | Equal | Member | Subclass | Frame]

Const '(' (TERM* | (Name '->' TERM)*) ')'

<Atom>
   <op> Const </op>
   [
    <args rif:ordered="yes"> TERM* </args>?
    |
    <slot rif:ordered="yes">
       <Name> Any Unicode string </Name>
       TERM
    </slot>*
   ]
</Atom>

TERM = TERM

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

TERM # TERM

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

TERM ## TERM

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

TERM ' [ ' (TERM ' -> ' TERM)* ' ] '

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

[ATOMIC | External | And | Or | Exists]

[ATOMIC | External | And | Or | NmNot | Exists]

'External '(' [Atom | Frame] ')'

<External>
   <content>
      [ Atom | Frame ]
   </content>
</External>

'And' '(' FORMULA* ')'

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

'Or' '(' FORMULA* ')'

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

Undefined

'Not' '(' FORMULA ')'

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

'Exists' Var+ '(' FORMULA ')'

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

Undefined

[ ASSERT | Retract ]

Undefined

[ Atom | Frame ]

Undefined

'Retract' '(' Atom | Frame ' ) '

<Retract>
   <target>
      [ Atom | Frame ]
   </target>
</Retract>

[ Forall | Implies | ATOMIC ]

[ Forall | Implies | ACTION ]

' Forall ' Var+ ' ( ' [Implies | ATOMIC] ' ) '

<Forall>
   <declare> Var </declare>+
   <formula>
       [Implies | ATOMIC ] 
   </formula>
</Forall>

' Forall ' Var+ (' ( ' FORMULA ' ) ')* ' ( ' RULE ' ) '

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

(ATOMIC | 'And' '(' ATOMIC* ')') ':-' FORMULA

<Implies>
   <if> FORMULA </if>
   <then>
      [ ATOMIC
        |
        <And>
           <formula>
              ATOMIC
           </formula>*
        </And>
      ]
   </then>
</Implies>

(ACTION | 'Do' '(' ACTION* ')') ':-' FORMULA

<Implies>
   <if> FORMULA </if>
   <then>
      ACTION
      ACTION*
   </then>
</Implies>

METADATA? 'Group' '(' ([RULE | Group])* ')'

<Group>
   <sentence> [ RULE | Group ] </sentence>*
</Group>

'Import' '(' IRI Profile? ')'

<Import>
   <location>lAny Unicode string</location>
   <profile><Profile>Any Unicode String1</Profile></profile>
</Import>

Undefined in this version of the draft

METADATA? 'Document' '(' [Import | Prefix | Base]* Group? ')'

<Document>
  <directive>
     [ Import | Prefix | Base]*
  </directive>
  <payload> Group </payload>?
</Document>

METADATA? 'Document' '(' Group? ')'

<Document>
  <payload> Group </payload>?
</Document>

'(*' Const? (Frame | 'And' '(' Frame* ')')? '*)'

<AnyClassTag>
   <id> Const </declare>?
   <meta>
      [ Frame 
        |
        <And>
           <formula> Frame </formula>
        </And>
       ]
   </meta>?
   other content of AnyClassTag
</AnyClassTag>

The intended semantics of any RIF XML document which is both a syntactically valid RIF-PRD document and a syntactically valid RIF-BLD document is the same whether it is considered a RIF-PRD or a RIF-BLD document. For any input set of facts, the set of rules contained in the document must produce the same output set of facts whether it is consumed as a RIF-PRD or a RIF-BLD document.

Proof. TBC

7 Appendix: UML-like diagram of RIF-PRD syntax

The picture below represents the complete syntax of RIF-PRD, according to this version of the draft, except for the Metadata construct, which is omitted for readibility's sake.