W3C


RIF Production Rule Dialect

W3C Editor's Draft 22 September21 November 2008

This version:
http://www.w3.org/2005/rules/wg/draft/ED-rif-prd-20080922/http://www.w3.org/2005/rules/wg/draft/ED-rif-prd-20081121/
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/http://www.w3.org/2005/rules/wg/draft/ED-rif-prd-20080922/ (color-coded diff)
Editors:
Christian de Sainte Marie, ILOG
Adrian Paschke , TechnicalPaschke, Free University DresdenBerlin
Gary Hallmark, Oracle

Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

This document specifies RIF-PRD, a Rule Interchange Format (RIF) dialect to enable the interchange of production rules.

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

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

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

Please Comment By 2008-09-252008-11-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.

Contents

1 Overview

1.1 IntroductionThis document specifies the production rule dialect of the W3C rule interchange format (RIF-PRD). Production(RIF-PRD), a common XML serialisation format for many production rule languages.

Production rules are rules with an "if""if" part and a "then""then" part. The "if""if" part, also called a "condition","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""then" part of production rules may contain actions, unlike the conclusion of logic rules that may contain only a logical statement. Actions can modify the facts, not only the knowledge basebase; and they can have other side-effects.

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

As a common XML serialisation format for manyproduction rule languages,interchange format, RIF-PRD specifies an XMLabstract syntax that is shared by many concrete production rule languages for the most widely used features ( section 2 - Syntax ),features, and the operationalassociates each abstract construct with normative semantics that RIF-PRD constructs are intended to represent ( section 3 - Operational(section 2, Abstract syntax and Semantics ). This document is mostly intended for the designers) and developers of RIF-PRD implementations, that is, applications that serialize production rules as RIF-PRDa normative XML (producer applications) and/or that deserialize RIF-PRDconcrete syntax (section 3, XML documents intosyntax).

Production rules (consumer applications). Editor's Note: This working draft specifies the RIF-PRD serialisation of a set of core constructs only. Future versionsare statements of this document will extendprogramming logic that specify the setexecution of RIF-PRD constructs to coverone or more actions in the most widely used featurescase that their conditions are satisfied. Production rules therefore have an operational semantic (formalizing state changes, e.g., on the basis of a state transition system formalism). The OMG Production Rule languages.Representation specification [PRR] summarizes it as follows:

  1. Match: the working group seeks feedbackrules are instantiated based on what features should be supported by RIF-PRDthe definition of the rule conditions and what constructs should or should notthe current state of the data source;
  2. Conflict resolution: select rule instances to be required from conformant RIF-PRD implementations. Asexecuted, per strategy;
  3. Act: change state of data source, by executing the selected rule instances’ actions. If a RIF dialect, RIF-PRDterminal state has alsonot been designedreached, the control loops back to maximize interoperability between rule languages overthe World Wide Web.first step (Match).

In this draft, this is achieved by sharing the same syntax for the subset of RIF documents wherethe section Operational semantics intended for a production ruleset serialized in RIF-PRD,of rules and the semantics intended for a logicrule base serialized in the basic logic dialect of RIF, RIF-BLDsets, agree.the correspondence between RIF-PRDsemantics for rules and RIF-BLDrule sets is detailed in Appendix: Compatibility with RIF-BLD . Editor's Note: Future versions of this working draft will draw on otherspecified, accordingly, as a label terminal transition system [ref Plotkin].

However, as a RIF documentsdialect, RIF-PRD has also been designed to maximize interoperability with otherbetween rule languages, most noticeably the RIF data types and builtins specification, RIF-DTB , andlanguages over the RIF extensibility framework (currently being specifiedWorld Wide Web. In RIF, this is achieved by sharing the working group; see also the RIF frameworksame syntax for logic dialects, RIF-FLD ,constructs that specifieshave the same semantics across multiple dialects. As a framework for designing RIF logic dialects). Inconsequence, RIF-PRD shares most of the section 2syntax for rule conditions with RIF-BLD, two related but distinct syntaxesand the semantics associated to the syntactic constructs used for representing the condition part of rules in RIF-PRD components are introduced: XML syntax. This syntaxis specified, in the normative XML serializationsection Semantics of RIF-PRD.conditions, in terms of a model theory, as it is meant, and has been designed, to workin the specification of RIF-BLD as a common XML serialisation for many production rule languages.well. In addition to emphasizing the similarity between the two dialects, it is also meant, and has been designed,allows them to work as a common XML serialisationshare the same definition for production rule languagesdata types and logic rule languages, wherever they agree onbuilt-ins by reference to the semantics: as a consequence, RIF-PRDRIF data types and RIF-BLD sharebuilt-ins specification.

In the same XML syntax whereversection Operational semantics of actions, the semantics associated with the constructs used to represent the action part of rules in RIF-PRD is specified in terms of a transition relation between successive states of the data source, as defined by the condition formulae that they agree onentail, thus making the semantics.link between the XMLmodel-theoretic semantics of conditions and the operational semantics of rules and rulesets.

The abstract syntax is specified using textual descriptionsin mathematical english, and BNF pseudo-schemas. A normative XML schema will also be providedthe abstract syntactic constructs defined in future versions ofsection 2, Abstract syntax and Semantics, are mapped one to one onto the document; Presentationconcrete XML syntax in section 3, XML syntax. A presentation syntaxlightweight notation is also specified,defined along with the abstract syntax, to allow for a more easily readable presentationhuman-friendlier specification of RIF-PRD language fragments (such as examples etc). To make the overlap between RIF-PRD and RIF-BLD visible, RIF-PRD re-usesthe semantics. A more complete presentation syntax of RIF-BLD wherever they shareis specified using an EBNF in section 4. However, only the sameXML syntax (and agree on the semantics).and the presentation syntax is nonassociated semantics are normative. A normative XML schema will also be provided in future versions of the document;

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) :-If      And( ?customer#ex1:Customer
                ?customer[ex1:purchasesYTD->?purchasesYTD]
                 pred:numeric-greater-than(?purchasesYTD 5000) )) Editor's Note: As a consequence of the re-use ofExternal(pred:numeric-greater-than(?purchasesYTD 5000)))
 Then ex1:Gold(?customer) )

RIF-PRD and RIF-BLD presentation syntax, examplesshare more than part of their condition language, and fragments written in RIF-PRD non-normative presentation syntax maywhole RIF documents have an unfamiliar look to production rules developers and users.the working group seeks feedback on this issue as well.same syntax and the overall structure ofsame intended meaning in both dialects. The syntax ofcorrespondence between RIF-PRD and RIF-BLD is also presented as an UML-like diagramdetailed in Appendix: UML-like diagram of RIF-PRD syntaxCompatibility with RIF-BLD.

This document is mostly intended for the diagram provides an overviewdesigners and developers of RIF-PRD syntactic classesimplementations, 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).


2 Abstact syntax and shows at a glance how they relate to each others. It is provided for informative purposes only. In theSemantics

2.1 Conditions

This section 3 ,specifies the intended semantics for RIF-PRD constructs is specified normatively. Aslanguage of the rule conditions that can be seen fromserialized using RIF-PRD, by specifying:

Note to the rdf: prefix stands for http://www.w3.org/1999/02/22-rdf-syntax-ns# ,reader: this section depends on Section Constants, Symbol Spaces, and rif: standsDatatypes of [RIF-DTB].

2.1.1 Abstract syntax

For a production rule language to be able to interchange rules using RIF-PRD, its alphabet for expressing the URIcondition parts of a rule must, at the RIF namespace, http://www.w3.org/2007/rif# .abstract syntax such as xsd:string should be understood aslevel, consist of:

For the string string . The compact URIsake of readibility and simplicity, this specification introduces a notation is usedfor brevity only, and xsd:string shouldthese constructs. That notation is not intended to be understood, in this document, as an abbreviationa concrete syntax and it leaves out many details that are not needed for http://www.w3.org/2001/XMLSchema#string . 1.2.2 BNF pseudo-schemasits purpose: the XMLonly concrete syntax offor RIF-PRD is specifiedthe XML syntax.

Notice that the production rule systems for each component aswhich RIF-PRD aims to provide a pseudo-schema, as partcommon XML serialization use only externally specified functions, e.g. builtins. This is one of two points where the description ofsyntaxes for conditions in RIF-PRD and RIF-BLD differ, since RIF-BLD specifies, in addition, a construct for serializing the component.logic functions that logic languages also use.

The pseudo-schemas use BNF-style conventionssecond point of difference between the syntaxes 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,conditions in RIF-PRD and "|" represents choice. Attributes are conventionally assignedRIF-BLD is that, unlike RIF-PRD, RIF-BLD does not specify a value which correspondsconstruct for negation. This is because logic rule languages use many different kinds of negations, none of them prevalent enough to their type, as definedjustify inclusion in the normative schema. Elements are conventionally assigned a value which is the namebasic logic dialect of RIF (see also the syntactic class of their content, as defined inRIF framework for logic dialects).

2.1.1.1 Terms

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.2.3 Syntactic components Three kinds of syntactic components are used to specify RIF-PRD: Abstract classes are defined only by their subclasses: they not visible in the XML markup andmost basic construct that can be thoughtserialized using RIF-PRD is the term. RIF-PRD provides for the representation and interchange of as extension points. In this document, abstract constructs will be denotedseveral kinds of terms: constants, variables, positional terms and terms with all-uppercase names; Concrete classes have a concretenamed arguments

Definition (Term).

  1. Constants and they are associated with specific XML markup. In this document, concrete constructs will be denoted with CamelCase names with leading capital letter; Properties ,variables. If t ∈ Const or roles , define how two classes relate to each other. They have concrete definitionst ∈ Var then t is a simple term.
  2. Positional terms. If t ∈ Const and t1, ..., tn, n≥0, are associated with specific XML markup. In this document, properties will be denotedterms then t(t1 ... tn) is a positional term.
    Here, the constant t represents a function and t1, ..., tn represent argument values.
  3. Terms with camelCase namesnamed arguments. A term with leading smallcase letter. 1.3 Running example This section describes the fictious RIF-PRD use casenamed arguments is of Joethe Hen Public,form t(s1->v1 ... sn->vn), where n≥0, t ∈ Const and v1, ..., vn are terms and s1, ..., sn are pairwise distinct symbols from the rule that will be used as a running example in this document. Joe the Hen Public developed a very sophisticated program to grow feeble chicks into deliciously plump chickens for a minimal cost. Joe publishes his method on his Web site www.juicychicken.org. Since he is still experimenting to improve his method,set ArgNames.
    The rules to follow change quite often,constant t here represents a function; s1, ..., sn represent argument names; and Joe decidedv1, ..., vn represent argument values. The argument names, s1, ..., sn, are required to publish them in RIF as well, sobe pairwise distinct. Terms with named arguments are like positional terms except that his followers can easily, even automatically, implementthe very latest version. Joe's methodarguments are named and their order is immaterial. Note that a complex exerciseterm of behavioural hen psychology: one aspect that is relevant forthe example isform f() is, trivially, both a positional term and a term with named arguments.
2.1.1.2 Atomics

The atomic truth-valued constructs that it requires that, under certain internal and/or external conditions, hen own potatoes, hen owned potatoescan be serialized using RIF-PRD are mashed, hen daily grain allowancecalled atomics.

Definition (Atomic). An atomic can have several different forms and is increased or decreased etc. Joe's latest addition to his knowledge basedefined as follows:

  1. Positional atomics. If t ∈ Const and t1, ..., tn, n≥0, are terms then t(t1 ... tn) is an advice that: ona Monday, ifpositional atomic (or simply a chicken over 8 months old ownspositional atom).
  2. Atomics with named arguments. An atomic with named arguments (or simply a potato that weights (in decigrams) more than half its age, and if the foxatom with named arguments) is not in the hen house, then the potato should be mashed and the daily grain allowanceof the chicken increased by 10%form t(s1->v1 ... sn->vn), where n≥0, t ∈ Const and v1, ..., vn are terms and s1, ..., sn are pairwise distinct symbols from the set ArgNames.
    Joe calls itThe "Chickenconstant t here represents a predicate; s1, ..., sn represent argument names; and Mashed Potatoes", or CMP, rule.v1, ..., vn represent argument values. The CMP ruleargument names, s1, ..., sn, are required to be pairwise distinct. Atoms with named arguments are like positional Atoms except that the arguments are named and their order is a production rule:immaterial. Note that an atom of the form t() is, whentrivially, both a positional atom and an atom with named arguments.
  3. Equality atomics. t = s is an equality atomic, if t and s are terms.
  4. Class membership atomics (or just membership atomics). t#s is a membership atomic if t and s are terms. the conditionterm t is satisfiedthe object and the ruleterm s is implemented (that is, fired),the consequenceclass.
  5. Subclass atomics. t##s is that some actionsa subclass atomic if t and s are executed (mashing potatoes, modifying a chicken's diet, managing ownership relations etc). Therefore, itterms.
  6. Frame atomics. t[p1->v1 ... pn->vn] is best interchanged using RIF-PRD,a frame atomic (or simply a frame) if t, p1, ..., pn, v1, ..., vn, n ≥ 0, are terms. The production rule dialectterm t is the object of RIF.the CMP rule might be rephrased in RIF-PRD non-normative presentation syntax as follows: (* joe:ChickenAndMashedPotatoes *) //frame; the identifier ofpi are the rule isproperty or attribute names; and 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 ofvi are the "allowance"property of the chicken thator attribute values. In this document, an attribute/value pair is boundsometimes called a slot.
    Membership, subclass, and frame atomics are used to ?chicken // is increased by 10% Retract(joe:owns(?chicken ?potato)) ) :- //describe objects, classifications and class hierarchies.
  7. Externally defined atomics. If And( // Rule conditions ?chicken#joe:Chicken // The object bound to ?chickent is a "Chicken"positional, named-argument, or a frame atomic then External(t) is an externally defined atomic.
    Such atomics are used for representing built-in predicates as specifiedwell as "procedurally attached" predicates, which might exist 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" // isvarious rule-based systems or applications, but are not 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 sureRIF-PRD.

Note that his rulesnot only predicates, but also frame atomics can be implemented unambiguously, Joe publishedexternally defined. Therefore, external information sources can be modeled in an object-oriented way via frames. For instance, External("http://example.com/acme"^^rif:iri["http://example.com/mycompany/president"^^rif:iri(?Year) -> ?Pres]) could be a data model (e.g.,representation of an XML schema)externally defined method "http://example.com/mycompany/president"^^rif:iri in an external object "http://example.com/acme"^^rif:iri.   ☐

Observe that identifies Chickenthe argument names of frames, p1, ..., pn, are terms and Potatoso, as two classes of objects: instances of Chickena special case, can be variables. In contrast, atoms with named arguments can use only the symbols from ArgNames to represent individual chickens.their argument names. They have a propertycannot be constants from Const or variables from Var.

Note that atomics are sometimes also called ageterms, e.g. in the realm of logic languages: the specification of RIF-BLD, in particular, follows that representsusage. The chicken's ageabstract syntactic elements that are called terms in months as an xsd:decimal and a propertythis specification, are called allowance that representbasic terms in the chicken's daily grain allowance as an xsd:integer ; instancesspecification of Potato represent individual potatoes. They have a property called weightRIF-BLD.

2.1.1.3 Formulas

Composite truth-valued constructs that represents the potato's weight in decigram ascan be serialized using RIF-PRD are called formulas.

Any atomic is also an xsd:decimalatomic formula.

Joe further specifies: a binary predicate owns(?o ?i)Note that denotes the ownership relation between owner ?oterms (constants, variables and owned item ?i ; a nullary function today() that returns the dayfunctions) are not formulas.

More general formulas are constructed out of the week as a xsd:string ;atomic formulas with the help of logical connectives.

Definition (Condition formula). A boolean fox sensor foxAlarm() that returns true ifcondition formula can have several different forms and onlyis defined as follows:

  1. Atomic: If the foxφ is in the hen house; andan atomic formula then it is also a command mash(?i)condition formula.
  2. Conjunction: If φ1, which execution results in the physical item that..., φn, n ≥ 0, are condition formulas then so is denoted by ?i being reduced toAnd(φ1 ... φn), called a soft pulpy state by beating or pressure (and in the corresponding logical object being removed from the instances of its class,conjunctive formula. As a consequence). All these (typesspecial case, And() is allowed and names) are defined in Joe's namespace http://rif.examples.com/2008/joe# . The assumptionis thattreated as a systemtautology, i.e., a formula that consumesis always true.
  3. Disjunction: If φ1, ..., φn, n ≥ 0, are condition formulas then so is Or(φ1 ... φn), called a RIF document published by Joe knows how to map Joe's published data model and specification of predicatesdisjunctive formula. As a special case, Or() is permitted and functions to/from its own underlying data representation. Whatis treated as a contradiction, i.e., a consumerformula that is expected to do when thisalways false.
  4. Negation: If φ is not the casea condition formula, then so is still under discussion and will be specified asNot(φ), called a conformance clause innegative formula.
  5. Existentials: If φ is a future version of this document. 2 Syntax This section specifies the XML syntax for serializing the rule conditionscondition formula and the rule actions?V1, as well as complete production rules..., ?Vn, groups of rules and formulae, and any accompanying metadata . Finally, RIF-PRD presentation syntax is specified. 2.1 Conditions This section specifies the XML syntax thatn>0, are variables then Exists ?V1 ... ?Vn(φ) is used to serialize,an existential formula.

In RIF-PRD,the different boolean expressions that can be found in production rules. That syntax is sometimes calleddefinition of a formula, the condition language , by referencecomponent formulas φ and φi are said to be subformulas of the respective condition language of RIF-BLD , which determines what conditions in a logic rule can be represented in RIF-BLD . It playsformulas that are built using these components.

The function Var(e) that maps a similar role in RIF-PRD and,term, atomic or formula e 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 TERMset of its free variables is an abstract construct, concretely visible, in RIF-PRD,defined as afollows:

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. 2.1.1 TERM The TERM class of constructsDefinition (Ground formula). A condition formula φ is used to represent constants, variablesa ground formula if and only if Varφ = {} and φ does not contain any existential subformula.

In other words, a ground formula does not contain any variable term.
2.1.1.4 Well-formed Formulas

The applicationspecification of function symbolsRIF-PRD does not assign a standard meaning to other TERM s. As an abstract class, TERM isall the formulas that can be serialized using its concrete XML syntax: formulas that can be meaningfully serialized are called well-formed. Not associatedall formulas are well-formed with specific XML markup in RIF-PRD instance documents. [ Const | Var | External ] 2.1.1.1 Const In RIF, the Const construct is usedrespect to represent a constant. The Const element has aRIF-PRD: it is required type attribute and an optional xml:lang attribute:that no constant appear in more than one context. What this means precisely is explained below.

The valueset of the type attributeall constant symbols, Const, is the identifierpartitioned into several subsets as follows:

Each predicate and function symbol has precisely one arity. For positional predicate and function symbols, an arity is a non-negative integer that all dialects includetells how many arguments the following builtin constant types. Rule sets that are exchanged through RIF can use additionalsymbol 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:decimalcan take. For symbols that take named arguments, an arity is a set {s1 ... sk} of argument names ( http://www.w3.org/2001/XMLSchema#decimalsi ∈ ArgNames) that are allowed for that symbol.

An important point is that neither the lexical spacesabove partitioning of constant symbols nor the above symbol spacesarity are defined inspecified explicitly. Instead, 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 subtypesarity of the XML Schema data type xs:duration with well-defined value spaces, since xs:duration does not havea well-defined value space (this may be corrected in later revisions of XML Schema data types, in which case the revised datasymbol and its type would be suitable for RIF DTB). The lexical spaces ofis determined by the above symbol spaces are definedcontext in which the document [ XDM ]. rdf:XMLLiteral ( http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral ). Thissymbol space represents XML content.is used.

Definition (Context of a symbol). The lexical spacecontext of rdf:XMLLiteral is definedan occurrence of a symbol, s∈Const, in the document [ RDF-CONCEPTS ]. rif:text ( http://www.w3.org/2007/rif#texta formula, φ, for text strings with language tags attached). Thisis determined as follows:

Definition (Well-formed formula). A rif:iriformula φ is well-formed iff:

Definition (RIF-PRD condition language). The lexical spaceRIF-PRD condition language consists of xs:string . Editor's Note:the listset of builtin constant types mayall well-formed formulas that can be modified in future versionsserialized using the RIF-PRD XML syntax.

2.1.2 Semantics of condition formulas

This document, based onsection specifies the content of future versionsintended semantics of the condition formulas in a RIF-PRD document.

For compatibility with other RIF specifications (in particular, RIF data types and builtins document, RIF-DTB . Editor's Note:), and to make the case of non-standard data types, that is, of constants that do not belong or cannot be cast in one ofinteroperability with RIF builtin typeslogic dialects (in particular RIF-Core and RIF-BLD), the intended semantics for interchange purposes,RIF-PRD condition formulas is still under discussionspecified in terms of a model theory.

2.1.2.1 Semantic Structures

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 RIFkey concept in onea model-theoretic semantics 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> ) hasa correct lexical part, since 123 belongs tologic language is the lexical spacenotion of the data type xsd:longa semantic structure [Enderton01, Mendelson97].

Definition (Semantic structure). In contrast, abc^^xsd:long ( <Const type="xsd:long">abc</Const> ) is ill-formed, as it does not haveA correct lexical part.semantic structure, I, is a compliant RIF-PRD translator MUST reject ill-formed symbols. Example 2.1. In eachtuple of the examples below, a constantform <TV, DTS, D, Dind, IC, IV, IP, INP, Iframe, Isub, Iisa, I=, Iexternal, Itruth>. Here D 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 typenon-empty set of elements called the constantdomain of I, and Dind is rif:iri : <Const type="rif:iri"> http://rif.examples.com/2008/joe#today </Const> c.a constant with symbol BigPotato thatnonempty subset of D. Dind is localused to interpret the setelements of rules where it appears (e.g. a RuleSet specific to Paula's farm).Const that are individuals. As before, Const denotes the typeset of the constant is rif:local : <Const type="rif:local">BigPotato</Const> d. Aall constant with non-builtin type xsd:intsymbols and value 123: <Const type="xsd:int">123</Const> 2.1.1.2Var In RIF,the Var construct is used to represent variables.set of all variable symbols. TV denotes the contentset of truth values that the Var elementsemantic structure uses and DTS is a set of identifiers for primitive datatypes (please refer to Section Datatypes of [RIF-DTB] for the variable's name, representedsemantics of datatypes).

As far as an Unicode character string. <Var> any Unicode string </Var> Example 2.2. The example below showsthe XML serializationassignement of a standard meaning to formulas in the variable ?chicken . Notice thatRIF-PRD condition language is concerned, the contentset TV of truth values consists of just two values, t and f.

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

For convenience, we also define the normative schema asfollowing mapping I from terms to D:

The slot key, and a required TERM that represents its value. <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:effect of datatypes. The slotted, or named arguments form ofset DTS must include the Atom construct is still under discussion (see also ISSUE-68 ).datatypes described in Section Primitive Datatypes of [RIF-DTB].

The working group seeks feedback on whether or not it should be includeddatatype identifiers in PRD. Example 2.4.DTS impose the example below showsfollowing restrictions. Given dt ∈ DTS, let LSdt denote the RIF XML representationlexical space of dt, VSdt denote its value space, and Ldt: LSdt → VSdt the predicate owns(?c ?p)lexical-to-value-space mapping (for the definitions of these concepts, see Section Primitive Datatypes of [RIF-DTB]. Then the following must hold:

That is, IC must map the predicate symbol owns is definedconstants of a datatype dt in the example namespace http://rif.examples.com/2008/joe#accordance with Ldt.

<Atom> <op> <Const type="rif:iri"> http://rif.examples.com/2008/joe#owns </Const> </op> <args rif:ordered="yes"> <Var>RIF-PRD does not impose restrictions on IC </Var> <Var> p </Var> </args> </Atom> 2.1.2.2 Equalfor constants in RIF, Equal is used to represent equality relations. The Equal element must contain one left sub-element an done right sub-element. The contentsymbol spaces that are not datatypes included in DTS.

2.1.2.2 Interpretation of condition formulas

This section defines how a semantic structure, I, determines the left and right elements must betruth value TValI(φ) of a constructcondition formula, φ.

We define a mapping, TValI, from the TERM abstract class. The orderset of all condition formulas to TV. Note that the sub-elements is not significant. <Equal> <left> TERM </left> <right> TERM </right> </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 instance 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. Itdefinition implies that TValI(φ) is required as well. <Member> <instance> TERM </instance> <class> TERM </class> </Member> Example 2.5. The example below showsdefined only if the RIF XML representationset DTS of a boolean expression that tests whether the individual denoted bythe variable ?c is a memberdatatypes of I includes all the class Chicken thatdatatypes mentioned in φ and Iexternal is defined on all externally defined functions and predicates 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> 2.1.2.4 SubclassDefinition (Truth valuation). Truth valuation for well-formed condition formulas in RIF, the Subclass elementRIF-PRD is used to represent class inclusion relations. The Subclass element contains unordered two sub-elements:determined using the sub element must be a construct fromfollowing function, denoted TValI:

2.1.2.3 Satisfaction of the builtin predicates specified for RIF-PRD, ora condition

We now define what it can be application specific. Inmeans for a set of ground formulas to satisfy a condition formula. The latter case, it is upsatisfaction of condition formulas by a set of ground formulas provides formal underpinning to the producers and consumersoperational semantics of RIF-PRDrulesets that reference non-builtin predicates to agree on their semantics. Example 2.7. The example below shows the RIF XML representation ofinterchanged using RIF-PRD.


Definition (Models). A boolean expression that tests whether the value denoted by variable ?a (e.g. the agesemantic structure I is a model of a chicken) is greater than the integer value 8, where the test is intended to behave like the builtin predicate op:numeric-greater-thancondition formula, φ, written as specified in XQuery 1.0I |= φ, iff TValI(φ) = t.

Definition (Logical entailment). Let φ and XPath 2.0 Functionsψ be formulas. We say that φ entails ψ, written as φ |= ψ, if and Operatorsonly if for every semantic structure, I, for which both TValI(φ) and TValI(ψ) are defined, I |= φ implies I |= ψ.

By extension, 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> 2.1.3.3 Andthis document, a FORMULA can represent the conjunction of zero of more statements, eachset of them represented byformulas, Φ = {φ1, ..., φn}, n ≥ 1, is said to entail a formula . This is represented by theψ, written as Φ |= ψ, if and construct. Theonly if for every semantic structure, I, for which TValI(φ0), ..., TValI(φn), and element contains zero or more formula elements, each containing an elementTValI(ψ) are defined, I |= φ0 and ... and I |= φn implies I |= ψ.

Definition (Condition Satisfaction). Let Φ = {φ1, ..., φm}, m ≥ 1, be a set of the FORMULA group. <And> <formula> FORMULA </formula>* </And> 2.1.3.4 Orground formulas and ψ be a FORMULA can represent the disjunction of zero of more statements, eachcondition formula. We say that Φ satisfies ψ if and only if, for every semantic structure I that is a model of them represented byall the ground formulas φi in Φ: I |= φi, i= 1..m, there is at least one semantic structure I* such that:

  1. I* |= ψ, and
  2. I* is exactly like I, except that a FORMULA . Thismapping I*V is represented by the Or construct. The Or element contains zero or more formula elements, each containing an elementused instead of IV, such that   I*V is defined to coincide with IV on all variables except, possibly, on the FORMULA group. <Or> <formula> FORMULA </formula>* </Or> 2.1.3.5 NmNotvariables ?v0 ... ?vn, n ≥ 0, that are free in ψ, that is, such that: Var(ψ) = {?v0 ... ?vn}.

In other words, a set of ground formulas Φ = {φ1, ..., φm}m ≥ 1 satisfies a condition formula can representψ iff Φ |= Exists ?v0 ... ?vn (ψ), where {?v0, ..., ?vn}n ≥ 0 = Var(ψ).
2.1.2.4 Matching substitution

At the non-monotonic negationsyntactic level, the interpretation of a statement, itself representedthe variables by a FORMULA : thisvaluation function IV is represenetdrealized by a substitution. The NmNot construct. The NnNot element contains exactly one formula element. The formula element contains an elementmatching substitution of constants to variables, as defined below, provides the FORMULA group, that representsformal link between the negated statement. <NmNot> <formula> FORMULA </formula> </NmNot> Editor's Note:model-theoretic semantics of condition formulas and the nameoperational semantics of that construct may change, includingrule sets in RIF-PRD.

Let Term be the tagset of the XML element. 2.1.3.6 Existsterms in RIF,the Exists constructRIF-PRD condition language (as defined in section Terms).

Definition (Substitution). A substitution is used to represent an existentially quantified FORMULA . The Exists element contains: one or more declare sub-elements, each containinga Var element that represents onefinitely non-identical assignment of the existentially quantifiedterms to variables; exactly one required formula sub-element that contains an elementi.e., a function σ 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 2.8. The example below shows the RIF XML representation of a boolean expressionto Term such that tests whetherthe chicken denoted by variable ?cset {x ∈ Var | x ≠ σ(x)} is older than 8 months, by testingfinite. This set is called the existencedomain of a value,σ and denoted by variable ?a , thatDom(σ). Such a substitution is both the age of ?c ,also written as represented bya Frameset such as in example 2.6 ,σ = {ti/xi}i=0..n where Dom(σ) = {xi}i=0..n and greater than 8, as represented by an External ATOMIC asσ(xi) = ti, i = 0..,n.

Definition (Ground Substitution). A ground substitution is a substitution σ that assigns only constants to the variables in example 2.7Dom(σ): ∀ x ∈ Dom(σ), σ(x) ∈ Const.

<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>Definition (Matching Substitution). Let ψ be a </Var> </slot> </Frame> <External> <content> <Atom> <op> <Const type="rif:iri"> op:numeric-greater-than </Const> </op> <args rif:ordered="yes"> <Var>condition formula; let σ be a </Var> <Const type="xsd:decimal"> 8 </Const> </args> </Atom> </content> </External> </And> </formula> </Exists> 2.2 Actions This section specifies the XML syntax that is used to serialize, in RIF-PRD, what can appear inground substitution for the action partfree variables of ψ, that is, such that: Var(ψ) ⊆ Dom(σ); and let Φ be a rule supported by RIF-PRD. RIF-PRD defines one single abstract class for actions, ACTION ,set of ground formulas that satisfies ψ. We say that σ is realized by: the ASSERT action, which is concretely represented by the Atom or the Framematching Ψ to be asserted; the concrete Retract construct, whichΦ (or simply, matching, when there is associatedno ambiguity with respect to Ψ and Φ) if an Atom or a Frameonly if, for every semantic structure I that represents the target of the action. The following sections specify each construct separately, grouped by abstract syntactic classes. Editor's Note: This sectionis still under discussion in the working group (see ISSUE-62 ). The working group considers adding an Assign action to represent the modificationa model of all the value of an attributeground formulas φi in Φ, there is at least one semantic structure I*, such that:

  1. I* is a fact represented bymodel of ψ: I* |= ψ;
  2. I* is exactly like I, except that a Framemapping I*V is used instead of IV, and an Execute actionsuch that   I*V is defined to represent the execution of an arbitrary, externally specified procedure. The working group seeks feedback regarding the proposed syntax forcoincide with IV on all variables except, possibly, on 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. 2.2.1 ACTION The ACTION class of constructs is used to represent the individual actionsvariables ?v0 ... ?vn that are free in ψ, that is, such that: Var(ψ) = {?v0 ... ?vn};
  3. I*V(?xi) = IC(σ(?xi)), for all ?xi in Var(ψ).

In the action partdefinition of a production rule representedmatching substitution, conditions 1 and 2 are the same as in RIF-PRD. This versionthe definition of RIF-PRD covers four ACTION s: ASSERT , NewCondition Satisfaction, Retractand ACTION_BLOCK . As an abstract class, ACTION is not associated with specific XML markup in RIF-PRD instance documents. [ ASSERT | New | Retract | ACTION_BLOCK ] 2.2.1.1 ASSERT An ASSERT construct is used to represent actionsthey guarantee that result in asserting an Atom orthe Φ-consistency of a Frame .substitution for compatibility with RIF-BLD , ASSERT is not associated with specific XML markupthe free variables in RIF-PRD instance documents, and itψ is represented only asdefined with respect to the target Atom or Framesame semantic structures that make Φ satisfy ψ. [ Atom | Frame ] Editor's Note:Condition 3 guarantees that Φ |= ψ[σ], where ψ[σ] denotes the working group seeks feedback regarding whetherground condition formula obtained by substituting σ(?x) for every occurence of ?x in ψ, for every variable ?x in Var(ψ).

In other words, a specific XML element, Assertformula ψ matches a ground formula And(φ1, modeled after the Retract element, below, should be used to serialize assertions, instead,..., φn), n > 0, with respect to a ground substitution σ, in the priceusual sense of reducing the interoperability with RIF-BLD . 2.2.1.2 New The New constructpattern matching algorithms, e.g. [REFERENCE], if and only if σ is used to createa new frame objectmatching substitution for the free variables of ψ with membership in a given class.respect to the New element has an optional instance sub-elementset of ground formulas Φ = {φ1, ..., φn}.

2.2 Actions

This section specifies the actions that contains a Var and a class sub-elementcan be serialized using RIF-PRD, by specifying:

(See also: Proposed modified abstract syntax and boundsemantics, taking csma's comments into account)

2.2.1 Abstract Syntax

For a production rule language to be able to interchange rules using RIF-PRD, its alphabet for expressing the instance variable. <New> <instance> Var </instance>? <class> Const </class> </New> Example 2.9.action part of a rule must, at the example below showsabstract syntax level, consist of syntactic constructs to denote:

Editor's Note: ... and/or others. We are especially interested in feedback about actions that represents the facts tocannot be removed on implementing the action. <Retract> <target> [ Atom | Frame | TERM ] </target> </Retract> Example 2.10. The example below shows the RIF XML representationdecomposed into a sequence of an action that updates the chicken-potato ownership table by removing the predicate that states that the chicken denoted by variable ?c ownsthe potato denoted by variable ?p .above.

For 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> 2.2.1.4 ACTION_BLOCK An ACTION_BLOCK construct is used to represent an ordered list of ACTION s. There are two kindssake of ACTION_BLOCK . One uses a restrictedreadability and construct for compatibility with RIF-BLD . The other usessimplicity, this specification introduces a Do constructnon-normative notation for these constructs. That notation is specific to RIF-PRD and permits local variablesnot intended to be declared. [a concrete syntax and | Do ] <And> <formula> ASSERT </formula>* </And> <Do> <declare> Var </declare>* <action> ACTION </action>* </Do> Example 2.11.it leaves out many details that are not needed for its purpose. The example below showsonly normative concrete syntax for RIF-PRD is the RIFXML representation ofsyntax.
2.2.1.1 Atomic actions

Atomic action constructs take constructs from the RIF-PRD condition language as their arguments.

Definition (Atomic action). An atomic 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> 2.3 Production Rules 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 rulescan have several different forms and rule sets. The RULE constructis an abstract class: in RIF-PRD instance documents, it is either visibledefined as follows:

  1. Assert: If φ is a Implies , aspositional atom, an atom with named arguments, a Forall ,frame, a membership atomic, or asa single ACTIONS :subclass atomic in the Implies associates one optionalRIF-PRD condition FORMULA and one non-empty ordered listlanguage, then Assert(φ) is an atomic action. φ is called the target of ACTIONS .the Forall construct declare s one or more Var s, and associates themaction.
  2. Retract: If φ is a positional atom, an atom with zeronamed arguments, or more FORMULA s, as pattern s that constrain the bindings ofa frame in the variables, and with one RULE asRIF-PRD condition language, then Retract(φ) is an atomic action. φ is called the formula in its scope. Editor's Note: This versiontarget of the draft does not specify a specific construct to serializeaction.
  3. Retract object: If t is a rulesetterm in RIF-PRD:the generic Group construct can be used for that purpose - as specified inRIF-PRD condition language, then Retract(t) is an atomic action. t is called the next section, Groupings and metadata . Future versionstarget of this draft may specifythe action.
2.2.1.2 Action variable bindings

Action variable bindings provide a specific-purpose construct, especially if semantically significant information has to be associatedlimited mechanism 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. 2.3.1 RULE In RIF-PRD, the RULE class of constructs is used to represent rules. As an abstract class, RULE is not associated with specific XML markup in RIF-PRD instance documents. [ Implies | Forall |initialize local action ] 2.3.1.1 Implies The Implies construct is usedvariables. Action variables may be bound to represent the conditional statement (that is, the "if-then", or condition-conclusion,newly created frame objects or antecedent-consequent pair) that is at the coreto slot values of a rule. The Implies element containsframes.

Definition (Action variable binding). An optional if sub-elementaction variable binding can have two forms and a then sub-element: the optionalis defined as follows:

  1. New: if element contains an element from the FORMULA class of constructs, that represents the condition of the rule; the required then element contains?o is a non-empty list of elements from thevariable defined in an enclosing action class of constructs. The order of theblock (described below), then New(?o) is an action constructsvariable binding.
  2. frame slot value: if f is a frame in the RIF-PRD condition language, then elementf is significant and MUST be preserved. <Implies> <if> FORMULA </if>? <then rif:ordered="yes">an action variable binding.
2.2.1.3 Action * </then> </Implies> 2.3.1.2 Forall The Forall construct is used to represent universally quantified rules. The Forall element contains: oneblocks

A sequence of zero or more declare sub-elements, each containingvariables followed by a Var element that represents onesequence of the universally quantified variable;zero or more pattern sub-elements, each containing an element from the FORMULA group of constructs that represents a constraint on theaction variable bindings followed by a sequence of one of the Var s thator more atomic actions is called an action block.

Definition (Action block). If v1, ..., vn1, n1 ≥ 0, are declared by the Forallvariables (sometimes called action variables) and b1, ..., bn2, n2 ≥ 0, are action variable bindings and a1, ..., an3, n3 ≥ 1, are atomic actions,

  1. if n1 = 0 then Do(a1 ... an3) is an action block.
  2. else Do v1 ... vn1(b1 ... bn2; a1 ... an3) is an action block.

Definition (Well-formed action block). An action block is well-formed if and only if:

Definition (Ground atomic action). An atomic action with target t is a ground atomic action (or, simply, a ground action) if and only if Var </declare>+ <pattern> FORMULA </pattern>* <formula> RULE </formula> </Forall> Editor's Note: Nested Forall s make explicit(t) ⊆ bv, where bv is the scopeset of thevariables declared variables, and, thus, imposein an order onenclosing action block, if any.
2.2.1.4 RIF-BLD compatibility

If the evaluationthen part of the pattern and if FORMULA e ina rule.rule consists of a single action Assert(φ) then that ordering andaction is written as simply φ.

If the usethen part of patterns to constrain the bindinga rule consists of variables maythe action block Do(Assert(φ1) ... Assert(φn)), n ≥ 2, then that action block is written as simply And(φ1 ... φn).
2.2.1.5 Well-formed actions

Definition (Well-formed action). An action α is well-formed if and only if:

Definition (RIF-PRD action language). The RIF-PRD action language consists of the set of all the well-formed actions.

2.2.2 Operational semantics of actions

This section specifies the intended semantics of the rules being interchanged (although they would be relevant ifactions in a RIF-PRD was to be extended to support some kinddocument.

The effect intended of "else" or "case" construct).the ground actions in addition, RIF-BLD does not allow nested Forall and does not supportthe association of contraining pattern sRIF-PRD action language is to declared variables.change the working group seeks feedback regarding whether nested Forallset of conditions that are satisfied before and constrainting pattern should be supported in RIF-PRD, toafter each action is implemented.

As a consequence, the costintended semantics of reducingthe interoperability with RIF-BLD . Example 2.10. The example below shows howground actions in the CMP rule extract: "if a chicken owns a potato and ..." could be serialized usingRIF-PRD action language determines 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> 2.4 Grouping and metadata This section specifiesrelation, called the additional constructs that are needed to build a complete instanceRIF-PRD document, to group rules into rulesets, and to serialize the metadata that is possibly associated with elements of a rule, a group of rules or atransition relation: →RIF-PRD instance document. 2.4.1 Group⊆ P(W) × L × P(W), where W denotes the Group construct is used to represent groupsset of rules.all the ground condition formulas in RIF-PRD, it is used to serialize rulesets, but it can be used more generally.the Group element has zero or more sentence sub-elements that contain each another Group element or an element ofRIF-PRD condition languages; where P(W) denotes the abstract RULE classpower set of constructs. <Group> <sentence> [ RULE | Group ] </sentence>* </Group> 2.4.2 DocumentW; and where L denotes the Document isset of all the top level constructground atomic actions in athe RIF-PRD instance document.action language.

Definition (RIF-PRD transition relation). The Document contains zero or one payload sub-element, that must contain a Group element. <Document> <payload> Group </payload>? </Document> 2.4.3 Metadata Metadata can be associated with any construct that represents a concrete class element in RIF-PRD: those areintended semantics of RIF-PRD actions is completely specified by the elements with a CamelCase tagname starting with an upper-case character: CLASSELT = [ TERM | ATOMIC | FORMULA | ACTION | RULE | Group | Document ] An identifier can be associated to any construct of the abstract CLASSELT class of constructs, as an optional id sub-element that MUST contain a Const of type rif:local or rif:iritransition relation →RIF-PRD ⊆ P(W) × L × P(W). Metadata can be included in any instance of a concrete class element using the meta sub-element. The(w, α, w') ∈ →RIF-PRD Frame construct is used to serialize metadata: the contentif and only if w ∈ W, w' ∈ W, and one of the Frame 's object sub-element identifies the object to which the metadatafollowing is associated:,true:

  1. α is Assert(φ) and the Frame 's slot s represent the metadata properly said as property-value pairs.for every ground formula ψ in W, w' |= ψ if the all the metadataand only if And(w, φ) |= ψ
  2. α is Retract(φ) and for every ground formula ψ ∈ W, w' |= ψ if and only if w |= ψ and ψ |≠ φ
  3. α is Retract(o) and o is a constant and f1, ..., fn, n ≥ 0, are ground frames where o is related tothe sameobject, and m1, ..., mn', n' ≥ 0, are ground member atomics where o is the meta element can contain a single Frame sub-element.object, and for every ground formula φ ∈ W, w' |= φ if metadata related to several different objects need be serialized, the meta role can contain anand with zeroonly if w |= φ and φ |≠ Or more formula sub-elements, each containing one Frame element. <CLASSELT> <id> Const </id>? <meta> [ Frame | <And> <formula> Frame </formula>* </And> ] </meta>? other CLASSELT content </CLASSELT> Notice that the content of the meta sub-element of an instance of a RIF-PRD class element(f1, ..., fn, m1, ..., mn')
  4. α is not necessarily associated to that same instance element: only the content of the object sub-element of the FrameDo v1...vnv(b1...bnb; α1...αna) such that
    1. represents the metadata specifies what the metadata is about, not where iteach variable vi is includedreplaced everywhere in the instance RIF document. Itactions α1...αna with constant ci, determined as follows. Let bj be the action variable binding that references vi, which is suggestedguaranteed to use Dublin Core, RDFS,exist and OWL propertiesbe unique if α is well-formed:
      1. if bj is New(vi), then ci is a constant such that
        1. 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,every constant k in W, w |≠ ci#k and
        2. foaf:maker. Example 2.11. TBC 2.5 Presentation syntax This section specifies a presentation syntaxfor RIF-PRD. The presentation syntax isevery frame f in W, ci does not normative: its main purpose is to help makeoccur in the normative specificationobject position of the semantics easier to read. The presentation syntaxf
      2. if bj is designed to be very close to RIF-BLD .a line by line comparison of the EBNF will show these few differences: the addition of Not the removal of Expr, the syntactic class of logical functions,frame, then ci comes from the replacement of ATOMIC in rule conclusions with ACTION,substitution ...
    2. (w1, α1, w'1) ∈ →RIF-PRD and ... and (wna, αna, w'na) ∈ →RIF-PRD and w = w1 and wi+1 = w'i and w'na = w'

Rule 1 says that all the addition of Do(ACTION*)condition formulas that were satisfied before an assertion will be satisfied after, and And(ASSERT*) insteadthat the condition formulas that are satisfied by the asserted ground formula will be satisfied after the assertion.

Rule 2 says that all the condition formulas that were satisfied before a retraction will be satisfied after, except if they are satisfied only by the retracted fact.

Rule 3 says that all the condition formulas that were satisfied before the removal of And(ATOMIC*) ina frame object will be satisfied after, except if they are satisfied only by one of the frame or membership formulas about the removed object or a conjunction of such formulas.

Rule conclusions. definition4 says that the effect of ASSERT, New, and Retract actions. Ita block of actions is intendedthe effect of executing each action one after the other.

2.3 Production rules and rulesets

This section specifies the rules and rulesets that can be serialized using RIF-PRD, by specifying:

In addition, this section specifies additional concrete XML syntax for wrapping a single Atom or Frame, Not is not used,ruleset in a RIF-PRD document and logical functions are not used.for adding meta-data to elements in a RIF-PRD document.

2.3.1 Abstract syntax

For a production rule language to be able to interchange rules using RIF-PRD, in addition to the following EBNF is from RIF-BLD ,RIF-PRD condition and action languages, its alphabet must, at the abstract syntax level, contain syntactic constructs:

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 ::= '?' UNICODESTRINGthe following EBNF is taken from RIF-DTBsake of readability and is unchangedsimplicity, this specification introduces a notation for PRD. Its purposethese constructs. That notation is not intended to provide shortcutsbe a concrete syntax and it leaves out many details that are not needed 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:localits purpose: the following EBNFonly concrete syntax for RIF-PRD is from RIF-BLD and defines rules, groups of rules, andthe containing document. Changed lines are prefixed with !. MetadataXML syntax.
2.3.1.1 Rules

Definition (Rule). A rule can be associatedeither:

A rule ')') | CLAUSE ! CLAUSE ::= Implies | ACTION ! Implies ::= IRIMETA? (ACTION | 'Do' '(' ACTION* ')') ':-' FORMULA IRIMETA ::= '(*' Const? (Frame | 'And' '(' Frame* ')')? '*)' IRI ::= UNICODESTRING Profile ::= UNICODESTRING Finally, the following EBNF describesIf condition, Then action can be equivalently noted action :- condition, that is, using RIF-BLD logic programming notation. Indeed, the normative XML syntax is the same for a conditional assertion in RIF-BLD and for a conditional action in RIF-PRD. The use of PRD actions.RIF-BLD notation is especially useful if the condition formula, condition, contains no negation, and if 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* ')' 3 Operationalis an atomic conclusion or a conclusion block, to emphasize that such a rule has the same semantics 3.1 Introductionin RIF-PRD and RIF-BLD.

Notice that the notation for a rule with bound variables uses the purposekeyword Forall for the same reasons, that is, to emphasize the overlap with RIF-BLD. Indeed, although Forall does not indicate the universal quantification of specifyingthe declared variables, in RIF-PRD, but merely that the execution of the rule must be considered for all their bindings as constrained by the binding patterns, the semantics of a RIF-PRD RuleSet , a productionrule system PRS is defined aswith bound variables and the semantics of a labeled terminal transition system (e.g. PLO04 ).RIF-BLD universally quantified rule coincide whenever they have the same RIF XML syntax.
2.3.1.2 Groups

Definition (labeled terminal transition system):(Group). If strategy denotes a labeled terminal transition systemconflict resolution strategy, if priority is a structure { Can integer, and if each rgj, L0 ≤ j ≤ n, →, T }, where Cis either a set of elements, c , called configurations; L isrule or a setgroup, then any of elements, a , called actions (or labels); → ⊆ C × L × C isthe transition relation, that is: ( c, a, c' ) ∈ → iff therefollowing is a transition labelled a fromgroup:
2.3.1.3 Well-formed rules and groups

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 transitionfunction Var(f), that has been defined for condition formulae, is extended to configuration c' . We note: c + a → c' or c a → c' ; T ⊆ Cactions, and, further, to rules, as follows:

Definition (Well-formed rule). A rule, r, is 6 months olda well-formed rule if and Julia (daily grain allowanceonly if it contains no free variable, that is, Var(r) = 14) is 10 months old; BigPotato weights 70g, SmallPotato weights 10g, UglyPotato weights 50g; Joe owns BigPotato, Jack0, and Woof own SmallPotato jointly (Woofeither:

Definition (Well-formed group). A well-formed group 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 toeither Joe, Jack or Julia and SmallPotato is too small); Supposea group that Judicael's implementation of today() returns Mondaycontains only well-formed rules and well-formed groups, or a group that the foxAlarm() is false when the CMPcontains no rule is applied:or group (an empty group).

The condition is satisfied, andset of the actions inwell-formed groups contains all the conclusion are executed with BigPotato substituted for ?potato , Joe substituted for ?chicken ,production rulesets that can be meaningfully interchanged using RIF-PRD.

2.3.2 Operational semantics of rules and 10 substitutedrule sets

For ?allowance . This results inthe following changes in the setpurpose of facts: BigPotato is mashed (and removed fromspecifying the list of potatoes to be considered in future applicationssemantics of the CMP rule); the daily grain allowancea RIF-PRD rule or group of Joerules, a production rule system PRS is defined as a labeled terminal transition system (e.g. PLO04).

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

A labeled transition system is a structure {C, L, →} (without a set T of terms that can be represented in RIF-PRD. Definition (signature): Let PRD be a signaturefinal states).

The idea of RIF-PRD defineddescribing a PRS as a tuple < DTS , Pred , Frame , Act , = , # , ## , External , Const , ArgNames , arity , type > with DTSlabeled terminal transition system is that, given a set of symbols for primitive datatypes (please refer to Section Datatypes ) Predproduction rules RS and a countably infiniteset of symbols called predicates where '' Pred ∈ Const .facts w0, the rules in RS that are satisfied, in some sense, in w0 determine an action a countably infinite set of frame symbols Frame where '' Frame ∈ Const . Act1, which execution results in a countably infinitenew set of symbols called actions where '' Act ∈ {ASSERT, RETRACT} .facts w1; the rules in RS that are satisfied in w1 determine an action a set of symols = , # , ##2 to execute in w1, External denoting equality, membership, subclass and external built-in functionsand predicatesso on, until the system reaches a countably infinitefinal state and stops. The result is the set of constant symbols Const . a countably infinite setfacts wn when the system stops.

Example 3.1. Judicael, one follower of argument names, ArgNames called named arguments (disjoint from Const ) a function arity where for each predicate P i ∈ Pred , arity(P i )Joe the Hen Public's method, has four chickens, Joe, Jack, Joe and Julia, that own three potatoes (BigPotato, SmallPotato, UglyPotato) among them:

That is the 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 1 , ...,dt k > where each dt j ∈ DTS , if t is an external predicateinitial set of arity k type(External(t))facts w0. 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 a k+1 tuple of datatypes from DTS definingapplied to w0:

Suppose that Judicael's implementation of arity k Editor's Note: Or do we even want to associate a type to framestoday() returns Monday and actions itself (not justthat the arguments), i.e.foxAlarm() is false when the type of a frame object,CMP rule is applied: the type of an action function?. if C i ∈ Const''condition is a constant, then type(C i )= dt givessatisfied, and the primitive data type dt of C i Definition (alphabet)actions in the conclusion are executed with BigPotato substituted for ?potato, Joe substituted for ?chicken, and 10 substituted for ?allowance. This results in the alphabet offollowing changes in the presentation language of RIF-PRD consistsset of the signature PRD = < DTS , Pred , Frame, Act , =, #, ##, External, Const, ArgNames, arity, type >facts:

The resulting set of variable symbols Var (disjoint from Const ) connective symbolsfacts w1 is thus:

When the symbols ImportCMP rule in applied to w1, Prefixthe first External predicate still selects {Joe/?chicken, Jack/?chicken, Julia/?chicken} as possible values for variable ?chicken, and Basebut the symbols Groupjoe:own relation and Documentthe auxiliary symbols ( , ) , [ , ] , < , > , and ^^ Definition (rule instance): An instance of asecond External predicate do not select any possible substitution for the couple (?chicken, ?potato) anymore: the rule r is a pair (r id , σ) , where r id uniquely identifies rcannot be satisfied, and σ is a ground substitution such that Var(r) ⊆ Dom(σ) . Giventhe system, having detected a rule r , id(r) denotes r id ,final state, stops.

The unique identifierresult of r ; given a rule instance ri = (r id , σ) , rule(ri) denotesthe rule thatexecution of the system is uniquely identifiedw1.

In the remainder of this section, as in the section on the operational semantics of actions, W denotes the set of all the ground condition formulas in the RIF-PRD condition languages, and L denotes the set of all the ground atomic actions in the RIF-PRD action language. In addition, LC denotes the set of the formulas in the RIF-PRD condition language, and R denotes the set of all the rules in the RIF-PRD rule language. Finally, given a set X, P(X) will denote the power set of X and S(X), the set of all the finite sequences of elements of X.

For the purpose of this section, an instance of a rule, r ∈ R, is defined as a couple (rid, σ), where rid uniquely identifies r and σ is a ground substitution such that Var(r) ⊆ Dom(σ). Given a rule instance ri = (rid, σ), rule(ri) denotes the rule that is uniquely identified by rid, and substitution(ri) denotes σ.

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

A RIF-PRD production rule system is defined as a labelled terminal transition system: given a rule set RS ⊆ R, let WCRS ⊆ P(W) × S(Inst(RS)) be thea set of ground formulas that can be represented in RIF-PRD, defined as follows: if p ∈ Conststates, where a state is the symbol of an externally specified predicate and t i ∈ Term Σ for ia pair c = 1..n, then External(p(t 1 ... t n )) ∈(w, ric), such that w ⊆ W ; if p ∈ Constis neither the symbola set of an externally specified predicate nor the symbol of an externally specified function,facts, and t i ∈ Term Σ for iric ∈ S(Inst(RS)) is an ordered instance of RS. Given a state c = 1..n, then p(t 1 ... t n(w, ric) ∈ W</sub> ; if t 1 ∈ Term Σ and t 2 ∈ Term Σ, then t 1 = t 2 ∈let facts(c) denote the first element, the set of facts w; if t 1 ∈ Term Σand t 2 ∈ Term Σlet picked(c) denote the second element, the ordered ruleset instance, ric.

The idea is that a state, c, then t 1 # t 2 ∈is made of a set, w ; if t 1 ∈ Term Σ, of ground FORMULAe that represent a state of facts; and t 2 ∈ Term Σof the ordered list, ric, then t 1 ## t 2 ∈ W ; if o ∈ Term Σof all the instances of the rules in the considered ruleset RS that are fired, in some sense to be further specified, in that state of facts.

Further, let HRS ⊆ S(CRS) be a set of histories, where a history, k i ∈ Term Σ forh, is an ordered list of states ci: h = 1..n,(cn...c1), n≥ 0. Given a history, h ∈ HRS, current(h) will be used to denote the first element of h and v i ∈ Term Σ for ihistory(h) will be used to denote h minus current(h): if h = 1..n, then o[k(cn...c1 ->v), n≥ 1 ... k n ->v, current(h) denotes cn ] ∈ W ;and history(h) denotes the ordered list (cn-1...c1), n≥ 1. If f i ∈ W for ih = 1..n, then AND(f 1 ... f n ) and OR(f 1 ... 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 1 .. x n (f) ∈ W . By convention, a ground formula Exists x 1 .. x n (f)() is always replaced bythe semantically equivalent ground formula fempty list, current(h) = history(h) = ∅.

Let L be the set ofThe 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 ∈ Widea is that a ground Framehistory, h, then a ∈ L and Retract(a) ∈ L . if c ∈ W isrepresents the stack of the states that have been successively traversed by a Const , then New ?o # c ∈ L , where ?o must be declaredproduction rule system, in an enclosing Do action block. if o ∈ W is a Const , then Retract(o) ∈ L . Editor's Note:the definition of L is subjectcurrent run, from its initial state to change asthe ACTION constructs are still under discussion. Finally, let R becurrent state: current(h) represents the setcurrent state of allthe rulessystem; history(h) represents its history, that can be represented in RIF-PRD. In this document, given a set X , P(X) denotesis, the power setstates of X ,facts that held and S(X) denotesthe set ofinstances that were fired in the previous cycles, ordered lists of elements of X .from most recent to initial.

Let further assume three functions:

Let extractActions: S(Inst(R)) → S(L), to I frame representsbe a helper function that, given an object andordered set, ori, of rule instances, returns the finite bag {< a1,v1 >, ..., < ak,vk >} represents a bagsequence of attribute-value pairs for d . We will see shortly how I frameACTIONs that is used to determinethe truth valuation of frame terms. Bags (multi-sets) are used here becauseconcatenation, preserving the order of the attribute/value pairsin 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 ?Bori, ?D with b . I sub gives meaning toof the subclass relationship. It is a mappingsequences of ground actions determined by each of the form D ind × D ind → Drule instances in ori.

The operator ##Editor's Note: extractActions is required tounderdefined. Need be transitive, i.e., c1 ## c2 and c2 ## c3 must imply c1 ## c3 . This is ensured byfixed at some point.

Given a restriction in Section Interpretation of Formulas . I isa gives meaning to class membership. Itruleset RS and the associated conflict resolution strategy LS, a RIF-PRD production rule system is defined as a mappinglabelled terminal transition system PRSRS,LS = {HRS, S(L), →RS,LS, TRS,LS}, where :

It gives meaning toIntuitively, the equality operator. I truth is a mappingfirst condition in the definition of the form D → TV . It is used to define truth valuation for formulas. I external istransition relation →RS,LS says that a mappingRIF-PRD production rule system can transition from one history to another only if the coherent setimplementation of schemas for externally defined functions to total functions D * → D . For each external schema σ = (?X 1 ... ?X n ; τ)the actions picked in the coherent setcurrent state of external schemas associated withthe PRD language, I external ( σ ) is a functionformer history produce the state of facts in the form D n → D . For every external schema, σ , associated withcurrent state of the language, I external ( σ ) is assumedlatter, according to be specified externally in some document (hencethe name external schema ). In particular, if σ is a schemasemantics of a RIF built-in predicate or function, I external ( σ ) isthe individual actions, as specified in [ RIF-DTB ] so that: If σ is a schemathe relation →RIF-PRD. Condition 2 guarantees that only the selection strategy and the specification of a built-in function then I external ( σ ) must bethe function defined inPICK determine which are the aforesaid document. If σ is a schemaallowed transition paths out of a built-in predicate then I truth ο ( I external ( σ )) (the composition of I truthgiven state. And I external ( σ ), a truth-valued function) must becondition 3 guarantees that the system halts as specified in [ RIF-DTB ]. For convenience, we also definesoon as it encounters a terminal state.

The following mapping I from terms to D : I ( k ) = I C ( k ), if kinput function is a symbol in Const I ( ?v )defined as:
Eval(RS, LS, w) →RS,LS h ∈ HRS, where facts(current(h)) = I V ( ?v ), if ?v is a variable in Var I ( o[a 1 ->v 1 ... a k ->v k ] )w, picked(current(h)) = I frame ( I ( o ))({< I ( a 1 ), I ( v 1 )>, ..., < 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) )PICK(w, ∅, RS, LS) and history(h) = I external ( σ )( I ( s 1 ), ..., I ( s n )), if t is an instance of∅
The external schema σ = (?X 1 ... ?X n ; τ) by substitution ?X 1 /s 1 ... ?X n /s 1 . Note that, by definition, External(t)output function is well-formed only ifdefined as:
h' ∈ T is an instance of an external schema. Furthermore, byRS,LS →RS,LS facts(current(h')) = w'

Or, using →*RS,LS to denote the definitiontransitive closure of coherent setsthe transition relation:

Eval(RS, w) →*RS,LS w'

Given the specification of external schemasPRSRS,LS, t can be an instancethe intended operational semantics of at most one such schema, so I ( External(t) )a production ruleset represented by a RIF-PRD Group RS is well-defined.completely specified by the effectspecification of datatypes.the set DTS must includethree functions INSTANTIATE, PICK and FINAL.

2.3.2.1 Rules instantiation: INSTANTIATE

The datatypes described in Section Primitive Datatypesevaluation of [ RIF-DTB ].the datatype identifiersfunction INSTANTIATE corresponds to the step that is often called matching in DTS imposethe following restrictions.description of production rule systems (e.g. PRR07). 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 ofa 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 .   ☐ 3.3 Operational semantics of actions Editor's Note: The operational semanticscollection of actions in RIF-PRD is still under discussion (see ISSUE-66 ).rules, it will evolve as the semanticsconsiders all possible ground rule instances, obtained by assigning ground terms to be associated withthe actions that are already specifiedvariables occuring in them. Its semantics is refined,defined, in particularaccordance with respect tothe creation and delationsemantics of objects; and as new ACTION constructs are added.the working group seeks feedback regarding what operational semantics would be most usefully associated withRIF-PRD ACTION constructs.condition language.

Let The transition relation → RIF-PRD ⊆ P(W) × L × P(W) isExtractCONDITIONS: R → LC be a function that, given a rule, r ∈ R, returns a well-formed condition formula defined recursively as follows:

Let InstantiateRULE: P(W) × R → P(Inst(R)), be used when the intended action is to adda fact tofunction that, given a set of groundfacts w . Rule 2 specifies that the Retract construct should be used when the intended action is to remove a fact from∈ W and a rule r ∈ R, instead.returns the intended semanticsset, ir ⊆ Inst(R), of all the actionsinstances of r that can be representedare satisfied in RIF-PRD is completely specified by the definitionw, where a rule instance ri = (rid, σ) satisfies a set of the labelled transition system {P(W), L, → RIF-PRD }fact w if and only if σ matches ExtractCONDITIONS(rule(rid)) to w.

The relation → * RIF-PRD ⊆ P(W) × S(L) × P(W) denote the transitive closureevaluation of the transition relation → RIF-PRD . 3.4 Operational semantics of rule sets A RIF-PRD production rule system is defined as a labelled terminal transition system: given a rule setfunction INSTANTIATE(w, RS), where w ⊆ W and RS ⊆⊆ R, let C RS ⊆ P(W) × P(Inst(RS))can now be specified as a set of configurations, wheresimple terminal transition system where:

The ideainput function is that a configuration, c ,defined as:

INSTANTIATE(w, RS) → (w, RS, ∅)

The output function is made ofdefined as:

(w, ∅, ri) → ri


Example 3.4. TBD

2.3.2.2 Instances selection: PICK

A set, w , of ground FORMULA e that representrule instance determines a statesequences of facts; and the set, ri c ,ground actions, by application of allthe instances ofassociated substitution to the rulesvariables in the considered ruleset RS that are satisfied,ACTIONs in some sensethe then component of the instantiated rule. The decision to be further specified, in that stateimplement the sequence of facts. Let further assume three functions: INSTANTIATE : P(W) × P(R) → P(Inst(R)) , that, givenactions that a rule instance determines is often called: firing the rule instance.

More than one rule from a rule set may be instantiated in a given state of facts, w andand, for a set of rules, RS , returnsgiven rule, there may be several different instances. The set of all the rule instances of the rules in RSthat are satisfied in w , ina sense thatgiven state is determined byoften called: the specificationconflict set; and the process of selecting one or more rule instances from the function; PICK : C RS × S(Strat) → P(Inst(R)) , where Strat is aconflict set of functions that implement, each, afor firing is often called: conflict resolution.

In RIF-PRD the conflict resolution algorithm (or conflict resolution strategy) that is intended for selectinga subset inset of rules is denoted by a keyword or a set of keywords that is attached to the rule instances, and possibly ordering it. Givenset. In this version of the RIF-PRD specification, a configuration, csingle conflict resolution strategy is specified normatively: it is denoted by the RIF-PRD keyword rif:standardForward, andfor it accounts for a selection strategy, PICK returnscommon conflict resolution strategy used in most forward-chaining production rule systems.

Editor's Note: Name of the ordered subset, ori ⊆ instance(c) , selected and ordered accordingstandard CR strategy to the input strategy,be discussed and agreed upon... standardForward used here as a placeholder.

Future versions of the rule instances that determineRIF-PRD specification may specify normatively the ordered list of ground actionsintended conflict resolution strategies to be implemented, that is,attached to additional keywords. In addition, RIF-PRD documents may include non-standard keywords: it is the sequenceresponsability of transitions to be executed fromthe input configuration; FINAL : C RS × P(R) → {true, false} , that, given a configurationproducers and a setconsumers of rules, returns true or false , dependingsuch document to agree on whetherthe intended conflict resolution strategies that are denoted by such non-standard keywords.
2.3.2.2.1 Conflict resolution: rif:standardForward

Most existing production rule systems implement conflict resolution algorithms that are a combination of the following elements (under these or notother, idiosyncratic names; and possibly combined with additional, idiosyncratic rules):

The RIF-PRD and instance(c') = INSTANTIATE(facts(c'), RS)) and c ∉ T RSkeyword rif:standardForward denotes the common conflict resolution strategy that can be summarized as follows: given a configuration cconflict set, as returned by the function INSTANTIATE

  1. Refraction is final iff FINAL(c, RS) = true : T RS = {c ∈ C RS | FINAL(c, RS) = true} . Intuitively,applied to the conditions 1 inconflict set, that is, all the definition ofrefracted rule instances are removed from the transition relation → RS guarantees thatconflict set;
  2. The remaining rule instances are ordered by decreasing priority, and only the specification ofrule instances with the function PICKhighest priority are kept in the conflict set;
  3. The remaining rule instances are ordered by decreasing recency, and only the selection strategy determine whichmost recent rule instances are kept in the allowed transition paths out ofconflict set;
  4. Any remaining tie is broken arbitrarily, and a single rule instance is kept for firing.

Accordingly, given configuration, and condition 2 guarantees that all transitions are compliant with the semanticsa state of fact, w ∈ W, a history, h ∈ HRS, and a rule set RS, the individual actions,function PICK(w, h, RS, rif:standardForward) returns a list that contain a single rule instance, selected from the conflict set generated by INTANTIATE(w, RS) as specified below.

As specified earlier, picked(c) denotes the relation → RIF-PRD . Condition 3 guarantees that the instance componentordered list of any reachable configuration contains allthe rule instances of the rules in RSthat are satisfiedwere picked in the configuration'sstate of facts, inc. Under the sense that is determinedconflict resolution strategy denoted by the specification of the function INSTANTIATErif:standardForward, and only those instances. And condition 4 guarantees thatthe system halts as soon as it encounterslist denoted by picked(c) contains a terminal configuration. The input function is defined as: Eval(RS, w) → RS (w, INSTANTIATE(w, RS)) ∈ C RS The output function is defined as: (w', ri w' ) ∈ T RS → RS w' Or, using → * RS to denote the transitive closure of the transition relation: Eval(RS, w) → * RS w'single rule instance, for any given state, c.

For the specificationpurpose of PRS RS,LSthis specification, an extended test, ∈inst, the intended operational semantics of a production ruleset represented by a RIF-PRD RuleSet RSis completelyspecified by the specification of the three functions INSTANTIATE , PICK and FINAL . 3.4.1 Rules instantiation: INSTANTIATEfor the evaluationmembership of the function INSTANTIATE corresponds to the step that is often called matchinga rule instance in the descriptiona set of productionrule systems (e.g. PRR07 ).instances: given a collectionrule instance, ri ∈ Inst(RS), and a set of rules, it considers all possible groundrule instances, obtained by assigning ground terms to the variables occuring in them. Its semanticsinstance, RI ⊆ Inst(RS), ri ∈inst RI if and only if there is defined in accordance witha rule instance, ri' ∈ RI such that rule(ri) = rule(ri') and, for each variable ?v ∈ Var(rule(ri)), σ(?v) = σ'(?v), where σ = substitution(ri) and σ' = substitution(ri').

Furthermore, let recency: Inst(RS) × HRS → N, where N denotes the semanticsset of the condition languagepositive integers, be an integer function that, given a rule instance, ri, and a history, h, returns the number of states in h, starting from the RIF logic frameworkfirst one, in terms of assignment intowhich ri is continuously satisfied: if h is the universehistory of the current state, recency(ri, h) provides a structuremeasure of the PRD language and a satisfaction relationrecency of the rule instance ri. The function is specified recursively as follows: for instantiated rules. Definition (Assignment):all rule instances ri ∈ Inst(RS), and forall history h ∈ HRS,

  1. if h is empty, recency(ri, ∅) = 0;
  2. if h is not empty,
    1. if ri ∈inst INSTANTIATE(facts(current(h)), RS), recency(ri, h) = 1 + recency(ri, history(h));
    2. if ri ∉inst INSTANTIATE(facts(current(h)), RS), recency(ri, h) = 1.

And let PRD belastPicked: Inst(RS) × HRS → N, where N denotes the language of PRD, Var its countableset of variables, and I a structure for PRD .the positive integers, be an assignment is ainteger function σ from Var (orthat, given a subset of Var ) intorule instance, ri, and a history, h, returns the universenumber of I . The assignmment function is given by a ground substitution as defined below.states in PRD the assignment function additionally needs to considerh, starting from the binding patterns defined byfirst one, since ri has been last fired. The FORALL quantifier, thatfunction is it assigns a value to each variable in such a wayspecified recursively as follows: for all constraints imposed by the binding patterns are satisfied by these values. Such an assignment is called consistent. Definition (Consistent Assignment): Let Var berule instances ri ∈ Inst(RS), and forall history h ∈ HRS,

  1. if ri ∈inst picked(current(h)), lastPicked(ri, h) = 1;
  2. if ri ∉inst picked(current(h)), lastPicked(ri, h) = 1 + lastPicked(ri, history(h)).

Finally, given a set of variables, Drule instance, ri ∈ Inst(RS), let priority(ri) denote the non-empty domain of possible values forpriority that is associated to rule(ri) in RS, or zero, if no priority is associated to rule(ri) in RS. If rule(ri) is inside nested Groups in RS, priority(ri) denotes the variables, Ppriority that is associated with the setinnermost Group to which a priority is explicitely associated, or zero.

Given a state of binding patterns,facts, w ∈ W, a history, h ∈ HRS, and C as set of constraints. Each constraint C i ∈ C involvesa rule set, RS, PICK(w, h, RS, rif:standardForward ) can now be defined with the sethelp of variables X ⊆ Var froma binding pattern P i ∈ P and specifiesterminal transition system {A, →sF, TsF}, where:

The variables in X : σ Xinput function is defined as:
PICK(w, h, RS; rif:standardForward) →sF a = {σ(x)/x | x ∈ X} . Let Term Σ beINSTANTIATE(w, RS)
The set of ground terms (that can be represented in RIF-PRD),output function is defined as follows: if c ∈ Const , then c ∈ Term Σ ; if f ∈ Constas:
a' ∈ TsF →sF keepOneFrom(a')

where keepOneFrom breaks any remaining tie by removing arbirarily all the elements but one from its argument list.
2.3.2.3 Halting test: FINAL

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 symbolWorking Group seeks feedback on which halting tests and which combinations of an externally specified functiontests should be supported by RIF-PRD and/or required from RIF-PRD implementations; and t i ∈ Term Σwhich halting test should be the default, if any.

By default, the specification for i = 1..n, then External(f(t 1 ... t n )) ∈ Term Σ . Definition (ground substitution):a ground substitutionterminal state that is intended for a substitution σ such that ∀ x ∈ Dom (σ), σ( x ) ∈ Term Σ . The function Var(e) that mapsset of production rules, when no halting test is explicitely associated to its representation as a RIF-PRD element e toRuleset, is when no rule instance is fireable: this is the case when INSTANTIATE returns an empty set of its freerule instances, 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 ∈ Termwhen all the rule instances that are satisfied in the state, according to the semantics of INSTANTIATE, for i = 0..n, then, Var(p(arg i ) = Var(p) ∪ i=0..n Var(arg i ) ; if p ∈ Term and arg i ∈ Termhave already been fired in a state that has not since changed significantly. That latter condition guarantees, in particular, that the system halts when it reaches a fixpoint.

Formally, ∀ RS ⊆ R, ∀ c ∈ CRS, for i = 0..n, then, Var(External(p(arg i ))PICK(c, RS) = Var(p) ∪ i=0..n Var(arg i ) ;true if t 1 ∈ Termand t 2 ∈ Term , then Var(t 1 [=|#|##] t 2 ) = Var(t 1 ) ∪ Var(t 2 ) ;only if o ∈ Term , k i ∈ Term for i = 1..n, and v i ∈ Term for i = 1..n, then Var(o[k 1 ->v 1 ... k n ->v n ])instance(c) - history(c) = Var(o) ∪ i=1..n Var(k i ) ∪ i=1..n Var(v i ) ; if f i are RIF-PRD FORMULA s for i∅. Otherwise, PICK(c, RS) = 0..n, then Var([AND|OR|NOT](f i )) = ∪ i=0..n Var(f ifalse.

3 XML Syntax

This section specifies a common concrete XML syntax to serialize any production rule set written in a language that share the abstract syntax speicifed in section 4.1, provided that its intended semantics agrees with the semantics that is described in section 4.2.

In the following, after the notational conventions are introduced, we specify the RIF-PRD XML constructs that carry a normative semantics with respect to the intended interpretation of the interchanged rules. They are specified with respect to the abstract syntax, and their specification is structured according to the specification of the abstract syntax in sections 2.1, 3.1 and 4.1.

The root element of any RIF XML document, Document and other XML constructs that do not carry a normative semantics with respect to the intended interpretation of the interchanged rules are specified in the last sub-section.

3.1 Notational conventions

3.1.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#.

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.

3.1.2 BNF pseudo-schemas

The XML syntax of RIF-PRD is specified for each component as a pseudo-schema, as part of the description of the component. The pseudo-schemas use BNF-style conventions for attributes and elements: "?" denotes optionality (i.e. zero or one occurrences), "*" denotes zero or more occurrences, "+" one or more occurrences, "[" and "]" are used to form groups, and "|" represents choice. Attributes are conventionally assigned a value which corresponds to their type, as defined in the normative schema. Elements are conventionally assigned a value which is the name of the syntactic class of their content, as defined in the normative schema.

<!-- sample pseudo-schema -->
    <defined_element
          required_attribute_of_type_string="xs:string"
          optional_attribute_of_type_int="xs:int"? >
      <required_element />
      <optional_element />?
      <one_or_more_of_these_elements />+
      [ <choice_1 /> | <choice_2 /> ]*
    </defined_element>

3.1.3 Syntactic components

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

3.2 Conditions

This section specifies the XML constructs that are used in RIF-PRD to serialize condition formulae.

3.2.1 TERM

The TERM class of constructs is used to serialize terms, be they simple terms, that is, constants and variables; or positional terms or terms with named arguments, both being, per the definition of a well-formed formula, representations of externally defined functions.

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

    [ Const | Var | External ]
3.2.1.1 Const

In RIF, the Const element is used to serialize a constant.

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

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

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

\{\{EdNote|text=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.\}\}

Example 2.1. In each of the examples below, a constant is first described, followed by its serialization 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>


3.2.1.2 Var

In RIF, the Var element is used to serialize a variable.

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

    <Var> any Unicode string </Var>

Example 2.2. The example below shows the XML serialization of a reference to a variable named: ?chicken.

<Var> chicken <Var>
3.2.1.3 External

As a TERM, the External element is used to serialize a positional term or a term with named arguments. In RIF-PRD, a positional or a named-argument term represents always a call to an externally specified function, e.g. a builtin, a user-defined function, a query to an external data source...

The External element contains one content element, which in turn contains one Expr element that contains one op element, followed zero or one args element or zero of more slot elements:

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

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

Example 2.3.

a. The first example below shows one way to serialize, in 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 serialization 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>

3.2.2 ATOMIC

The ATOMIC class is used to serialize atomics: positional and named-arguments atoms, equality, membership and subclass atomics, frame atomics and externally defined atomics..

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

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

In RIF, the Atom element is used to serialize a positional atomics or an atomic with named arguments.

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

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

Editor's Note: The slotted, or named arguments form of the Atom construct is still under discussion (see also 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 serialization of the positional atomicsowns(?c ?p), where the predicate symbol owns is defined in the example namespace http://rif.examples.com/2008/joe#.

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

In RIF, the Equal element is used to serialize equality atomics.

The Equal element must contain one left sub-element and one right sub-element. The content of the left and right elements must be a construct from the TERM abstract class. The order of the sub-elements is not significant.

    <Equal>
       <left> TERM </left>
       <right> TERM </right>
    </Equal>
3.2.2.3 Member

In RIF, the Member element is used to serialize membership atomics.

The Member element contains two unordered sub-elements:

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

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

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

In RIF, the Subclass element is used to serialize subclass atomics.

The Subclass element contains two unordered sub-elements:

    <Subclass>
       <sub> TERM </sub>
       <super> TERM </super>
    </Subclass>
3.2.2.5 Frame

In RIF, the Frame element is used to serialize frame atomics.

Accordingly, a Frame element must contain:

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

Example 2.6. The example below shows the RIF XML syntax that serializes an expression that states that the object denoted by the variable ?c has the value denoted by the variable ?a for the property Chicken/age that is defined in the example namespace http://rif.examples.com/2008/joe#.

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

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

3.2.2.6 External

In RIF-PRD, the External element is also used to serialize an externally defined atomic.

When it is a ATOMIC (as opposed to a TERM; if fthat is, in particular, when it appears in a place where an ATOMIC is expected, and not a TERM), the External element contains one content element that contains one Atom element. The Atom element serializes the externally defined atom properly said:

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

The op Const in the Atom element must be a symbol of type rif:iri that must uniquely identify the externally defined predicate to be applied to the args TERMs. It can be one of the builtin predicates specified for RIF dialects, as listed in section List of RIF Builtin Predicates and Functions of the RIF data types and builtins document, or it can be application specific. In the latter case, it is up to the producers and consumers of RIF-PRD rulesets that reference non-builtin predicates to agree on their semantics.

Example 2.7. The example below shows the RIF XML serialization of an externally defined atomic that tests whether the value denoted by the variable named ?a (e.g. the age of a chicken) is greater than the integer value 8, where the test is intended to behave like the builtin predicate op: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>

3.2.3 FORMULA

The FORMULA class is aused to serialize condition formulas, that is, atomic formulas, conjunctions, disjunctions, negations and existentials.

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

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

An atomic formula is serialized using a single ATOMIC statement. See specification of ATOMIC, above.

3.2.3.2 And

x i ∈A conjunction is serialized using the And element.

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

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


3.2.3.3 Or

A disjunction is serialized using the Or element.

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

    <Or>
       <formula> FORMULA </formula>*
    </Or>
3.2.3.4 NmNot

A negation is serialized using the NmNot element.

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

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

Editor's Note: The name of that construct may change, including the tag of the XML element.

3.2.3.5 Exists

An existentially quantified formula is serialized using the Exists element.

The Exists element contains:

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

Example 2.8. The example below shows the RIF XML serialization of a boolean expression that tests whether the chicken denoted by variable ?c is older than 8 months, by testing the existence of a RIF-PRD ATOMICvalue, denoted by variable ?a, then Var([ASSERT|RETRACT](a)) = Var(a) ; if fthat is both the age of ?c, as serialized as a RIF-PRD FORMULAFrame element, as in example 2.6, and a igreater than 8, as serialized as an External ATOMIC, i = 1..n are RIF-PRD ACTION s, then Var(IF f THENas in example 2.7.

<Exists>
   <declare> <Var> a  1 ...</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  n ) = Var(f) ∪ i=1..n Var(a i ) ; if r is</Var>
            </slot>
         </Frame>
         <External>
            <content>
               <Atom>    
                  <op> <Const type="rif:iri"> op:numeric-greater-than </Const> </op>
                  <args rif:ordered="yes">
                     <Var> a  RIF-PRD RULE , x i ∈ Var for i = 1..n, and p j , j = 0..m, are RIF-PRD FORMULA s, then Var(Forall x 1 ... x n SUCH</Var>
                     <Const type="xsd:decimal"> 8 </Const>
                  </args>
               </Atom>
            </content>
         </External>
      </And>
   </formula>
</Exists>

3.3 Actions

This section specifies the XML syntax that p j (r)) = Var(r) ∪ j=1..m Var(p j ) ; if r i , i = 0..n, are RIF-PRDis used to serialize the action part of a rule s, then Var(RULESET(r i )) = ∪ i=1..n Var(r i ) . Definition (Satisfaction):supported by RIF-PRD.

3.3.1 ACTION

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

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

    [ ATOMIC_CONCLUSION | ATOMIC_ACTION | ACTION_BLOCK | CONCLUSION_BLOCK ]
3.3.1.1 ATOMIC_CONCLUSION

The structure IATOMIC_CONCLUSION class of PRD under assignment σ , written as I |= φ[σ] , if thereconstructs is an consistent assignment σused to I .represent the inductive requirementstargets of the satisfaction relation |= are: I |= φ[σ]Assert construct and is also used for any ATOMIC formula φ ofcompatibility with RIF-Core.

    [ Atom | Frame | Member | Subclass ]
3.3.1.2 ATOMIC_ACTION

The form p(t 1 ,..,t n ) iff {σ(t 1 ),..,σ(t n )} ∈ I(φ) I |= External(φ)[σ] for any EXTERNAL formula External(φ)ATOMIC_ACTION class of the form External(f(t 1 ,..,t n )) iff I |= External(f(σ(t 1 ),..,σ(t n ))) (evaluates to true) I |= ¬ φ[σ] iff itconstructs is notused to represent the caseprimitive actions assert and retract.

    [ Assert | Retract ]
3.3.1.2.1 Assert

An Assert construct is used to represent actions that I |= φ[σ] I |= And(φ 1 ... φ n )[σ] iff I |= φ 1 [σ], ... ,I |= φ n [σ] I |= Or(φ 1 ... φ n )[σ] iff I |= φ 1 [σ] v ... v I |= φ n [σ] I |= Exists ?V(φ)[σ] iff there exsits some assignment σ* suchresult in asserting an ATOMIC_CONCLUSION.

    <Assert>
         <target> ATOMIC_CONCLUSION </target>
    </Assert>
3.3.1.2.2 Retract

The Retract construct is used to represent actions that for every variable ?X differentresult in removing facts from ?V σ*(?X) = σ(?X) σ*(?V)working memory.

An Atom, a Frame, or a frame object may be retracted. A frame object is defined,denoted using a TERM. A frame object is retracted by removing it from the Member relation and I |= φ[σ*] I |= ∀ ?V(φ)[σ] iff for any assignment σ* I |= φ[σ*]removing all its Frames.

The Retract element has one target sub-element that contains an Atom, where for every variable ?X different from ?V σ*(?X) = σ(?X) σ*(?V) is defined I |= φ[σ]a Frame, where φ isor a RIF-PRD Rule ψ :- τ consistingTERM construct that represents the facts to be removed on implementing the action.

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

Example 2.10. The example below shows the RIF XML representation of a condition formula τ andan action formula ψ , iff I |= τ[σ] then I |= ψ[σ] Editor's Note: Note,that :- might changeupdates 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>


3.3.1.3 ACTION_BLOCK

An ACTION_BLOCK construct is used to => Definition (Pattern Matching): Given a set w ⊆ W of ground RIF-PRD ATOMIC srepresent optional local variables and a RIF-PRD FORMULA φ , φtheir bindings plus several ATOMIC_ACTIONs.

    <Do rif:ordered="yes">
       <declare> Var+ </declare>?
       <binding> [ New | Frame ] </binding>*
       <action> ATOMIC_ACTION  </action>+
    </Do>


3.3.1.3.1 New

The New construct is saidused to match w andcreate a new frame object.

The New element has an assignment σ , iff I |= φ[σ(w)]instance sub-element that contains a Var. All possible instantiation ofA RIF-PRD formula φ are obtained by substituting each variable ?X i ∈new object is created and bound to the instance variable.

    <New>
       <instance> Var  of φ with</instance>?
    </New>


Example 2.9. The value of σ(?X i ) fromexample below shows the matching facts w ∈ W . 3.4.2 Instances selection: PICK Editor's Note: This sectionRIF XML representation of an action block that asserts a new 100 decigram potato.

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

A CONCLUSION_BLOCK construct is still under discussion (see ISSUE-64 ). This version of RIF-PRD specifies five elementary strategies,used to represent several ATOMIC_CONCLUSIONs in a way of combining them, and a default combination. Future working drafts may specify different and/or additional elementary strategies,that is compatible with RIF-Core.

    <And>
       <formula> ATOMIC_CONCLUSION </formula>+
    </And>

3.4 Rules and no or a different default.Groups

This section specifies 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;XML constructs that are used, in RIR-PRD, to serialize rules and which strategy or combination should begroups.

3.4.1 RULE

In RIF-PRD, the default, if any. ARULE instance determines a sequencesclass of groundconstructs is used to serialize rules, that is, unconditional as well as conditional actions, by application of theor rules with bound variables.

As an abstract class, RULE is not associated substitution to the variableswith specific XML markup in theRIF-PRD instance documents.

    [ Implies | Forall | ACTION  s]
3.4.1.1 ACTION

An unconditional action block is serialized, in RIF-PRD XML, using the then componentACTION class of the instantiated rule. The decisionconstruct.

Editor's Note: To implementbe updated based according ot the sequenceuptodate version of the XML syntax for actions.

3.4.1.2 Implies

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

The Implies element contains an optional if sub-element and a then sub-element:

Editor's Note: To be fired, and, therefore,updated based according ot the sequenceuptodate version of actionsthe XML syntax for actions.

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

The Forall construct is used, in RIF-PRD, to be implemented, based onrepresent rules with bound variables.

The Forall element contains:

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

Editor's Note: Nested Foralls make explicit the specificationscope of the INSTANTIATE function, since the rule instance has been last fired; Priority.declared variables, and, thus, impose an order on the rule instances are ordered by priorityevaluation of the instantiated rules,pattern and only the rule instances with the highest priority are selected. This requires thatif FORMULAe in a priority be associated withrule. That ordering and the RIF-PRD representationuse of each rule; Recency.patterns to constrain the binding of variables may be of practical significance for some production rule instancessystems, but they are ordered by how long a rule instance has been continuously satisfied byirrelevant with respect to the states of factsintended semantics of the traversed configurations,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 onlydoes not support the most recent ones are selected. Random. A singleton rule instance is selected at random; All-at-once. Allassociation of contraining patterns to declared variables. The rule instances are selected,working group seeks feedback regarding whether nested Forall and they are firedconstrainting pattern should be supported in RIF-PRD, to 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 ,cost of excludedreducing the interoperability with RIF-BLD.

Example 2.10. The example below shows how the CMP rule instances, andextract: "if a keyword, k , indicative of an single selection strategy, returnchicken owns a subset fri ⊆ ori , selectedpotato and ordered according to..." 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>

3.4.2 Group

The strategy indicated by kGroup construct is used to serialize a group.

The keywords "no-repeat""Group element has zero or one behavior sub-element and "all" indicate, respectively,zero or more sentence sub-elements:

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

3.5 Non-semantic carrying constructs

3.5.1 Document

The function fireableINSTANCESDocument is precisely specified inthe next subsection.root element in a RIF-PRD instance document.

The function PICK(c, LS)Document contains zero or one payload sub-element, that must contain a Group element.

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

3.5.2 Metadata

Metadata can be specifiedassociated with any concrete class element in RIF-PRD: those are the help of a terminal transition system where: a configuration iselements with 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: if sCamelCase tagname starting with an upper-case character:

    CLASSELT =  "all" , then (sLS', ori, c) → (∅, ori, c) if s ≠ "all" , then (sLS', ori, c) → (LS', fireableINSTANCES(ori, history(c), s), c)[ TERM | ATOMIC | FORMULA | ACTION | RULE | Group | Document ]

An identifier can be associated to any instance element of the abstract CLASSELT class of constructs, as an optional id sub-element that MUST contain a configurations (LS, ori, c) is final if and only if LS = ∅Const of type rif:local or rif:iri.

Metadata can be included in any instance of a concrete class element using the input function is defined as: PICK(c, RS, sLS) → (LS"random", fireableINSTANCES(instance(c), history(c), "no-repeat"), c)meta sub-element.

The output function againstRIF-PRD Frame construct is defined as: (∅, ori, c) → ori Intuitively, the strategy for the selection of the rule instancesused to be fired that is intended forserialize metadata: the set of rules represented by a RIF-PRD Ruleset , is : starting fromcontent of the ordered set returned by INSTANTIATE inFrame's object sub-element identifies the configuration,object to removewhich the instances that were already fired,metadata is associated:, and the Frame's slots represent the metadata properly said as listed inproperty-value pairs.

If the configuration's history . That is,all the no-repetition strategymetadata is always applied first; successive subsets of instances are selected perrelated to the sequence of selection strategies keywords associated withsame object, the Ruleset ; and, finally,meta element can contain a single rule instance is selected at random fromFrame sub-element. If metadata related to several different objects need be serialized, the resulting subset.meta role element can contain an And element with zero or more formula sub-elements, each containing one Frame element.

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

Notice that is, the random strategy is always applied atthe endcontent of the selection process. In other words, if the sequencemeta sub-element of an instance of strategies provided witha RIF-PRD Rulesetclass element is LR ,not necessarily associated to that same instance element: only the intended selection strategy is: "no-repeat" LR "random"content of the default, when no selection strategyobject sub-element of the Frame that represents the metadata specifies what the metadata is explicitely indicatedabout, not where it is included in the instance RIF document.

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

4 Presentation syntax

This section specifies a Ruleset , is, therefore: "no-repeat" "random"presentation syntax for RIF-PRD. The exceptionpresentation syntax is not normative: its main purpose is to help make the all-at-once strategy, represented in RIF-PRD by the keyword : "all" . If that keyword appears anywhere innormative specification of the sequence,semantics easier to read.

The intended strategypresentation syntax is that all the rule instances that have been selected at that pointdesigned to be fired in sequence, in the ordervery close to RIF-BLD. A line by line comparison of the selection. That is, ifEBNF will show these few differences:

  1. the sequenceaddition of strategies provided with a RIF-PRD Ruleset is LR 1 "all"LR 2 , the intended selection strategy is : "no-repeat" LR 1 3.4.2.1 fireableINSTANCESNot
  2. the operational semanticsremoval of Expr, the function fireableINSTANCES depends on its third argument, the elementary selection strategy. It is therefore specified separately for each valuesyntactic class of that parameter, that is, for each individual rule instances selection strategy supported by RIF-PRD. Editor's Note:logical functions,
  3. the precise operational semanticsreplacement of the "no-repetition", "priority" and "recency" strategies are still under discussion in the working group. In addition, this working draft does not specify a way to specify the intended instance selection strategy for a RIF-PRD rulesetATOMIC in a RIF document. As a consequence, onlyrule conclusions with ACTION, and the "random" strategy is precisely specified in this version. No-Repetition. TBD Priority. TBD Recency. TBD Random. fireableINSTANCES(ori, h, "random") , where ori ∈ S(Inst(R))addition of Do(ACTION*) and h ∈ P(Inst(R)) , returns a randomly selected singleton subsetAnd(ASSERT*) instead of ori : fireableINSTANCES(ori, h, "random") → {ri} , such that ri ∈ ori. 3.4.3 Halting test: FINAL Editor's Note: This section is still under discussion (see ISSUE-65 ). This version specifies a single, default halting test: future versionAnd(ATOMIC*) in rule conclusions.
  4. definition of this draft may specify additional halting tests, and/or a different default. The Working Group seeks feedback on which halting testsAssert, New, Retract, and Do actions.

It is intended that the syntax and which combinationssemantics of tests should be supported by RIF-PRD and/or required from RIF-PRD implementations;RIF-BLD and which halting test should beRIF-PRD are the default, if any. By default,same when the specification forrule conclusion contains a terminal configuration thatonly Atoms and Frames, "Not" is intended for a set of production rules, when no halting testnot used, and logical functions are not used.

The following EBNF is explicitely associated to its representation as a RIF-PRD Rulesetfrom 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 when no rule instancetaken from RIF-DTB and is fireable: thisunchanged 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 case when INSTANTIATE returns an empty setfollowing EBNF is from RIF-BLD and defines rules, groups of rule instances, or when allrules, and the rule instances thatcontaining document. Changed lines are satisfied in the configuration, according to the semantics of INSTANTIATEprefixed with !. Metadata can be associated with Document, 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 RSGroup, PICK(c, RS) = true ifand only if instance(c) - history(c) = ∅ . Otherwise, PICK(c, RS) = false . 4RULE constructs.

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

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

  ACTION             ::= ATOMIC_CONCLUSION | ATOMIC_ACTION | ACTION_BLOCK | CONCLUSION_BLOCK 
  ATOMIC_CONCLUSION  ::= Atom | Frame | Member | Subclass
  ATOMIC_ACTION      ::= Assert | Retract
  Assert             ::= 'Assert' '(' ATOMIC_CONCLUSION ')'
  Retract            ::= 'Retract' '(' Atom | Frame | TERM ')'
  ACTION_BLOCK       ::= 'Do' Var* '(' ( ACTION_VAR_BINDING+ ';' )? ATOMIC_ACTION+ ')' 
  ACTION_VAR_BINDING ::= New | Frame
  New                ::= 'New' '(' Var ')'
  CONCLUSION_BLOCK   ::= 'And' '(' ATOMIC_CONCLUSION ATOMIC_CONCLUSION+ ')'

5 References

[CIR04]
Production Systems and Rete Algorithm Formalisation, Cirstea H., Kirchner C., Moossen M., Moreau P.-E. Rapport de recherche n°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/.


56 Appendix: XML Schema for RIF-PRD

TBD

67 Appendix: Compatibility with RIF-BLD

6.17.1 Syntactic compatibility between RIF-PRD and RIF-BLD

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

The syntactic differences between the two dialects are summarized below:

Below is a complete, construct by construct, comparison table of RIF-PRD and RIF-BLD presentation and XML syntaxes. A construct is tagged "BLD""BLD" or "PRD""PRD" if it is specific to the dialect, or tagged "Core""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.

Presentation syntax XML syntax
TERM ::=TERM ::=
BLD 
[Const | Var | Expr | External]
PRD 
[Const | Var | External]
Const ::=Const ::=
Core 
 '"''"' UNICODESTRING  '"^^''"^^' SYMSPACE

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

<Var>
   Any Unicode string
</Var>
Expr ::=Expr ::=
BLD 
Const '(' (TERM* | (Name '->' TERM)*) ')'

<Expr>
   <op> Const </op>
   [
    <args  rif:ordered="yes">rif:ordered="yes"> TERM* </args>?
    |
    <slot  rif:ordered="yes">rif:ordered="yes">
       <Name> Any Unicode string </Name>
       TERM
    </slot>*
   ]
</Expr>
PRD 
Undefined except when wrapped in an External (as TERM), as follows.
External (as TERM) ::=TERM) ::=
Core 
'External' '(' Expr ')'

<External>
   <content>
      Expr
   </content>
</External>
ATOMIC ::=ATOMIC ::=
Core 
[Atom | Equal | Member | Subclass | Frame]
Atom ::=Atom ::=
Core 
Const '(' (TERM* | (Name '->' TERM)*) ')'

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

<Equal>
   <left> TERM </left>
   <right> TERM </right>
</Equal>
Member ::=Member ::=
Core 
TERM # TERM

<Member>
   <instance> TERM </instance>
   <class> TERM </class>
</Member>
Subclass ::=Subclass ::=
Core 
TERM ## TERM

<Subclass>
   <sub> TERM </sub>
   <super> TERM </super>
</Subclass>
Frame ::=Frame ::=
Core 
TERM ' [ ' (TERM ' -> ' TERM)* ' ] '

<Frame>
   <object> TERM </object>
   <slot  rif:ordered="yes">rif:ordered="yes"> TERM TERM </slot>*
</Frame>
FORMULA ::=FORMULA ::=
BLD 
[ATOMIC | External | And | Or | Exists]
PRD 
[ATOMIC | External | And | Or | NmNot | Exists]
External (as FORMULA) ::=FORMULA) ::=
Core 
'External '(' [Atom | Frame] ')'

<External>
   <content>
      [ Atom | Frame ]
   </content>
</External>
And ::=And ::=
Core 
'And' '(' FORMULA* ')'

<And>
   <formula> FORMULA </formula>*
</And>
Or ::=Or ::=
Core 
'Or' '(' FORMULA* ')'

<Or>
   <formula> FORMULA </formula>*
</Or>
NmNot ::=NmNot ::=
BLD 
Undefined
PRD 
'Not' '(' FORMULA ')'

<NmNot>
   <formula> FORMULA </formula>
</NmNot>
Exists ::=Exists ::=
Core 
'Exists' Var+ '(' FORMULA ')'

<Exists>
   <declare> Var </declare>+
   <formula> FORMULA </formula>
</Exists>
ACTION ::=ACTION ::=
BLD 
Undefined
PRD 
[ ASSERT | Retract ]
ASSERT ::=ASSERT ::=
BLD 
Undefined
PRD 
[ Atom | Frame ]
Retract ::=Retract ::=
BLD 
Undefined
PRD 
'Retract' '(' Atom | Frame ' ) '

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

<Forall>
   <declare> Var </declare>+
   <formula>
       [Implies | ATOMIC ] 
   </formula>
</Forall>
PRD 
' Forall ' Var+ (' ( ' FORMULA ' ) ')* ' ( ' RULE ' ) '

<Forall>
   <declare> Var </declare>+
   <pattern> FORMULA </pattern>*
   <formula> RULE </formula>
</Forall>
Implies ::=Implies ::=
BLD 
(ATOMIC | 'And' '(' ATOMIC* ')') ':-' FORMULA

<Implies>
   <if> FORMULA </if>
   <then>
      [ ATOMIC
        |
        <And>
           <formula>
              ATOMIC
           </formula>*
        </And>
      ]
   </then>
</Implies>
PRD 
(ACTION | 'Do' '(' ACTION* ')') ':-' FORMULA

<Implies>
   <if> FORMULA </if>
   <then>
      ACTION
      ACTION*
   </then>
</Implies>
Group ::=Group ::=
Core 
METADATA? 'Group' '(' ([RULE | Group])* ')'

<Group>
   <sentence> [ RULE | Group ] </sentence>*
</Group>
Import ::=Import ::=
BLD 
'Import' '(' IRI Profile? ')'

<Import>
   <location>lAny Unicode string</location>
   <profile><Profile>Any Unicode String1</Profile></profile>
</Import>
PRD 
Undefined in this version of the draft
Document ::=Document ::=
BLD 
METADATA? 'Document' '(' [Import | Prefix | Base]* Group? ')'

<Document>
  <directive>
     [ Import | Prefix | Base]*
  </directive>
  <payload> Group </payload>?
</Document>
PRD 
METADATA? 'Document' '(' Group? ')'

<Document>
  <payload> Group </payload>?
</Document>
METADATA ::=METADATA ::=
Core 
'(*' Const? (Frame | 'And' '(' Frame* ')')? '*)'

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

6.27.2 Semantic compatibility between RIF-PRD and RIF-BLD

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.