Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document specifies RIF-PRD, a Rule Interchange Format (RIF) dialect to enable the interchange of production rules.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is being published as one of a set of 6 documents:
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.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Contents |
This document specifies the production rule dialect of the W3C rule interchange format (RIF-PRD). It is mostly intended for the designers of RIF-PRD implementations.
As a common XML serialisation format for many production rule languages, RIF-PRD specifies an XML syntax for the most widely used features (section [ Syntax]), and the operational semantics that RIF-PRD constructs are intended to represent (section [ Operational semantics]). Production rules are rules where the part that describes the consequence of condition being satisfied specifies actions rather than logical statements. Production rules, in general, are not amenable to a model theory and, followingly, the intended semantics of rules and set of rules serialized as RIF-PRD is specified operationally, in this document.
Editor's Note: This working draft specifies the RIF-PRD serialisation of a set of core constructs only. Future versions of this document will extend the set of RIF-PRD constructs to cover the most widely used features of production rule languages. The working group seeks feedback on what features should be supported by RIF-PRD and what constructs should or should not be required from conformant RIF-PRD implementations.
As a RIF dialect, RIF-PRD has also been designed to maximise inter-operability between rule languages over the World Wide Web. In this draft, this is achieved by sharing the same XML syntax for the subset of RIF documents where the semantics intended for a production ruleset serialised in the production rule dialect of RIF, RIF-PRD, and the semantics intended for a logic rule base serialised in the basic logic dialect of RIF, RIF-BLD, agree. The correspondance between RIF-PRD and RIF-BLD is detailled in [ Appendix: Compatibility with RIF-BLD].
Editor's Note: Future versions of this working draft will draw on other RIF documents to maximise inter-operability with othe rule languages, most noticeably the RIF data types and builtins specification (RIF-DTB) and the RIF extensibility framework (currently being specified by the working group; see also the RIF framework for logic dialects (RIF-FLD) that specifies a framework for designing RIF logic dialects).
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 -- a macro that expands to a concatenation of the character sequence denoted by the prefix xsd and the string string. The compact URI notation is used for brevity only, and xsd:string should be understood, in this document, as an abbreviation for http://www.w3.org/2001/XMLSchema#string. The compact URI notation is not part of the RIF-PRD syntax.
The XML syntax of RIF-PRD is specified for each component as a pseudo-schemas, as part of the description of the component. The pseudo-schemas use BNF-style conventions for attributes and elements: "?" denotes optionality (i.e. zero or one occurrences), "*" denotes zero or more occurrences, "+" one or more occurrences, "[" and "]" are used to form groups, and "|" represents choice. Attributes are conventionally assigned a value which corresponds to their type, as defined in the normative schema. Elements are conventionally assigned a value which is the name of the syntactic class of their content, as defined in the normative schema.
<!-- sample pseudo-schema -->
<defined_element
required_attribute_of_type_string="xs:string"
optional_attribute_of_type_int="xs:int"? >
<required_element />
<optional_element />?
<one_or_more_of_these_elements />+
[ <choice_1 /> | <choice_2 /> ]*
</defined_element>
Jim the Hen Handler developed a very sophisticated program to grow feeble chicks into deliciously plump chickens for a minimal cost. Jim publishes his method on his Web site www.juicychicken.org. Since he is still experimenting to improve his method, the rules to follow change quite often, and Jim decided to publish them in RIF as well, so that his followers can easily, even automatically, implement the very latest version.
Jim's latest addition to his knowledge base is the following advice:
Jim calls it the "Chicken and Mashed Potatoes", or CMP, rule. Rephrased in a more "rule-like" form, the rule could read like:
The CMP rule is a production rule: that is, when the rule is implemented and the condition is satisfied, the consequence is that some actions are executed (mashing potatoes, modifying a chicken's regime, managing ownership relations etc). Therefore, it is best interchanged using the production rule dialect of RIF, and Jim the Hen Handler's method, and especially his "chicken and mashed potatoes" rule and components thereof, will be used as a running example in this document.
To make sure that his rules can be implemented unambiguously, Jim (the Hen Handler, not the chicken) published a data model (e.g., an XML schema) that identifies Chicken and Potato as two classes of objects:
Jim further specifies:
All these (types and names) are defined in Jim's namespace, which is represented in this document by the prefix jim:.
In this document, three related but distinct representations for RIF-PRD components are introduced:
Three kinds of syntactic components are used to specify RIF-PRD:
This section specifies the XML syntax that is used to represent the different boolean expressions that can be found in production rules. The language is called the condition language by reference to the condition longuage of [ RIF-BLD], that determines what can appear as a condition in a rule supported by RIF-BLD. The language plays a similar role in RIF-PRD and both dialects share the same construct everywhere they agree on the semantics.
The most basic construct in RIF is the TERM. The TERM is an abstract construct, concretly visible, in RIF-PRD, as a Const, a Var or an External.
The ATOMIC is the basic building block of RIF. ATOMIC is an abstract class: it is visible in RIF-PRD as either an Atom, an Equal, a Member, a Subclass or a Frame. Each kind of ATOMIC is a composition of TERMs.
The next level of constructs are assemblies of ATOMICs. Together, the various kinds of assemblies form the abstract construct FORMULA. RIF-PRD knows six kinds of FORMULAs: the single ATOMIC, the Externallly evaluated Atom or Frame, and the recursively specified And, Or, NmNot and Exists.
The following sections specify each construct separately, grouped by abstract syntactic classes.
Editor's Note: The RIF-PRD condition language is still under discussion. 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.
The TERM class of constructs is used to represent constants, variables and the application of function symbols to other TERMs.
As an abstract class, TERM is not associated with specific XML markup in RIF-PRD instance documents. It is specified in the normative schema as a substitution group.
[ Const | Var | External ]
In RIF, the Const construct is used to represent a constant.
The Const element has a required type attribute and an optional xml:lang attribute:
The content of the Const element is the constant's litteral, which can be any Unicode character string.
<Const type="IRI" [xml:lang="xsd:language"]? >
Any Unicode string
</Const>
Constant types. RIF-PRD conformant implementations MUST support the following builtin constant types:
Editor's Note: The list of builtin constant types may be modified in future versions of this document, based on the content of future versions of the RIF data types and builtins document [ RIF-BLD].
Symbols with an ill-formed lexical part. Constants that are represented in RIF in one of the aforesaid builtin types must be well-formed, i.e., their representation must belong to the lexical space associated with the type. For instance, 123^^xsd:long (that is, <Const type="xsd:long">123</Const>) has a correct lexical part, since 123 belongs to the lexical space of the data type xsd:long. In contrast, abc^^xsd:long (<Const type="xsd:long">abc</Const>) is ill-formed, as it does not have a correct lexical part. A compliant RIF-PRD translator MUST reject ill-formed symbols.
Symbols with non-standard types. RIF-PRD builtin types are meant to be used for the interchange of constants that belong to the corresponding XML and RDF types. They can also be used for the interchange of constants with non builtin, application specific types with overlaping lexical and value spaces or similar behaviours: this may require additional translations steps and may result in unexpected or incorrect results; in addition, the information regarding the original types is lost in RIF-PRD, which may affect round-tripping.
Constants that do not belong or cannot be cast in one of RIF builtin types for interchange purposes, can be represented using the same <Const type="TYPE">LITERAL</Const> syntax, where TYPE is not one of the RIF builtin types. RIF does not ascribe any specific lexical space to these types and any Unicode string should be considered a well-formed constant symbol as far as RIF is concerned. In the same way, RIF does not ascribe any particular semantics to such non-builtin TYPEs: it is the responsibility of the producers and consumers of RIF-PRD rulesets that reference types that are not built in RIF-PRD to agree on their lexical space and on their semantics.
Dialects that extend RIF-PRD might define additional builtin types, give them special semantics and appropriate the names of some non-standard types to name them.
Examples. In each of the examples below, a constant is first described, followed by its representation in RIF-PRD XML syntax.
a. A constant with builtin type xsd:integer and value 123:
<Const type="xsd:integer">123</Const>
b. A constant which symbol today is defined in Jim the Hen Handler's namespace, identified by the prefix jim:. The type of the constant is rif:iri:
<Const type="rif:iri">jim: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>
e. A constant with symbol Tuesday, defined in the literal space of the application specific data type jim:DayOfTheWeek:
<Const type="jim:DayOfTheWeek">Tuesday</Const>
In RIF, the Var construct is used to represent variables.
The content of the Var element is the variable's name, represented as an Unicode character string.
<Var> any Unicode string </Var>
As a TERM, an External element is used to represent 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 by zero or more arg elements:
<External>
<content>
<Expr>
<op> Const </op>
<arg> TERM </arg>*
</Expr>
</content>
</External>
Builtin functions. RIF-PRD specifies a subset of XPath/XQuery Functions and Operators [X F&O] that any conformant RIF-PRD implementation MUST support. The RIF-PRD builtin functions are listed in the [ Data Type and Builtins] document.
The op Const must represent a constant symbol of type rif:iri that must uniquely identify the evaluated function to be applied to the arg TERMs. It can be one of the builtin functions specified for RIF-PRD, or it can be application specific. In the latter case, it is the responsibility of the producers and consumers of RIF-PRD rulesets that reference non-builtin functions to agree on their semantics.
Examples.
a. The first example below shows one way to represent, in RIF-PRD, the sum of integer 1 and variable ?X, where the addition conforms to the specification of the builtin fn:numeric-add.
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>
<arg> <Const type="xsd:integer"> 1 </Const> </arg>
<arg> <Var> ?X </Var> </arg>
</Expr>
</content>
</External>
b. Another example, that shows the RIF XML representation of a call to the application-specific nullary function today(), which symbol is defined in the example's namespace:
<External>
<content>
<Expr>
<op> <Const type="rif:iri"> jim:today </Const> </op>
</Expr>
</content>
</External>
The ATOMIC class is used to represent atomic truth-valued statements. RIF-PRD covers rule languages in which the truth values of atomic statements can only be "true" or "false": that is, ATOMICs represent boolean statements. Dialects extending RIF-PRD may support additional truth values.
As an abstract class, ATOMIC is not associated with specific XML markup in RIF-PRD instance documents. It is specified in the normative schema as a substitution group.
[ Atom | Equal | Member | Subclass | Frame ]
In RIF, the Atom element is used to represent a relation (or predicate).
The Atom element contains one op element, followed by zero or more arg arguments:
<Atom>
<op> Const </op>
<arg> TERM </arg>*
</Atom>
Example. The example below shows the RIF XML representation of the predicate owns(?c ?p), where the predicate symbol owns is defined in the example namespace denoted by the prefix jim:.
<Atom> <op> <Const type="rif:iri"> jim:owns </Const> </op> <arg> <Var> ?c </Var> </arg> <arg> <Var> ?p </Var> </arg> </Atom>
In RIF, Equal is used to represent equality relations.
The Equal element must contain two unordered side elements. The content of each side element must be a construct from the TERM abstract class. The order of the side elements is not significant and must not be preserved.
<Equal>
<side> TERM </side>
<side> TERM </side>
</Equal>
In RIF, the Member element is used to represent membership relations.
The Member element contains two unordered sub-elements:
<Member>
<instance> TERM </instance>
<class> TERM </class>
</Member>
Example. The example below shows the RIF XML representation of a bollean expression that tests whether the individual denoted by the variable ?c is a member of the class Chicken that is defined in the example namespace denoted by the prefix jim:.
<Member> <instance> <Var> ?c </Var> </instance> <class> <Const type="rif:iri"> jim:Chicken </Const> </class> </Member>
In RIF, the Subclass element is used to represent class inclusion relations.
The Subclass element contains unordered two sub-elements:
<Subclass>
<sub> TERM </sub>
<super> TERM </super>
</Subclass>
In RIF, the Frame construct is used to represent relations that hold between an individual, also called an object, and the values of some its properties or attributes: that is, object-attribute-value triples.
Accordingly, a Frame element must contain:
<Frame>
<object> TERM </object>
<slot> Prop </slot>*
</Frame>
<Prop>
<key> TERM </key>
<val> TERM </val>
</Prop>
Example. The example below shows the RIF XML syntax of an expression that states that the object denoted by the variable ?c has the value denoted by the variable ?a for the property Chicken/age that is defined in the example namespace.
<Frame>
<object> <Var> ?c </Var> </object>
<slot>
<Prop>
<key> <Const type="rif:iri"> jim:Chicken/age </Const> </key>
<val> <Var> ?a </Var> </val>
</Prop>
</slot>*
</Frame>
Editor's Note: 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-XXX]).
The FORMULA class is used to represent any truth-valued statement, atomic or not, that is allowed in the condition part of a rule covered by RIF-PRD. In rule languages covered by RIF-PRD, the truth values of statements can be "true" or "false": that is, FORMULAs can only represent boolean statements.
Dialects extending RIF-PRD may support additional truth values.
As an abstract class, FORMULA is not associated with specific XML markup in RIF-PRD instance documents. It is specified in the normative schema as a substitution group.
[ ATOMIC | External | And | Or | NmNot | Exists ]
A FORMULA can be a single ATOMIC statement. See specification of [ ATOMIC], above.
In RIF-PRD, an External represents an externally specified predicate when it is a FORMULA (as opposed to a TERM; that is, in particular, when it appears in a place where a FORMULA is required, and not a TERM).
The External element contains one content element that contains one Atom element:
<External>
<content>
Atom
</content>
</External>
Builtin predicates. RIF-PRD specifies a subset of XPath/XQuery Functions and Operators [X F&O] that any conformant RIF-PRD implementation MUST support. The RIF-PRD builtin predicates are listed in the [ Data Types and Builtins] document.
The op Const in the Atom element must be a symbol of type rif:iri that must uniquely identify the evaluated predicate to be applied to the arg TERMs. It can be one of the builtin predicates specified for RIF-PRD, or it can be application specific. In the latter case, it is up to the producers and consumers of RIF-PRD rulesets that reference non-builtin predicates to agree on their semantics.
Example. The example below shows the RIF XML representation of a boolean expression that tests whether the value denoted by variable ?a (e.g. the age of a chicken) is greater than the integer value 8, where the test is intended to behave like the builtin predicate op:numeric-greater-than as specified in XQuery 1.0 and XPath 2.0 Functions and Operators.
In the example, the prefix op: is associated with the namespace http://www.w3.org/2007/rif-builtin-predicate#.
<External>
<content>
<Atom>
<op> <Const type="rif:iri"> op:numeric-greater-than </Const> </op>
<arg> <Var> ?a </Var> </arg>
<arg> <Const type="xsd:decimal"> 8 </Const> </arg>
</Atom>
</content>
</External>
A FORMULA can represent the conjunction of zero of more statements, each of them represented by a FORMULA. This is represented by the And construct.
The And element contains zero or more formula elements, each containing an element of the FORMULA group.
<And>
<formula> FORMULA </formula>*
</And>
A FORMULA can represent the disjunction of zero of more statements, each of them represented by a FORMULA. This is represented by the Or construct.
The Or element contains zero or more formula elements, each containing an element of the FORMULA group.
<Or>
<formula> FORMULA </formula>*
</Or>
A FORMULA can represent the non-monotonic negation of a statement, itself represented by a FORMULA: this is represenetd by the NmNot construct.
The NnNot element contains exactly one formula element. The formula element contains an element of the FORMULA group, that represents the negated statement.
<NnNot>
<formula> FORMULA </formula>
</NmNot>
In RIF, the Exists construct is used to represent an existentially quantified FORMULA.
The Exists element contains:
<Exists>
<declare> Var </declare>+
<formula> FORMULA </formula>
</Exists>
Example. The example below shows the RIF XML representation of a boolean expression that tests whether the chicken denoted by variable ?c is older than 8 months, by testing the existence of a value, denoted by variable ?a, that is both the age of ?c, as represented by a Frame as in example XX, and greater than 8, as represented by an External ATOMIC as in example YY.
<Exists>
<declare> <Var> ?a </Var> </declare>
<formula>
<And>
<Frame>
<object> <Var> ?c </Var> </object>
<slot>
<Prop>
<key> <Const type="rif:iri"> jim:Chicken/age </Const> </key>
<val> <Var> ?a </Var> </val>
</Prop>
</slot>*
</Frame>
<External>
<content>
<Atom>
<op> <Const type="rif:iri"> op:numeric-greater-than </Const> </op>
<arg> <Var> ?a </Var> </arg>
<arg> <Const type="xsd:decimal"> 8 </Const> </arg>
</Atom>
</content>
</External>
</And>
</formula>
</Exists>
This section specifies the XML syntax that is used in RIF-PRD to represent what can appear in the action part of a rule supported by RIF-PRD.
Editor's Note: Difference wrt RIF-BLD: all the constructs in this section are specific to RIF-PRD.
Editor's Note: What about truth maintenance capabilities in many PR systems?
RIF-PRD defines one single abstract class for actions: ACTION, that is realised by five concrete constructs:
Editor's Note: Should other actions be considered in RIF-PRD? Esp., do we need some basic programatic constructs, such as a loop?
Editor's Note: Except for the different names, the missing abstract class that groups the Assert, Retract and Update actions, and the possibility to Assign a value to a (ruleset) variable (which are not defined in this draft), the ACTION abstract class is copied from the ImperativeExp abstract class that specifies the actions in the OMG [ PRR OCL] specification.
The following sections specify each construct separately, grouped by abstract syntactic classes. Each element is given an XML syntax, in the form of an informative BNF pseudo schema: the normative XML syntax is given in the [ RIF-PRD XML schema].
The ACTION class of constructs is used to represent the individual actions in the action part of a production rule represented in RIF-PRD.
This version of RIF-PRD covers five ACTIONs: Assert, Retract, Update, Execute and Assign.
As an abstract class, ACTION is not associated with specific XML markup in RIF-PRD instance documents. It is specified in the normative schema as a substitution group.
Editor's Note: ...Substitution group or another construct, depending on how we handle extensibility in the XML schema.
[ Assert | Retract | Update | Execute | Assign ]
The Assert construct is used to represent actions that result in asserting an atomic statement.
The Assert element has one target sub-element that contains a construct from the ATOMIC group, which represents the atomic statement to be asserted on implementing the action. The Equal construct is not allowed as the target of an Assert
Editor's Note: Are there other restrictions on the kind of ATOMIC that can be Assert-ed? Shall we allow Member and Subclass ATOMICs to be Assert-ed? Or should we make no restriction: the assertion of an Equal might be well-formed, after all; its assertion might have unexpected results, but is that RIF's concern?
Editor's Note: Issues: ATOMIC might not be the right way to represent the target anyway: what about the case where a new individual has to be created? Use, by convention, the assertion of an anonymous frame (that is, a frame where the object is the name of a class, not an individual)?
Editor's Note: Or remove the Assert construct and interpret an ATOMIC as an ACTION as an assert? That would improve PRD/BLD/Core compatibility at the synatctic level. What would be the drawbacks?
<Assert>
<target> ATOMIC </target>
</Assert>
The Retract construct is used to represent actions that result in negating an atomic statement.
The Retract element has one target sub-element that contains a construct from the ATOMIC group that represents the atomic statement to be removed on implementing the action.
Editor's Note: Are there any restriction on the kind of ATOMIC that can be removed? E.g. what would it mean to remove an Equal? Should we allow a Member or a Subclass ATOMIC to be Retract-ed?
Editor's Note: Issue: ATOMIC might not be the right way to represent the target anyway: e.g. how to Retract an individual (if empty Frames are not allowed)?
<Retract>
<target> ATOMIC </target>
</Retract>
Editor's Note: Issue: How to reatrct multiple facts at once? E.g. Retract-ing an individual: use empty frames (if allowed) as a convention?
Example. The example below shows the RIF XML representation of an action that updates the chicken-potato ownership table by removing the predicate that states that the chicken denoted by variable ?c owns the potato denoted by variable ?p. The predicate is represented as in example XX.
<Retract>
<target>
<Atom>
<op> <Const type="rif:iri"> jim:owns </Const> </op>
<arg> <Var> ?c </Var> </arg>
<arg> <Var> ?p </Var> </arg>
</Atom>
</target>
</Retract>
The Update construct is used to represent actions that result in updating an atomic statement.
The Update element has one target sub-element that contains a construct from the ATOMIC group that represents the atomic statement to be updated on implementing the action.
<Update>
<target> ATOMIC </target>
</Update>
From the specification of OMG PRR-OCL [ PRR]: "Some operations modify the state of objects and others do not. If the modified objects are in the scope of the engine, the engine must be notified that the objects state has been modified to be able to compute the list of eligible rules. It is not possible from the operation call to determine automatically what objects will be modified so it may be necessary in the rule to explicitly notify the engine."
Editor's Note: Issues: The Update as an action is specific to some rule engine technologies or implementations (e.g. RETE-based). Since it is required by such implementations only because of the opaque nature of the Execute actions with respect to the modification of ATOMICs, and since the specification of the procedural attachments to be Execute-ed requires a specific interchange channel anyway (as builtins or depending on an out-of-band agreement), should not the information relevant to any ATOMIC impacted by an Execute-ed procedure, and thus to required updates for engines that use them, rather be interchanged as part of the specification of said procedures? And Update not be covered by RIF-PRD, as a consequence?
The Execute is used to represent actions that result in the execution of a procedural attachment.
The Execute element has one op sub-element that represents the symbol of the procedural attachement to be executed on implementing the action, followed by zero or more arg sub-elements that represent its arguments:
Editor's Note: Or should the op element be restricted to a Const instead?
Or use the External construct instead (AdrianP)? But how
about (i) the ambiguity with fixed interprestation predicates; (ii)
asserted ATOMICs if we remove the Assert construct?
<Execute>
<op> TERM </op>
<arg> TERM </arg>*
</Execute>
Builtin operations.
TBD
Editor's Note: Should RIF-PRD have builtin executable operations (e.g. print etc) or should they be left to be the application specific?
Example. The example below shows the RIF-PRD XML representation of the action which execution results in the physical potato denoted by variable ?p being mashed, following the specification of the mash action in the example namespace denoted by the prefix jim:.
<Execute> <op> <Const type="rif:iri"> jim:mash </Const> </op> <arg> <Var> ?p </Var> </arg> </Execute>
The Assign construct is used to represent actions that result in a value being assigned to a property of an individual.
The Assign element has one target sub-element that contains a Frame that represents an object-attribute-value, where the "value" has to be assigned to the "attribute" of the "object" on implementing the action.
Editor's Note: Or reuse the Equal construct (AdranP)? But that would be with a different semantics
Editor's Note: How will values be assigned to parameters (if and once we add them)?
<Assign>
<target> Frame </target>
</Assign>
Example. The example below shows the RIF-PRD XML represnetation of the action that increases by 10% the value of the daily grain allowance of the chicken denoted by ?c.
<Assign>
<target>
<Frame>
<object> <Var> ?c </Var> </object>
<slot>
<Prop>
<key> <Const type="rif:iri"> jim:Chicken/allowance </Const> </key>
<val> ????Would need to declare a variable to compute 110% of its value??? </val>
</Prop>
</slot>*
</Frame>
</target>
</Assign>
Editor's Note: Really needs to define a standard syntax for getters and setters for properties, not just accessors à la Frame...
This section specifies the RIF-PRD constructs that are required, in addition to the [ RIF-PRD condition language] and the [ RIF-PRD action language], to represent, and interchange, complete production rules and rule sets.
The RULE construct is an abstract class: in RIF-PRD instance documents, it is either visible as a ConditionalStatement or as a Forall:
Editor's Note: Difference wrt RIF-BLD: The ConditionalStatement is the Implies construct of RIF-BLD. However, the word "Implies" does not carry the appropriate meaning for RIF-PRD. The proposal is to rename the Implies in RIF-BLD (to ConditionalStatement or whatever other name that is prefered) so that RIF-BLD and RIF-PRD can inherit the same construct from Core?
The RuleSet construct has zero or more constructs of the RULE group associated as rules.
Editor's Note: Do we need ruleset parameters, etc?
The following sections specify each construct separately, grouped by abstract syntactic classes. Each element is given an XML syntax, in the form of an informative BNF pseudo schema: the normative XML syntax is given in the [ RIF-PRD XML schema].
In RIF-PRD, the RULE class of constructs is used to represent rules, that is "if-then" statements, possibly universally quantified.
As an abstract class, RULE is not associated with specific XML markup in RIF-PRD instance documents. It is specified in the normative schema as a substitution group.
Editor's Note: ...Substitution group or another construct, depending on how we handle extensibility in the XML schema.
[ ConditionalStatement | Forall ]
Editor's Note: Difference wrt RIF-BLD: The FORMULA is optional in a ConditionalStatement, but a list of ACTIONS with a trivially satisfied FORMULA is not the same, conceptually, as a head without a body in a logic program (e.g. it does not belong to the fact base). Thus, the rationale for making the head-without-a-body a different kind of RULE does not apply in the RIF-PRD case. ISSUE: how does Core represent a fact? From the answer to that question depends whether PRD and BLD may differ on this; preferably, they should not differ.
The ConditionalStatement construct is used to represent the conditional statement (that is, the "if-then", or condition-conclusion, or antecedent-consequent pair) that is at the core of a rule.
The ConditionalStatement element contains zero or one if sub-element and one then sub-element:
Editor's Note: Should we have an "else"-part, in addition to the if-part and the then-part? On the one hand, it is one of the rationale for separating the variable binding patterns FORMULAe from the if-part FORMULA; on the other hand, what is the support for it among the rule languages RIF-PRD aims to cover?
<ConditionalStatement>
<if> FORMULA </if>?
<then>
ACTION
ACTION*
</then>
</ConditionalStatement>
Editor's Note: Difference wrt RIF-BLD: the content of the then element is specific to RIF-PRD (but PRD and BLD share the structure of the construct).
The Forall construct is used to represent universally quantified rules.
The Forall element contains:
<Forall>
<declare> Var </declare>+
<pattern> FORMULA </pattern>*
<formula> RULE </formula>
</Forall>
Editor's Note: Difference wrt RIF-BLD: the Forall in RIF-PRD adds, wrt BLD, the pattern sub-element to associate FORMULAs to the declared Vars. One of the rationale for the Pattern sub-element is to allow "if-then-else" rules. Both differences are specific to RIF-PRD.
Example. The exmaple below shows the RIF-PRD XML representation of a simplified version of the CMP rule that reads: except on Tuesdays, every potato thet belongs to a chicken is mashed, and the ownership table is updated, or
Forall ?c, where ?c is a jim:Chicken Forall ?p, where ?p is a jim:Potato and owns(?c ?p) If Not( jim:today() equal "Tueday" Then mash(?p) and remove (?c ?p) from the ownership table.
Some tags and content are emphasized (bold-face) for readibility in the XML fragment below. . The complete RIF-PRD XML representation of the CMP rule can be found in [ appendix XXX].
<Forall>
<declare> <Var> ?c </Var> </declare>
<pattern>
<Member>
<object> <Var> ?c </Var> </object>
<class> <Const type="rif:iri"> jim:Chicken </Const> </class>
</Member>
</pattern>
<formula>
<Forall>
<declare> <Var> ?p </Var> </declare>+
<pattern>
<And>
<Member>
<object> <Var> ?p </Var> </object>
<class> <Const type="rif:iri"> jim:Potato </Const> </class>
</Member>
<Atom>
<op> <Const type="rif:iri"> jim:owns </Const> </op>
<arg> <Var> ?c </Var> </arg>
<arg> <Var> ?p </Var> </arg>
</Atom>
</And>
</pattern>
<formula>
<ConditionalStatement>
<if>
<:NmNot>
<formula>
<Equal>
<side>
<External>
<content>
<Expr>
<op> <Const type="rif:iri"> jim:today </Const> </op>
</Expr>
</content>
</External>
</side>
<Const type="jim:DayOfTheWeek"> Tuesday </Const>
<side>
</side>
</Equal>
</formula>
</NmNot>
</if>
<then>
<Execute>
<op> <Const type="rif:iri"> jim:mash </Const> </op>
<arg> <Var> ?p </Var> </arg>
</Execute>
<Retract>
<target>
<Atom>
<op> <Const type="rif:iri"> jim:owns </Const> </op>
<arg> <Var> ?c </Var> </arg>
<arg> <Var> ?p </Var> </arg>
</Atom>
</target>
</Retract>
</then>
</ConditionalStatement>
</formula>
</Forall>
</formula>
</Forall>
The RuleSet construct is used to represent a set of rules that have to be considered together from a semantic or operational viewpoint (e.g. a knowledge base, a rule base, a ruleset).
The RuleSet element contains zero or more rule element. Each rule element contains an element from the RULE group of constructs that represents one of the rules contained in the rule set.
Editor's Note: Shouldn't that be "at least one rule element"?
Editor's Note: RuleSet parameters? Input/ouput Vars?
<RuleSet>
<rule> RULE </rule>*
</RuleSet>
Editor's Note: Difference wrt BLD: the RuleSet construct does not exist in BLD, although its grouping capability can be represented by the Group construct. However, production rule systems use the ruleset as a first-class construct, passing parameters and scoping local variables.
TBD
This section specifies a presentation syntax for RIF-PRD. The presentation syntax is not normative: its main purpose is to help make the normative specification of the semantics easier to read.
The presentation syntax is specified by the following EBNF, directly in terms of names of the XML elements specified in the previous sections (and, normatively, in the [ XML schema for RIF-PRD]. Where elements with the same name are used in different context with different content, which would lead to ambiguous productions, the ambiguous name has been appended to a disambiguating, context-specific prefix: namely, the name of the containing element. Specifically, the target role in the Assign production (and element) has been renamed assign_target to differenciate it from the target role of other ACTION elements, and the formula role in the Forall production has been renamed forall_formula.
TERM ::= Const | Var | External
Const ::= LITERAL '^^' type ('@' xml:lang)?
LITERAL ::= any Unicode string
type ::= IRI
xml:lang ::= xs:language
Var ::= xs:NMTOKEN
External ::= ' External( ' op ' ( ' arg* ' )) '
op ::= TERM
arg ::= TERM
ATOMIC ::= Atom | Equal | Member | Subclass | Frame Atom ::= op ' ( ' arg* ' ) ' Equal ::= side ' = ' side side ::= TERM Member ::= object ' # ' class object ::= TERM class ::= TERM Subclass ::= subClass ' ## ' class subClass ::= TERM Frame ::= object ' [ ' (key ' -> ' val)* ' ] ' key ::= TERM val ::= TERM
FORMULA ::= ATOMIC | External | And | Or | Naf | Exists And ::= 'AND ( ' formula* ' ) ' formula ::= FORMULA Or ::= 'OR ( ' formula* ' ) ' NmNot ::= ' NOT ( ' formula ' ) ' Exists ::= ' Exists ' declare+ ' ( ' formula ' ) ' declare ::= Var
ACTION ::= Assert | Retract | Update | Execute | Assign
Assert ::= ' ASSERT ( ' target ' ) '
target ::= ATOMIC
Retract ::= ' RETRACT ( ' target ' ) '
Update ::= ' UPDATE ( ' target ' ) '
Execute ::= ' EXECUTE { ' op ' ( ' arg* ' ) } '
Assign ::= ' SET ( ' assign_target ' ] ) '
assign_target ::= Frame
RULE ::= ConditionalStatement | Forall
ConditionalStatement ::= (' IF ' if ' THEN ')? then
if ::= FORMULA
then ::= ACTION (' ; ' ACTION)*
Forall ::= ' Forall ' declare+ (' SUCH THAT ' pattern)* ' ( ' forall_formula ' ) '
pattern ::= FORMULA
forall_formula ::= RULE
RuleSet ::= 'RULESET ( ' rule* ' ) '
rule ::= RULE
Example. The example below shows the RIF-PRD presentation syntax for the simplified version of the CMP rule shown in example XX. The RIF-PRD presentation syntax for the complete CMP rule is shows in [ appendix XX].
FORALL ?c SUCH THAT ?c#jim:Chicken^^rif:iri
( FORALL ?p SUCH THAT AND( ?p#jim:Potato^^rif:iri jim:owns^^rif:iri(?c ?p))
( IF NOT( jim:today^^rif:iri() = "Tuesday"^^jim:DayOfTheWeek )
THEN EXECUTE( jim:mash^^rif:iri(?p) );
RETRACT ( jim:owns^^rif:iri(?c ?p) )
)
)
For the purpose of specifying the semantics of a RIF-PRD RuleSet, a production rule system PRS is defined as a labelled terminal transition system (e.g. Plo04).
Definition (labelled terminal transition system): A labelled terminal transition system is a structure {Γ, L, →, T}, where
A labelled transition system is a structure {Γ, L, →} (without a set T of final configurations).
The idea of describing a PRS as a labelled terminal transition system is that, given a set of production rules RS and a set of facts w0, the rules in RS that are satisfied, in some sense, in w0 determine an action α1, which execution results in a new set of facts w1; the rules in RS that are satisfied in w1 determine an action α2 to execute in w1, and so on, until the system reaches a final configuration and stops. The result is the set of facts wn when the system stops.
Example. Judicael, one follower of Jim the Hen Handler's method, has four chicken, Jim, Jack, Joe and Julia, that own three potatoes (BigPotato, SmallPotato, UglyPotato) among them:
That is the initial set of facts w0. Paula's rule set contains one single rule, that is, Jim's CMP rule:
When the rule is applied to w0:
Suppose that Judicael's implementation of today() returns Monday and that the foxAlarm() is false when the CMP rule is applied: the condition is satisfied, and the actions in the conclusion are executed with BigPotato substituted for ?p and Jim substituted for ?c. This results in the following changes in the set of facts:
The resulting set of facts w1 is thus:
When the CMP rule in applied to w1, the first line still selects {?c/Jim, ?c/Jack, ?c/Julia} as possible values for variable ?c, but the second line does not select any possible substitution for the couple (?c, ?p) anymore: the rule cannot be satisfied, and the system, having detected a final configuration, stops.
The result of the execution of the system is w1.
Let Const be the set of constant symbols that can be represented in RIF-PRD, as determined by the the specification of the Const construct; Var, the set of variable symbols that can be represented in RIF-PRD, as determined by the specification of the Var construct; and Term the set of terms that can be represented in RIF-PRD, as determined by the the specification of the TERM class of constructs. A substitution is defined as follows (e.g. HAK07):
Definition (substitution): A substitution is a finitely non-identical assignment of terms to variables; i.e., a function σ from Var to Term such that the set {x ∈ Var | x ≠ σ(x)} is finite. This set is called the domain of σ and denoted by Dom(σ). Such a substitution is also written as a set such as σ = {ti/xi}i=1..n where Dom(σ) = {xi}i=1..n and σ(xi) = ti for i = 1 to n.
Given X, a set of variables, and σ, a substitution such that X ⊆ Dom(σ), σX denotes, in this document, the restriction of σ to the variables in X: σX = {σ(x)/x | x ∈ X}.
Let TermΣ be the set of ground terms (that can be represented in RIF-PRD), defined as follows:
Definition (ground substitution): A ground substitution is a substitution σ such that ∀ x ∈ Dom(σ), σ(x) ∈ TermΣ.
The function Var(e) that maps a RIF-PRD element e to the set of its free or universally quantified variables is defined as follows:
Definition (rule instance): An instance of a rule r is a pair (rid, σ), where rid uniquely identifies r and σ is a ground substitution such that Var(r) ⊆ Dom(σ). Given a rule r, id(r) denotes rid, the unique identifier of r; given a rule instance ri = (rid, σ), rule(ri) denotes the rule that is uniquely identified by rid.
Definition (ruleset instance): 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 in RS.
Let W be the set of ground formulas that can be represented in RIF-PRD, defined as follows:
Editor's Note: ..or W could be defined, except for the Exists, as the set of the formulas f such that Var(f) = {}?
Let L be the set of the atomic ground actions that can be represented in RIF-PRD:
Editor's Note: The definition of L is subject to change when the ACTIONs will be specified more precisely.
Finally, let R be the set of all the rules that can be represented in RIF-PRD.
In this document, given a set X, P(X) denotes the power set of X, and S(X) denotes the set of the ordered lists of elements of X.
The transition relation →RIF-PRD ⊆ P(W) × L × P(W) is defined as follows:
The intended semantics of the actions that can be represented in RIF-PRD is completely specified by the definition of the labelled transition system {P(W), L, →RIF-PRD}.
Editor's Note: The definition of W would need to be modified if we wanted to cover non-ground facts as well, but the definition of the relation would remain essentially the same.
The relation →*RIF-PRD ⊆ P(W) × S(L) × P(W) denote the transitive closure of the transition relation →RIF-PRD.
A RIF-PRD production rule system is defined as a labelled terminal transition system: given a rule set RS ⊆ R, let CRS ⊆ W × S(Inst(RS)) × P(Inst(RS)) be a set of configurations, where a configuration is a triple c = (w, ric, h), such that w ⊆ W is a set of facts, ric ∈ S(Inst(RS)) is an ordered instance of RS, and h ∈ P(Inst(RS)) is an instance of RS. Given a configuration c = (w, ric, h), let facts(c) denote the first element, the set of facts w; let instance(c) denote the second element, the ordered ruleset instance, ric; and let history(c) denote the third element, the set of rule instances h.
The idea is that a configuration, c, is made of a set, w, of ground FORMULAe that represent a state of facts; the set, ric, of all the instances of the rules in the considered ruleset RS that are satisfied, in some sense to be further specified, in that state of fact; and a set, h of rule instances that represent a part of the history of the system, in that it collects the rule instances that determined some of the actions that led to the present configuration, and that have been satisfied, in the same sense as before, in all the states of facts that have been traversed since. In the same way, the order among the rule instances, in ric, represents another part of the system's history: the longer a rule instance has been continuously satisfied by the states of facts of the traversed configurations, in terms of number of configurations, the farther it is in the ordering. These elements of the history of the system are relevant when selecting the next transition.
Let further assume three functions:
Let mergeInstances: S(Inst(R)) × P(Inst(R)) → S(Inst(R)), be a helper function that, given an ordered set of rule instances, ori, and an unordered set of rule instances, ri, returns ri, ordered in such a way that the order of ori is preserved among all the rule instances in ri ∩ ori, and the rule instances in ri - ori come first in the order.
Let extractActions: S(Inst(R)) → S(L), be another helper function that, given an ordered set, ori, of rule instances, returns the sequence of ACTIONs that is the concatenation, preserving the order in ori, of the sequences of ground actions determined by each of the rule instances in ori.
Given a ruleset RS and a selection strategy LS, a RIF-PRD production rule system is defined as a labelled terminal transition system PRSRS,LS = {CRS, S(L), →RS, TRS}, where :
Intuitively, the conditions 1 in the definition of the transition relation →RS guarantees that only the specification of the function PICK and the selection strategy determine which are the allowed transition paths out of a given configuration, and condition 2 guarantees that all transitions are compliant with the semantics of the individual actions, as specified the relation →RIF-PRD. Condition 3 guarantees that the instance component of any reachable configuration contains all the instances of the rules in RS that are satisfied in the configuration's state of facts, ordered in the appropriate way. Condition 4 means that the systems keeps a memory of the rule instances which action part has been executed, and that have been been part of the instances returned by INSTANTIATE in all the configurations that have been since traversed. And condition 5 guarantees that the system halts as soon as it encounters a terminal configuration.
The input function is defined as:Or, using →*RS to denote the transitive closure of the transition relation:
Given the specification of PRSRS,LS, the intended operational semantics of a production ruleset represented by a RIF-PRD RuleSet RS is completely specified by the specification of the three functions INSTANTIATE, PICK and FINAL.
The evaluation of the function INSTANTIATE corresponds to the step that is often called matching in the description of production rule systems (e.g. PRR07).
Indeed, the function is most easily specified using the widely spread notion of pattern matching. The following definition is adapted from CIR04.
Definition (pattern matching): Given a set w ⊆ W of ground RIF-PRD ATOMICs and a RIF-PRD FORMULA p, p is said to match w with respect to a theory τ and a ground substitution σ, denoted σ(p) «τ w, iff one of the following is true:
A set P of RIF-PRD FORMULAe is said to match a set w ∈ W of ground RIF-PRD ATOMICs with respect to a theory τ and a ground substitution σ, denoted σ(P) «τ w, iff σ(pi) «τ w for all pi ∈ P.
Editor's Note: The definition is easily, if tediously, extended to cover the case of matching arbitrary FORMULAe against any set of ground FORMULAe ⊆ W.
Editor's Note: The matching theory τ to be taken into account includes the equality theory defined between frames, the builtin datatypes, functions and relations, and any externally defined datatypes, classification theory, functions and relations as required by the ruleset. This is to be further specified when references to application-specific data models and externals is specified.
Editor's Note: Do we need to go into any deeper details wrt the matching of ATOMICs, or is that unambiguous enough?
Example. TBD
Let InstantiateRULE: P(W) × R → P(Inst(R)), be a function that, given a set of facts w ∈ W and a rule r ∈ R, returns a set, ir ⊆ Inst(R), of instances of r.
The evaluation of InstantiateRULE(w, r) is specified based on a terminal transition system where:
Intuitively, a configuration is made of the set of facts, w, against which the rule is instantiated; the rule, r, to be instantiated; the substitution, σ, that is under evaluation as possibly instantiating r in such a way that its condition matches w; the set, Σ, of the candidate substitutions that are still to be evaluated, including σ; and the instances accumulator, acc, that relates the identifier, id, of the input rule, rinput, to the set of the substitutions that have been evaluated and with respect to which the condition of rinput is known to match w.
Given a rule r ∈ R, let Σr denote the set of the restrictions to Var(r) of all the subtitutions σ such that Var(r) ⊆ Dom(σ): Σr = {σVar(r) | ∀ σ, Var(r) ⊆ Dom(σ)}.
The input function can now be defined as:The output function is defined as:
The role of the function InstantiateRULE is to loop through all the possible substitutions for the variables of the input rule, and to select the ones with respect to which all the pattern FORMULAe in the Foralls of rinput, if any, as well as the if FORMULA, if there is one in rinput, match w.
As a consequence, in the definition of the transition relation, the first rule represents the initialisation of the process, when a substitution σ is selected out of Σ for evaluation. The rules also guarantees that each candidate substitution is evaluated once and only once on each single path.
Rule 2 and 3 progress the instantiation through a rule's nested Forall and guarantee that any pattern formula associated with an enclosing Forall matches w with respect to the substitution under consideration (rule 2) and that σ is not further considered and rejected as soon as a pattern formula does not match w with respect to it; and that the process is re-initiated for another substitution to be evaluated.
Rule 4 and 5 guarantee that a substitution that a substitution is added to the ouput accumulator if (rule 4) and only if (rule 5) the if FORMULA matches w with respect to that substitution; and that the process is re-initiated for the evaluation of another candidate substitution.
In complement to rule 4, rule 6 handles the trivial case where the optional if FORMULA is missing, and thus considered, by convention, matching every set of facts with respect to any substitution and theory.
Editor's Note: There are certainly more elegant ways to make sure that all the possible instances have been found... Suggestion, anyone?
The input function initializes the transition system with respect to the state of facts and the rule, and the output function transforms the set of selected substitutions in the accumulator in the corresponding set of instances of the input rule.
Example. TBD
The evaluation of the function INSTANTIATE(w, RS), where w ⊆ W and RS ⊆ R, can now be specified as a simple terminal transition system where:
The input function is defined as:
The output function is defined as:
Editor's Note: To Be Added: textual explanation of the rules and the TTS (esp. re its confluence).
Example. TBD
Editor's Note: This section is still under discussion (see [ ISSUE-XX]). This version of RIF-PRD specifies five elementary strategies, a way of combining them, and a default combination. Future working drafts may specify different and/or additional elementary strategies, and no or a different default. The Working Group seeks feedback on which instances selection strategies and which combinations of strategies should be supported by RIF-PRD and/or required from RIF-PRD implementations; and which strategy or combination should be the default, if any.
A rule instance determines a sequences of ground actions, by application of the associated substitution to the variables in the ACTIONs in the then component of the instantiated rule. The decision to implement the sequence of actions that a rule instance determines is often called: firing the rule instance.
Most implementations of production rule languages select the rule instances to be fired, and, therefore, the sequence of actions to be implemented, based on one or a combination of the following strategies (under these or other, idiosyncratic names; and possibly combined with additional, idiosyncratic rules):
Let fireableINSTANCES: S(Inst(R)) × P(Inst(R)) × {no-repeat, priority, recency, random, all} → S(Inst(R)) be a function that, given an ordered set, ori, of candidate rule instances, a set, h, of excluded rule instances, and a keyword, k, indicative of an single selection strategy, return a subset fri ⊆ ori, selected and ordered according to the strategy indicated by k. The keywords "no-repeat"" and "all" indicate, respectively, the no-repetition and all-at-once selection strategies, and the other keywords indicate each the strategy by the same name.
The function fireableINSTANCES is precisely specified in the next subsection.
The function PICK(c, LS) can be specified with the help of a terminal transition system where:
Intuitively, the strategy for the selection of the rule instances to be fired that is intended for the set of rules represented by a RIF-PRD Ruleset, is :
The operational semantics of the function fireableINSTANCES depends on its third argument, the elementary selection strategy. It is therefore specified separately for each value of that parameter, that is, for each of the supported rule instances selection strategy.
Editor's Note: This working draft does not specify a way to specify a non-default instance selection strategy for a RIF-PRD ruleset in a RIF document. As a consequence, only the elementary strategies that are required to implement the default strategy are precisely specified in this version.
No-Retition. The evaluation of the function fireableINSTANCES(ori, h, "no-repeat"), where ori ∈ S(Inst(R)) is an ordered set of candidate rule instances and h ∈ P(Inst(R)) is a set of excluded rule instances, can be specified with the help of a simple terminal transition system, where,
The system walks through the input ordered set of candidate rule instances ori and rewrite it in the output set, perserving the order (as guaranteed by rule 2) but removing any element that belongs to the input set of excluded rule instance h (as guaranteed by rule 1).
Example. TBD
Random. fireableINSTANCES(ori, h, "random"), where ori ∈ S(Inst(R)) and h ∈ P(Inst(R)), returns a randomly selected singleton subset of ori:Editor's Note: This section is still under discussion (see [ ISSUE-XX]). This version specifies a single, default halting test: future version of this draft may specify additional halting tests, and/or a different default. The Working Group seeks feedback on which halting tests and which combinations of tests should be supported by RIF-PRD and/or required from RIF-PRD implementations; and which halting test should be the default, if any.
By default, the specification for a terminal configuration that is intended for a set of production rules, when no halting test is explicitely associated to its representation as a RIF-PRD Ruleset, is when no rule instance is fireable: this is the case when INSTANTIATE returns an empty set of rule instances, or when all the rule instances that are satisfied in the configuration, according to the semantics of INSTANTIATE, have already been fired in a configuration that has not since changed significantly. That latter condition guarantees, in particular, that the system halts when it reaches a fixpoint.
Formally, ∀ RS ⊆ R, ∀ c ∈ CRS, PICK(c, RS) = true if and only if instance(c) - history(c) = ∅. Otherwise, PICK(c, RS) = false.
TBD