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/.
The Rule Interchange Format (RIF) Working Group participantsseeks
public feedback on these Working Drafts. Please send your
comments as soon asto public-rif-comments@w3.org (public archive). If possible, please offer
specific changes to help guide discussion at F2F9 .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.
***Editor's Note:
General introduction to be developed.
To be updated following restructuring of the draft The RIF production rule dialect (RIF-PRD) follows the above general modelTBD
and rulesets closely. As a consequence, RIF-PRD specifies two sublanguages: the RIF-PRD condition language, which extends the RIF-Core ([ RIF-Core]) [ condition language], determines what can appear in the condition of a rule supported by RIF-PRD; the RIF-PRD action language, which extends the RIF-PRD condition language, determines what can appear in the action part of a rule supported by RIF-PRD. RIF-PRD extends these sublanguages to specify the interchange format for production rules and rulesets. 1.2.1. RIF-PRD as an interchange format for production rules ***Editor's Note:
Overview of PRD and its semantics to be developed
To make RIF dialects suitable as Web languages, RIF supports XML Schema primitive data types and some other data types. In addition, RIF promotes the use of Internationalized Resource Identifiers (or IRIs) RFC 3987 to refer to individuals, predicates, and functions.
1.2.3.Editor's Note:
Does this still make sense?
To ensure compatibility with RIF Core dialect ([ RIF-Core]) and its extensions, the RIF production rule language (RIF-PRD) does not draw a sharp boundary between the symbols used to denote individuals from symbols used as names for functions or predicates. Instead, all constant, predicate, and function symbols are drawn from the same universal set. The framework for logic-based RIF dialects RIF-FLD explains how RIF logic dialects control the contexts in which the different symbols can occur by attaching signatures to these symbols. *** "Individual"? "Object"? The intention is to make it clear that constants may stand for something more complex that a single, simple value, and I would fear that using "object" might be too specific, e.g. what about records, etc? Anyway, whatever terminology we use must be consistent and defined. *** In RIF-PRD, individuals, constants, functions and predicates behave as if they were drawn from different sets and signatures are not part of the RIF-PRD language. *** Or should we just drop that section altogether? *** 1.2.4.TBD
In this document we will introduce twothree related but distinct
representations for RIF-PRD components:
used in RIF-PRD will be presented as UML diagrams.This syntax is the diagrams are used to introduce RIF-PRD syntactic classesnormative XML serialization of RIF-PRD. It is
meant, and has been designed, to show atwork as a glance how they relate to each others.common XML serialisation
for many production rule languages.
Three kinds of syntactic components are used to specify RIF-PRD:
Shall PRD have structural diagrams? Only if BLD has them? Only of Core has them? Even if none of them has them? In no case whatsoever?... *** XML syntax. This syntax is the normative XML serialization of RIF-PRD. The key features of this syntax are derived from the structural diagrams, but some aspects related to rule exchange do not have counterparts in the diagrams; Presentation syntax. A human-friendly presentation syntax is specified non-normatively. 1.3. Overview of this document TBD 1.3.1. BNF pseudo-schemaThe XML syntax is specified for each component as a
pseudo-schemas, beforeas 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_elementrequired_attribute_of_type_string="required_attribute_of_type_string="xs:string"optional_attribute_of_type_int="" optional_attribute_of_type_int="xs:int"?>"? > <required_element/>/> <optional_element/>?/>? <one_or_more_of_these_elements/>+/>+ [ <choice_1/>/> | <choice_2/>/> ]* </defined_element>1.3.2.>
The BNF-like pseudo schema are not normative: the XML schema is normative.
A presentation syntax is also specified, to allow a more easily readable presetation of RIF-PRD language fragments (such as examples etc). The presentation syntax is used mainly to specify the intended semantics of RIF-PRD rulesets. It is non normative.
The overall structure of the syntax of RIF-PRD is also presented as an UML-like diagram in appendix [ XXX]. The diagram provides an overview of RIF-PRD syntactic classes and shows at a glance how they relate to each others.
TBD
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. In the next version of this document we intend to introduce a syntax for defining prefixes for compact URIs.
***Editor's Note:
Namespace for RIF-PRD constructs...
Jim the language of expressions thatHen 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 usedstill experimenting to representimprove
his method, the different components of a rule supported by RIF-PRD.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 languagevery latest version.
Jim's latest addition to his knowledge base is calledthe language of conditions , because it extendsfollowing
advice:
Jim calls it the condition part of production rules"Chicken and Mashed Potatoes", or CMP, rule.
Rephrased in RIF-PRD condition sublanguagea more "rule-like" form, the rule could read like:
The basic building block of RIF. ATOMIC is an abstract class: itCMP rule is visible in RIF-PRD as either an Uniterm , an ExtTerm , an Equal , a Member , a Subclass ora Frame . Notice that, for clarity, onlyproduction rule: that is, when the basic form ofrule is
implemented and the Frame constructcondition is represented insatisfied, the diagram: in addition,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 syntaxproduction rule dialect of RIF-PRD condition language allowsRIF, and Jim the
representation of nestedHen Handler's method, and especially his "chicken and composite Frame s. However, a nestedmashed
potatoes" rule and composite Frame can alwayscomponents thereof, will be representedused as a conjunction of basic Frame s and other ATOMIC constructs. Each kind of ATOMIC isrunning
example in this document.
To make sure that his rules can be implemented unambiguously,
Jim (the Hen Handler, not the chicken) published a composition of TERM s. The next leveldata model
(e.g., an XML schema) that identifies Chicken and
Potato as two classes of constructs are assembliesobjects:
The Exists construct also belongs to the QUANTIFICATION abstract class,Jim further specifies:
All these is normative: the normative XML syntax is given in the [ RIF-PRD XML schema](types and the normative semanticsnames) are defined in Jim's namespace,
which is givenrepresented in this document by the prefix
jim:.
This section [ Operational semantics]. 2.1.1. TERMspecifies the TERM class of constructsXML syntax that is used to represent
constants, variables andthe applicationdifferent boolean expressions that can be found in production
rules. The language is called the language of conditions,
because it extends the language of conditions of [ RIF-Core], that
determines what can appear as a condition in a rule supported by
RIF-Core. The language plays a similar role in RIF-PRD.
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 function symbols to otherTERMs.
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 atomic relation, and the recursively specified And, Or, Naf and Exists.
The following sections specify each construct separately,
grouped by abstract syntactic classes. Each element is given an XML
syntax.syntax, in the form of an informative BNF pseudo schema: the
normative XML syntax is given in the [ RIF-PRD XML schema].
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.
***Editor's Note:
...Substitution group or another construct, depending on how we
handle extensibility in the XML schema.
***[ Const | Var |ExtTermExternal ]
***Editor's Note:
Difference wrt RIF-BLD: in RIF-PRD, there are no logic functions
=>=> a TERM cannot be a (non evaluated) Uniterm. *** *** Difference wrt RIF-BLD: The latest version of BLD seems to allow any COUMPOUND (ex-ATOMIC) as TERM. As this has not been discussed yet, that idfference is not commented here. *** Presentation syntax . TERM ::= Const | Var | ExtTerm 2.1.1.1.Expr.
In RIF, the Const construct is used to represent a constant.
The constant is represented by a character string; it is associated with an identifier of the constant's type and, optionally where permitted, a language identifier. XML syntax. TheConst element has a required type
attribute and an optional xml:lang attribute:
The content of the Const element is the constant's symbol, which can be any Unicode character string.
***Editor's Note: Or
should constant litterals be limited to xs:NormalizedString
instead?
***<Consttype="type="IRI"[xml:lang="" [xml:lang="xs:language"]?>"]? > Any Unicode string</Const>Presentationsyntax.Const::=LITERAL'^^'TYPE['@'LANGUAGE_ID]</Const>
Editor's Note: The following (until and exclusing examples, will be revised based on the content of DTB document.
Constant types. RIF-PRD conformant implementations MUST support the following builtin constant types:
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><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><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 LITERAL^^TYPE (i.e.
<Const type="TYPE">LITERAL</Const><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.
Informal semantics. The LITERAL of a constant represents the value of that constant according to its TYPE .Examples. In each of the examples below, a constant is
first described, followed by its representedrepresentation in RIFRIF-PRD XML
syntax (left) and in RIF presentation syntax (right).syntax.
a. A constant with builtin type xsd:integer and value 123:
<Consttype="xsd:integer">123</Const>123^^xsd:integertype="xsd:integer">123</Const>
b. A constant with non-builtin type xsd:int and value 123: <Const type="xsd:int"> 123 </Const> 123^^xsd:int c. A constant whosewhich symbol myConsttoday is defined in Jim the
namespaceHen Handler's namespace, identified by the prefix myXs:jim:. The
type of the constant is rif:iri:
<Consttype="rif:iri">myXs:myConst</Const>myXs:myConst^^rif:irid.type="rif:iri">jim:today</Const>
c. A constant with symbol myLocalCstBigPotato that is local to the
set of rules where it appears: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:
<Consttype="rif:local">myLocalCst</Const>myLocalCst^^rif:local2.1.1.2.type="jim:DayOfTheWeek">Tuesday</Const>
In RIF, the Var construct is used to represent variables.
XML syntax.The content of the Var element is the variable's name,
represented as an Unicode character string.
***Editor's Note:
Shouldn't variable's names rather be limited to be, e.g.
xs:NMTOKEN?
***<Var><Var> xs:NMTOKEN</Var>***</Var>
Editor's Note: Or should Var have a type attribute (and we could, maybe, get rid of the Member construct)?
*** ***Editor's Note:
Difference wrt RIF-BLD: RIF-BLD says only that a Var element
contains a VARNAME. However, most implemented rule languages
enforce some syntactic restrictions on the name of variables and
requiring all RIF implementations to support any Unicode string as
VARNAMEs might be an additional burden with little benefits
associated. This is a proposed alternative: whatever the decision,
BLD and PRD should use the same definition.
As a TERM, an ExtTermExternal element is used to
represent an evaluated function.
***Editor's Note:
builtin function, evaluated function, or fixed interpretation
function... need consistent terminology (Gary)
*** As explainedThe External element contains one content
element, which in turn contains one Expr element that
contains one op</tt> element, followed by zero or more
arg elements:
***Editor's Note: Or
should the op element be restricted to contain a Const element
only?
<ExtTerm><op>TERM</op><arg>TERM</arg>*</ExtTerm>***<External> <content> <Expr> <op> TERM </op> <arg> TERM </arg>* </Expr> </content> </External>
Editor's Note:
Difference wrt RIF-BLD: This version of the construct for representing builtinsPRD draft does not seem to be included in RIF-BLD yet. The label ExtTerm is useduse
named argument UNITERMs.
Editor's Note:
Difference wrt RIF-BLD: Since PRD does not have logical function
(non-External Expr, in the syntax proposalsBLD), it could be a good case for fallbacks
to replace, in PRD, the List of BLD built-ins . This is<External><content><Expr>
cascade by a proposal: whatever the decision, BLD and PRD should use the same definition.*** Presentation syntax. ExtTerm ::= ' Builtin( ' TERM ' ( ' TERM* ' )) ' *** The problem with the "Builin" notation is that all fixed interpretation functions need not be builtin... ***single equivalent <Function> element.
Builtin functions. RIF-PRD specifies a subset of
XPath/XQuery Functions and Operators [X F&O] that any
conformant RIF-PRD implementation MUST support. The RIF-PRD builtin
functions are listed in the appendix[ List of Builtin FunctionsData Type and Operators]. Informal semantics . ExtTerm s are usedBuiltins] document.
Editor's Note:
TBC how to represent procedural attachments: their semantics is always specified outside of a RIF instance document where they appear.reference non-builtin evaluated functions
The op TERM 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.
An evaluated function applied to arguments in its domain of definition evaluatesExamples.
a. The first example below shows one way to a constant valuerepresent, in
its range: subject toRIF-PRD, the binding of its variable arguments, the external call represented by an ExtTerm TERM is another equivalent representation of that constant. Arguments out of the domain of definition. For arguments out of its domain of definition, the value of an evaluated function is not defined. RIF-PRD does not specify any expected behaviour for that case: it is the responsibility of the consummer of a RIF-PRD ruleset to know the expected behaviour or to handle the error. Examples. The example below shows one way to represent, in RIF-PRD, the sumsum of integer 1 and variable ?X,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/2005/xpath-functions.
XMLsyntax.<ExtTerm><op><External> <content> <Expr> <op> <Consttype="rif:iri">type="rif:iri"> fn:numeric-add</Const></op><arg></Const> </op> <arg> <Consttype="xsd:integer">type="xsd:integer"> 1</Const></arg><arg><Var></Const> </arg> <arg> <Var> ?X</Var></arg></ExtTerm>Presentationsyntax.Builtin(fn:numeric-add^^rif:iri(1^^xsd:integer?X))2.1.2.</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""true" or "false":"false":
that is, ATOMICs represent boolean statements. Dialects
extending RIF-PRD may support additional truth values.
XML syntax.As an abstract class, ATOMIC is not associated with
specific XML markup in RIF-PRD instance documents. It is specified
in the normative schema as a substitution group.
***Editor's Note:
...Substitution group or another construct, depending on how we
handle extensibility in the XML schema.
***[Uniterm|ExtTerm|Equal|Member|Subclass|Frame]***DifferencewrtRIF-BLD:ThelatesversionofBLDchangedthenameofATOMICtoCOMPOUND.Asnodecisionhasbeenmadeaboutthisyet(noraboutnamingingeneral),thisdraftkeepsbythepreviousname.Whateverthedecision,BLDandPRDshouldusethesamedefinition.***Presentationsyntax.ATOMIC::=[Uniterm|ExtTermAtom | Equal | Member | Subclass | Frame ]
In RIF, all belong to the same set of constants. As a consequence,the same Uniterm construct could potentially be used to represent functions as well as predicates (or relations). However, this is more general than what is needed in RIF-PRD: in RIF-PRD, an UnitermAtom element is alwaysused to represent a
predicate, and it is always an ATOMIC . Other dialects, including extensions of RIF-PRD, may extend this. XML syntax.relation (or predicate).
The UnitermAtom element contains one op element,
followed by zero or more arg arguments:
<Uniterm><op>Const</op><arg><Atom> <op> TERM </op> <arg> TERM</arg>*</Uniterm>***</arg>* </Atom>
Editor's Note:
Difference wrt RIF-BLD: Not sure what is the support for relational
atoms where the predicate would not be a constant, among production
rule languages. Hence the question above. Dependinglanguages: should op be restricted to be a
Const? Depending on the answer, it might make sense for
PRD to differ from BLD here. The benefits and drawbacks (e.g. wrt
the definition of Core) have to be weighted.
*** ***Editor's Note:
Difference wrt RIF-BLD: Named arguments Uniterms do not seem to have much support in production rule languages => TheyAtoms are not included in
this draft.
PRD and BLD might differ in this respect. A consequence would be that Core would not have named argument Uniterms. *** Presentation syntax. Uniterm ::= Const ' ( ' TERM* ' ) ' Informal semantics . The Uniterm ATOMIC is used to represent an atomic statement that is true iffExample. The individuals or values represented byexample below shows the arg s elements are known to satisfyRIF XML
representation of the predicate (relation) represented by the op element. 2.1.2.2. ExtTerm As an ATOMICowns(?c ?p), an ExtTerm is used to represent an evaluated relation. As explained inwhere the
Overview , for compatibility reasons, individuals, function symbols andpredicate symbolssymbol owns' is defined in RIF, all belong tothe same set of constants. As a consequence,example namespace
denoted by the same ExtTerm constructprefix 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 both evaluated functions and evaluated predicates (or relations). However, this is more general than what is needed in RIF-PRD. In RIF-PRD, an ExtTerm represents always an evaluated predicate when it is an ATOMIC (that is, in particular, when it appears in a place where an ATOMIC is required). XML syntax.equality
relations.
The ExtTermEqual element contains one op element, followed by zero or more arg arguments: When the ExtTerm is an ATOMIC ,must contain two unordered
side elements. The content of the opeach side element
must be a construct from the TERM abstract class. When the ExtTerm is an ATOMIC , the content of the op sub-element represents a predicate symbol; *** Or should the op element be restricted to contain a Const element only? ***The
contentorder of the argside elements is not significant and must not
be constructs from thepreserved.
<Equal> <side> TERMabstractclass.</side> <side> TERM </side> </Equal>
In RIF, the order ofMember element is used to represent
membership relations.
The argMember element contains two unordered
sub-elements:
<Member> <object> TERM</op><arg></object> <class> TERM</arg>*</ExtTerm>***</class> </Member>
Editor's Note:
Difference wrt RIF-BLD: Same remarkobject and class make
more sense to me as wrtthe TERM ÃxtTerm `. *** Presentation syntax. ExtTerm ::= ' Builtin( ' TERM ' ( ' TERM* ' )) ' ***roles in addition to the problem witha membership relation than BLD's
lower and upper. But, as noticed earlier, the
"Builtin" notation applyingdiscussion about naming is still to fct that maybe user-defined, ishad, and I do not care that
much about label's names anyway... This is a proposed alternative:
whatever the ExtTerm ::= ' Builtin( ' Uniterm ' ) ' kinddecision, BLD and PRD should use the same
definition.
Example. The example below shows the RIF XML
representation of confusing? I knowa bollean expression that they are equivalent, but I prefer to keeptests whether the
individual denoted by the developed production (CSMA) *** Builtin predicates. RIF-PRD specifiesvariable ?c is a subsetmember of XPath/XQuery Functions and Operators [X F&O] that any conformant RIF-PRD implementation MUST support.the
RIF-PRD builtin predicates are listedclass Chicken that is defined in the appendix [ List of Builtin Functions and Operators]. Informal semanticsexample namespace
denoted by the prefix jim:.
ExtTermsare<Member> <object> <Var> ?c </Var> </object> <class> <Const type="rif:iri"> jim:Chicken </Const> </class> </Member>
In RIF, the Subclass element is used to represent procedural attachments: their semantics is always specified outside of a RIF instance document where they appear.class
inclusion relations.
The op TERMSubclass element contains unordered two
sub-elements:
<Subclass> <subClass> TERM </subClass> <class> TERM </class> </Subclass>
Editor's Note:
Difference wrt RIF-BLD: BLD's lower and consumers of RIF-PRD rulesets that reference non-builtin predicates to agree on their semantics. Arguments out ofupper
make more sense. I kept class for the domain of definition. An evaluated predicate applied to arguments within its domain of definition evaluates to a truth value.upper
element for arguments out of its domain of definition,consistency with the truth value of an evaluated predicate is not defined. RIF-PRD doesMember element, and
subClass seemmed to make more sense, associated with
class than lower would. But, again, I am not
specify any expected behaviour for that case: itreligious about tags. This is the responsibility of the consummer ofa RIF-PRD ruleset to knowproposed alternative: whatever the
expected behaviour or to handledecision, BLD and PRD should use the error. 2.1.2.3. Equalsame definition.
In RIF, Equalthe Frame construct is used to represent
equality relations. *** Or should RIF-PRD have only evaluated (builtin + application specific) equality relations? *** XML syntax.relations that hold between an individual, also called an object,
and the Equalvalues of some its properties or attributes: that is,
object-attribute-value triples.
Accordingly, a Frame element must contain two unordered side elements.contain:
<Frame> <object> TERMInformalsemantics.</object> <slot> Prop </slot>* </Frame>
<Prop> <key> TERM </key> <val> TERM </val> </Prop>
Example. The Equal element is used to represent a predicateexample below shows the RIF XML syntax of an
expression that states that is is true iffthe values or individuals representedobject denoted by the Equal 's side TERM s are equal. 2.1.2.4. Membervariable
?c has the value denoted by the variable ?a for the
property Chicken/age that is defined in RIF,the Member elementexample
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: Used an XPath style for the key. This has to be discussed, of course.
The FORMULA class is used to represent membership relations. ***any truth-valued
statement, atomic or should RIF-PRD have only evaluated (builtin + application specific) membership relations? *** XML syntax. The Member element contains two sub-elements:not, that is allowed in the object elements must becondition part of
a construct fromrule covered by RIF-PRD. In rule languages covered by RIF-PRD,
the TERMtruth 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.class, FORMULA is not associated with
specific XML markup in RIF-PRD instance documents. It is required;specified
in the class element must benormative schema as a construct fromsubstitution group.
Editor's Note:
...Substitution group or another construct, depending on how we
handle extensibility in the TERM abstract class. It is required as well. <Member> <object> TERM </object> <class> TERM </class> </Member> ***XML schema.
[ ATOMIC | External | And | Or | NmNot | Exists ]
Editor's Note:
Difference wrt RIF-BLD: object and class make more sense to me as the roles ina membership relation than BLD's lower and upper . But, as noticed earlier, the discussion about naming is still to be had, and I do not care that much about label's names anyway... This isRIF-PRD without a proposed alternative: whatever the decision, BLD and PRD should useconstruct for
closed-world negation would not make mush sense; hence the
same definition. *** Presentation syntax. Member ::= TERM ' # ' TERM Informal semantics.addition, wrt BLD, of the Membernon-monotonic (inflationary) negation
NmNot construct. This construct is usedspecific to represent predicates that are true iff therePRD.
A FORMULA can be a single ATOMIC statement. See specification of [ ATOMIC], above.
In RIF-PRD, an External represents an evaluated
predicate when it is a known classification accordingFORMULA (as opposed to which the argumenta
TERM; that is represented by the class TERM isis, in particular, when it appears in a classplace
where a FORMULA is required, and not a TERM).
The value or individualExternal element contains one content
element that is represented by the object TERM iscontains one Atom element:
<External> <content> Atom </content> </External>
Builtin predicates. RIF-PRD specifies a membersubset of
XPath/XQuery Functions and Operators [X F&O] that class. 2.1.2.5. Subclass In RIF,any
conformant RIF-PRD implementation MUST support. The Subclass element is used to represent class inclusion relations. *** Or shouldRIF-PRD have onlybuiltin
predicates are listed in the[ Data Types and Builtins]
document.
Editor's Note:
TBC how to reference non-builtin evaluated (builtin + application specific) subclass relations? *** XML syntax.predicates
The Subclass element contains two sub-elements:op TERM in the subClassAtom element must
berepresent a construct from the TERM abstract class. It is required as well; the class elementsconstant symbol of type rif:iri that must
be a construct fromuniquely identify the TERM abstract class.evaluated predicate to be applied to the
arg TERMs. It is required. <Subclass> <subClass> TERM </subClass> <class> TERM </class> </Subclass> *** Difference wrt RIF-BLD: BLD's lower and upper make more sense. I kept class forcan be one of the upper elementbuiltin predicates
specified for consistency withRIF-PRD, or it can be application specific. In the
Member element, and subClass seemmed to make more sense, associated with class than lower would. But, again, I am not religious about tags. Thislatter case, it is a proposed alternative: whateverup to the decision, BLDproducers and PRD should use the same definition. *** Presentation syntax. Subclass ::= TERM ' ## ' TERM Informalconsumers of RIF-PRD
rulesets that reference non-builtin predicates to agree on their
semantics.
Example. The Subclass construct is used to represent predicates that are true iff there isexample below shows the RIF XML
representation of a known classification according to whichboolean expression that tests whether the arguments representedvalue
denoted by variable ?a (e.g. the TERM s inage of a chicken) is
greater than the subClass and class sub-elements are both classes andinteger value 8, where the formertest is a sub-class ofintended to
behave like the latter. 2.1.2.6. Framebuiltin predicate op:numeric-greater-than
as specified in RIF,XQuery 1.0 and XPath 2.0
Functions and Operators.
Editor's Note:
What about the Frame construct is used to represent relations that hold between an individual, also called an object,namespace associated with the prefix op:?
<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 valueconjunction of onezero of its properties or attributes: that is, object-attribute-value triples. XML syntax. Accordingly, in its basic form,more
statements, each of them represented by a FrameFORMULA. This is
represented by the And construct.
The And element must contain: an object element, thatcontains an element of the TERM abstract class, the contentzero or more formula
elements, each containing an element of which representsthe individual; a slotKey element, that containsFORMULA
group.
<And> <formula> FORMULA </formula>* </And>
A Const element that representsFORMULA can represent the namedisjunction of zero of more
statements, each of them represented by a FORMULA. This is
represented by the attribute (or property); ***Or shouldconstruct.
The slotKeyOr element be allowed to contain any TERM instead? *** a slotValue element, thatcontains zero or more formula
elements, each containing an element of the TERM abstract class,FORMULA
group.
<Or> <formula> FORMULA </formula>* </Or>
A FORMULA can represent the contentnon-monotonic negation of which represents the attribute's value. *** Or should empty frames be allowed (and, thus, the slotKey-slotValue pair optional)? If yes: how to forbida
slotKey element withoutstatement, itself represented by a slotValue, or reciprocally, without breakingFORMULA: this is
represenetd by the striping? *** <Frame> <!-- Basic form --> <object> TERM </object> <slotKey> Const </slotKey> <slotValue> TERM </slotValue> </Frame> *** Difference wrt RIF-BLD: in RIF-BLD, a basic Frame has only two sub-elements: object and slot ; where slot has two contents:NmNot construct.
The key andNnNot element contains exactly one formula
element. The filler. Althoughformula element contains an element of the
XML syntax has not been discussed yet, I supposeFORMULA group, that represents the rationalenegated statement.
<NnNot> <formula> FORMULA </formula> </NmNot>
Editor's Note:
Difference wrt RIF-BLD: that construct is specific to preserveRIF-PRD. I
used a different name form the associationtwo kinds of the value to the key, but, on the other hand, it seemsnegations specified in
FLD (Not and Naf) for fear of snippers: naming remains to breakbe
discussed, anyway.
In RIF, the stripping. So, hereExists construct is used to represent an
alternative proposal, that preserve the stripping, but whereexistentially quantified FORMULA.
The associationExists element contains:
<Exists> <declare> Var </declare>+ <formula> FORMULA </formula> </Exists>
Example. The answer,example below shows the RIF XML
representation of a boolean expression that tests whether PRD and BLD should differ will be considered. *** *** Difference wrt RIF-BLD: Not sure aboutthe
semanticschicken denoted by variable ?c is older than 8 months, by
testing the existence of an empty Frame (no slot/value pair); and not surea value, denoted by variable ?a,
that it would beis both the sameage of ?c, as represented by a
Frame as in BLD and PRD. Hence the question. Not sure about PRDexample XX, and BLD differeng ongreater 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 one, either. *** However,section specifies the XML syntax of the Frame element allows alsothat is used in RIF-PRD to
represent compactlywhat can appear in the predicationaction part of multiple object-attribute-value triples fora rule supported by
RIF-PRD.
Editor's Note:
Difference wrt RIF-BLD: all the same object.constructs in that compact form, the frame element containsthis section are
specific to RIF-PRD.
Editor's Note: What about truth maintenance capabilities in many PR systems?
RIF-PRD defines one single object element and one or more ordered pairs of slotKey-slotValue elements. In addition, Frame elements can be nested,abstract class for actions:
ACTION, that is, a complete Frame elementis allowed asrealised 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 construct ofloop?
Editor's Note:
Except for the TERMdifferent names, the missing abstract class, a Member element, or a Subclass element; one or more ordered pair of a slotKey element,class that
must contain a Const element; *** Ditto: shouldgroups the slotKey element be allowedAssert, Remove and Update actions, and the possibility
to contain any TERM instead? ***Assign a slotValue element. The content of the slotValue element can bevalue to a construct of(ruleset) variable (which are not defined in
this draft), the TERMACTION abstract class or a Frame element.is copied from the pairs are not ordered, but within each pair,ImperativeExp
abstract class that specifies the order slotKey-slotValue MUST be preserved. <Frame> <!-- Complete specification --> <object> [ TERM | Member | Subclass ]</object> [ <slotKey> Const </slotKey> <slotValue> [ TERM | Frame ] </slotValue> ]+ </Frame> Presentation syntax. Frame ::= [TERM | Member | Subclass] 'actions in the OMG [ ' (Const ' -> ' (TERM | Frame))+ ' ] ' Informal semantics.PRR OCL]
specification.
The basic Framefollowing sections specify each construct is used to represent object-attribute-value triples that are true iff the individual that is representedseparately,
grouped by the TERM in the object sub-element of the Frameabstract syntactic classes. Each element is known to have the value represented by the TERMgiven an XML
syntax, in its slotValue sub-element forthe property, or attribute, represented byform of an informative BNF pseudo schema: the
Const in its slotKey sub-element. A nested or combined Frame is used to represent a statement thatnormative XML syntax is true if all the atomic statements represented by the ATOMIC s that are nested and combinedgiven in the Frame are true. 2.1.3. CONDITION[ RIF-PRD XML schema].
The CONDITIONACTION class of constructs is used to represent any truth-valued statement, atomic or not, that is allowedthe
individual actions in the conditionaction part of a production rule
covered by RIF-PRD.represented in rule languages covered by RIF-PRD, the truth valuesRIF-PRD.
This version of statements can be "true" or "false": that is, CONDITION s can only represent boolean statements. Dialects extendingRIF-PRD may support additional truth values. XML syntax.covers five ACTIONs:
Assert, Remove, Update, Execute
and Assign.
As an abstract class, CONDITIONACTION 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.
***[ATOMICAssert |AndRemove |OrUpdate |NafExecute |ExistsAssign ]
The Naf construct wrt BLD. ThisAssert construct is specificused to PRD. *** Presentation syntax. CONDITION ::= ATOMIC | And | Or | Naf | Exists 2.1.3.1. ATOMIC A CONDITION can be a singlerepresent actions that
result in asserting an atomic statement.
See specification of [ ATOMIC], above. 2.1.3.2. And A CONDITION can representThe conjunction of zero of more statements, each of them represented byAssert element has one target sub-element
that contains a CONDITION . This is represented byconstruct from the And construct. XML syntax.ATOMIC group, which
represents the And element contains zero or more formula elements, each containing an element ofatomic statement to be asserted on implementing the
CONDITION group. <And> <formula> CONDITION </formula>* </And> Presentation syntax. And ::= 'AND ( ' CONDITION* ' ) ' Informal semantics.action. The AndEqual construct is used to represent a statements that is true iff: it is an empty conjunction, represented bynot allowed as the
target of an emptyAssert
Editor's Note:
Are there other restrictions on the kind of ATOMIC that can be
Assert-ed? Shall we allow Member and element;Subclass ATOMICs to be
Assert-ed? Or allshould we make no restriction: the sub-statements represented byassertion 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 CONDITION s inright way to represent the And 's formula sub-elements are true. 2.1.3.3. Ortarget
anyway: what about the case where a CONDITION can representnew individual has to be
created? Use, by convention, the disjunction of zero of more statements, eachassertion of them represented byan anonymous frame
(that is, a CONDITION . Thisframe where the object is represented bythe name of a class, not an
individual)?
Editor's Note: Or
construct. XML syntax.remove the Or element contains zero or more formula elements, each containingAssert construct and interpret an element ofATOMIC as an ACTION as
an assert? That would improve PRD/BLD/Core compatibility at the
CONDITION group. <Or> <formula> CONDITION </formula>* </Or> Presentation syntax. Or ::= ' OR ( ' CONDITION* ' ) ' Informal semantics.synatctic level. What would be the Ordrawbacks?
<Assert> <target> ATOMIC </target> </Assert>
The Remove construct is used to represent a statements that is true iff: it is not an empty disjunction,actions that
is, if it has at least one non-empty formula sub-element; and at least one of the sub-statements represented by the CONDITION sresult in negating an atomic statement.
The Or 's formula sub-elements is true. 2.1.3.4. Naf A CONDITION can represent the non-monotonic negation of a statement, itself represented by a CONDITION : this is represenetd by the NAF construct. XML syntax. The NafRemove element contains exactlyhas one formula element. The formula elementtarget sub-element
that contains an element ofa construct from the CONDITION group,ATOMIC group that
represents the negated statement. <Naf> <formula> CONDITION </formula> </Naf> *** Difference wrt RIF-BLD: that construct is specificatomic statement to RIF-PRD. *** Presentation syntax. Naf ::= ' NAF ( ' CONDITION ' ) ' Informal semantics.be removed on implementing the
Naf construct is used to represent statements thataction.
Editor's Note:
Are true iff the statement represented bythere any restriction on the CONDITION formula is not known tokind of ATOMIC that can be
true. ***removed? E.g. what is the truth value of an empty NAF? *** 2.1.3.5. Exists *** is this needed in additionwould it mean to 2.1.4.2.? (Gary) ***remove an Equal?
Should we allow a CONDITION canMember or a Subclass ATOMIC to be Remove-ed?
Editor's Note:
Issue: ATOMIC might not be the right way to represent an existentially quantified formula ofthe CONDITION class: this is represented bytarget
anyway: e.g. how to Remove an individual (if empty Frames are not
allowed)?
<Remove> <target> ATOMIC </target> </Remove>
Editor's Note: Issue: How to remove multiple facts at once? E.g. Remove-ing an individual: use empty frames (if allowed) as a convention?
Example. The Exists construct. *** Difference wrt RIF-BLD:example below shows the notionRIF XML
representation of an aggregate variable is rather basic in production rule languages, much more than in logic languages, I guess. Therefore, due toaction that updates the different semantics of Var in BLD and PRD, aggregation should be at least considered for inclusion in PRD, even if it is not in BLD. See alsochicken-potato
ownership table by removing the remark underpredicate that states that the
specification of Exists, inchicken denoted by variable ?c owns the QUANTIFICATION Section, below. *** In addition of being a CONDITION , Exists is also a concrete construct ofpotato denoted by
variable ?p. The QUANTIFICATION class. Itpredicate is further specified under that class, below. 2.1.4. QUANTIFICATIONrepresented as in example
XX.
<Remove> <target> <Atom> <op> <Const type="rif:iri"> jim:owns </Const> </op> <arg> <Var> ?c </Var> </arg> <arg> <Var> ?p </Var> </arg> </Atom> </target> </Remove>
The QUANTIFICATION classUpdate construct is used to represent any quantified formulaactions that
is allowed in rules covered by RIF-PRD.result in rule languages covered by RIF-PRD, only existential quantification, represented byupdating an atomic statement.
The Exists construct, is allowed inUpdate element has one target sub-element
that contains a construct from the condition language. RIF-PRD allows universal quantification, represented byATOMIC group that
represents the Forall construct, only atatomic statement to be updated on implementing the
rule level [ Rule section]. Dialects extending RIF-PRD may supportaction.
<Update> <target> ATOMIC </target> </Update>
From the usespecification of these quantifiers in additional positions, as well as additional quantifiers.OMG PRR-OCL [ PRR]: "Some
operations modify the overall structurestate of objects and others do not. If the
syntax used to represent quantificationmodified objects are in RIF-PRD is depicted onthe following diagram. QUANTIFICATION is an abstract class: it is visible in RIF-PRD as either an Exists or a Forall . *** Difference wrt RIF-BLD:scope of the abstract QUANTIFICATION classengine, the engine must be
notified that the objects state has been added as a didactic device,modified to makebe able to
compute the specificationlist of aggregation easier.eligible rules. It might alsois not possible from the
operation call to determine automatically what objects will be
modified so it may be usefulnecessary in the rule to explicitly notify
the engine."
Editor's Note:
Issues: The Update as an extension point inaction is specific to some rule engine
technologies or implementations (e.g. RETE-based). Since it is
required by such implementations only because of the future. *** Allopaque nature
of the constructsExecute actions with respect to the modification of ATOMICs,
and since the QUANTIFICATION class share a common structure. They have: one or more declare sub-elements, each containing either: a Var element that represents onespecification of the quantified variables; or, if a quantified variable isprocedural attachments to be
bound toExecute-ed requires a specific interchange channel anyway
(as builtins or depending on an aggregate value,out-of-band agreement), should not
the information relevant to any ATOMIC impacted by an
Aggregation elementsExecute-ed procedure, and thus to required updates for
engines that representsuse them, rather be interchanged as part of the
quantified variablespecification of said procedures? And that specifies howUpdate not be covered by
RIF-PRD, as a consequence?
The aggregate valueExecute is computed; one required formula sub-elementused to represent actions that represents the formularesult in
the scopeexecution of a procedural attachment.
The quantifier. What is allowed asExecute element has one op sub-element
that represents the contentsymbol of the formula sub-element may dependprocedural attachement to be
executed on implementing the quantifier: RIF-PRD allows only a CONDITION as the formula inaction, followed by zero or more
arg sub-elements that represent its arguments:
Editor's Note: Or
should the scope ofop element be restricted to a Forall . In the following,Const instead?
Or another construct, depending onuse the External construct instead (AdrianP)? But how
about (i) the ambiguity with fixed interprestation predicates; (ii)
asserted ATOMICs if we handle extensibility inremove the XML schema. *** *** Difference wrt RIF-BLD: QUANTIFICATION couldAssert 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 omitted fromthe schema, if it does not seem useful as an extension point.application specific?
Example. The example below shows the RIF-PRD XML
representation of the action which execution results in that case,the
physical potato denoted by variable ?p being mashed,
following the specification of that classthe mash action in PRD would not add any concrete syntactic difference with BLD. If, onthe
other hand,example namespace denoted by the abstractprefix jim:.
<Execute> <op> <Const type="rif:iri"> jim:mash </Const> </op> <arg> <Var> ?p </Var> </arg> </Execute>
The Assign construct is considered useful, the proposal wouldused to include it in BLD's schema as well (not necessarily requiringrepresent actions that
the text be changed, though. *** [ Exists | Forall ] Presentation syntax. QUANTIFICATION ::= [ Exists | Forall ] 2.1.4.1. Aggregation The Aggregation construct is used to representresult in a variable that is to be bound to an aggregate value, and to specify how that aggregatevalue isbeing assigned to be computed. In RIF-PRD, it is associated with the quantification ofa variable. XML syntax.property of an
Aggregation element contains four required sub-elements:individual.
The bindsAssign element has one target sub-element
that contains a Var elementFrame that represents an
object-attribute-value, where the variable"value" has to be boundassigned to the
aggregate value; the aggregates sub-element contains a Var elements that represents the variable that is the target"attribute" of the aggregation;"object" on implementing the aggregationMode sub-element contains an element fromaction.
Editor's Note: Or
reuse the AGGREGATIONMODE class of constructs,Equal construct (AdranP)? But that represents the aggregation function towould be applied to the collection ofwith a
different semantics
Editor's Note:
How will values tobe aggregated; *** What areassigned to parameters (if and once we add
them)?
<Assign> <target> Frame </target> </Assign>
Example. The allowed AGGREGATIONMODEs? An enumerationexample below shows the RIF-PRD XML
represnetation of QNames, each identifying an aggregation mode, e.g. "collect", "sum", whatever; an ExtTerm , thus allowing arbitrary aggregation functions; both? In extensions, probably both; in RIF-PRD, only a (very) limited enumeration? ***the pattern sub-element contains an element fromaction that increases by 10% the CONDITION classvalue of constructs, that represents a condition onthe
binding valuesdaily grain allowance of the targetchicken 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 variableforbeingtakenintoaccountintheaggregation.***Thepatternsub-elementhastoberequiredinRIF-PRD,sincethedialectdoescompute 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 allowjust accessors à la Frame...
This section specifies the direct typing of variables... *** <Aggregation> <binds> Var </binds> <aggregationMode> AGGREGATIONMODE </aggregationMode> <aggregates> Var </aggregates> <pattern> CONDITION </pattern> </Aggregation> *** Difference wrt RIF-BLD:RIF-PRD constructs that construct is specificare required,
in addition to RIF-PRD. *** Presentation syntax.the first Var represents[ RIF-PRD condition language] and the variable[ RIF-PRD
action language], to be bound; that is, the content of the binds sub-element of the Aggregation element. The second Var represents the target of the aggregation; that is, the content of the aggregates sub-element of the Aggregation element. Aggregation ::= Var ' : ' AGGREGATIONMODE Var ' SUCH THAT ( ' CONDITION ' ) ' Informal semantics.represent, and interchange, complete
production rules and rule sets.
The AggregationRULE construct is used to indicated that the variable thatan abstract class: in RIF-PRD
instance documents, it is represented byeither visible as a
ConditionalStatement or as a Forall:
Editor's Note:
Difference wrt RIF-BLD: The binds VarConditionalStatement is to be bound to a single value that aggregates allthe
accepted binding valuesImplies construct of a target variable, represented byRIF-BLD. However, the aggregates Var , that verifyword "Implies"
does not carry the condition represented byappropriate meaning for RIF-PRD. The pattern CONDITION , subjectproposal is
to rename the bindings of anyImplies in RIF-BLD (to ConditionalStatement
or whatever other variablesname that are referenced in the condition. The aggregationMode sub-elementis used to indicate how the binding values of the target variableprefered) so that satisfy the condition are to be aggregated. This version ofRIF-BLD and
RIF-PRD covers a single aggregation mode: collect , wherecan inherit the binding values ofsame construct from Core?
The binds Var . ***RuleSet construct has zero or do we want amore open classconstructs of
aggregation modes? *** 2.1.4.2. Exists A QUANTIFICATION can represent an existentially quantified formula: this is represented bythe Exists construct. RIF-PRD covers existentially quantified formulae of the CONDITION class only. XML syntax.RULE group associated as rules.
Editor's Note: Do we need ruleset parameters, etc?
The Exists element contains: one or more declare elements,following sections specify each construct separately,
grouped by abstract syntactic classes. Each containing either: a Varelement that represent one of the existentially quantified variable; or, if an existentially quantified variableis to be bound togiven an aggregate value,XML
syntax, in the form of an Aggregation elements that representsinformative BNF pseudo schema: the
quantified variable and that specifies hownormative XML syntax is given in the aggregate value[ RIF-PRD XML schema].
In RIF-PRD, the RULE class of constructs is computed; exactly one formula elementused to
represent rules, that containsis "if-then" statements, possibly universally
quantified.
As an element ofabstract class, RULE is not associated with
specific XML markup in RIF-PRD instance documents. It is specified
in the CONDITIONnormative schema as a substitution group.
Editor's Note:
...Substitution group that represents the formulaor another construct, depending on how we
handle extensibility in the scope of the quantifier. <Exists> <declare>XML schema.
[VarConditionalStatement |AggregationForall ]
</declare>+ <formula> CONDITION </formula> </Exists> ***Editor's Note:
Difference wrt RIF-BLD: The choice betweenFORMULA is optional in a Var and and Aggregation for the contentConditionalStatement,
but a list of ACTIONS with a declaretrivially satisfied FORMULA is specific to RIF-PRD. *** Presentation syntax. Exists ::= ' EXISTS ' [ Var | Aggregation ]+ ' ( ' CONDITION ' ) ' Informal semantics.not the
Exists construct is usedsame, conceptually, as a head without a body in a logic program
(e.g. it does not belong to represent statements that are true iff there is at least one combination of bindings ofthe variables represented infact base). Thus, the Exists 's declare sub-elements, that makesrationale for
making the statement represented byhead-without-a-body a different kind of RULE does not
apply in the CONDITION formula true. 2.1.4.3. ForallRIF-PRD case. ISSUE: how does Core represent a QUANTIFICATION canfact?
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
an universally quantified formula: thisthe conditional statement (that is, the "if-then", or
condition-conclusion, or antecedent-consequent pair) that is represented byat the
Forall construct. RIF-PRD covers universally quantified formulaecore of a rule.
The RULEConditionalStatement element contains zero or one
if sub-element and one then sub-element:
Editor's Note:
Should we have an ATOMIC"else"-part, in which alladdition to the TERM are Const s.if-part and the
WM is assumed to represent explicitely, inthen-part? On the formone hand, it is one of ground ATOMIC s, allthe relevant information and knowledge that is available torationale for
separating the consumer of a RIF-PRD instance document, including, in particular, ground equality, membership and subclass relations, as well asvariable binding patterns FORMULAe from the specification of all evaluated functions and predicates. *** Must be more specific aboutif-part
FORMULA; on the semantics of Equal, Member and Subclass, e.g. that Equal is a relation of equivalence, Subclass a pre-order etc. But also wrtother hand, what MUST be equal, e.g. litterals that map to the same value inis the value space, objects that havesupport for it among the
same address etc (or require that a specific equality predicate be define ofr each different equality relation); dittorule languages RIF-PRD aims to cover?
<ConditionalStatement> <if> FORMULA </if>? <then> ACTION ACTION* </then> </ConditionalStatement>
Editor's Note:
Difference wrt Member, Subclass. *** More specifically,RIF-BLD: the content of the WMthen element is
assumedspecific to contain, for each tuple of constant arguments in an evaluated function's domain, an Equal ATOMIC where oneRIF-PRD (but PRD and BLD share the structure of the
side sub-elements containsconstruct).
The ground ExtTerm thatForall construct is used to represent universally
quantified rules.
The application of that function toForall element contains:
<Forall> <declare> Var </declare>+ <pattern> FORMULA </pattern>* <formula> RULE </formula> </Forall>
Editor's Note:
Difference wrt RIF-BLD: the operational semantics forForall in RIF-PRD CONDITION s that is specified below, and subject to a consistent translation of the specified data sources.adds, wrt BLD, the
following sections specifypattern sub-element to associate FORMULAs to the normative operational semanticsdeclared
Vars. One of each construct separately, grouped by abstract syntactic classes. 2.2.2. TERMthe operational semantics of TERM s specifies how arbitrary TERM s match Const s.rationale for the sectionsPattern sub-element is
to allow "if-then-else" rules. Both differences are specific to
RIF-PRD.
Example. The exmaple below specifiesshows the operational semanticsRIF-PRD XML
representation of the constructsa simplified version of the TERM class, where they have one. 2.2.2.1. ConstCMP rule that reads:
except on Tuesdays, every potato thet belongs to a Const matches itselfchicken is
mashed, and any other Const to which itthe ownership table is equal,updated, or
Forall ?c, wheretwoConstc_1andc_2areequalifthere?c is agroundjim:Chicken Forall ?p, where ?p is a jim:Potato and owns(?c ?p) If Not( jim:today() equalATOMICintheWMsuchthatc_1mactchestheConstcontentofoneofthesidesub-elements"Tueday" Then mash(?p) andc_2matchesremove (?c ?p) from theConstownership table.
Some tags and content ofare emphasized (bold-face) for readibility
in the other side sub-element. 2.2.2.2. Var A binding associates a Var to a ConstXML fragment below. . A bound Var matches any Const thatThe Const to which it is bound matches. An unbound Var does not have an operational semanticscomplete RIF-PRD XML
representation of the CMP rule can be found in RIF-PRD. *** What happens when[ 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> <Remove> <target> <Atom> <op> <Const type="rif:iri"> jim:owns </Const> </op> <arg> <Var> ?c </Var> </arg> <arg> <Var> ?p </Var> </arg> </Atom> </target> </Remove> </then> </ConditionalStatement> </formula> </Forall> </formula> </Forall>
The RuleSet construct is used to represent a Var "does notset of
rules that have an operational semantics in RIF-PRD"? *** *** Binding Varsto Vars? (AdrianP) *** 2.2.2.3. ExtTermbe considered together from a semantic or
operational viewpoint (e.g. a knowledge base, a rule base, a
ruleset).
The semantics ofRuleSet element contains zero or more rule
element. Each rule element contains an ExtTerm TERM is determined byelement from the
specificationRULE group of the evaluated function that is identified by a Constconstructs that represents one of the TERMrules
contained in the op sub-element matches. Therefore, an ExtTerm TERM t matches any Construle set.
Editor's Note:
Shouldn't that matchesbe "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 Const containedRuleSet construct does not exist
in one side sub-element of an Equal ATOMIC whereBLD, although its grouping capability can be represented by the
other side sub-element containsGroup construct. However, production rule systems use the
ruleset as a ground ExtTerm t_g such that:first-class construct, passing parameters and scoping
local variables.
This section specifies a presentation syntax for RIF-PRD. The
TERM content ofpresentation syntax is not normative: its main purpose is to help
make the op sub-elementnormative specification of t matches any Const that matchesthe Const content ofsemantics easier to
read.
The op sub-element of t_g ; andpresentation syntax is specified by the TERM contentfollowing EBNF,
directly in terms of eachnames of the arg sub-elements of t matches any Const that matches the Const content ofXML elements specified in the
same position arg sub-element of t_g . An ExtTerm TERM does not have an operational semanticsprevious sections (and, normatively, in RIF-PRD if:the TERM content of one of its sub-elements does not have an operational semantics[ XML schema for
RIF-PRD]. Where elements with the same name are used in RIF-PRD; or it does not match any Const accordingdifferent
context with different content, which would lead to ambiguous
productions, the above definition. *** The implication being that, eitherambiguous name has been appended to a
disambiguating, context-specific prefix: namely, the op does not match any known evaluated predicate, or onename of the
arguments if out ofcontaining element. Specifically, the predicate's domain *** *** What happens when a TERM "does not have an operational semanticstarget role in RIF-PRD"? *** 2.2.3. ATOMIC The operational semantics of ATOMIC s specifiesthe
truth value of arbitrary ATOMIC with respectAssign production (and element) has been renamed
assign_target to the WM by specifying how arbitrary ATOMIC s match ground ATOMIC s: an arbitrary ATOMIC is true iffdifferenciate it matches a ground ATOMICfrom the WM . The sections below specifies the operational semantics of the constructstarget
role of other ACTION elements, and the ATOMIC class, where they have one. 2.2.3.1. Uniterm An Uniterm matches any ground Uniterm such that:formula
role in the Forall production has been renamed
forall_formula.
TERMcontentoftheopsub-elementofthematchingUnitermmatchesany::= Constthatmatchesthe| Var | External Constcontentofthe::= LITERAL '^^' type ('@' xml:lang)? LITERAL ::= any Unicode string type ::= IRI xml:lang ::= xs:language Var ::= xs:NMTOKEN External ::= ' External( ' opsub-elementofthegroundUniterm;andthe' ( ' arg* ' )) ' op ::= TERMcontentofeachoftheargsub-elementsofthematchingUnitermmatchesanyConstthatmatchestheConstcontentoftheargsub-elementwiththesamepositionintheorderedlistofthegroundUniterm'sargsub-elements.AnUnitermdoesnothaveanoperationalsemanticsinRIF-PRDiftheTERMcontentofoneofitssub-elementsdoesnothaveanoperationalsemanticsinRIF-PRD.***WhathappenswhenanUniterm"doesnothaveanoperationalsemanticsinRIF-PRD"?***AnUnitermistrueiffitmatchesagroundUnitermfromtheWM.2.2.3.2.ExtTermThesemanticsofanExtTerm ATOMICisdeterminedbythespecificationoftheevaluatedpredicatethatisidentifiedbyaConstthattheTERMintheopsub-elementmatches.Therefore,anATOMIC ExtermmatchesanygroundATOMIC Extermsuchthat:the::= TERM
contentoftheopsub-elementofthematchingExtTermmatchesanyConstthatmatchestheConstcontentoftheATOMIC ::= Atom | Equal | Member | Subclass | Frame Atom ::= opsub-elementofthegroundExtTerm;andthe' ( ' arg* ' ) ' Equal ::= side ' = ' side side ::= TERMcontentofeachoftheargsub-elementsofthematchingExtTermmatchesanyConstthatmatchestheConstcontentoftheargsub-elementwiththesamepositionintheorderedlistofthegroundExtTerm'sargsub-elements.AnATOMIC ExtTermdoesnothaveanoperationalsemanticsinRIF-PRDif:theMember ::= object ' # ' class object ::= TERMcontentofoneofitssub-elementsdoesnothaveanoperationalsemanticsinRIF-PRD;oritdoesnotmatchanygroundATOMIC ExtTermintheWMnoranygroundATOMIC ExtTermsub-elementoftheNotelementintheWM.***Theimplicationbeingthat,eithertheopdoesnotmatchanyknownevaluatedfunction,oroneoftheargumentsifoutofthefunction'sdomain******WhathappenswhenanExtTerm"doesnothaveanoperationalsemanticsinRIF-PRD"?***AnExtTermistrueiffitmatchesagroundExtTermfromtheWM.2.2.3.3.EqualAnEqualmatchesanygroundEqualsuchthattheTERMcontentofoneofthematchingEqual'ssidesub-elementsmatchesanyConstthatmatchestheConstcontentofoneofthegroundEqual'ssidesub-elementsandtheTERMcontentoftheothermatchingEqual'ssidesub-elementmatchesanyConstthatmatchestheConstcontentoftheothergroundEqual'ssidesub-element.AnEqualdoesnothaveanoperationalsemanticsinRIF-PRDiftheTERMcontentofoneofitssub-elementsdoesnothaveanoperationalsemanticsinRIF-PRD.***WhathappenswhenanEqual"doesnothaveanoperationalsemanticsinRIF-PRD"?***AnEqualistrueiffitmatchesagroundEqualfromtheWM.2.2.3.4.MemberAMembermatchesanygroundMembersuchthattheTERMcontentofthematchingMember'sobjectsub-elementmatchesanyConstthatmatchestheConstcontentofthegroundMember'sobjectsub-elementandtheTERMcontentofthematchingMember'sclasssub-elementmatchesanyConstthatmatchestheConstcontentofthegroundMember'sclasssub-element.AMemberdoesnothaveanoperationalsemanticsinRIF-PRDiftheTERMcontentofoneofitssub-elementsdoesnothaveanoperationalsemanticsinRIF-PRD.***WhathappenswhenanMember"doesnothaveanoperationalsemanticsinRIF-PRD"?***AMemberistrueiffitmatchesagroundMemberfromtheWM.2.2.3.5.SubclassASubclassmatchesanygroundSubclasssuchthattheTERMcontentofthematchingSubclass'ssubClasssub-elementmatchesanyConstthatmatchestheConstcontentofthegroundSubclass'ssubClasssub-elementandtheTERMcontentofthematchingSubclass'sclasssub-elementmatchesanyConstthatmatchestheConstcontentofthegroundSubclass'sclasssub-element.AnSubclassdoesnothaveanoperationalsemanticsinRIF-PRDiftheTERMcontentofoneofitssub-elementsdoesnothaveanoperationalsemanticsinRIF-PRD.***WhathappenswhenanSubclass"doesnothaveanoperationalsemanticsinRIF-PRD"?***ASubclassistrueiffitmatchesagroundSubclassfromtheWM.2.2.3.6.FrameAbasicFramematchesanygroundbasicFramesuchthattheTERMcontentsofthematchingFrame'sobject,slotKeyandslotValuesub-elementsmatchanyConstthatmatchtheConstcontentsof,respectively,thegroundFrame'sobject,slotKeyandslotValuesub-elements.AbasicFramedoesnothaveanoperationalsemanticsinRIF-PRDiftheTERMcontentofoneofitssub-elementsdoesnothaveanoperationalsemanticsinRIF-PRD.AbasicFrameistrueiffitmatchesagroundFramefromtheWM.Unnestingframes.ThesemanticsofanestedorcombinedFrameisspecifiedrecusively,basedonthesemanticsofitscomponents:AFramewithmultipleslotKey-slotValuepairsistrueiffalltheFramesformedwiththesameobjectsub-elementandeachoftheslotKey-slotValuepairsaretrue.AFramewheretheobjectelementcontainsaMemberelementistrueifftheMemberelementistrueandtheFrameelementwiththecontentoftheobjectelementreplacedwiththecontentoftheMember'sobjectsub-elementistrue.AFramewheretheobjectelementcontainsaSubclasselementistrueifftheSubclasselementistrueandtheFrameelementwiththecontentoftheobjectelementreplacedwiththecontentoftheSubclass'ssubClasssub-elementistrue.AFramewhereaslotValuesub-elementcontainsaFrameistrueifftheFrameintheslotValueelementistrueandtheenclosingFrameistruewiththecontentoftheslotValuesub-elementreplacedby:thecontentoftheobjectsub-elementoftheenclosedFrame,ifitisaTERM;thecontentoftheMember'sobjectsub-element,iftheobjectsub-elementoftheenclosedFramecontainsaMemberelement;thecontentoftheSubclass'ssubClasssub-element,iftheobjectsub-elementoftheenclosedFramecontainsaSubclasselement;AnestedFramedoesnothaveanoperationalsemanticsinRIF-PRDifoneofitscomponentATOMICsdoesnothaveanoperationalsemanticsinRIF-PRD.***WhathappenswhenaFrame"doesnothaveanoperationalsemanticsinRIF-PRD"?***2.2.4.CONDITIONTheoperationalsemanticsofCONDITIONsspecifiesthetruthvalueofarbitraryCONDITIONs,basedonthetruthvaluesofitscomponentATOMICs.ACONDITIONdoesnothaveanoperationalsemanticsinRIF-PRDifoneofitscomponentATOMICsdoesnothaveanoperationalsemanticsinRIF-PRD.***WhathappenswhenaCONDITION"doesnothaveanoperationalsemanticsinRIF-PRD"?***ThesectionsbelowspecifiestheoperationalsemanticsoftheconstructsoftheCONDITIONclass,wheretheyhaveone.2.2.4.1.ATOMICAnATOMIC CONDITIONistrueiffitmatchesagroundATOMICfromtheWM.2.2.4.2.AndAnAnd CONDITIONistrueiffithasnoformulasub-elementoralltheCONDITIONsinitsformulasub-elementsaretrue.Unnestingframes.AnestedFrameelementcanalwaysbereplacedbyanAndelementwheretheconjoinedformulasarethebasicFrameand,possibly,Memberelementsobtainedwhenunnestingit.Reciprocally,conjunctsformulasinanAndelementcanbecombinedintoanestedorcombinedFrameelementasfollows:Iffthecontentoftheobjectsub-elementofaFrameelementisaTERManditissyntacticallyidenticaltotheTERMcontentoftheobjectsub-elementofaMemberelement,theMemberandFrameelementscanbereplacedbyasinglecombinedFrameelementwherethecontentoftheobjectsub-elementoftheFramehasbeenreplacedbytheMemberelement;Iffthecontentoftheobjectsub-elementofaFrameelementisaTERManditissyntacticallyidenticaltotheTERMcontentofthesubClasssub-elementofaSubclasselement,theSubclassandFrameelementscanbereplacedbyasinglecombinedFrameelementwherethecontentoftheobjectsub-elementoftheFramehasbeenreplacedbytheSubclasselement;IffthecontentofaslotValuesub-elementofaFrameisaTERMthatissyntacticallyidenticaltotheTERMcontentoftheobjectsub-elementofanotherFrame,thetwoFrameelementscanbereplacedbyasinglenestedelementwherethelatterFramereplacesthecontentoftheslotValuesub-elementintheformerFrame;IffthecontentofaslotValuesub-elementofaFrameisaTERMthatissyntacticallyidenticaltotheTERMcontentoftheobjectsub-elementoftheMemberelementthatisthecontentoftheobjectsub-elementofanotherFrame,thetwoFrameelementscanbereplacedbyasinglenestedelementwherethelatterFramereplacesthecontentoftheslotValuesub-elementintheformerFrame;IffthecontentofaslotValuesub-elementofaFrameisaTERMthatissyntacticallyidenticaltotheTERMcontentofthesubClasssub-elementoftheSubclasselementthatisthecontentoftheobjectsub-elementofanotherFrame,thetwoFrameelementscanbereplacedbyasinglenestedelementwherethelatterFramereplacesthecontentoftheslotValuesub-elementintheformerFrame;TwoFrameelementscanbereplacedbyasingleFramethatcombinestheirslotKey-slotValuepairsofsub-elementsiff:theobjectsub-elementsofFramesaresyntacticallyidentical:theobjectsub-elementofoneoftheoriginalFramescontainsaTERMandtheobjectsub-elementoftheotheronecontainsaMemberelementandthecontentoftheobjectsub-elementofthatMemberissyntacticallyidenticaltothatTERM.Inthatcase,theMemberelementbecomesthecontentoftheobjectsub-elementoftheresultingcombinedFrame;theobjectsub-elementofoneoftheoriginalFramescontainsaTERMandtheobjectsub-elementoftheotheronecontainsaSubclasselementandthecontentofthesubClasssub-elementofthatSubclassissyntacticallyidenticaltothatTERM.Inthatcase,theSubclasselementbecomesthecontentoftheobjectsub-elementoftheresultingcombinedFrame.2.2.4.3.OrAnOr CONDITIONistrueiffithasatleastoneformulasub-elementandtheCONDITIONinatleastoneofitsformulasub-elementsistrue.2.2.4.4.NafANaf CONDITIONistrueifftheCONDITIONinitsformulasub-elementisnottrue,butdoeshaveanoperationalsemanticsinRIF-PRD.2.2.4.5.ExistsAnExists CONDITIONistrueiffithasatleastoneinstanceandatleastoneofitsinstancesistrue.ThenotionsofinstanceisspecifictotheconstructsoftheQUANTIFICATIONclass,towhichtheExistselementbelongsaswell.Itisfurtherspecifiedunderthatclass,below.2.2.5.QUANTIFICATIONTheoperationalsemanticsofQUANTIFICATIONsspecifiesthenotionofinstanceofaformula,basedonthenotionsoftheacceptedbindingsofaVarandofacombinationofbindingsofasetofVars,andontheoperationalsemanticsoftheAggregationconstruct.Varbinding.Asalreadydefinedearlier,abindingofaVaristheassociationofthatVarandaConst.OnlyboundVarshaveanoperationalsemanticsinRIF-PRDand,asaconsequence,anyconstructthatcontainsaVarhasanoperationalsemanticsonlywhenthatVarisbound.Inthefollowing,aVarissaidtobedeclaredbyaQUANTIFICATIONifitiseither:thecontentofadeclaresub-elementofthatQUANTIFICATION;orthecontentofthebindssub-elementofanAggregationelementthatisthecontentofadeclaresub-elementoftheQUANTIFICATION.AVarisdeclaredbyanAggregationifitisthecontentoftheaggregatessub-elementofthatAggregation.Varsaredeclaredforthepurposeofbinding:allthesub-elementsoftheconstructwhereitisdeclared,andonlythoseelements,areinthescopeofaVar'sbinding.Candidateandacceptedbindings.AnyConstthatcanbefoundintheWMisacandidatebindingforanyVar.ConstructsthatdeclareVarsmayallowtherepresentationofadditionalconditionsonthebindingsofthedeclaredVars.ThecandidatebindingsforaVarthatsatisfytheseadditionalconditionsarecalled,forthepurposeofthisspecification:acceptedbindings.Intheabsenceofsuchadditionalconditions,anycandidatebindingforaVarisalsoanacceptedbindingforthatVar.InthisversionofRIF-PRD,theconstructsthatallowtherepresentationofsuchadditionalconditionsonthebindingsofaVarthattheydeclareare,exclusively:theForallQUANTIFICATION,thatwillbefurtherspecifiedinthe[Rulesection];andtheAggregationconstruct,whereanadditionalconditiononthebindingsoftheVarthatisdeclaredbytheAggregation(thatis,theVarcontentoftheAggregation'saggregatessub-element)isrepresentedbytheCONDITIONcontentoftheAggregation'spatternsub-element.TheacceptedbindingsfortheVarthatisdeclaredbyanAggregationarethosepossiblebindingsoftheVarthatmaketruetheCONDITIONcontentoftheAggregation'spatternsub-element,subjecttothebindingsofanyotherVarinthatCONDITIONthataredeclaredbyanenclosingconstruct,ifany.TheacceptedbindingsforaVarthatisdeclaredbyanExistsare,therefore,allthecandidatebindingsforthoseVars.***Thelattersentenceisnotmeanttoimplythatimplementationsmustactuallyconsiderorhavethecapabilitytobindanyvariabletoanyconstantinthespecifieddatasource(s);butratherthatitmustnotconsiderbindingstoconstantsthatarenotinthedatasources(andthusnotmatchable),provided,ofcourse,thatitconsidersatleastallthebindingsthatwouldsatisfytheformula(thusnotmissinganysuccessfulmatch).Shouldthatbemadeexplicitinthetext?***AVarthatisdeclaredbyaQUANTIFICATIONasthecontentofthebindssub-elementofanAggregationelementthatiscontainedinthedeclaresub-elementofaQUANTIFICATIONhasonesinglecandidatebinding,calledanaggregatebinding,thatisthesinglevaluecomputedbytheaggregationfunctionthatisspecifiedbythecontentoftheAggregation'saggregationModesub-element,appliedtothesetoftheacceptedbindingsoftheVarcontentoftheAggregation'saggregatessub-element.***Acandidateaggregatebindingiscomputedbyaggregationoftheacceptedbindingsoftheaggregation'stargetvariable.Thatcandidateaggregatebindingisanacceptedaggregatebindingiffitmakesanyadditionalconditionstrue,thatmaybesetbytheQUANTIFICATIONthatdeclarestheaggregateVar.Isthatclearorshoulditbemadeexplict?***Combinationofbindings.AcombinationofbindingsforasetofVarsisanelementofthecartesianproductofthesetsofthebindingsconsideredforeachVarintheset.***ForthedeterminationofthesetofVarstobebound,twosyntacticallyidenticalVararethesameVar,eveniftheyarecontainedintwodifferentdeclares.Shouldthatbemadeexplicitinthetext?***AcombinationofacceptedbindingsforasetofVarsisacombinationofbindingstakenfromthecombinationsofalltheacceptedbindingsforeachoftheVarsintheset.***So,acombinationofacceptedbindingscontainsoneandonlyonebindingforeachoftheVarintheconsideredset;andthesetofthecombinationsofacceptedbindingsisemptyifoneoftheVarsdoesnothaveanyacceptedbinding.Isthatobvious,orshoulditbemadeexplicit?***Instancesofaformula.AninstanceofaQUANTIFICATIONQisdefinedrecursivelyastheassociationtoaninstanceoftheformulathatiscontainedintheformulasub-elementofQ,forthepurposeoftruthvaluation,ofacombinationofacceptedbindingsforthesetoftheVarsthataredeclaredbyQ,possiblyappendedtothecombinationofbindingsthatisassociatedtoQ,ifQiswithinthescopeofsomeVarsbinding(e.g.ifitisitselftheformulacontainedintheformulasub-elementofanenclosingQUANTIFICATIONbeinginstantiated).AninstanceofaformulathatisnotaQUANTIFICATIONistheformulaitself.AQUANTIFICATIONdoesnothaveanyinstanceisoneoftheVarsthatitdeclaresdoesnothaveanyacceptedbinding,oriftheformulacontainedinitsformulasub-elementdoesnothaveanyinstance.Twoinstancesaresaidtobeequalifftheirformulaaresyntacticallyidentical,andtheassociatedcombinationsofbindingscontainbindingsforthesamesetofVars,andtheConsttowhichanyVarisboundinoneinstancematchestheConsttowhichitisboundintheotherinstance.AninstanceofaformuladoesnothaveanoperationalsemanticsinRIF-PRDifthecombinationofacceptedbindingscontainsmorethanonebindingforthesameVar.***OristhereanotherwayweshoulddealwiththatcasewhenaVarisredeclaredbyaconstructthatiswithinthescopeofanotherconstructthatalreadydeclaredthatVar?***3.Actions(Editor'sNote:ThistextismaintainedonwikipageActions).TheRIF-PRDactionlanguagedetermineswhatcanappearintheactionpartinarulesupportedbyRIF-PRD.Inthefirstpartofthissection,thesyntaxofRIF-PRDactionlanguageisspecifiednon-normatively:thenormativereferencefortheXMLsyntaxisthe[XMLschema].Inthesecondpart,thenormativesemanticsofRIF-PRDactionlanguageisspecified.***DifferencewrtRIF-BLD:alltheconstructsinthissectionarespecifictoRIF-PRD.******WhatabouttruthmaintenancecapabilitiesinmanyPRsystems***3.1.SyntaxTheoverallstructureofthesyntaxusedintheRIF-PRDactionlanguageisdepictedonthefollowingdiagram.***Exceptforthedifferentnames,themissingabstractclassthatgroupstheAssert,RemoveandUpdateactions,andthepossibilitytoAssignavaluetoa(ruleset)variable(whicharenotdefinedinthisdraft),theACTIONabstractclassiscopiedfromtheImperativeExpabstractclassthatspecifiestheactionsintheOMG[PRROCL]specification.***RIF-PRDdefinesonesingleabstractclassforactions:ACTION,thatisrealisedbyfiveconcreteconstructs:theAssert,RemoveandUpdateconstructsareassociatedwithanATOMICthatrepresentsthetargetoftheeponymactions;theExecuteconstructisassociatedwithaTERMthatidentifiestheoperationtobeexecuted,andzeroormoreTERMsthatrepresenttheargumentswithwhichtheoperationistobeexecuted;theAssignconstructisassociatedwithaFramethatrepresentsthetargetobjectandslot,aswellasthenewvaluetobeassigned.***ShouldotheractionsbeconsideredinRIF-PRD?Esp.,doweneedsomebasicprogramaticconstructs,suchasaloop?***Thefollowingsectionsspecifyeachconstructseparately,groupedbyabstractsyntacticclasses.EachelementisgivenanXMLsyntax,intheformofaBNFpseudoschema;apresentationsyntax,intheformofanEBNFproduction;andaninformalsemantics.Noneoftheseisnormative:thenormativeXMLsyntaxisgiveninthe[RIF-PRDXMLschema]andthenormativesemanticsisgiveninthesection[Operationalsemantics].3.1.1.ACTIONTheACTIONclassofconstructsisusedtorepresenttheactionsthatareintendedasaconsequenceoffiringaproductionrule.ThisversionofRIF-PRDcoversfiveACTIONs:Assert,Remove,Update,ExecuteandAssign.XMLSyntax.Asanabstractclass,ACTIONisnotassociatedwithspecificXMLmarkupinRIF-PRDinstancedocuments.Itisspecifiedinthenormativeschemaasasubstitutiongroup.***...Substitutiongrouporanotherconstruct,dependingonhowwehandleextensibilityintheXMLschema.***[Assert|Remove|Update|Execute|Assign]Presentationsyntax.ACTION::=Assert|Remove|Update|Execute|Assign3.1.1.1.AssertTheAssertconstructisusedtorepresentactionsthatresultinassertinganatomicstatement.XMLSyntax.TheAssertelementhasonetargetsub-elementthatcontainsaconstructfromtheATOMICgroup,whichrepresentstheatomicstatementtobeassertedonimplementingtheaction.***ArethereanyrestrictiononthekindofATOMICthatcanbeAssert-ed?E.g.whatwoulditmeantoAssertanEqualoranExtTerm?ShallweallowMemberandSubclassATOMICstobeAssert-ed?******Issues:ATOMICmightnotbetherightwaytorepresentthetargetanyway:whataboutthecasewhereanewindividualhastobecreated?Use,byconvention,theassertionofananonymousframe(thatis,aframewheretheobjectisthenameofaclass,notanindividual)?******OrremovetheAssertconstructandinterpretanATOMICasanACTIONasanassert?ThatwouldimprovePRD/BLD/Corecompatibilityatthesynatcticlevel.Whatwouldbethedrawbacks?***<Assert><target>ATOMIC</target></Assert>Presentationsyntax.Assert::='ASSERT('ATOMIC')'Informalsemantics.TheAssertcontructisusedtorepresentactionsthatresultisanatomicstatement,representedbytheATOMICcontentoftheAssert'stargetsub-element,beingtrue;andthathavenoeffectifthatatomicstatementwasalreadytruebeforetheaction.***WhataboutnestedFrames,iftheyareallowedasatargetATOMIC?***3.1.1.2.RemoveTheRemoveconstructisusedtorepresentactionsthatresultinnegatinganatomicstatement.XMLSyntax.TheRemoveelementhasonetargetsub-elementthatcontainsaconstructfromtheATOMICgroupthatrepresentstheatomicstatementtoberemovedonimplementingtheaction.***ArethereanyrestrictiononthekindofATOMICthatcanberemoved?E.g.whatwoulditmeantoremoveanEqualoranExtTerm?ShouldweallowaMemberoraSubclassATOMICtobeRemove-ed?******Issue:ATOMICmightnotbetherightwaytorepresentthetargetanyway:e.g.howtoRemoveanindividual(ifemptyFramesarenotallowed)?***<Remove><target>ATOMIC</target></Remove>Presentationsyntax.Remove::='REMOVE('ATOMIC')'Informalsemantics.TheRemovecontructisusedtorepresentactionsthatresultisanatomicstatement,representedbytheATOMICcontentoftheRemove'stargetsub-element,notbeingtrueanymore;andthathavenoeffectifthatatomicstatementwasnottruebeforetheaction.***Issue:Howtoremovemultiplefactsatonce?E.g.Remove-inganindividual:useemptyframes(ifallowed)asaconvention?******WhataboutnestedFrames,iftheyareallowedasatargetATOMIC?***3.1.1.3.UpdateTheUpdateconstructisusedtorepresentactionsthatresultinupdatinganatomicstatement.XMLSyntax.TheUpdateelementhasonetargetsub-elementthatcontainsaconstructfromtheATOMICgroupthatrepresentstheatomicstatementtobeupdatedonimplementingtheaction.<Update><target>ATOMIC</target></Update>Presentationsyntax.Update::='UPDATE('ATOMIC')'Informalsemantics.FromthespecificationofOMGPRR-OCL[PRR]:"Someoperationsmodifythestateofobjectsandothersdonot.Ifthemodifiedobjectsareinthescopeoftheengine,theenginemustbenotifiedthattheobjectsstatehasbeenmodifiedtobeabletocomputethelistofeligiblerules.Itisnotpossiblefromtheoperationcalltodetermineautomaticallywhatobjectswillbemodifiedsoitmaybenecessaryintheruletoexplicitlynotifytheengine."***Issues:TheUpdateasanactionisspecifictosomeruleenginetechnologiesorimplementations(e.g.RETE-based).SinceitisrequiredbysuchimplementationsonlybecauseoftheopaquenatureoftheExecuteactionswithrespecttothemodificationofATOMICs,andsincethespecificationoftheproceduralattachmentstobeExecute-edrequiresaspecificinterchangechannelanyway(asbuiltinsordependingonanout-of-bandagreement),shouldnottheinformationrelevanttoanyATOMICimpactedbyanExecute-edprocedure,andthustorequiredupdatesforenginesthatusethem,ratherbeinterchangedaspartofthespecificationofsaidprocedures?AndUpdatenotbecoveredbyRIF-PRD,asaconsequence?******WhataboutnestedFrames,iftheyareallowedasatargetATOMIC?***3.1.1.4.ExecuteTheExecuteisusedtorepresentactionsthatresultintheexecutionofaproceduralattachment.XMLSyntax.TheExecuteelementhasoneopsub-elementthatrepresentsthesymboloftheproceduralattachementtobeexecutedonimplementingtheaction,followedbyzeroormoreargsub-elementsthatrepresentitsarguments:ThecontentoftheopelementmustbeaconstructoftheTERMabstractclass;***OrshouldtheopelementberestrictedtoaConstinstead?***ThecontentoftheargelementsmustbeconstructsfromtheTERMabstractclass.TheorderoftheargelementsissignificantandMUSTbepreserved.***OrusetheExtTermconstructinstead(AdrianP)?Buthowabout(i)theamiguitywithfixedinterprestationpredicates;(ii)assertedATOMICsifweremovetheAssertconstruct?***<Execute><op>TERM</op><arg>TERM</arg>*</Execute>Presentationsyntax.Execute::='EXECUTE{'op'('arg*')}'Builtinoperations.TBD***ShouldRIF-PRDhavebuiltinexecutableoperations(e.g.etc)orshouldtheybelefttobetheapplicationspecific?***Informalsemantics.TheExecutecontructisusedtorepresentactionsthatresultintheexecutionaproceduralattachement,identifiedbytheTERMcontentiftheExecute'sopsub-elementandappliedtotheargumentsrepresentedbytheTERMcontentofitsargsub-elements,ifany.Thevaluethatresultsfromexecutingtheproceduralattachment,ifany,islost,sothatonlythepossibleside-effectshaveanimpact.Resultingchangesmayormaynotimpactthetruthvalueofotherstatements.ThesemanticsoftheproceduralattachmentsisalwaysspecifiedoutsideofaRIFinstancedocumentwheretheyappear.Theop TERMmustrepresentaconstantsymboloftyperif:irithatmustuniquelyidentifytheoperationtobeappliedtothearg TERMs.ItcanbeoneofthebuiltinoperationsspecifiedforRIF-PRD,oritcanbeapplicationspecific.Inthelattercase,itisuptotheproducersandconsumersofRIF-PRDrulesetsthatreferencenon-builtinoperationstoagreeontheirsemantics.Argumentsoutofthedomainofdefinition.Anoperationcanbesuccessfullyexecutedonlyifitsargumentsarewithintheoperation'sdomainofdefinition.Forargumentsoutofitsdomainofdefinition,theresultofexecutinganoperationisnotdefined.RIF-PRDdoesnotspecifyanyexpectedbehaviourforthatcase:itistheresponsibilityoftheconsummerofaRIF-PRDrulesettoknowtheexpectedbehaviourortohandletheerror.3.1.1.5.AssignTheAssignconstructisusedtorepresentactionsthatresultinavaluebeingassignedtoapropertyofanindividual.XMLSyntax.TheAssignelementhasonetargetsub-elementthatcontainsaFramethatrepresentsanobject-attribute-value,wherethe"value"hastobeassignedtothe"attribute"ofthe"object"onimplementingtheaction.***Onlybasicframesshouldbeallowed,right?******OrreusetheEqualconstruct(AdranP)?Butthatwouldbewithadifferentsemantics******Howwillvaluesbeassignedtoparameters(ifandonceweaddthem)?***<Assign><target>Frame</target></Assign>Presentationsyntax.Assign::='SET('Frame'])'Informalsemantics.TheAssigncontructisusedtorepresentactionsthatresultinassigningavaluetoagivenpropertyofagivenindividual,asrepresentedbytheFramecontentoftheAssign'stargetsub-element,replacingthepreviousone,ifany;andthathavenoeffectotherwise.Inotherterms,therepresentedactionresultsintheatomicstatementrepresentedbytheFramecontentoftheAssign'stargetsub-elementbeingtrue,andinanyconflictingatomicstatementaboutthevalueofthesamepropertyforthesameindividualnotbeingtrueanymore.***AssignisequivalenttoRemove-ingtheFramewiththepreviousvalueandAssert-ingthetargetFrameinstead,exceptthatyoudonothavetocareaboutrepresentingthepreviousvalue,right?******Whatiftheindividualdoesnotexist?IstheAssign-ementequivalenttoAssert-ingthetargetFrame,orisitano-op?******Whatiftheindividualhasseveralvaluesfortheproperty?***3.2.Operationalsemantics3.2.1.DatasourcesTheoperationalsemanticsoftheACTIONconstructsisspecifiedwithrespecttothestateofthespecifieddatasources(orfactbase)aftertheactionstheyrepresenthavebeenimplemented.ForthepurposeofspecifyingtheoperationalsemanticsofRIF-PRD,thedatasourcesareconsideredcollectivelytobeacollectionofgroundATOMICsnamedWM:asspecifiedinsection[operationalsemanticsofCONDITIONs],theWMisassumedtorepresentexplicitely,intheformofgroundATOMICs,alltherelevantinformationandknowledgethatisavailabletotheconsumerofaRIF-PRDinstancedocument.Inparticular,theWMisassumedtocontainaspecialExecutableelement,defined,forthepurposeofspecifyingtheoperationalsemanticsoftheRIF-PRDactionlanguageonly,tocontainthesetofgroundExecutestatements,wheretheConstcontentoftheopandargssub-elementsrepresenta(ground)proceduralattachmentsthathasasemantics.***Howdowereferencedatasources?Atwhatlevel:ATOMIC?CONDITION/ACTION?RULE?RuleSet?RIFinstancedocument?***ImplementorsareresponsibleformakingsurethattheRIF-PRDtranslationofactionstatementspreservestheirnativesemantics,accordingtotheoperationalsemanticsforRIF-PRDACTIONsthatisspecifiedbelow,andsubjecttoaconsistenttranslationofthespecifieddatasources.ConformantimplementationsMUSTtranslateACTIONsretrievedfromRIF-PRDinsuchawaythattheirnativeevaluationagainstthespecifieddatasourcespreservestheirsemantics,accordingtotheoperationalsemanticsforRIF-PRDACTIONsthatisspecifiedbelow,andsubjecttoaconsistenttranslationofthespecifieddatasources.Thefollowingsectionsspecifythenormativeoperationalsemanticsofeachconstructseparately,groupedbyabstractsyntacticclasses.3.2.2.ACTIONThesectionsbelowspecifiestheoperationalsemanticsoftheconstructsoftheACTIONclass,wheretheyhaveone.AnACTIONdoesnothaveanoperationalsemanticsinRIF-PRDifanyofitssub-elementdoesnothaveanoperationalsemanticsinRIF-PRD.***WhathappenswhenaACTION"doesnothaveanoperationalsemanticsinRIF-PRD"?***AnACTIONthatdoesnothaveanoperationalsemanticsinRIF-PRDcannotbesuccessfullyimplemented.3.2.2.1.AssertThesuccessfulimplementationofanAssert ACTIONresultsintheATOMICcontentofitstargetsub-elementbeingtrue.3.2.2.2.RemoveThesuccessfulimplementationofaRemove ACTIONresultstheATOMICcontentofitstargetsub-elementnotbeingtrue.3.2.2.3.UpdateThesuccessfulimplementationofanUpdate ACTIONresultsinTBD3.2.2.4.ExecuteAnExecuteelementEmatchesagroundExecutesub-elementE_gintheExecutableelementoftheWMiff:theTERMcontentoftheopsub-elementofEmatchesanyConstthatmatchestheConstcontentoftheopsub-elementofE_g;andtheTERMcontentofeachoftheargsub-elementsofEmatchesanyConstthatmatchestheConstcontentofthesamepositionargsub-elementofE_g.AnExecuteelementthatdoesnotmatchagroundExecutesub-elementintheExecutableelementoftheWMdoesnothaveanoperationalsemanticsinRIF-PRD.ThesuccessfulimplementationofanExecute ACTIONresultsintheoperationexecutedbytheConstcontentofopsub-elementofthegroundExecutesub-elementoftheExecutableelementoftheWMthattheExecute ACTIONmatchesbeingexecutedwiththeargumentsrepresentedbytheTERMcontentofitsargsub-elements.***...thatis,iftheACTIONhasasemantics,ofcourse:shouldthatbesaidexplicitelyagain?***ThesuccessfulimplementationofanExecute ACTIONmayormaynothaveside-effectsthatmayormaynotresultinchangesintheWM:theeffectsthatareintendedfromtheexecutionofRIF-PRDbuiltinopérationsarespecifiedin[thesectionwherethearespecified].ItistheresponsibilityoftheconsumerofaRIF-PRDinstancedocumenttoknowwhataretheintendedeffectsofexecutingapplication-specificoperations.3.2.2.5.AssignThesuccessfulimplementationofanAssign ACTIONresultsin:theFramecontainedinitstargetsub-elementbeingtrue;andanyFramebeingfalse,ifthecontentofitsobjectandslotKeysub-elementsmatch,respectively,ConststhatmatchthesameConstsasthecontentoftheobjectandslotKeysub-elementsoftheFramecontentoftheAssign'starget,andthecontentofitsslotValuesub-elementmatchesaConstthattheslotValuesub-elementoftheFramecontentoftheAssign'stargetdoesnotmatch.***Theoptiontakenhereisthat,iftheobjectofthetargetFramedoesnotexist,theAssignfunctionsasanAssert:isthattheusualinterpretation?******ThesecondbulletmustberemovedifFramesareallowedmultipleslotValuesforthesameslotKey.***4.ProductionRules(Editor'sNote:ThistextismaintainedonwikipageProductionRules).ThissectionspecifiestheRIF-PRDconstructsthatarerequired,inadditiontothe[RIF-PRDconditionlanguage]andthe[RIF-PRDactionlanguage],torepresent,andinterchange,completeproductionrulesandrulesets.Inthefirstpartofthissection,thesyntaxthatisusedtorepresentproductionrulesandrulesetsispresentednon-normatively:thenormativereferencefortheXMLsyntaxisthe[XMLschema].Inthesecondpart,thenormativesemanticsforRIF-PRDrulesandrulesetsisspecified.4.1.SyntaxTheoverallstructureofthesyntaxusedtorepresentproductionrulesandrulesetsinRIF-PRDisdepictedonthefollowingdiagram.TheRULEconstructisanabstractclass:inRIF-PRDinstancedocuments,itiseithervisibleasaConditionalStatementorasaForall:TheConditionalStatementassociatesanoptionalCONDITIONandonenon-emptyorderedlistofACTIONS.***DifferencewrtRIF-BLD:TheConditionalStatementistheImpliesconstructofRIF-BLD.However,theword"Implies"doesnotcarrytheappropriatemeaningforRIF-PRD.TheproposalistorenametheImpliesinRIF-BLD(toConditionalStatementorwhateverothernamethatisprefered)sothatRIF-BLDandRIF-PRDcaninheritthesameconstructfromCore?***TheForallconstructdeclaresoneormoreVars,possibllyusingtheAggregationconstruct,andassociatesthemwithzeroormoreCONDITIONs,aspatternsthatconstrainthebindingsofthevariables,andwithoneRULEastheformulainitsscope.TheRuleSetconstructhaszeroormoreconstructsoftheRULEgroupassociatedasrules.***Doweneedrulesetparameters,etc?***Thefollowingsectionsspecifyeachconstructseparately,groupedbyabstractsyntacticclasses.EachelementisgivenanXMLsyntax,intheformofaBNFpseudoschema;apresentationsyntax,intheformofanEBNFproduction;andaninformalsemantics.Noneoftheseisnormative:thenormativeXMLsyntaxisgiveninthe::= TERM Subclass ::= subClass ' ## ' class subClass ::= TERM Frame ::= object ' [RIF-PRDXMLschema]' (key ' -> ' val)* ' ] ' key ::= TERM val ::= TERM
FORMULA ::= ATOMIC | External | Andthenormativesemanticsisgiveninthesection[Operationalsemantics].4.1.1.RULEInRIF-PRD,theRULEclassofconstructsisusedtorepresentrules,thatis"if-then"statements,possiblyuniversallyquantified.XMLsyntax.Asanabstractclass,RULEisnotassociatedwithspecificXMLmarkupinRIF-PRDinstancedocuments.Itisspecifiedinthenormativeschemaasasubstitutiongroup.***...Substitutiongroup| Oranotherconstruct,dependingonhowwehandleextensibilityintheXMLschema.***[ConditionalStatement|Forall]***DifferencewrtRIF-BLD:TheCONDITIONisoptionalinaConditionalStatement,butalistofACTIONSwithatriviallysatisfiedCONDITIONisnotthesame,conceptually,asaheadwithoutabodyinalogicprogram(e.g.itdoesnotbelongtothefactbase).Thus,therationaleformakingthehead-without-a-bodyadifferentkindofRULEdoesnotapplyintheRIF-PRDcase.ISSUE:howdoesCorerepresentafact?FromtheanswertothatquestiondependswhetherPRDNaf | Exists AndBLDmaydifferonthis;preferably,theyshould::= 'AND ( ' formula* ' ) ' formula ::= FORMULA Or ::= 'OR ( ' formula* ' ) ' NmNot ::= ' NOTdiffer.***Presentationsyntax.( ' formula ' ) ' Exists ::= ' Exists ' declare+ ' ( ' formula ' ) ' declare ::= Var
ACTION ::= Assert | Remove | Update | Execute | Assign Assert ::= ' ASSERT ( ' target ' ) ' target ::= ATOMIC Remove ::= ' REMOVE ( ' target ' ) ' Update ::= ' UPDATE ( ' target ' ) ' Execute ::= ' EXECUTE { ' op ' ( ' arg* ' ) } ' Assign ::= ' SET ( ' assign_target ' ] ) ' assign_target ::= Frame
RULE ::= ConditionalStatement | Forall4.1.1.1.ConditionalStatementTheConditionalStatementconstructisusedtorepresenttheconditionalstatement(thatis,the"if-then",orcondition-conclusion,orantecedent-consequentpair)thatisatthecoreofarule.XMLsyntax.TheConditionalStatementelementcontainszeroorone::= (' IFsub-elementandone' if ' THEN ')? thensub-element:theoptionalifelementcontainsanelementfromtheCONDITIONclassofconstructs;therequired::= FORMULA thenelementcontainsanon-emptylistofelementsfromtheACTIONclassofconstructs.Theorderofthe::= ACTIONconstructsinthethenelementissignificantandMUSTbepreserved.***Shouldwehavean"else"-part,inadditiontotheif-partandthethen-part?Ontheonehand,itisoneoftherationaleforseparatingthevariablebindingpatternsCONDITIONsfromtheif-partCONDITION;ontheotherhand,whatisthesupportforitamongthe(' ; ' ACTION)* Forall ::= ' Forall ' declare+ (' SUCH THAT ' pattern)* ' ( ' forall_formula ' ) ' pattern ::= FORMULA forall_formula ::= RULElanguagesRIF-PRDaimstocover?***<ConditionalStatement><if>CONDITION</if>?<then>ACTIONACTION*</then></ConditionalStatement>***DifferencewrtRIF-BLD:RuleSet ::= 'RULESET ( ' rule* ' ) ' rule ::= RULE
Example. The content ofexample below shows the then element is specific toRIF-PRD (but PRD and BLD sharepresentation
syntax for the structuresimplified version of the construct). ***CMP rule shown in example
XX. The RIF-PRD presentation syntax. ConditionalStatement ::= ('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'CONDITION'NOT( jim:today^^rif:iri() = "Tuesday"^^jim:DayOfTheWeek ) THEN')?ACTIONSACTIONS::=ACTION(';'ACTION)*Informalsemantics.EXECUTE( jim:mash^^rif:iri(?p) ); REMOVE( jim:owns^^rif:iri(?c ?p) ) ) )
For the ConditionalStatementpurpose of specifying the semantics of a RIF-PRD
RuleSet, a production rule system PRS is used to representdefined as a
conditional statementlabelled terminal transition system (e.g. Plo04).
Definition (labelled terminal transition system): A labelled terminal transition system is a structure {Γ, L, →, T}, where
A truth valuation of ConditionalStatementslabelled transition system is used here for compatibility with RIF Core. Ina pure production rule context, "is true" could be informally translated by "has been successfully implemented" when applied tostructure {Γ, L,
→} (without a ConditianlStatement *** 4.1.1.2. Forallset T of final configurations).
The Forall constructidea of describing a PRS as a labelled terminal transition
system is used to represent universally quantified rules. In addition to beingthat, given a constructset of the RULE class, Forall is alsoproduction rules RS and a constructset
of facts w0, the QUANTIFICATION class: it inherits the syntactic featuresrules in RS that are
common to that class, as specifiedsatisfied, in some sense, in w0 determine an
action α1, which execution results in [ section QUANTIFICATION]. XML syntax. The Forall element contains: one or more declare sub-elements, each containing either:a Var element that represent onenew set
of facts w1; the universally quantified variable; or, ifrules in RS that are
satisfied in w1 determine an universally quantified variable is to be boundaction
α2 to an aggregate value, an Aggregation elements that representsexecute in w1, and so on,
until the quantified variablesystem reaches a final configuration and that specifies howstops. The
aggregate valueresult is computed; exactly one formula sub-element that representsthe formula in the scopeset of facts wn when the quantifiersystem
stops.
Example. Judicael, one follower of Jim the Hen Handler's
method, has four chicken, Jim, Jack, Joe and Julia, that contains an element of the RULE group; zero or more pattern sub-elements, each containing an element fromown three
potatoes (BigPotato, SmallPotato, UglyPotato) among them:
That represent a constraint onis the bindingsinitial set of facts w0. Paula's
rule set contains one of the Var ssingle rule, that are declared by the Forall . <Forall> <formula> CONDITION </formula> <declare> [ Var | Aggregation ] </declare>+ <pattern> CONDITION </pattern>* </Forall> *** Formula sub-element first to facilitate processing of nested Forallsis, Jim's CMP rule:
When the rule content ofis applied to w0:
Suppose that Judicael's implementation of today() returns
Monday and that the variables declared byfoxAlarm() is false when
the Forall that verifyCMP rule is applied: the condition content ofis satisfied, and the
pattern sub-elements, if any. ***actions in the notion of a truth valuation of rulesconclusion are executed with BigPotato
substituted for ?p and Foralls is used hereJim substituted for compatibility with RIF Core.?c.
This results in the following changes in a pure production rule context, "is true" could be informally translated by "has been successfully implemented" when applied to a rule or a Forall. *** 4.1.2. RuleSetthe RuleSet construct is used to represent aset of rules that have to be considered together from a semantic or operational viewpoint (e.g. a knowledge base, a rule base, a ruleset). XML syntax. The RuleSet element contains zero or more rule element. Each rule element contains an elementfacts:
The RULE contentresulting set of all its rule sub-elementsfacts w1 is true. *** the notion of a truth valuation of RuleSetsthus:
When the CMP rule in a pure productionapplied 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 context, "is true" couldcannot be informally translated by "has been successfully implemented" when applied tosatisfied, and the
system, having detected a RuleSet . *** 4.2. Operational semanticsfinal configuration, stops.
The operational semanticsresult of RULE s and ` RuleSetsthe execution of the system is
specified,w1.
Let Const be the set of constant symbols that can be
represented in RIF-PRD, based onas determined by the operational semanticsthe specification of
the condition language, as specifiedConst construct; Var, the set of variable
symbols that can be represented in [ section Operational semanticsRIF-PRD, as determined by the
specification of the condition language],Var construct; and ofTerm the
action language, as specified in [ section Operational semantcsiset of action language. Implementors are responsible for making sureterms that can be represented in RIF-PRD, as determined by
the RIF-PRD translationthe specification of rulesthe TERM class of constructs. A
substitution and rulesets preserves their native semantics, accordingthe composition of substitutions are
defined as usual (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 operational semantics for RIF-PRD RULE sset
{?x ∈ Var | ?x ≠ σ(?x)} is finite. This
set is called the domain of σ and RuleSet s thatdenoted by Dom(σ). Such a
substitution is specified below,also written as a set such as σ =
{ti/?xi}i=1..n where
Dom(σ) = {?xi}i=1..n and
subjectσ(?xi) = ti for i = 1 to
n.
Given X, a consistent translationset of the specified data sources. Conformant implementations MUST translate RULE svariables, and RuleSet s retrieved from RIF-PRD in suchσ, a waysubstitution such
that their native evaluation againstX ⊆ Dom(σ), σX denotes, in
this document, the specified data sources preserves their semantics, accordingrestriction of σ to the operational semantics for RIF-PRD RULE svariables in X:
σX = {σ(?x)/?x | ?x ∈ X}.
Definition (composition of substitutions): Given two
substitutions σ = {ti/?xi},
i = 1..n, and RuleSet s thatθ =
{sj/?yj}, j = 1..m,
their composition σθ is specified below, and subject to a consistent translation ofthe specified data sources.substitution which yields the following sections specifysame
result on all terms as first applying σ then applying θ on the
normative operational semantics of each construct separately, grouped by abstract syntactic classes. 4.2.1. RULEresult.
Given two substitutions σ and θ, and a construct of the RULE class does not have an operational semantics if oneset of its components does not have an operational semantics. *** What happens when a RULE "does not have an operational semanticsvariables
V, θ(σ\V) denote, in RIF-PRD"? ***this document, the sections below specifiessubstitution
θ(σ\V) = {θ(?x)/?x | ∀ ?x ∈ V} ∪ {σ(?x)/?x |
∀ ?x ∉ V}.
Let TermΣ be the operational semanticsset of ground terms (that can
be represented in RIF-PRD), defined as usual:
By convention, a ConditionalStatementground External term is true iff any of the followingalways evaluated
and replaced by a constant symbol that represents its value.
Definition (ground substitution): A ground
substitution is true:a substitution σ such that ∀ ?x ∈
Dom(σ), σ(?x) ∈ TermΣ.
The CONDITION contentfunction Var(e) that maps a RIF-PRD element e
to the set of its free or universally quantified variables is
defined as usual:
Definition (rule instance): An instance of a Var declared byrule
r is a Forall are: all its candidate bindingscouple (rid, as specified in [ section Candidate and accepted bindings], if the Forall does not have any pattern sub-element or if none of the Forall 's pattern sub-elements contains the Var ; or those candidate bindings that make true the CONDITION content of all the Forall 's pattern sub-elements that contain the Varσ), possibly subject to the bindings associated to the Forall for Var s declared by enclosing QUANTIFICATION s. ***where
rid uniquely identifies r and σ is a
CONDITION patternground substitution such that constrain the binding ofVar(r) ⊆ Dom(σ). Given
a Var cannot contain another Var declared by the same Forall, since the latter is not bound (andrule r, id(r) denotes rid, the CONDITION, therefore, does not haveunique
identifier of r; given a semantics). Does that follow fromrule instance ri =
(rid, σ), rule(ri) denotes the above specification or shouldrule that be specified explicitely? *** *** The rationale for attaching 'pattern's to the Forall for constraining the bindings of variables instead of having all the conditions conjoined in the if-partis
support for if-then-else or even more complex constructs in future versions/extensions of RIF-PRD; and of sequential modesuniquely identified by rid.
Definition (ruleset instance): an instance of ruleset evaluation *** 4.2.2. RuleSet Except if thea rule content of oneset
RS is a set of itsrule sub-elements does not have an operational semantics in RIF-PRD, in which case it does not have an operational semantics in RIF-PRD itself,instances rii, where ∀
i, rule(rii) ∈ RS. Given a RuleSet is true iff: it does not contain anyrule sub-element; or orset
RS, Inst(RS) denotes the RULE contentset of all its rule sub-elements is true. *** What happens when a RuleSet "does not have an operational semanticsthe possible
instances of RS.
Let W be the set of ground formulas that can be
represented in RIF-PRD"? ***RIF-PRD, defined as usual:
Editor's Note:
..or W could be defined, except for the purpose of specifying the operational semantics of a RuleSetExists, as
an ordered list of pairs, each composed of an instance of a RULE and a mark that can be: true or firable . Inference cycle.the inference cycle isset of the processformulas f such that determinesVar(f) = {}?
Let L be the truth value of every instancesset of the RULE content of each rule sub-element ofatomic ground actions that can be
represented in RIF-PRD:
Editor's Note:
The definition of an instance being fired mayL is subject to change when the ACTIONs
will be specified more precisely.
Finally, let R be the set of all the instances ofrules that can be
represented in RIF-PRD.
In this document, given a set X, P(X) denotes the
RULE content of one or morepower set of X, and S(X) denotes the RuleSet 's rule sub-elements. For the purposeset of specifyingthe
ordered lists of elements of X.
The inference cycletransition relation →RIF-PRD ⊆
P(W) × L × P(W) is defined in three steps: Update agenda: The RULE content of each ofas follows:
The rule sub-elementsintended semantics of the RuleSet are instantiated as specifiedactions that can be represented in
[ section Instances of a formula] and [ section Forall],RIF-PRD is completely specified by the CONDITION contentdefinition of the if sub-element oflabelled
transition system {P(W), L,
→RIF-PRD}.
Editor's Note:
The ConditionalStatement partdefinition of allW would need to be modified if we wanted
to cover non-ground facts as well, but the resulting instances is evaluated, anddefinition of the
Agenda is updated accordingly. To updaterelation would remain essentially the Agenda , each instance i resulting fromsame.
The instantiation is compared withrelation →*RIF-PRD ⊆
P(W) × S(L) × P(W) denote the instance parttransitive
closure of the elements in the Agendatransition relation
→RIF-PRD.
Assuming a function INSTANTIATE: if there is an element i_a in the Agenda with an instance part that is equal to iP(W) ×
P(R) → P(Inst(R)), that, given a set of facts and if the CONDITION contenta
set of rules, returns a set of the if sub-elementinstances of the ConditionalStatement partrules, let
ΓRS be a set of iconfigurations, where a configuration is
false, the element i_aa triple γ = (w, h, INSTANTIATE(w, RS)), where w ⊆ W
is removed from the Agenda ; if the instance parta set of no element in the Agendafacts, h ∈ S(ΓRS - γ) is equal to ian ordered
list of configurations that does not contain γ itself, and ifRS ⊆
R is a rule set.
Given a configuration γ = (w, h, a), let w(γ)
denote the CONDITION content offirst element, the if sub-elementset of facts w, and let
h(γ) denote the ConditionalStatement partsecond element, the history h.
Assuming two more functions:
a RIF-PRD prduction rule system is defined as a labelled terminal transition system where:
Or, using →*RS to denote the
then sub-elementtransitive closure of the ConditionalStatement parttransition relations:
The intended operational semantics of a production ruleset
represented by a RIF-PRD RuleSet RS is, therefore,
completely specified by the instance are implemented inspecification of the specified order withthree functions
INSTANTIATE, PICK and FINAL.
Editor's Note: to
be developed: explain, by reference to the associated Var bindings, if any. Afterusual description of a
PRS as a match-resolve conflict-fire cycle, why 3 functions
instead of only PICK and final if allempty pick.
The ACTION s have been implemented successfully,evaluation of the instancefunction INSTANTIATE corresponds to
the step that is marked trueoften called matching in the Agenda (replacingdescription of
production rule systems (e.g. PRR07).
Indeed, the function is most easily specified using the firable mark). 5. Compatibility with other RIF dialects (Editor's Note: This textwidely
spread notion of pattern matching. The following definition
is maintained on wiki page Compatibilityadapted 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 other RIF dialects ). 5.1. RIF-Core 5.1.1.respect to a RIF-Core strawman The syntaxtheory τ and a ground
substitution σ, denoted σ(p) «τ w, iff one of the
condition language for RIF-Corefollowing is true:
A set P of RIF-PRD FORMULAe is the syntaxsaid to match a
set w ∈ W of RULEground RIF-PRD ATOMICs with respect to
a theory τ and RuleSet sa ground substitution σ, denoted σ(P)
«τ w, iff σ(pi) «τ w
for RIF-BLD.all pi ∈ P.
Editor's Note:
The Semantics of RIF-Coredefinition is easily, if tediously, extended to cover the semanticscase
of RIF-BLD, withmatching arbitrary FORMULAe against any set of ground FORMULAe ⊆
W.
Editor's Note:
The restrictionmatching theory tau; to be taken into account includes the
syntax of the condition language applied, except forequality theory defined between frames, the semantics ofbuiltin datatypes,
functions and relations, and any externally defined datatypes,
classification theory, functions and relations as required by the
Equal construct that hasruleset. This is to be appropriately restrictedfurther specified when references to
matchapplication-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 and a rule, returns a set of
instances of RIF-PRD. *** Alternatively,the Equal construct in RIF-PRDrule.
The evaluation of InstantiateRULE(w, r), where w ⊆
W and r ∈ R, is renamed, RIF-Core hasspecified as a terminal
transition system where:
Given a rule r ∈ R, let Σr
denote the set of the RIF-Core defined inrestrictions to Var(r) of all the
previous section: Any RIF-PRD RuleSetsubtitutions σ such that contains no Naf nor Aggregation elements and whereVar(r) ⊆ Dom(σ):
Σr = {σVar(r) | ∀ σ, Var(r) ⊆
Dom(σ)}.
The output function is defined as:
Editor's Note:
There are certainly more elegant ways to RIF-Core by: replacingmake sure that all the
CONDITION contentpossible instances have been found... Suggestion, anyone?
Editor's Note: To
Be Added: textual explanation of the ConditionalStatement contained in each rule element by anrules and that containsthe said CONDITION as well asTTS.
Example. TBD
The CONDITION contentevaluation of any pattern that might be associated to a Forall contained intothe same rule element;function INSTANTIATE(w, RS), where
w ⊆ W and removing the AssertRS ⊆ R, can now be specified
as a simple terminal transition system where:
The RuleSet Based on [ Vianu's paper on rule-based languages], it should be easy thatinput function is defined as:
The result setoutput function is defined as:
Editor's Note: To
Be Added: textual explanation of RIF-Core rules hasthe same semantics asrules and the original set of RIF-PRD rules; Any RIF-Core RuleSet canTTS (esp. re its
confluence).
Example. TBD
TBD (default for 1st WD could be converted into a semantically equivalent RIF-PRD RuleSet by wrappingto return the ATOMIC contentinstantiate
then-part of the then -part of eachfirst, or a random, rule instance in
an Assert and a target element. 6. Glossary (Editor's Note: This textINSTANTIATE(w, RS), after refraction).
TBD (default for 1st WD is maintained on wiki pagelikely to be when INSTANTIATE(w, RS)
is empty after refraction = PICK return an empty list of
actions).
TBD