May Be Superseded
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
Set of Documents This document is being published as one of a set of 6 documents: RIF Use Cases and Requirements RIF Basic Logic Dialect RIF Framework for Logic Dialects RIF RDF and OWL Compatibility RIF Production Rule Dialect (this document) RIF Data Types and Built-InsPlease Comment By 2008-06-132008-07-07
The Rule Interchange Format (RIF) Working Group seeks
public feedback on these Working Drafts. Please send your
comments to public-rif-comments@w3.org (public archive). If possible, please offer
specific changes to the text that would address your
concern. You may also wish to check the Wiki
Version of this document for internal-review comments and changes being
drafted which may address your concerns.
No Endorsement
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Patents
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Overview
1.1 Introduction
This document specifies the production rule dialect of the W3C
rule interchange format (RIF-PRD). ItProduction rules are rules with
an "if" part and a "then" part. The "if" part, also called a
"condition", is mostly intendedlike the condition part of logic rules (as covered
by the basic logic dialect of the W3C rule interchange format,
RIF-BLD). The "then"
part of production rules may contain actions, unlike the conclusion
of logic rules that may contain only a logical statement. Actions
can modify the knowledge base and have other side-effects.
Example 1.1. A customer becomes a "Gold" customer as
soon as his cumulative purchases during the current year top
$5000; Customers that become "Gold" customers must be
notified immediately, and a golden customer card will be printed
and sent to them within one week; For shopping carts worth
more than $1000, "Gold" customers receive an additional discount of
10% of the designerstotal amount are all examples of RIF-PRD implementations.production
rules.
As a common XML serialisation format for many production rule
languages, RIF-PRD specifies an XML syntax for the most widely used
features (section [ Syntax]),(section 2 - Syntax),
and the operational semantics that RIF-PRD constructs are intended
to represent (section [(section 3 -
Operational semantics]).semantics).
This document is mostly intended for the designers and
developers of RIF-PRD implementations, that is, applications that
serialize production rules are rules where the partas RIF-PRD XML (producer applications)
and/or that describesdeserialize RIF-PRD XML documents into production rules
(consumer applications).
Editor's Note:
This working draft specifies the consequence of condition being satisfied specifies actions rather than logical statements. Production rules, in general, are not amenable to a model theory and, followingly, the intended semantics of rules and set of rules serialized as RIF-PRD is specified operationally, in this document. Editor's Note: This working draft specifies the RIF-PRD serialisationRIF-PRD serialisation of a set of
core constructs only. Future versions of this document will extend
the set of RIF-PRD constructs to cover the most widely used
features of production rule languages. The working group seeks
feedback on what features should be supported by RIF-PRD and what
constructs should or should not be required from conformant RIF-PRD
implementations.
As a RIF dialect, RIF-PRD has also been designed to maximise
inter-operabilityinteroperability between rule languages over the World Wide Web. In
this draft, this is achieved by sharing the same XMLsyntax for the
subset of RIF documents where the semantics intended for a
production ruleset serialised in the production rule dialect of RIF,RIF-PRD, and the semantics
intended for a logic rule base serialised in the basic logic
dialect of RIF, RIF-BLD,RIF-BLD, agree. The correspondancecorrespondence between RIF-PRD and
RIF-BLD is detailleddetailed
in [Appendix: Compatibility
with RIF-BLD].RIF-BLD.
Editor's Note:
Future versions of this working draft will draw on other RIF
documents to maximise inter-operabilityinteroperability with otheother rule languages,
most noticeably the RIF data types and builtins specification (RIF-DTB)specification,
RIF-DTB, and the RIF
extensibility framework (currently being specified by the working
group; see also the RIF framework for logic dialects (RIF-FLD)dialects, RIF-FLD, that specifies a
framework for designing RIF logic dialects).
1.2 Notational conventions 1.2.1 Namespaces Throughout this document, the xsd: prefix stands for the XML Schema namespace URI http://www.w3.org/2001/XMLSchema# ,In the rdf: prefix stands for http://www.w3.org/1999/02/22-rdf-syntax-ns#section 2, and rif: standstwo
related but distinct syntaxes for RIF-PRD components are
introduced:
- XML syntax. This syntax is the
URInormative XML
serialization of the RIF namespace, http://www.w3.org/2007/rif# . Syntax such as xsd:string should be understoodRIF-PRD. It is meant, and has been designed, to
work as a compact uri -- a macro that expandscommon XML serialisation for many production rule
languages. It is also meant, and has been designed, to work as a
concatenation of the character sequence denoted by the prefix xsd and the string string . The compact URI notation is usedcommon XML serialisation for brevity only,production rule languages and xsd:string should be understood, in this document,logic
rule languages, wherever they agree on the semantics: as an abbreviation for http://www.w3.org/2001/XMLSchema#string .a
consequence, RIF-PRD and RIF-BLD share the compact URI notation is not part ofsame XML syntax wherever they agree on
the RIF-PRD syntax. 1.2.2 BNF pseudo-schemassemantics. The XML syntax of RIF-PRDis specified for each component asusing textual
descriptions and BNF pseudo-schemas. A pseudo-schemas, as part of the descriptionnormative XML schema will
also be provided in future versions 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 assigneddocument;
- Presentation syntax. A
value which correspondspresentation syntax is also
specified, to their type,allow a more easily readable presentation of RIF-PRD
language fragments (such as definedexamples etc). To make the overlap
between RIF-PRD and RIF-BLD visible, RIF-PRD re-uses the presentation syntax
of RIF-BLD wherever
they share the same XML syntax (and agree on the semantics). The
presentation syntax is non normative.
Example 1.2. In RIF-PRD presentation syntax, the normative schema. Elements are conventionally assignedfirst
rule in example 1.1. might be represented as follows:
Prefix(ex1 http://rif.example.com/2008/prd#)
(* ex1:rule_1 *)
Forall ?customer ?purchasesYTD (
ex1:Gold(?customer)
:-
And(
?customer#ex1:Customer
?customer[ex1:purchasesYTD->?purchasesYTD]
pred:numeric-greater-than(?purchasesYTD, 5000) ))
Editor's Note: As
a value which isconsequence of the namere-use of RIF-BLD presentation syntax, examples and fragments
written in RIF-PRD non-normative presentation syntax may have an
unfamiliar look to production rules developers and users. The
syntactic classworking group seeks feedback on this issue as well.
The overall structure of their content,the syntax of RIF-PRD is also presented
as definedan UML-like diagram in appendix: UML-like diagram of RIF-PRD syntax. The normative schema. <!-- sample pseudo-schema --> < defined_element required_attribute_of_type_string=" xs:string " optional_attribute_of_type_int=" xs:int "? > <required_element /> <optional_element />? <one_or_more_of_these_elements />+ [ <choice_1 /> | <choice_2 /> ]* </ defined_element > 1.3 Running example Jim the Hen Handler developeddiagram
provides an overview of RIF-PRD syntactic classes and shows at a
very sophisticated programglance how they relate to grow feeble chicks into deliciously plump chickenseach others. It is provided for
a minimal cost. Jim publishes his method on his Web site www.juicychicken.org. Since he is still experimenting to improve his method, the rules to follow change quite often, and Jim decided to publish theminformative purposes only.
In RIFthe section 3, the
intended semantics for RIF-PRD constructs is specified normatively.
As well, so that his followerscan easily, even automatically, implementbe seen from the very latest version. Jim's latest additionexamples above, production rules, in
general, are not logic rules, and they are not amenable to his knowledge base is the following advice: Except on Tuesdays, every potato owned bya chicken gets mashed, andmodel
theory: followingly, the daily grain allowanceintended semantics of every chicken that owns a potato is increased by 10%, if the chicken is older than 8 months, the potato's weight (in decigrams) is more than half the chicken's age (in months),rules and thereset of
rules serialized as RIF-PRD is no foxspecified operationally, in this
document. The hen house. Do not forget to delete the mashed potatoes from the ownership table! Jim calls itcompatibility with the "Chicken and Mashed Potatoes", or CMP, rule. Rephrased in a more "rule-like" form,model theoretic semantics of
RIF-BLD for the
rule could read like: Rule ChickensAndMashedPotatoes: Forall ?c, where ?ccontructs they share is a chickenexplained and the age of ?cproven in months is > 8; Forall ?p, where ?p is a potato, ?p is owned by ?c, andappendix: Compatibility with
RIF-BLD.
1.2 Notational conventions
1.2.1 Namespaces
Throughout this document, the weight in decigrams of ?p > (age of ?c)/2; If today is not Tuesday, and there is no fox inxsd: prefix stands for
the hen house Then mash ?p, increaseXML Schema namespace URI
http://www.w3.org/2001/XMLSchema#, the grain allowance of ?c by 10%,rdf:
prefix stands for
http://www.w3.org/1999/02/22-rdf-syntax-ns#, and
remove the couple (?c, ?p) fromrif: stands for the ownership relation.URI of the CMP rule is a production rule: that is, when the rule is implemented and the condition is satisfied, the consequence is that some actions are executed (mashing potatoes, modifying a chicken's regime, managing ownership relations etc). Therefore, it is best interchanged using the production rule dialect of RIF, and Jim the Hen Handler's method, and especially his "chicken and mashed potatoes" rule and components thereof, willRIF namespace,
http://www.w3.org/2007/rif#.
Syntax such as xsd:string should be usedunderstood as a
running example in this document. To make sure that his rules can be implemented unambiguously, Jim (the Hen Handler, not the chicken) publishedcompact URI (CURIE) -- a data model (e.g., an XML schema)macro
that identifies Chicken and Potato as two classes of objects: instances of Chicken represent individual chickens. They haveexpands to a property called age that representsconcatenation of the chicken's age in months as an xs:decimalcharacter sequence denoted
by the prefix xsd and a property called allowance that representthe chicken's daily grain allowance as an xs:integer ; instances of Potato represent individual potatoes. They have a property called weight that representsstring string. The
potato's weightcompact URI notation is used for brevity only, and
xsd:string should be understood, in decigramthis document, as an
xs:decimalabbreviation for
http://www.w3.org/2001/XMLSchema#string.
Jim further specifies: a data type DayOfTheWeek that specifies1.2.2 BNF pseudo-schemas
The daysXML syntax of the weekRIF-PRD is specified for each component as a
subsetpseudo-schema, as part of xs:string a binary predicate owns(?o ?i) that denotes the ownership relation between owner ?o and owned item ?i ; a nullary function today() that returnsthe daydescription of the week as a DayOfTheWeek ; a boolean fox sensor foxAlarm() that returns true if and only if the fox is incomponent. The
hen house;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 command mash(?i) ,value
which execution resultscorresponds to their type, as defined in the physical item that is denoted by ?i being reduced tonormative
schema. Elements are conventionally assigned a soft pulpy state by beating or pressure (and removed fromvalue which is the
instancesname of its class,the syntactic class of their content, as a consequence). All these (types and names) aredefined in Jim's namespace, which is represented in this document bythe
prefix jim: . 2 Syntax In this document,normative schema.
<!-- sample pseudo-schema -->
<defined_element
required_attribute_of_type_string="xs:string"
optional_attribute_of_type_int="xs:int"? >
<required_element />
<optional_element />?
<one_or_more_of_these_elements />+
[ <choice_1 /> | <choice_2 /> ]*
</defined_element>
1.2.3 Syntactic components
Three related but distinct representations for RIF-PRDkinds of syntactic components are introduced: XML syntax. This syntax isused to specify
RIF-PRD:
- Abstract classes are defined only by their
subclasses: they not visible in the
normativeXML serialization of RIF-PRD. It is meant,markup and has been designed, to workcan be thought
of as a common XML serialisation for many production rule languages. It is specifiedextension points. In the following subsection using textual descriptions and BNF pseudo-schemas. A normative XML schema will also be provided in future versions of the document. Presentation syntax . A presentation syntax is also specified, to allow a more easily readable presetation of RIF-PRD language fragments (such as examples etc). The presentation syntax is non normative. Structural diagram. The overall structure of the syntax of RIF-PRD is also presented as an UML-like diagram in appendix [ RIF-PRD Structural diagram]. The diagram provides an overview of RIF-PRD syntactic classes and shows at a glance how they relate to each others. It is provided for informative purposes only. Three kinds of syntactic components are used to specify RIF-PRD: Abstract classes are defined only by their subclasses: they not visible in the XML markup and can be thought of as extension points. In this document, abstract constructsthis document, abstract constructs will
be denoted with all-uppercase names;
- Concrete classes have a concrete definition and
they are associated with specific XML markup. In this document,
concrete constructs will be denoted with CamelCase names with
leading capital letter;
- Properties, or roles, define how two
classes relate to each other. They have concrete definitions and
are associated with specific XML markup. In this document,
properties will be denoted with camelCase names with leading
smallcase letter.
2.1 Condition Language1.3 Running example
This section specifies the XML syntax that is used to represent the different boolean expressions that can be found in production rules.describes the language is calledfictious RIF-PRD use case of Jim the
condition language by reference toHen Handler, and the condition longuage of [ RIF-BLD],rule that determines what can appearwill be used as a conditionrunning example in
a rule supported by RIF-BLD.this document.
Jim the language playsHen Handler developed a similar role in RIF-PRD and both dialects share the same construct everywhere they agreevery sophisticated program to
grow feeble chicks into deliciously plump chickens for a minimal
cost. Jim publishes his method on his Web site
www.juicychicken.org. Since he is still experimenting to improve
his method, the semantics. The most basic constructrules to follow change quite often, and Jim decided
to publish them in RIF is the TERM . The TERM is an abstract construct, concretly visible, in RIF-PRD,as a Const , a Var or an External .well, so that his followers can easily,
even automatically, implement the ATOMICvery latest version.
Jim's method is the basic building blocka complex exercise of RIF. ATOMICbehavioural hen
psychology: one aspect that is an abstract class:relevant for the example is that it
requires that, under certain internal and/or external conditions,
hen own potatoes, hen owned potatoes are mashed, hen daily grain
allowance is increased or decreased etc.
Jim's latest addition to his knowledge base is visible in RIF-PRD as either an Atom ,an Equal ,advice that:
on a Member ,Monday, if a Subclass orchicken over 8 months old owns a Frame . Each kind of ATOMICpotato that
weights (in decigrams) more than half its age, and if the fox is
a composition of TERM s.not in the next level of constructs are assemblies of ATOMIC s. Together,hen house, then the various kinds of assemblies formpotato should be mashed and the
abstract construct FORMULA . RIF-PRD knows six kindsdaily grain allowance of FORMULA s: the single ATOMIC ,the External lly evaluated Atom or Frame , andchicken increased by 10%.
Jim calls it the recursively specified"Chicken and ,Mashed Potatoes", or , NmNot and Exists .CMP, rule. The
following sections specify each construct separately, grouped by abstract syntactic classes. Editor's Note:CMP rule is a production rule: that is, when the RIF-PRDcondition languageis
still under discussion. Future version of this document will specify additional constructs to increase the expressive coverage of RIF-PRD,satisfied and the precise syntax of some constructs may change.rule is implemented (that is, fired), the
working group seeks feedback on which additional constructs and/or which extension of specified constructs would be most useful to add. 2.1.1 TERM The TERM class of constructsconsequence is used to represent constants, variables andthat some actions are executed (mashing potatoes,
modifying a chicken's diet, managing ownership relations etc).
Therefore, it is best interchanged using RIF-PRD, the applicationproduction
rule dialect of function symbols to other TERM s. As an abstract class, TERM is not associated with specific XML markupRIF.
The CMP rule might be rephrased in RIF-PRD instance documents. Itnon-normative
presentation
syntax as follows:
(* jim:ChickenAndMashedPotatoes *)
// The identifier of the rule is specified inthe normative schema as a substitution group. [ Const | Var | External ] 2.1.1.1 Const In RIF,IRI "jim:ChickenAndMashedPotatoes"
Forall ?chicken ?potato ?allowance ?age ?weight (
// The ConstForall construct is used to represent a constant.declare the Const element has a required type attribute and an optional xml:lang attribute:rule variables: "?chicken" etc
Do( // Rule actions list
Execute(jim:mash(?potato))
// The value offirst action is to mash the type attributepotato that is bound to variable ?potato
Retract(?chicken[jim:allowance->?allowance])
?chicken[jim:allowance->External(func:numeric-multiply(?allowance 1.1))]
// The identifiervalue of the Const symbol space. It must be an absolute IRI; The xml:lang attribute, as defined by 2.12 Language Identification"allowance" property of XML 1.0 or its successor specifications inthe W3C recommandation track,chicken that is optionally usedbound to identify?chicken
// is increased by 10%
Retract(jim:owns(?chicken ?potato)) )
:- // IF
And( // Rule conditions
?chicken#jim:Chicken
// The language forobject bound to ?chicken is a "Chicken" as specified in Jim's object model
?chicken[jim:age->?age jim:allowance->?allowance]
// The presentationvalue of the Const to"age" property of the user. It"Chicken" object bound to ?chicken is
allowed only in association with constants of// equal to the type rif:text . A compliant implementation MUST ignorevalue bound to the xml:lang attribute ifvariable ?age, and the typevalues of the Const"allowance"
// property is not rif:text .equal to the content ofvalue bound to ?allowance
External(pred:numeric-greater-than(?age, 8))
// The Const elementvalue bound to ?age is greater than 8, where the constant's litteral, which can be any Unicode character string. <Const type=" IRI " [xml:lang=" xsd:language "]? > Any Unicode string </Const> Constant types.function "numeric-grater-than"
// is specified by RIF-PRD conformant implementationsand must support the following builtin constant types: xsd:long ( http://www.w3.org/2001/XMLSchema#long ), as defined in the documentbe supported by all implementations
?potato#jim:Potato
?potato[jim:weight->?weight]
jim:owns(?chicken ?potato)
External(pred:numeric-greater-than(?weight External(func:numeric-divide(?age 2))))
External(pred:string-not-equal(External(jim:today()), "Tuesday"))
Not(External(jim:foxAlarm())) ))
To make sure that his rules can be implemented unambiguously,
Jim published a data model (e.g., an XML Schema Part 2: Datatypes ; xsd:string ( http://www.w3.org/2001/XMLSchema#string ),schema) that identifies
Chicken and Potato as defined intwo classes of objects:
- instances of Chicken represent individual chickens. They
have a property called age that represents the
document XML Schema Part 2: Datatypes ; xsd:integer ( http://www.w3.org/2001/XMLSchema#integer ), as definedchicken's age
in the document XML Schema Part 2: Datatypes ;months as an xsd:decimal ( http://www.w3.org/2001/XMLSchema#decimal ),and a property called
allowance that represent the chicken's daily grain allowance
as definedan xsd:integer;
- instances of Potato represent individual potatoes. They
have a property called weight that represents the potato's
weight in decigram as an xsd:decimal.
Jim further specifies:
- a binary predicate owns(?o ?i) that denotes the
document XML Schema Part 2: Datatypesownership relation between owner ?o and owned item
?i;
-
xsd:double ( http://www.w3.org/2001/XMLSchema#double ),a nullary function today() that returns the day of the
week as defineda xsd:string;
- a boolean fox sensor foxAlarm() that returns true
if and only if the fox is in the
document XML Schema Part 2: Datatypes ; xsd:time ( http://www.w3.org/2001/XMLSchema#time ), as definedhen house;
- and a command mash(?i), which execution results in the
document XML Schema Part 2: Datatypes ; xsd:dateTime ( http://www.w3.org/2001/XMLSchema#dateTime ), as definedphysical item that is denoted by ?i being reduced to a soft
pulpy state by beating or pressure (and in the document XML Schema Part 2: Datatypes ; xs:dayTimeDuration and xs:yearMonthDuration , as defined in http://www.w3.org/TR/xquery-operators/#dt-yearMonthDuration ; rdf:XMLLiteral ( http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral ),corresponding
logical object being removed from the instances of its class, as a
consequence).
All these (types and names) are defined in Jim's namespace
http://rif.examples.com/2008/jim#.
The assumption is that a system that consumes a RIF document
Resource Description Framework (RDF): Conceptspublished by Jim knows how to map Jim's published data model and
Abstract Syntax ; rif:text , for text strings with language tags attached.specification of predicates and functions to/from its own
underlying data representation. What a consumer is expected to do
when this is not the language tag requirescase is still under discussion and will be
specified as a conformance clause in a special treatmentfuture version of rif:text constants with respect tothis
document.
2 Syntax
This section specifies the XML syntax; rif:iri ,syntax for internationalized resource identifier or IRIserializing the
rule conditions and the
rule actions, as well as
complete production rules,
groups of rules and formulae, and
any accompanying metadata. Finally, RIF-PRD presentation
syntax is specified.
2.1 Conditions
This typesection specifies the XML syntax that is used to represent constantsserialize,
in RIF-PRD, the different boolean expressions that are intended tocan be usedfound in
a way similarproduction rules. That syntax is sometimes called the condition
language, by reference to RDF resources .the lexical space consistscondition language of all absolute IRIs as specifiedRIF-BLD, which
determines what conditions in RFC 3987 ;a logic rule can be represented in
RIF-BLD. It is unrelatedplays a
similar role in RIF-PRD and, to maximize interoperability, the XML primitive type anyURItwo
dialects share the same constructs everywhere they agree on the
semantics.
The most basic construct in RIF is the TERM. A rif:iri constantThe
TERM is supposed to be interpretedan abstract construct, concretely visible, in
RIF-PRD, as a reference to one andConst, a Var or an
External.
The same object regardless ofATOMIC is the contextbasic building block of RIF.
ATOMIC is an abstract class: it is visible in which that constant occurs. rif:localRIF-PRD as
either an Atom, for constant symbols that are not visible outsidean Equal, a Member, a
Subclass or a Frame. Each kind of ATOMIC
is a particular setcomposition of rules interchanged in RIF. ConstantsTERMs.
The next level of this typeconstructs are used locally in their respective rule sets. This means that occurrencesassemblies of ATOMICs.
Together, the same rif:local -constant in different rule sets are viewed as unrelated distinct constants, but occurrencesvarious kinds of assemblies form the same constant in the same rule set must refer to the same object. The lexical spaceabstract
construct FORMULA. RIF-PRD knows six kinds of
rif:local isFORMULAs: the same assingle ATOMIC, the
lexical space of xsd:stringExternallly evaluated Atom or Frame, and
the recursively specified And, Or, NmNot
and Exists.
The following sections specify each construct separately,
grouped by abstract syntactic classes.
Editor's Note:
The list of builtin constant types may be modified inFuture versionsversion of this document, based ondocument will specify additional constructs
to increase the content of future versionsexpressive coverage of the RIF data typesRIF-PRD, and builtins document [ RIF-BLD]. Symbols with an ill-formed lexical part. Constants that are represented in RIF in onethe precise
syntax of some constructs may change. The aforesaid builtin types mustworking group seeks
feedback on which additional constructs and/or which extension of
specified constructs would be well-formed, i.e., their representation must belongmost useful to add.
2.1.1 TERM
The lexical spaceTERM 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 type. For instance, 123^^xsd:long (that is, <Const type="xsd:long">123</Const> ) hasnormative schema as a correct lexical part, since 123 belongssubstitution group.
[ Const | Var | External ]
2.1.1.1 Const
In RIF, the Const construct is used to represent a
constant.
The lexical spaceConst element has a required type
attribute and an optional xml:lang attribute:
- The value of the
datatype xsd:long . In contrast, abc^^xsd:long ( <Const type="xsd:long">abc</Const> )attribute 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 forthe interchangeidentifier of
constants thatthe Const symbol space. It must belong to the correspondingtype
xsd:anyURI;
- The xml:lang attribute, as defined by 2.12 Language
Identification of XML
and RDF types. They can also be1.0 or
its successor specifications in the W3C recommendation track, is
optionally used to identify the language for the interchangepresentation of
constantsthe Const to the user. It is allowed only in association
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 oneof RIF builtin types for interchange purposes, can be represented usingthe same <Const type="TYPE">LITERAL</Const> syntax, wheretype rif:text. A compliant
implementation MUST ignore the xml:lang attribute if the
type of the Const is not onerif:text.
The content of the RIF builtin types. RIF does not ascribeConst element is the constant's
litteral, which can be any specific lexical space to these types andUnicode character string.
<Const type=xsd:anyURI [xml:lang=xsd:language]? >
Any Unicode string
should be considered a well-formed</Const>
Constant symbol as far astypes. RIF is concerned. Inrequires that all dialects include
the same way,following builtin constant types. Rule sets that are exchanged
through RIF does not ascribe any particular semantics to such non-builtin TYPE s: it iscan use additional symbol spaces.
- xs:string
(http://www.w3.org/2001/XMLSchema#string)
- xs:time
(http://www.w3.org/2001/XMLSchema#time)
- xs:date
(http://www.w3.org/2001/XMLSchema#date)
- xs:dateTime
(http://www.w3.org/2001/XMLSchema#dateTime)
- xs:double
(http://www.w3.org/2001/XMLSchema#double)
- xs:integer
(http://www.w3.org/2001/XMLSchema#integer)
- xs:decimal
(http://www.w3.org/2001/XMLSchema#decimal)
The responsibilitylexical spaces of the producers and consumers of RIF-PRD rulesets that reference types thatabove symbol spaces are not builtdefined 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 appropriatethe
names of some non-standard types to name them. Examples. In eachdocument [XML-SCHEMA2].
- xs:dayTimeDuration
(http://www.w3.org/2001/XMLSchema#dayTimeDuration)
- xs:yearMonthDuration
(http://www.w3.org/2001/XMLSchema#yearMonthDuration)
These two symbol spaces represent two subtypes of the examples below, a constant is first described, followed by its representation in RIF-PRDXML syntax. a. A constant with builtinSchema
data type xsd:integer andxs:duration with well-defined value 123 : <Const type="xsd:integer">123</Const> b.spaces,
since xs:duration does not have a constantwell-defined value space
(this may be corrected in later revisions of XML Schema data types,
in which case the revised data type would be suitable for RIF DTB).
The lexical spaces of the above symbol today isspaces are defined in Jim the Hen Handler's namespace, identified bythe
prefix jim: .document [XDM].
- rdf:XMLLiteral
(http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral).
This symbol space represents XML content. The typelexical space of
the constantrdf:XMLLiteral is rif:iri : <Const type="rif:iri">jim:today</Const> c. A constantdefined in the document [RDF-CONCEPTS].
- rif:text (http://www.w3.org/2007/rif#text,
for text strings with language tags attached).
This symbol BigPotato thatspace represents text strings with a language tag
attached. The lexical space of rif:text is local tothe set of rules where it appears (e.g. a RuleSet specific to Paula's farm). The typeall
Unicode strings of the constant is rif:local : <Const type="rif:local">BigPotato</Const> d. A constantform ...@LANG, i.e., strings that
end with non-builtin type xsd:int and value 123: <Const type="xsd:int">123</Const> e.@LANG where LANG is a constant with symbol Tuesday ,language
identifier as defined in the literal space of the application specific data type jim:DayOfTheWeek : <Const type="jim:DayOfTheWeek">Tuesday</Const> 2.1.1.2 Var[RFC-3066].
- rif:iri (http://www.w3.org/2007/rif#iri, for
internationalized resource identifiers or
IRIs).
Constants in RIF, the Var construct isthis symbol space are intended to be used in a way
similar to represent variables.RDF resources [RDF-SCHEMA]. The contentlexical space consists of the Var element is the variable's name, represented as an Unicode character string. <Var> any Unicode string </Var> 2.1.1.3 Externalall absolute IRIs
as a TERM , an External elementspecified in [RFC-3987]; it
is usedunrelated to represent an externally specified function, e.g. a builtin,the XML primitive type anyURI. A
user-defined function,rif:iri constant must be interpreted as a queryreference to an external data source... The External element containsone
content element, whichand the same object regardless of the context in turn contains one Expr elementwhich that
contains one op element, followed by zero or more arg elements:constant occurs.
- rif:local (http://www.w3.org/2007/rif#local,
for constant symbols that are not visible outside of the
content and Expr element ensure compatibility with [RIF
Basic Logic Dialect], that allows non-evaluated (that is, logic) functionsdocument in which they occur).
Constants in this symbol space are local to be represented by an Expr element;the contentRIF documents in
which they occur. This means that occurrences of the op element must be a Const . When the External is a TERM , the contentsame
rif:local constant in different documents are viewed as
unrelated distinct constants, but occurrences of the op element represents a function symbol; The content ofsame
rif:local constant in the arg elementssame document must be constructs fromrefer to the
TERM abstract class.same object. The orderlexical space of the arg elementsrif:local is significant and MUST be preserved. <External> <content> <Expr> <op> Const </op> <arg> TERM </arg>* </Expr> </content> </External> Builtin functions. RIF-PRD specifies a subsetthe same as
the lexical space of XPath/XQuery Functions and Operators [X F&O] that any conformant RIF-PRD implementation MUST support.xs:string.
Editor's Note:
The RIF-PRDlist of builtin functions are listedconstant types may be modified in future
versions of this document, based on the [content of future versions
of the RIF data Typetypes and Builtins] document.builtins document, RIF-DTB.
Editor's Note:
The op Const must represent a constant symbolcase of type rif:irinon-standard data types, that must uniquely identify the evaluated function to be applied to the arg TERM s. It canis, of constants that do
not belong or cannot be cast in one of theRIF builtin functions specifiedtypes for
RIF-PRD, or it can be application specific. In the latter case, itinterchange purposes, is still under discussion in the responsibility ofWG. The producersWG
seeks feedback on whether they should be allowed and consumers of RIF-PRD rulesetswhy.
Symbols with an ill-formed lexical part. Constants that
reference non-builtin functions to agree on their semantics. Examples. a. The first example below showsare represented in RIF in one wayof the aforesaid builtin types must
be well-formed, i.e., their representation must belong to represent, in RIF-PRD,the
sum of integer 1 and variable ?X, wherelexical space associated with the addition conformstype. For instance,
123^^xsd:long (that is,
<Const type="xsd:long">123</Const>) has a
correct lexical part, since 123 belongs to the specificationlexical
space of the builtin fn:numeric-adddata type xsd:long. In contrast,
abc^^xsd:long
(<Const type="xsd:long">abc</Const>) is
ill-formed, as it does not have a correct lexical part. A compliant
RIF-PRD translator MUST reject ill-formed symbols.
Example
2.1. In each of the prefix fnexamples below, a constant is associatedfirst
described, followed by its representation in RIF-PRD XML
syntax.
a. A constant with the namespace http://www.w3.org/2007/rif-builtin-function# . <External> <content> <Expr> <op> <Const type="rif:iri"> fn:numeric-add </Const> </op> <arg>builtin type xsd:integer and value
123:
<Const type="xsd:integer"> 1 </Const> </arg> <arg> <Var> ?X </Var> </arg> </Expr> </content> </External>type="xsd:integer">123</Const>
b. Another example, that shows the RIF XML representation ofA call to the application-specific nullary function today() ,constant which symbol today is defined in Jim the
example's namespace: <External> <content> <Expr> <op>Hen Handler's namespace http://rif.examples.com/2008/jim#.
The type of the constant is rif:iri:
<Const type="rif:iri">
jim:todayhttp://rif.examples.com/2008/jim#today
</Const>
</op> </Expr> </content> </External> 2.1.2 ATOMIC The ATOMIC classc. A constant with symbol BigPotato that is usedlocal to represent atomic truth-valued statements. RIF-PRD covers rule languages in whichthe
truth valuesset of atomic statements can only be "true" or "false": that is, ATOMIC s represent boolean statements. Dialects extending RIF-PRD may support additional truth values. As an abstract class, ATOMICrules where it appears (e.g. a RuleSet specific to Paula's
farm). The type of the constant is not associatedrif:local:
<Const type="rif:local">BigPotato</Const>
d. A constant with specific XML markupnon-builtin type xsd:int and value 123:
<Const type="xsd:int">123</Const>
2.1.1.2 Var
In RIF-PRD instance documents. ItRIF, the Var construct is specified inused to represent
variables.
The normative schemacontent of the Var element is the variable's name,
represented as an Unicode character string.
<Var> any Unicode string </Var>
2.1.1.3 External
As a substitution group. [ Atom | Equal | Member | Subclass | Frame ] 2.1.2.1 Atom In RIF, the AtomTERM, an External element is used to
represent an externally specified function, e.g. a relation (or predicate).builtin, a
user-defined function, a query to an external data source...
The AtomExternal element contains one content
element, which in turn contains one Expr element that
contains one op element, followed byzero or one
args element or zero of more arg arguments:slot elements:
- The content and Expr element ensure
compatibility with the RIF Basic Logic Dialect, RIF-BLD, that
allows non-evaluated (that is, logic) functions to be represented
by an Expr element;
- The content of the op element must be a
Const.
It representsWhen the predicate symbol (the name ofExternal is a relation);TERM, the
content of the arg elements must beop element represents a function
symbol;
- The optional args element contains zero or more
constructs from the TERM abstract class. The order of the
arg elementsargs sub-elements is significant and MUST be preserved.
<Atom>This is emphasized by the required value "yes" of the
required attribute rif:ordered;
- Each optional slot element contains one required
Name sub-element, that contains an Unicode string that
represents the slot key, and a required TERM that
represents its value.
<External>
<content>
<Expr>
<op> Const </op>
<arg>[ <args rif:ordered="yes"> TERM </arg>* </Atom> Example. The example below shows* </args>?
|
<slot rif:ordered="yes">
<Name> Any Unicode string </Name>
TERM
<slot>* ]
</Expr>
</content>
</External>
Editor's Note:
The RIF XML representationslotted, or named arguments form of the predicate owns(?c ?p) , where the predicate symbol ownsExternal
TERM construct is defined instill under discussion (see also
ISSUE-68).
The example namespace denoted byworking group seeks feedback on whether or not it should be
included in PRD.
Builtin functions. RIF-PRD specifies a subset of
XPath/XQuery Functions and Operators (XPath-Functions) that any
conformant RIF-PRD implementation MUST support. The prefix jim: . <Atom> <op> <Const type="rif:iri"> jim:owns </Const> </op> <arg> <Var> ?c </Var> </arg> <arg> <Var> ?p </Var> </arg> </Atom> 2.1.2.2 EqualRIF-PRD builtin
functions are listed in RIF, Equal is used to represent equality relations.the Equal element must contain two unordered side elements.Data Type and
Builtins document.
The content of each side elementop Const must berepresent a construct from the TERM abstract class. The orderconstant symbol
of the side elements is not significant andtype rif:iri that must not be preserved. <Equal> <side> TERM </side> <side> TERM </side> </Equal> 2.1.2.3 Member In RIF,uniquely identify the Member element is usedevaluated
function to be applied to represent membership relations.the Member element contains two unordered sub-elements:args TERMs. It can be
one of the instance elements mustbuiltin functions specified for RIF-PRD, or it can be
a construct fromapplication specific. In the TERM abstract class.latter case, it is required; the class element must be a construct fromthe TERM abstract class. It is required as well. <Member> <instance> TERM </instance> <class> TERM </class> </Member> Example.responsibility
of the producers and consumers of RIF-PRD rulesets that reference
non-builtin functions to agree on their semantics.
Example 2.2.
a. The first example below shows one way to represent, in
RIF-PRD, the RIF XML representationsum of a bollean expression that tests whetherinteger 1 and variable ?X, where the
individual denoted byaddition conforms to the variable ?c is a memberspecification of the class Chicken thatbuiltin
fn:numeric-add.
The prefix fn is defined inassociated with the examplenamespace
denoted by the prefix jim:http://www.w3.org/2007/rif-builtin-function#.
<Member> <instance> <Var> ?c </Var> </instance> <class><External>
<content>
<Expr>
<op> <Const type="rif:iri"> jim:Chickenfn:numeric-add </Const> </class> </Member> 2.1.2.4 Subclass In RIF, the Subclass element is used to represent class inclusion relations. The Subclass element contains unordered two sub-elements: the sub element must be a construct from the TERM abstract class. It is required;</op>
<args rif:ordered="yes">
<Const type="xsd:integer"> 1 </Const>
<Var> ?X </Var>
</args>
</Expr>
</content>
</External>
b. Another example, that shows the super elements must beRIF XML representation of a
construct fromcall to the TERM abstract class. Itapplication-specific nullary function today(),
which symbol is required. <Subclass> <sub> TERM </sub> <super> TERM </super> </Subclass> 2.1.2.5 Framedefined in RIF,the Frame constructexample's namespace http://rif.examples.com/2008/jim#:
<External>
<content>
<Expr>
<op>
<Const type="rif:iri">
http://rif.examples.com/2008/jim#today
</Const>
</op>
</Expr>
</content>
</External>
2.1.2 ATOMIC
The ATOMIC class is used to represent relations that hold between an individual, also called an object, andatomic
truth-valued statements. RIF-PRD covers rule languages in which the
truth values of some its propertiesatomic statements can only be "true" or attributes:"false":
that is, object-attribute-value triples. Accordingly, a Frame element must contain: an object element, that contains an element of the TERM abstract class, the content of which represents the individual; zero to many slot elements, each containing a Prop element that represents an attribute-value pair as: a key element that contains an element of the TERM abstract class that represents the name of the attribute (or property); a val element, that contains an element of the TERM abstract class, the content of which represents the attribute's value. <Frame> <object> TERM </object> <slot> Prop </slot>* </Frame> <Prop> <key> TERM </key> <val> TERM </val> </Prop> Example. The example below shows the RIF XML syntax of an expression that states that the object denoted by the variable ?c has the value denoted by the variable ?a for the property Chicken/age that is defined in the example namespace. <Frame> <object> <Var> ?c </Var> </object> <slot> <Prop> <key> <Const type="rif:iri"> jim:Chicken/age </Const> </key> <val> <Var> ?a </Var> </val> </Prop> </slot>* </Frame> Editor's Note: The example uses an XPath style for the key. How externally specified data models and their elements should be referenced is still under discussion (see [ ISSUE-XXX]). 2.1.3 FORMULA The FORMULA class is used to represent any truth-valued statement,ATOMIC or not, that is allowed in the condition part of a rule covered by RIF-PRD. In rule languages covered by RIF-PRD, the truth values of statements can be "true" or "false": that is, FORMULAs can onlyrepresent boolean statements. Dialects
extending RIF-PRD may support additional truth values.
As an abstract class, FORMULAATOMIC is not associated with
specific XML markup in RIF-PRD instance documents. It is specified
in the normative schema as a substitution group.
[ ATOMIC | ExternalAtom | AndEqual | OrMember | NmNotSubclass | ExistsFrame ]
2.1.3.1 ATOMIC A FORMULA can be a single ATOMIC statement. See specification of [ ATOMIC], above. 2.1.3.2 External2.1.2.1 Atom
In RIF-PRD, an External represents an externally specified predicate when itRIF, the Atom element is a FORMULA (as opposedused to represent a
TERM ; that is, in particular, when it appears in a place where a FORMULA is required, and not a TERM ).relation (or predicate).
The ExternalAtom element contains one content element that containsop element,
followed by zero or one Atom element: <External> <content> Atom </content> </External> Builtin predicates. RIF-PRD specifies a subset of XPath/XQuery Functions and Operators [X F&O] that any conformant RIF-PRD implementation MUST support. The RIF-PRD builtin predicates are listed inargs element or zero or more
slot arguments:
- The
[ Data Types and Builtins] document.content of the op Const in the Atomelement must be a
Const. It represents the predicate symbol (the name of type rif:iri that must uniquely identifya
relation);
- The
evaluated predicate to be applied tooptional args element contains zero or more
constructs from the arg TERM s. It can be oneTERM abstract class. The order of the
builtin predicates specified for RIF-PRD, or it canarg's sub-elements is significant and MUST be application specific. Inpreserved.
This emphasized by the latter case, it is up torequired value "yes" of the
producersrequired attribute rif:ordered;
- Each optional slot element contains one required
Name sub-element, that contains an Unicode string that
represents the slot key, and
consumers of RIF-PRD rulesetsa required TERM that
reference non-builtin predicates to agreerepresents its value.
<Atom>
<op> Const </op>
[ <args rif:ordered="yes"> TERM* </args>?
|
<slot rif:ordered="yes">
<Name> Any Unicode string </Name>
TERM
<slot>* ]
</Atom>
Editor's Note:
The slotted, or named arguments form of the Atom construct
is still under discussion (see also ISSUE-68).
The working group seeks feedback on their semantics. Example.whether or not it should be
included in PRD.
Example
2.3. The example below shows the RIF XML representation of a boolean expression that tests whetherthe
value denoted by variable ?a (e.g. the age of a chicken) is greater than the integer value 8,predicate owns(?c ?p), where the test is intended to behave like the builtinpredicate op:numeric-greater-than as specified in XQuery 1.0 and XPath 2.0 Functions and Operators . In the example, the prefix op:symbol
owns is associated withdefined in the example namespace http://www.w3.org/2007/rif-builtin-predicate#http://rif.examples.com/2008/jim#.
<External> <content><Atom>
<op>
<Const type="rif:iri">
op:numeric-greater-thanhttp://rif.examples.com/2008/jim#owns
</Const>
</op>
<arg><args rif:ordered="yes">
<Var> ?a?c </Var>
</arg> <arg> <Const type="xsd:decimal"> 8 </Const> </arg><Var> ?p </Var>
</args>
</Atom>
</content> </External> 2.1.3.3 And A FORMULA can represent the conjunction of zero of more statements, each of them represented by a FORMULA . This2.1.2.2 Equal
In RIF, Equal is represented by the And construct.used to represent equality
relations.
The AndEqual element contains zero or more formula elements, each containingmust contain one left
sub-element an elementdone right sub-element. The content of the
FORMULA group. <And> <formula> FORMULA </formula>* </And> 2.1.3.4 Orleft and right elements must be a FORMULA can representconstruct from
the disjunction of zero of more statements, eachTERM abstract class. The order of them represented by a FORMULA . Thisthe sub-elements is
represented bynot significant.
<Equal>
<left> TERM </left>
<right> TERM </right>
</Equal>
2.1.2.3 Member
In RIF, the Or construct.Member element is used to represent
membership relations.
The OrMember element contains zero or more formula elements, each containing an element oftwo unordered
sub-elements:
- the
FORMULA group. <Or> <formula> FORMULA </formula>* </Or> 2.1.3.5 NmNotinstance elements must be a FORMULA can representconstruct from the
non-monotonic negation of a statement, itself represented by a FORMULA : thisTERM abstract class. It is represenetd by the NmNot construct. The NnNot element contains exactly one formula element.required;
- the
formula element contains anclass element ofmust be a construct from the
FORMULA group, that represents the negated statement. <NnNot> <formula> FORMULA </formula> </NmNot> 2.1.3.6 Exists In RIF, the Exists constructTERM abstract class. It is used to represent an existentially quantified FORMULA . The Exists element contains: one or more declare sub-elements, each containing a Var element that represents one of the existentially quantified variables; exactly onerequired formula sub-element that contains an element from the FORMULA abstract class: the FORMULA represents the formula in the scope of the quantifier. <Exists> <declare> Var </declare>+ <formula> FORMULA </formula> </Exists> Example.as well.
<Member>
<instance> TERM </instance>
<class> TERM </class>
</Member>
Example
2.4. The example below shows the RIF XML representation of a
boolean expression that tests whether the chickenindividual denoted by the
variable ?c is older than 8 months, by testing the existence ofa value, denoted by variable ?a ,member of the class Chicken that is
both the age of ?c , as represented by a Frame as in example XX, and greater than 8, as represented by an External ATOMIC asdefined in the example YY. <Exists> <declare> <Var> ?a </Var> </declare> <formula> <And> <Frame> <object>namespace http://rif.examples.com/2008/jim#.
<Member>
<instance> <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></instance>
<class>
<Const type="rif:iri">
op:numeric-greater-than </Const> </op> <arg> <Var> ?a </Var> </arg> <arg> <Const type="xsd:decimal"> 8http://rif.examples.com/2008/jim#Chicken
</Const>
</arg> </Atom> </content> </External> </And> </formula> </Exists> 2.2 Actions This section specifies</class>
</Member>
2.1.2.4 Subclass
In RIF, the XML syntax thatSubclass element is used in RIF-PRDto represent what can appear inclass
inclusion relations.
The action part ofSubclass element contains unordered two
sub-elements:
- the sub element must be a
rule supported by RIF-PRD. Editor's Note: Difference wrt RIF-BLD: allconstruct from the
constructs in this section are specific to RIF-PRD. Editor's Note: What about truth maintenance capabilities in many PR systems? RIF-PRD defines one singleTERM abstract class for actions: ACTION , thatclass. It is realised by five concrete constructs: the Assert , Retract and Update constructs are associated with an ATOMIC that represents the target of the eponym actions;required;
- the
Executesuper elements must be a construct from the
TERM abstract class. It is associated with arequired.
<Subclass>
<sub> TERM that identifies</sub>
<super> TERM </super>
</Subclass>
2.1.2.5 Frame
In RIF, the operationFrame construct is used to be executed,represent
relations that hold between an individual, also called an object,
and zerothe values of some its properties or more TERM sattributes: that representis,
object-attribute-value triples.
Accordingly, a Frame element must contain:
- an object element, that contains an element of the
arguments withTERM abstract class, the content of which represents the
operation isindividual;
- zero to
be executed; the Assign construct is associated withmany slot elements, each containing a
FrameProp element that represents the target object and slot, as well as the new value to be assigned. Editor's Note: Should other actions be considered in RIF-PRD? Esp., do we need some basic programatic constructs, suchan attribute-value pair as a
loop? Editor's Note: Except for the different names,pair of elements of the missingTERM abstract class that groupsclass, the Assert, Retract and Update actions, andfirst one
that represents the possibility to Assign a value to a (ruleset) variable (which are not defined in this draft),name of the ACTION abstract class is copied fromattribute (or property); the ImperativeExp abstract classsecond
that specifiesrepresents the actions inattribute's value. The OMG [ PRR OCL] specification.order of the
following sections specify each construct separately, grouped by abstract syntactic classes. Each elementslot's sub-elements is given an XML syntax, insignificant and MUST be preserved.
This is emphasized by the formrequired value "yes" of an informative BNF pseudo schema:the
normativerequired attribute rif:ordered.
<Frame>
<object> TERM </object>
<slot rif:ordered="yes"> TERM TERM </slot>*
</Frame>
Example
2.5. The example below shows the RIF XML syntax of an
expression that states that the object denoted by the variable
?c has the value denoted by the variable ?a for the
property Chicken/age that is givendefined in the [ RIF-PRD XML schema]. 2.2.1 ACTIONexample
namespace http://rif.examples.com/2008/jim#.
<Frame>
<object> <Var> ?c </Var> </object>
<slot rif:ordered="yes">
<Const type="rif:iri">
ttp://rif.examples.com/2008/jim#Chicken/age
</Const>
<Var> ?a </Var>
</slot>
</Frame>
Editor's Note:
The ACTIONexample uses an XPath style for the key. How externally
specified data models and their elements should be referenced is
still under discussion (see ISSUE-37).
2.1.3 FORMULA
The FORMULA class of constructsis used to represent the individual actionsany truth-valued
statement, atomic or not, that is allowed in the actioncondition part of
a productionrule represented incovered by RIF-PRD. This versionIn rule languages covered by RIF-PRD,
the truth values of statements can be "true" or "false": that is,
FORMULAs can only represent boolean statements.
Dialects extending RIF-PRD covers five ACTION s: Assert , Retract , Update , Execute and Assign .may support additional truth
values.
As an abstract class, ACTIONFORMULA 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.[ AssertATOMIC | RetractExternal | UpdateAnd | ExecuteOr | AssignNmNot | Exists ]
2.2.1.1 Assert The Assert construct is used to represent actions that result in asserting an2.1.3.1 ATOMIC
statement. The Assert element has one target sub-element that containsA construct from the ATOMIC group, which represents the atomic statement toFORMULA can be asserted on implementing the action. The Equal construct is not allowed as the target of an Assert Editor's Note: Are there other restrictions on the kinda single ATOMIC statement.
See specification of ATOMIC that can be Assert-ed? Shall we allow Member and Subclass ATOMICs to be Assert-ed? Or should we make no restriction: the assertion of,
above.
2.1.3.2 External
In RIF-PRD, an Equal might be well-formed, after all; its assertion might have unexpected results, butExternal represents an externally
specified predicate when it is that RIF's concern? Editor's Note: Issues: ATOMIC might not be the right way to represent the target anyway: what about the case wherea new individual hasFORMULA (as opposed to be created? Use, by convention, the assertion of an anonymous frame (thata
TERM; that is, in particular, when it appears in a frameplace
where the object is the name ofa class,FORMULA is required, and not an individual)? Editor's Note: Or removea TERM).
The Assert constructExternal element contains one content
element that contains one Atom element:
<External>
<content>
Atom
</content>
</External>
Builtin predicates. RIF-PRD specifies a subset of
XPath/XQuery Functions and interpret an ATOMIC as an ACTION as an assert?Operators (XPath-Functions) that would improve PRD/BLD/Core compatibility atany
conformant RIF-PRD implementation MUST support. The synatctic level. What would beRIF-PRD builtin
predicates are listed in the drawbacks? <Assert> <target> ATOMIC </target> </Assert> 2.2.1.2 RetractData Types and
Builtins document.
The Retract construct is used to represent actions that resultop Const in negating an atomic statement.the RetractAtom element has one target sub-element that containsmust
be a construct from the ATOMIC groupsymbol of type rif:iri that representsmust uniquely identify
the atomic statementevaluated predicate to be removed on implementing the action. Editor's Note: Are there any restriction onapplied to the
kind of ATOMIC thatargs TERMs. It can be removed? E.g. what wouldone of the builtin predicates
specified for RIF-PRD, or it mean to remove an Equal ? Should we allow a Member or a Subclass ATOMIC to be Retract-ed? Editor's Note: Issue: ATOMIC might notcan be application specific. In the
right waylatter case, it is up to representthe target anyway: e.g. how to Retract an individual (if empty Frames are not allowed)? <Retract> <target> ATOMIC </target> </Retract> Editor's Note: Issue: Howproducers and consumers of RIF-PRD
rulesets that reference non-builtin predicates to reatrct multiple facts at once? E.g. Retract -ing an individual: use empty frames (if allowed) as a convention? Example.agree on their
semantics.
Example 2.6. The example below shows the RIF XML
representation of an action that updates the chicken-potato ownership table by removing the predicate that statesa boolean expression that tests whether the chickenvalue
denoted by variable ?c owns?a (e.g. the potato denoted by variable ?p .age of a chicken) is
greater than the predicateinteger value 8, where the test is representedintended to
behave like the builtin predicate op:numeric-greater-than
as specified in example XX. <Retract> <target>XQuery 1.0 and XPath 2.0
Functions and Operators.
In the example, the prefix op: is associated with the
namespace http://www.w3.org/2007/rif-builtin-predicate#.
<External>
<content>
<Atom>
<op> <Const type="rif:iri"> jim:ownsop:numeric-greater-than </Const> </op>
<arg> <Var> ?c </Var> </arg> <arg><args rif:ordered="yes">
<Var> ?p?a </Var>
</arg><Const type="xsd:decimal"> 8 </Const>
</args>
</Atom>
</target> </Retract> 2.2.1.3 Update The Update construct is used to</content>
</External>
2.1.3.3 And
A FORMULA can represent actions that result in updating an atomic statement.the Update element has one target sub-element that containsconjunction of zero of more
statements, each of them represented by a construct fromFORMULA. This is
represented by the ATOMIC group that representsAnd construct.
The atomic statement to be updated on implementingAnd element contains zero or more formula
elements, each containing an element of the action. <Update> <target> ATOMIC </target> </Update> FromFORMULA
group.
<And>
<formula> FORMULA </formula>*
</And>
2.1.3.4 Or
A FORMULA can represent the specificationdisjunction of OMG PRR-OCL [ PRR]: "Some operations modify the statezero of objects and others do not. If the modified objects are in the scopemore
statements, each of them represented by a FORMULA. This is
represented by the engine,Or construct.
The engine must be notified thatOr element contains zero or more formula
elements, each containing an element of the objects state has been modified to be able to computeFORMULA
group.
<Or>
<formula> FORMULA </formula>*
</Or>
2.1.3.5 NmNot
A FORMULA can represent the listnon-monotonic negation of eligible rules. Ita
statement, itself represented by a FORMULA: this is
not possible from the operation call to determine automatically what objects will be modified so it may be necessary inrepresenetd by the rule to explicitly notifyNmNot construct.
The engine." Editor's Note: Issues:NnNot element contains exactly one formula
element. The Update asformula element contains an action is specific to some rule engine technologies or implementations (e.g. RETE-based). Since it is required by such implementations only because of the opaque natureelement of the
Execute actions with respect toFORMULA group, that represents the modification of ATOMICs, and sincenegated statement.
<NmNot>
<formula> FORMULA </formula>
</NmNot>
Editor's Note:
The specificationname of the procedural attachments to be Execute -ed requires a specific interchange channel anyway (as builtins or depending on an out-of-band agreement), should not the information relevant to any ATOMIC impacted by an Execute -ed procedure, and thus to required updates for enginesthat use them, rather be interchanged as part ofconstruct may change, including the specificationtag of said procedures? And Update not be covered by RIF-PRD, as a consequence? 2.2.1.4 Executethe ExecuteXML
element.
2.1.3.6 Exists
In RIF, the Exists construct is used to represent actions that result in the execution of a procedural attachment.an
existentially quantified FORMULA.
The ExecuteExists element hascontains:
- one
op sub-elementor more declare sub-elements, each containing a
Var element that represents the symbolone of the procedural attachement to be executed on implementing the action, followed by zero or more arg sub-elementsexistentially
quantified variables;
- exactly one required formula sub-element that
represent its arguments: The content of the op element must be a construct of the TERM abstract class; Editor's Note: Or should the opcontains
an element be restricted to a Const instead? The content of the arg elements must be constructsfrom the TERMFORMULA abstract class. The order of the arg elements is significant and MUST be preserved. Review comment from Adrian Or useclass: the
External construct instead (AdrianP)? But how about (i)FORMULA represents the ambiguity with fixed interprestation predicates; (ii) asserted ATOMICs if we removeformula in the Assert construct? <Execute> <op> TERM </op> <arg> TERM </arg>* </Execute> Builtin operations. TBD Editor's Note: Should RIF-PRD have builtin executable operations (e.g. print etc) or should they be left to bescope of the
application specific? Example.quantifier.
<Exists>
<declare> Var </declare>+
<formula> FORMULA </formula>
</Exists>
Example
2.7. The example below shows the RIF-PRDRIF XML representation of a
boolean expression that tests whether the action which execution results in the physical potatochicken denoted by
variable ?p being mashed, following?c is older than 8 months, by testing the specificationexistence
of a value, denoted by variable ?a, that is both the mash actionage of
?c, as represented by a Frame as in theexample namespace denoted2.5, and greater than 8,
as represented by the prefix jim:an External ATOMIC as in
example 2.6.
<Execute><Exists>
<declare> <Var> ?a </Var> </declare>
<formula>
<And>
<Frame>
<object> <Var> ?c </Var> </object>
<slot rif:ordered="yes">
<Const type="rif:iri">
http://rif.examples.com/2008/jim#Chicken/age
</Const>
<Var> ?a </Var>
</slot>
</Frame>
<External>
<content>
<Atom>
<op> <Const type="rif:iri"> jim:mashop:numeric-greater-than </Const> </op>
<arg><args rif:ordered="yes">
<Var> ?p?a </Var>
</arg> </Execute> 2.2.1.5 Assign<Const type="xsd:decimal"> 8 </Const>
</args>
</Atom>
</content>
</External>
</And>
</formula>
</Exists>
2.2 Actions
This section specifies the Assign constructXML syntax that is used to represent actions that resultserialize,
in RIF-PRD, what can appear in a value being assigned to a property of an individual.the Assign element hasaction part of a rule supported
by RIF-PRD.
RIF-PRD defines one target sub-elementsingle abstract class for actions:
ACTION, that containsis realised by three concrete constructs:
- the ASSERT and Retract constructs are
associated with an Atom or a Frame that
represents
an object-attribute-value, where the "value" has to be assigned tothe "attribute"target of the "object" on implementing the action. Editor's Note: Or reuseactions.
The Equalfollowing sections specify each construct (AdranP)? But that would be with a different semanticsseparately,
grouped by abstract syntactic classes.
Editor's Note:
How will values be assigned to parameters (if and once we add them)? <Assign> <target> Frame </target> </Assign> Example. The example below showsThis section is still under discussion in the RIF-PRD XML represnetation ofworking group (see
ISSUE-62).
The working group considers adding an Assign action that increases by 10%to
represent the valuemodification of the daily grain allowancevalue of the chicken denotedan attribute in a fact
represented 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 declarea variableFrame, and an Execute action to
compute 110%represent the execution of its value??? </val> </Prop> </slot>* </Frame> </target> </Assign> Editor's Note: Really needs to define a standardan arbitrary, externally specified
procedure. The working group seeks feedback regarding the proposed
syntax for getters and setters for properties, not just accessors à la Frame... 2.3 Production Rules This section specifiesthe currently specified actions, as well as regarding
which constructs for serializing individual actions should be
supported by RIF-PRD and/or required from RIF-PRD
implementations.
2.2.1 ACTION
The ACTION class of constructs that are required, in additionis used to represent the
[ RIF-PRD condition language] andindividual actions in the [ RIF-PRDaction language], to represent, and interchange, completepart of a production rules andrule
sets. The RULE construct is an abstract class:represented in RIF-PRD instance documents, it is either visible as a ConditionalStatement or as a Forall : The ConditionalStatement associates an optional FORMULA and one non-empty ordered list of ACTIONS . Editor's Note: Difference wrt RIF-BLD: The ConditionalStatement is the Implies construct of RIF-BLD. However, the word "Implies" does not carry the appropriate meaning forRIF-PRD.
The proposal is to rename the Implies in RIF-BLD (to ConditionalStatement or whatever other name that is prefered) so that RIF-BLD and RIF-PRD can inherit the same construct from Core? The Forall construct declare s one or more Var s, and associates them with zero or more FORMULA s, as pattern s that constrain the bindingsThis version of the variables,RIF-PRD covers two ACTIONs:
ASSERT and with one RULE as the formula in its scope. The RuleSet construct has zero or more constructs of the RULE group associatedRetract.
As rule s. Editor's Note: Do we need ruleset parameters, etc? The following sections specify each construct separately, grouped byan abstract syntactic classes. Each elementclass, ACTION is given annot associated with
specific XML syntax,markup in the form of an informative BNF pseudo schema: the normative XML syntaxRIF-PRD instance documents. It is givenspecified
in the normative schema as a substitution group.
[ RIF-PRD XML schema]. 2.3.1 RULE In RIF-PRD, the RULE class of constructsASSERT | Retract ]
2.2.1.1 ASSERT
An ASSERT construct is used to represent rules,actions that
is "if-then" statements, possibly universally quantified. Asresult in asserting an abstract class, RULEatomic statement.
In this version of the draft, only the ASSERTion of an
Atom or of a Frame is covered by RIF-PRD.
For compatibility with RIF-BLD,
ASSERT is not associated with specific XML markup in
RIF-PRD instance documents.documents, and it is represented only as the
target Atom or Frame. It is specified in the
normative schema as a substitution group.
[ Atom | Frame ]
Editor's Note:
...Substitution group or another construct, depending on how we handle extensibility in the XML schema. [ ConditionalStatement | Forall ] Editor's Note: Difference wrt RIF-BLD: The FORMULA is optional in a ConditionalStatement , but a list of ACTIONS with a trivially satisfied FORMULA is notThe same, conceptually, as a head without a body inworking group seeks feedback regarding whether a logic program (e.g. it does not belongspecific XML
element should be used to serialize assertions, instead, to the
fact base). Thus, the rationale for making the head-without-a-body a different kindprice of RULE does not apply in the RIF-PRD case. ISSUE: how does Core represent a fact? Fromreducing the answer to that question depends whether PRD and BLD may differ on this; preferably, they should not differ. 2.3.1.1 ConditionalStatementinteroperability with RIF-BLD.
2.2.1.2 Retract
The ConditionalStatementRetract construct is used to represent actions that
result in negating an atomic statement.
In this version of the conditional statement (that is,draft, only the "if-then", or condition-conclusion,Retraction of an
Atom or antecedent-consequent pair) that is at the coreof a rule.Frame is covered by RIF-PRD.
The ConditionalStatementRetract element contains zero orhas one iftarget sub-element
and one then sub-element: the optional if elementthat contains an element from the FORMULA class of constructs,Atom or a Frame construct that
represents the condition of the rule;atomic statement to be removed on implementing the
required then element contains a non-empty list of elements fromaction.
<Retract>
<target> [ Atom | Frame ] </target>
</Retract>
Example
2.8. The ACTION class of constructs.example below shows the orderRIF XML representation of the ACTION constructs in the then element is significant and MUST be preserved. Editor's Note: Should we havean
"else"-part, in addition to the if-part and the then-part? Onaction that updates the one hand, it is one ofchicken-potato ownership table by removing
the rationale for separatingpredicate that states that the chicken denoted by variable
binding patterns FORMULAe from?c owns the if-part FORMULA; onpotato denoted by variable ?p. The
other hand, whatpredicate is represented as in example 2.3.
<Retract>
<target>
<Atom>
<op>
<Const type="rif:iri">
http://rif.examples.com/2008/jim#owns
</Const>
</op>
<args rif:ordered="yes">
<Var> ?c </Var>
<Var> ?p </Var>
</args>
</Atom>
</target>
</Retract>
2.3 Production Rules
This section specifies the support for it among the rule languagesRIF-PRD aimsconstructs that are required,
in addition to cover? <ConditionalStatement> <if> FORMULA </if>? <then> ACTION ACTION * </then> </ConditionalStatement> Editor's Note: Difference wrt RIF-BLD:the content ofones specified in the then element is specificsections on Conditions and Actions, to RIF-PRD (but PRDserialize, and
BLD share the structure of the construct). 2.3.1.2 Forallinterchange, complete production rules and rule sets.
The ForallRULE construct is used to represent universally quantified rules. Thean abstract class: in RIF-PRD
instance documents, it is either visible as a Implies, as
a Forall element contains: one, or more declare sub-elements, each containingas a Var element that represent one ofsingle ACTIONS:
- The
universally quantified variable; exactlyImplies associates one optional condition
FORMULA sub-element that represents the formula in the scope of the quantifierand that contains an elementone non-empty ordered list of
ACTIONS.
- The
RULE group;Forall construct declares one or more
Vars, and associates them with zero or more
pattern sub-elements, each containing an element from theFORMULA group of constructss, as patterns that represent a constraint onconstrain the bindings
of one ofthe Var s that are declared byvariables, and with one RULE as the
Forall . <Forall> <declare> Var </declare>+ <pattern>formula </pattern>* <formula> RULE </formula> </Forall>in its scope.
Editor's Note:
Difference wrt RIF-BLD:This version of the Foralldraft does not specify a specific construct to
serialize a ruleset in RIF-PRD adds, wrt BLD,RIF-PRD: the pattern sub-element to associate FORMULAs togeneric Group
construct can be used for that purpose - as specified in the declared Vars. Onenext
section, Groupings and
metadata. Future versions of this draft may specify a
specific-purpose construct, especially if semantically significant
information has to be associated to rulesets (e.g. parameters etc).
The rationale forworking group seeks feedback on this (see also ISSUE-63).
The Pattern sub-elementfollowing sections specify each construct separately,
grouped by abstract syntactic classes.
2.3.1 RULE
In RIF-PRD, the RULE class of constructs is used to
allow "if-then-else"represent rules.
Both differences areAs an abstract class, RULE is not associated with
specific to RIF-PRD. Example. The exmaple below shows the RIF-PRDXML representation of a simplified version ofmarkup in RIF-PRD instance documents. It is specified
in the CMP rule that reads: except on Tuesdays, every potato thet belongs tonormative schema as a chicken is mashed, andsubstitution group.
[ Implies | Forall | ACTION ]
2.3.1.1 Implies
The ownership tableImplies construct is updated ,used to represent the
conditional statement (that is, the "if-then", or
Forall ?c, where ?c is a jim:Chicken Forall ?p, where ?pcondition-conclusion, or antecedent-consequent pair) that is at the
core of a jim:Potato and owns(?c ?p)rule.
The Implies element contains an optional if
Not( jim:today() equal "Tueday" Then mash(?p)sub-element and remove (?c ?p)a then sub-element:
- the optional if element contains an element from the
ownership table. Some tags and content are emphasized (bold-face) for readibility inFORMULA class of constructs, that represents the XML fragment below. .condition
of the complete RIF-PRD XML representationrule;
- the required then element contains a non-empty list of
elements from the ACTION class of constructs. The
CMP rule can be foundorder of
the ACTION constructs in [ appendix XXX]. < Forall > <declare> <Var> ?c </Var> </declare> <pattern> < Member > <object> <Var> ?c </Var> </object> <class> <Const type="rif:iri"> jim:Chicken </Const> </class> </Member> </pattern> <formula> < Forall > <declare> <Var> ?p </Var> </declare>+ <pattern> < And > < Member > <object> <Var> ?p </Var> </object> <class> <Const type="rif:iri"> jim:Potato </Const> </class> </Member> <Atom> <op> <Const type="rif:iri"> jim:owns </Const> </op> <arg> <Var> ?c </Var> </arg> <arg> <Var> ?p </Var> </arg> </Atom> </And> </pattern> <formula> <ConditionalStatement> < if > <: NmNot > <formula> < Equal > <side> <External> <content> <Expr> <op> <Const type="rif:iri"> jim:today </Const> </op> </Expr> </content> </External> </side> <Const type="jim:DayOfTheWeek"> Tuesday </Const> <side> </side> </Equal> </formula> </NmNot> </if> <the then > < Execute > <op> <Const type="rif:iri"> jim:mash </Const> </op> <arg> <Var> ?p </Var> </arg> </Execute> < Retract > <target> <Atom> <op> <Const type="rif:iri"> jim:owns </Const> </op> <arg> <Var> ?c </Var> </arg> <arg> <Var> ?p </Var> </arg> </Atom> </target> </Retract>element is
significant and MUST be preserved.
<Implies>
<if> FORMULA </if>?
<then rif:ordered="yes">
ACTION
ACTION*
</then>
</ConditionalStatement> </formula> </Forall> </formula> </Forall> 2.3.2 RuleSet</Implies>
2.3.1.2 Forall
The RuleSetForall construct is used to represent a set of rules that have to be considered together from a semanticuniversally
quantified rules.
The Forall element contains:
- one or
operational viewpoint (e.g. a knowledge base, a rule base,more declare sub-elements, each containing a
ruleset). The RuleSetVar element containsthat represents one of the universally
quantified variable;
- zero or more
rule element.pattern sub-elements, each rule element containscontaining an
element from the RULEFORMULA group of constructs that
represents a constraint on the bindings of one of the rules containedVars
that are declared by the Forall;
- exactly one formula sub-element that represents the
formula in the
rule set. Editor's Note: Shouldn'tscope of the quantifier and that be "at least onecontains an element
of the RULE element"? Editor's Note: RuleSet parameters? Input/ouput Vars? <RuleSet> <rule>group.
<Forall>
<declare> Var </declare>+
<pattern> FORMULA </pattern>*
<formula> RULE </rule>* </RuleSet></formula>
</Forall>
Editor's Note:
Difference wrt BLD:Nested Foralls make explicit the RuleSet construct does not exist in BLD, although its grouping capability can be represented byscope of the Group construct. However, production rule systems usedeclared
variables, and, thus, impose an order on the ruleset as a first-class construct, passing parameters and scoping local variables. 2.4 Groupingevaluation of the
pattern and metadata TBD 2.5 Presentation syntax This section specifiesif FORMULAe in a presentation syntax for RIF-PRD. The presentation syntax is not normative: its main purpose is to help makerule. That
ordering and the normative specificationuse of the semantics easierpatterns to read. The presentation syntax is specified byconstrain the following EBNF, directly in termsbinding of
namesvariables may be of the XML elements specified in the previous sections (and, normatively, in the [ XML schemapractical significance for RIF-PRD]. Where elements with the same namesome production rule
systems, but they are used in different contextirrelevant with different content, which would leadrespect to ambiguous productions,the ambiguous name has been appended to a disambiguating, context-specific prefix: namely,intended
semantics of the namerules being interchanged (although they would be
relevant if RIF-PRD was to be extended to support some kind of
"else" or "case" construct). In addition, RIF-BLD does not allow nested Forall and
does not support the containing element. Specifically,association of contraining patterns
to declared variables. The target roleworking group seeks feedback regarding
whether nested Forall and constrainting pattern
should be supported in the Assign production (and element) has been renamed assign_targetRIF-PRD, to differenciate it fromthe target rolecost of other ACTION elements, andreducing the
interoperability with RIF-BLD.
Example
2.10. The example below shows how the CMP rule extract: "if
a chicken owns a potato and ..." could be serialised using a
binding pattern FORMULA role in:
<Forall>
<declare><Var>?chicken</Var></declare>
<formula>
<Forall>
<declare><Var>?potato</Var></declare>
<pattern>
<External>
<content>
<Atom>
<Const type="rif:iri">
http://rif.examples.com/2008/jim#owns
</Const>
<Args rif:ordered="yes">
<Var>?chicken</Var>
<Var>?potato</Var>
</Args>
</Atom>
</content>
</External>
</pattern>
<formula>
...
</formula>
</Forall>
</formula>
</Forall>
2.4 Grouping and metadata
This section specifies the Forall production has been renamed forall_formula . TERM ::= Const | Varadditional constructs that are needed
to build a complete instance RIF-PRD document, to group rules into
rulesets, and to serialize the metadata that is possibly associated
with elements of a rule, a group of rules or a RIF-PRD instance
document.
2.4.1 Group
The Group construct is used to represent groups of
rules. In RIF-PRD, it is used to serialise rulesets, but it can be
used more generally.
The Group element has zero or more sentence
sub-elements that contain each another Group element or an
element of the abstract RULE class of constructs.
<Group>
<sentence> [ RULE | External Const ::= LITERAL '^^' type ('@' xml:lang)? LITERAL ::=Group ] </sentence>*
</Group>
2.4.2 Document
The Document is the top level construct in a RIF-PRD
instance document.
The Document contains zero or one payload
sub-element, that must contain a Group element.
<Document>
<payload> Group </payload>?
</Document>
2.4.3 Metadata
Metadata can be associated with any Unicode string type ::= IRI xml:lang ::= xs:language Var ::= xs:NMTOKEN External ::= ' External( ' op ' ( ' arg* ' )) ' op ::= TERM arg ::= TERM ATOMIC ::= Atom | Equal | Member | Subclass | Frame Atom ::= op ' ( ' arg* ' ) ' Equal ::= side ' = ' side side ::= TERM Member ::= object ' # ' class object ::= TERM class ::= TERM Subclass ::= subClass ' ## 'construct that represents a
concrete class subClass ::= TERM Frame ::= object 'element in RIF-PRD: those are the elements with a
CamelCase tagname starting with an upper-case character:
CLASSELT = [ ' (key ' -> ' val)* ' ] ' key ::= TERM val ::=TERM FORMULA ::=| ATOMIC | ExternalFORMULA | AndACTION | OrRULE | NafGroup | Exists And ::= 'AND ( ' formula* ' ) ' formula ::= FORMULA Or ::= 'OR ( ' formula* ' ) ' NmNot ::= ' NOT ( ' formula ' ) ' Exists ::= ' Exists ' declare+ ' ( ' formula ' ) ' declare ::= Var ACTION ::= Assert | Retract | Update | Execute | Assign Assert ::= ' ASSERT ( ' target ' ) ' target ::= ATOMIC Retract ::= ' RETRACT ( ' target ' ) ' Update ::= ' UPDATE ( ' target ' ) ' Execute ::= ' EXECUTE { ' op ' ( ' arg* ' ) } ' Assign ::= ' SET ( ' assign_target 'Document ]
) ' assign_target ::= Frame RULE ::= ConditionalStatement | Forall ConditionalStatement ::= (' IF ' if ' THEN ')? then if ::= FORMULA then ::= ACTION (' ; ' ACTION)* Forall ::= ' Forall ' declare+ (' SUCHAn identifier can be associated to any construct of the abstract
CLASSELT class of constructs, as an optional id
sub-element that ' pattern)* ' ( ' forall_formula ' ) ' pattern ::= FORMULA forall_formula ::= RULE RuleSet ::= 'RULESET ( ' rule* ' ) ' rule ::= RULE Example.MUST contain a Const of type
rif:local or rif:iri.
Metadata can be included in any instance of a concrete class
element using the example below showsmeta sub-element.
The RIF-PRD presentation syntax forFrame construct is used to serialize
metadata: the simplified versioncontent of the CMP rule shown in example XX.Frame's object
sub-element identifies the RIF-PRD presentation syntax forobject to which the complete CMP rulemetadata is
shows in [ appendix XX]. FORALL ?c SUCH THAT ?c#jim:Chicken^^rif:iri ( FORALL ?p SUCH THAT AND( ?p#jim:Potato^^rif:iri jim:owns^^rif:iri(?c ?p)) ( IF NOT( jim:today^^rif:iri() = "Tuesday"^^jim:DayOfTheWeek ) THEN EXECUTE( jim:mash^^rif:iri(?p) ); RETRACT ( jim:owns^^rif:iri(?c ?p) ) ) ) 3 Operational semantics 3.1 Introduction Forassociated:, and the purpose of specifyingFrame's slots represent the
semantics of a RIF-PRD RuleSet , a production rule system PRS is definedmetadata properly said as a labelled terminal transition system (e.g. Plo04 ). Definition (labelled terminal transition system): A labelled terminal transition system is a structure { Γ , L , →, T }, where Γ is a set of elements, γ , called configurations; L is a set of elements, α , called actions (or labels); → ⊆ Γ × L × Γ isproperty-value pairs.
If the transition relation, that is: ( γ, α, γ' ) ∈ → iff thereall the metadata is a transition labelled α fromrelated to the configuration γsame object, the
meta element can contain a single Frame
sub-element. If metadata related to several different objects need
be serialized, the configuration γ' or,meta role can contain an And
with zero or more appropriately informula sub-elements, each containing
one Frameelement.
<CLASSELT>
<id> Const </declare>?
<meta>
[ Frame
|
<And>
<formula> Frame </formula>*
</And>
]
</meta>?
other CLASSELT content
</CLASSELT>
Notice that the casecontent of a PRS,the executionmeta sub-element of an
instance of action α in the configuration γ causesa transition to configuration γ' . We note: γ + α → γ' or γ α → γ' ; T ⊆ ΓRIF-PRD class element is not necessarily associated
to that same instance element: only the setcontent of final configurations,the
object sub-element of the Frame that is,represents
the setmetadata specifies what the metadata is about, not where it is
included in the instance RIF document.
It is suggested to use Dublin Core, RDFS, and OWL properties for
metadata, along the lines of allhttp://www.w3.org/TR/owl-ref/#Annotations
-- specifically owl:versionInfo, rdfs:label, rdfs:comment,
rdfs:seeAlso, rdfs:isDefinedBy, dc:creator, dc:description,
dc:date, and foaf:maker.
Example 2.11. TBC
2.5 Presentation syntax
This section specifies a presentation syntax for RIF-PRD. The
configurations γ from which there are no transitions: T = { γ ∈ Γ | ∀ α ∈ L, ∀ γ' ∈ Γ, ( γ, α, γ' ) ∉ →}. A labelled transition systempresentation syntax is a structure {Γ, L, →} (without a set T of final configurations).not normative: its main purpose is to help
make the ideanormative specification of describing a PRS as a labelled terminal transition systemthe semantics easier to
read.
The presentation syntax is that, givendesigned to be very close to RIF-BLD. A setline
by line comparison of production rules RS and a setthe EBNF will show these few differences:
- the addition of
facts w 0 ,Not
- the
rules in RS that are satisfied, in some sense, in w 0 determine an action α 1 , which execution results in a new setremoval of facts w 1 ;Expr, the rules in RS that are satisfied in w 1 determine an action α 2 to executesyntactic class of logical
functions,
- the replacement of ATOMIC in
w 1 ,rule conclusions with ACTION, and
so on, untilthe system reaches a final configurationreplacement of And(ATOMIC*) in rule conclusions with
Do(ACTION*)
- definition of ASSERT and
stops. The resultRetract actions.
It is intended that the setsyntax and semantics of facts w n whenRIF-BLD and
RIF-PRD are the system stops. Example. Judicael, one follower of Jimsame when the Hen Handler's method, has four chicken, Jim, Jack, Joerule conclusion contains a single
Atom or Frame, Not is not used, and Julia, that own three potatoes (BigPotato, SmallPotato, UglyPotato) among them: Jim (daily grain allowance = 10)logical functions are not
used.
The following EBNF is 12 months old, Jack (daily grain allowance = 12) is 9 months old, Joe (daily grain allowancefrom RIF-BLD, with
lines prefixed with ! indicating a change for RIF-PRD:
FORMULA ::= 'And' '(' FORMULA* ')' |
'Or' '(' FORMULA* ')' |
'Exists' Var+ '(' FORMULA ')' |
ATOMIC |
'External' '(' Atom | Frame ')' |
! 'Not' '(' FORMULA ')'
ATOMIC ::= Atom | Equal | Member | Subclass | Frame
Atom ::= UNITERM
UNITERM ::= Const '(' (TERM* <| (Name '->' TERM)*) ')'
Equal ::= TERM ' = 6)' TERM
Member ::= TERM '#' TERM
Subclass ::= TERM '##' TERM
Frame ::= TERM '[' (TERM '->' TERM)* ']'
! TERM ::= Const | Var | 'External' '(' Expr ')'
Expr ::= UNITERM
Var ::= '?' UNICODESTRING
The following EBNF is 6 months oldtaken from RIF-DTB and Julia (daily grain allowance = 14)is
10 months old; BigPotato weights 70g, SmallPotato weights 10g, UglyPotato weights 50g; Jim owns BigPotato, Jack and Woof own SmallPotato jointly (Woofunchanged for PRD. Its purpose is to provide shortcuts for
constants.
ANGLEBRACKIRI ::= '<' IRI_REF '>'
STRING ::= '"' UNICODESTRING '"'
CURIE ::= PNAME_LN | PNAME_NS → see RIF-DTB
Const ::= STRING '^^'ANGLEBRACKIRI
| STRING '^^' CURIE
| ANGLEBRACKIRI → shortcut for rif:iri
| CURIE → shortcut for rif:iri
| STRING → shortcut for xsd:string
| NumericLiteral → shortcut for xsd:integer,xsd:decimal,xsd:double
| '_' LocalName → shortcut for rif:local
The farm's dog. It inherited joint ownership of SmallPotatofollowing EBNF is from its aunt Georgette)RIF-BLD and
Joe owns UglyPotato. That is the initial setdefines rules, groups of facts w 0 . Paula's rule set contains one single rule, that is, Jim's CMP rule: Rule ChickensAndMashedPotatoes: Forall ?c, where ?c is a chickenrules, and the age of ?c in months is > 8; Forall ?p, where ?p is a potato, ?p is owned by ?c,containing document.
Changed lines are prefixed with !. Metadata can be associated
with Document, Group, and RULE
constructs.
! Document ::= IRIMETA? 'Document' '(' Group? ')'
Group ::= IRIMETA? 'Group' '(' (RULE | Group)* ')'
! RULE ::= (IRIMETA? 'Forall' Var+ ('(' FORMULA '))* '(' RULE ')') | CLAUSE
! CLAUSE ::= Implies | ACTION
! Implies ::= IRIMETA? (ACTION | 'Do' '(' ACTION* ')') ':-' FORMULA
IRIMETA ::= '(*' Const? (Frame | 'And' '(' Frame* ')')? '*)'
IRI ::= UNICODESTRING
Profile ::= UNICODESTRING
Finally, the weight in decigrams of ?p > (age of ?c)/2; If today is not Tuesday, and there is no fox infollowing EBNF describes the hen house Then mash ?p, increase the grain allowance of ?c by 10%, and remove the couple (?c, ?p) fromsyntax of PRD
actions.
ACTION ::= ASSERT | Retract
ASSERT ::= Atom | Frame
Retract ::= 'Retract' '(' Atom | Frame ')'
3 Operational semantics
3.1 Introduction
For the ownership relation. Whenpurpose of specifying the semantics of a RIF-PRD
RuleSet, a production rule system PRS is applied to w 0 : the first line selects {Jim/?c, Jack/?c, Julia/?c}defined as possible values for variable ?c (Joea
labeled terminal transition system (e.g. PLO04).
Definition (labeled terminal transition system): A
labeled terminal transition system is too young); the second line selects {(Jim/?c, BigPotato/?p)} as the only possible substitution for the variables ?c and ?p (UglyPotato does not belong to either Jim, Jack or Julia and SmallPotatoa structure {Γ,
L, →, T}, where
- Γ is
too small); Suppose that Judicael's implementationa set of today() returns Monday and that the foxAlarm()elements, γ, called
configurations;
- L is
false when the CMP rulea set of elements, α, called actions (or
labels);
- → ⊆ Γ × L × Γ is
applied:the conditiontransition relation, that is: (γ, α,
γ' ) ∈ → iff there is satisfied, and the actions ina transition labelled α from the
conclusion are executed with BigPotato substituted for ?p and Jim substituted for ?c . This results inconfiguration γ to the following changesconfiguration γ' or, more
appropriately in the setcase of facts: BigPotato is mashed (and removed froma PRS, the listexecution of potatoes to be consideredaction
α in future applications ofthe CMP rule); the daily grain allowance of Jim is now 11; Jim does not own a potato anymore.configuration γ causes a transition to
configuration γ' . We note: γ + α → γ' or γ
α→ γ';
- T ⊆ Γ is the
resultingset of final configurations, that is, the
set of all the configurations γ from which there are no
transitions: T = {γ ∈ Γ | ∀ α ∈ L, ∀ γ' ∈ Γ,
(γ, α, γ' ) ∉ →}.
A labeled transition system is a structure {Γ, L,
→} (without a set T of final configurations).
The idea of describing a PRS as a labeled terminal transition
system is that, given a set of production rules RS and a set
of facts w0, the rules in RS that are
satisfied, in some sense, in w0 determine an
action α1, which execution results in a new set
of facts w1; the rules in RS that are
satisfied in w1 determine an action
α2 to execute in w1, and so on,
until the system reaches a final configuration and stops. The
result is thus:the set of facts wn when the system
stops.
Example 3.1. Judicael, one follower of Jim the Hen
Handler's method, has four chickens, Jim, Jack, Joe and Julia, that
own three potatoes (BigPotato, SmallPotato, UglyPotato) among
them:
- Jim (daily grain allowance =
11)10) is 12 months old, Jack (daily
grain allowance = 12) is 9 months old, Joe (daily grain allowance =
6) is 6 months old and Julia (daily grain allowance = 14) is 10
months old;
- BigPotato weights 70g, SmallPotato weights 10g, UglyPotato
weights 50g;
- Jim owns BigPotato, Jack and Woof own SmallPotato jointly (Woof
is the farm's dog. It inherited joint ownership of SmallPotato from
its aunt Georgette) and Joe owns UglyPotato.
WhenThat is the CMP rule in applied toinitial set of facts w 1 , the first line still selects {?c/Jim, ?c/Jack, ?c/Julia} as possible0. Paula's
rule set contains one single rule, that is, Jim's CMP rule:
(* jim:ChickenAndMashedPotatoes *)
Forall ?chicken ?potato ?allowance ?age ?weight (
Do( Execute(jim:mash(?potato))
Retract(?chicken[jim:allowance->?allowance])
?chicken[jim:allowance->External(func:numeric-multiply(?allowance 1.1))]
Retract(jim:owns(?chicken ?potato)) )
:-
And( ?chicken#jim:Chicken
?chicken[jim:age->?age jim:allowance->?allowance]
External(pred:numeric-greater-than(?age, 8))
?potato#jim:Potato
?potato[jim:weight->?weight]
jim:owns(?chicken ?potato)
External(pred:numeric-greater-than(?weight External(func:numeric-divide(?age 2))))
External(pred:string-not-equals(External(jim:today()), "Tuesday"))
Not(External(jim:foxAlarm())) ))
When the rule is applied to w0:
- the first 3 conjuncts select {Jim/?chicken, Jack/?chicken,
Julia/?chicken} as possible values for variable
?c?chicken
(Joe is too young);
- conjuncts 4-7 select {(Jim/?chicken, BigPotato/?potato)}
as the only possible substitution for the variables ?chicken
and ?potato (UglyPotato does not belong to either Jim, Jack
or Julia and SmallPotato is too small);
Suppose that Judicael's implementation of today() returns
Monday and that the foxAlarm() is false when
the CMP rule is applied: the condition is satisfied, and the
actions in the conclusion are executed with BigPotato
substituted for ?potato, Jim substituted for
?chicken, and 10 substituted for ?allowance.
This results in the following changes in the set of facts:
- BigPotato is mashed (and removed from the list of
potatoes to be considered in future applications of the CMP
rule);
- the daily grain allowance of Jim is now 11;
- Jim does not own a potato anymore.
The resulting set of facts w1 is thus:
- Jim (daily grain allowance = 11) is 12 months old, Jack (daily
grain allowance = 12) is 9 months old, Joe (daily grain allowance =
6) is 6 months old and Julia (daily grain allowance = 14) is 10
months old;
- SmallPotato weights 10g, UglyPotato weights 50g;
- Jack and Woof own SmallPotato jointly and Joe owns
UglyPotato.
When the CMP rule in applied to w1, the first
External predicate still selects {Jim/?chicken, Jack/?chicken,
Julia/?chicken} as possible values for variable
?chicken, but the jim:own relation and the second
line doesExternal predicate do not select any possible substitution for the
couple (?c, ?p)(?chicken, ?potato) anymore: the rule cannot be
satisfied, and the system, having detected a final configuration,
stops.
The result of the execution of the system is
w1.
3.2 Definitions and notation
Let Const be the set of constant symbols that can be
represented in RIF-PRD, as determined by the the specification of
the Const construct; Var, the set of variable
symbols that can be represented in RIF-PRD, as determined by the
specification of the Var construct; and Term the
set of terms that can be represented in RIF-PRD, as determined by
the the specification of the TERM class of constructs. A
substitution is defined as follows (e.g. HAK07):
Definition (substitution): A substitution is a
finitely non-identical assignment of terms to variables; i.e., a
function σ from Var to Term such that the set
{x ∈ Var | x ≠ σ(x)} is finite. This
set is called the domain of σ and denoted by Dom(σ). Such a
substitution is also written as a set such as σ =
{ti/xi}i=1..n where
Dom(σ) = {xi}i=1..n and
σ(xi) = ti for i = 1 to
n.
Given X, a set of variables, and σ, a substitution such
that X ⊆ Dom(σ), σX denotes, in
this document, the restriction of σ to the variables in X:
σX = {σ(x)/x | x ∈ X}.
Let TermΣ be the set of ground terms (that can
be represented in RIF-PRD), defined as follows:
- if c ∈ Const, then c ∈
TermΣ;
- if f ∈ Const is the symbol of an externally
specified function and ti ∈
TermΣ for i = 1..n, then
External(f(t1 ... tn)) ∈
TermΣ.
Definition (ground substitution): A ground
substitution is a substitution σ such that ∀ x ∈
Dom(σ), σ(x) ∈ TermΣ.
The function Var(e) that maps a RIF-PRD element e
to the set of its free or universally quantified variables is
defined as follows:
- if e ∈ Const, then Var(e) = {};
- if e ∈ Var, then Var(e) = {e};
- if p ∈ Term and argi ∈
Term, for i = 0..n, then,
Var(p(argi) = Var(p) ∪i=0..n
Var(argi);
- if p ∈ Term and argi ∈
Term, for i = 0..n, then,
Var(External(p(argi)) = Var(p)
∪i=0..n Var(argi);
- if t1 ∈ Term and t2
∈ Term, then Var(t1 [=|#|##]
t2) = Var(t1) ∪
Var(t2);
- if o ∈ Term, ki ∈ Term
for i = 1..n, and vi ∈ Term for
i = 1..n, then Var(o[k1->v1 ...
kn->vn]) = Var(o)
∪i=1..n Var(ki) ∪i=1..n
Var(vi);
- if fi are RIF-PRD FORMULAs for
i = 0..n, then Var([AND|OR|NOT](fi)) =
∪i=0..n Var(fi);
- if f is a RIF-PRD FORMULA and
xi ∈ Var for i = 1..n, then,
Var(Exists x1 .. xn (f)) =
Var(f) - {xi}.
- if a is a RIF-PRD ATOMIC, then
Var([ASSERT|RETRACT|UPDATE|SET](a))Var([ASSERT|RETRACT](a)) = Var(a);
- if
op ∈ Term and arg i ∈ Term , for i = 0..n, then, Var(EXECUTE(op(arg i )) = Var(op) ∪ i=0..n Var(arg i ) ; iff is a RIF-PRD FORMULA and
ai, i = 1..n are RIF-PRD ACTIONs,
then Var(IF f THEN a1 ... an) = Var(f)
∪i=1..n Var(ai);
- if r is a RIF-PRD RULE, xi ∈
Var for i = 1..n, and pj, j
= 0..m, are RIF-PRD FORMULAs, then Var(Forall
x1 ... xn SUCH THAT pj (r)) =
Var(r) ∪j=1..m Var(pj);
- if ri, i = 0..n, are RIF-PRD
RULEs, then Var(RULESET(ri)) =
∪i=1..n Var(ri).
Definition (rule instance): An instance of a rule
r is a pair (rid, σ), where
rid uniquely identifies r and σ is a
ground substitution such that Var(r) ⊆ Dom(σ). Given
a rule r, id(r) denotes rid, the unique
identifier of r; given a rule instance ri =
(rid, σ), rule(ri) denotes the rule that is
uniquely identified by rid.
Definition (ruleset instance): an instance of a rule set
RS is a set of rule instances rii, where ∀
i, rule(rii) ∈ RS. Given a rule set
RS, Inst(RS) denotes the set of all the possible
instances of all the rules in RS.
Let W be the set of ground formulas that can be
represented in RIF-PRD, defined as follows:
- if p ∈ Const is the symbol of an externally
specified predicate and ti ∈
TermΣ for i = 1..n, then
External(p(t1 ... tn)) ∈
W</sub>W;
- if p ∈ Const is neither the symbol of an
externally specified predicate nor the symbol of an externally
specified function, and ti ∈
TermΣ for i = 1..n, then
p(t1 ... tn) ∈
W</sub>;
- if t1 ∈ TermΣ and
t2 ∈ TermΣ, then
t1 = t2 ∈ W;
- if t1 ∈ TermΣ and
t2 ∈ TermΣ, then
t1 # t2 ∈ W;
- if t1 ∈ TermΣ and
t2 ∈ TermΣ, then
t1 ## t2 ∈ W;
- if o ∈ TermΣ, ki ∈
TermΣ for i = 1..n, and
vi ∈ TermΣ for i = 1..n,
then o[k1->v1 ...
kn->vn] ∈ W;
- if fi ∈ W for i = 1..n, then
AND(f1 ... fn) and OR(f1
... fn) are ground formulas;
- if f ∈ W, then NOT(f) ∈ W;
- if f ∈ W and xi ∈ Var
for i = 1..n, then, ∀ n ≥ 1, Exists x1
.. xn (f) ∈ W. By convention, a ground
formula Exists x1 .. xn (f) is always
replaced by the semantically equivalent ground formula
f.
Editor's Note: ..or W could be defined, except for the Exists , as the set of the formulas f such that Var(f) = {}?Let L be the set of the atomic ground actions that can be
represented in RIF-PRD:
- if
TACTION isa targeted RIF-PRD ACTION : ASSERT , RETARCT , UPDATE or SET , and if its target element∈ W is a ground ATOMIC a ∈ W, them TACTION(a)then
ASSERT(a) ∈ L ; if f ∈ Const is the symbol of an externally specified functionand t i ∈ Term Σ for i = 1..n, then EXECUTE(f(t 1 ... t n ))RETRACT(a) ∈ L.
Editor's Note:
The definition of L is subject to change whenas the
ACTIONs will be specified more precisely.ACTION constructs are still under discussion.
Finally, let R be the set of all the rules that can be
represented in RIF-PRD.
In this document, given a set X, P(X) denotes the
power set of X, and S(X) denotes the set of the
ordered lists of elements of X.
Given an expression f and a set of ground instances
w, Eval(f, w) denotes the set of ground formulae that
results of evaluating f in the context of w. The
expression, f, is evaluated as a black-box: any side-effect
of the evaluation, on w or otherwise, depends only on the
specification of the semantics of f.
3.3 Operational semantics of
actions
Editor's Note:
The operational semantics of actions in RIF-PRD is still under
discussion (see ISSUE-66). It
will evolve as the semantics to be associated with the actions that
are already specified is refined, in particular with respect to the
creation and delation of objects; and as new ACTION
constructs are added. The working group seeks feedback regarding
what operational semantics would be most usefully associated with
RIF-PRD ACTION constructs.
Let The transition relation →RIF-PRD ⊆
P(W) × L × P(W) is defined as follows:
- ∀ w ⊆ P(W), w + ASSERT(f)
→RIF-PRD w' = w ∪ {f};
- ∀ w ⊆ P(W), w + RETRACT(f)
→RIF-PRD w' =
w - fw\f;
∀Rule 1 specifies that the Assert construct should be
used when the intended action is to add a fact to a set of ground
facts w ⊆ P(W) , w + UPDATE(f) → RIF-PRD w' = TBD ; ∀ w ⊆ P(W) , w + EXECUTE(f) → RIF-PRD w' = TBD ; ∀. Rule 2 specifies that the Retract
construct should be used when the intended action is to remove a
fact from w ⊆ P(W), w + ASSIGN(f) → RIF-PRD w' = TBD ;instead.
The intended semantics of the actions that can be represented in
RIF-PRD is completely specified by the definition of the labelled
transition system {P(W), L,
→RIF-PRD}.
Editor's Note: The definition of W would need to be modified if we wanted to cover non-ground facts as well, but the definition of the relation would remain essentially the same.The relation →*RIF-PRD ⊆
P(W) × S(L) × P(W) denote the transitive
closure of the transition relation
→RIF-PRD.
3.4 Operational semantics of rule
sets
A RIF-PRD production rule system is defined as a labelled
terminal transition system: given a rule set RS ⊆ R, let
CRS ⊆ W × S(Inst(RS)) ×
P(Inst(RS)) be a set of configurations, where a configuration
is a triple c = (w, ric, h), such that w ⊆
W is a set of facts, ric ∈ S(Inst(RS)) is an
ordered instance of RS, and h ∈ P(Inst(RS)) is an
instance of RS. Given a configuration c = (w,
ric, h), let facts(c) denote the first
element, the set of facts w; let instance(c) denote
the second element, the ordered ruleset instance,
ric; and let history(c) denote the third
element, the set of rule instances h.
The idea is that a configuration, c, is made of a set,
w, of ground FORMULAe that represent a state of
facts; the set, ric, of all the instances of the
rules in the considered ruleset RS that are satisfied, in
some sense to be further specified, in that state of fact; and a
set, h of rule instances that represent a part of the
history of the system, in that it collects the rule instances that
determined some of the actions that led to the present
configuration, and that have been satisfied, in the same sense as
before, in all the states of facts that have been traversed since.
In the same way, the order among the rule instances, in
ric, represents another part of the system's
history: the longer a rule instance has been continuously satisfied
by the states of facts of the traversed configurations, in terms of
number of configurations, the farther it is in the ordering. These
elements of the history of the system are relevant when selecting
the next transition.
Let further assume three functions:
- INSTANTIATE: P(W) × P(R) →
P(Inst(R)), that, given a set of facts, w and a set
of rules, RS, returns the set of all the instances of the
rules in RS that are satisfied in w, in a sense that
is determined by the specification of the function;
- PICK: CRS ×
S({priority, recency, all}) → P(Inst(R)), that, given
a configuration, c, and a selection strategy, returns the
ordered subset, ori ⊆ instance(c), selected according
to the input strategy, of the rule instances that determine the
ordered list of ground actions to be implemented, that is, the
sequence of transitions to be executed from the input
configuration;
- FINAL: CRS ×
P(R) → {true, false}, that, given a configuration and
a set of rules, returns true or false, depending on
whether or not the configuration is terminal.
Let mergeInstances: S(Inst(R)) × P(Inst(R))
→ S(Inst(R)), be a helper function that, given an ordered
set of rule instances, ori, and an unordered set of rule
instances, ri, returns ri, ordered in such a way that
the order of ori is preserved among all the rule instances
in ri ∩ ori, and the rule instances in ri - ori come
first in the order.
Let extractActions: S(Inst(R)) → S(L), be
another helper function that, given an ordered set, ori, of
rule instances, returns the sequence of ACTIONs that is
the concatenation, preserving the order in ori, of the
sequences of ground actions determined by each of the rule
instances in ori.
Given a ruleset RS and a selection strategy LS, a
RIF-PRD production rule system is defined as a labelled terminal
transition system PRSRS,LS =
{CRS, S(L),
→RS, TRS},
where :
- CRS is the set of
configurations;
- S(L) is the set of labels;
- The transition relation →RS ⊆
CRS × S(L) ×
CRS, is defined as follows:
∀ (c, s, c' ) ∈
CRS × S(L) ×
CRS, (c, s,
c' ) ∈ →RS if and only if all of the
following hold:
- s = extractACTIONS(PICK(c, LS))
- and (facts(c), s, facts(c')) ∈
→*RIF-PRD
- and instance(c') = mergeInstances(instance(c),
INSTANTIATE(w, RS))
- and history(c') = (history(c) ∩
instance(c)) ∪ PICK(c, LS)
- and c ∉ TRS
- A configuration c is final iff FINAL(c, RS) =
true: TRS = {c ∈ CRS |
FINAL(c, RS) = true}.
Intuitively, the conditions 1 in the definition of the
transition relation →RS guarantees that only
the specification of the function PICK and the selection
strategy determine which are the allowed transition paths out of a
given configuration, and condition 2 guarantees that all
transitions are compliant with the semantics of the individual
actions, as specified the relation →RIF-PRD.
Condition 3 guarantees that the instance component of any
reachable configuration contains all the instances of the rules in
RS that are satisfied in the configuration's state of facts,
ordered in the appropriate way. Condition 4 means that the systems
keeps a memory of the rule instances which action part has been
executed, and that have been been part of the instances returned by
INSTANTIATE in all the configurations that have been since
traversed. And condition 5 guarantees that the system halts as soon
as it encounters a terminal configuration.
The input function is defined as:
Eval(RS, w) →RS (w, INSTANTIATE(w,
RS), ∅) ∈ CRS
The output function is defined as:
(w', riw', h) ∈ TRS
→RS w'
Or, using →*RS to denote the
transitive closure of the transition relation:
Eval(RS, w) →*RS
w'
Given the specification of
PRSRS,LS, the intended operational
semantics of a production ruleset represented by a RIF-PRD
RuleSet RS is completely specified by the
specification of the three functions INSTANTIATE,
PICK and FINAL.
3.4.1 Rules instantiation:
INSTANTIATE
The evaluation of the function INSTANTIATE corresponds to
the step that is often called matching in the description of
production rule systems (e.g. PRR07).
Indeed, the function is most easily specified using the widely
spread notion of pattern matching. The following definition
is adapted from CIR04.
Definition (pattern matching): Given a set w ⊆
W of ground RIF-PRD ATOMICs and a RIF-PRD
FORMULA p, p is said to match
w with respect to a theory τ and a ground
substitution σ, denoted σ(p) «τ w, iff one of the
following is true:
- p is a RIF-PRD ATOMIC and ∃ f ∈ w
such that σ(p) =τ f (read: σ(p) is
identical to f modulo τ);
- p is a RIF-PRD External and σ(p)
evaluates to true;
- p is a RIF-PRD And that contains no conjunct,
that is, p = AND();
- p = AND(p1 ... pn), i =
1..n, and ∀ pi, σ(pi) «τ
w;
- p = OR(p1 ... pn), i =
1..n, and ∃ pi such that σ(pi)
«τ w;
- p = NOT(p') and σ(p') does not match w
with respect to τ;
- p = Exists {xi} p' , where
{xi}, i = 1..n, denotes the set of the
variables that are existentially quantified in p, and there
is a substitution θ with {xi} ⊆ Dom(θ), Dom(σ)
⊆ Dom(θ) and ∀ y ∈ Var(p') - {xi}, θ(y) =
σ(y), such that θ(p') «τ w.
A set P of RIF-PRD FORMULAe is said to match a
set w ∈ W of ground RIF-PRD ATOMICs with respect to
a theory τ and a ground substitution σ, denoted σ(P)
«τ w, iff σ(pi) «τ w
for all pi ∈ P.
Editor's Note:
The definition is easily, if tediously, extended to cover the case of matching arbitrary FORMULAe against any set of ground FORMULAe ⊆ W . Editor's Note: Thematching theory τ to be taken into account includes the
equality theory defined between frames, the builtin datatypes,
functions and relations, and any externally defined datatypes,
classification theory, functions and relations as required by the
ruleset. This is to be further specified when references to
application-specific data models and externals is specified.
Editor's Note: Do we need to go into any deeper details wrt the matching of ATOMICs, or is that unambiguous enough? Example.Example 3.2. TBD
Let InstantiateRULE: P(W) × R → P(Inst(R)), be a function
that, given a set of facts w ∈ W and a rule r
∈ R, returns a set, ir ⊆ Inst(R), of instances
of r.
The evaluation of InstantiateRULE(w, r) is specified
based on a terminal transition system where:
- A configuration is a quintuple (w, r, σ, Σ, acc), where
w ⊆ W, r ∈ R, σ is either either the
empty set, or a substitution such that Var(r) ∈
Dom(σ), Σ is a set of substitutions such that σ ∈ Σ or σ =
∅, and acc is a pair (id, Σ'), where id is the
unique identifier of a rule, and Σ' is a set of substitutions;
- The transition relation is defined by the following rules:
- if σ ∈ Σ:
(w, r, ∅, Σ, acc) → (w, r, σ, Σ - σ,
acc)
- if σ ∈ Σ and either σ(P) «τ
w, or P is empty:
(w, Forall {xi} P (r), σ, Σ, acc) →
(w, r, σ, Σ, acc)
- if σ ∈ Σ and ¬(σ(P) «τ
w):
(w, Forall {xi} P (r), σ, Σ, (id, Σ')) →
(w, rule(id), ∅, Σ, (id, Σ'))
- if σ ∈ Σ and σ(c) «τ w:
(w, IF c THEN a, σ, Σ, (id, Σ')) → (w, rule(id),
∅, Σ, (id, Σ' ∪ {σ}))
- if σ ∈ Σ and ¬(σ(c) «τ
w):
(w, IF c THEN a, σ, Σ, (id, Σ')) → (w, rule(id),
∅, Σ, (id, Σ'))
-
(w, THEN a, σ, Σ, (id, Σ')) → (w, rule(id), ∅, Σ,
(id, Σ' ∪ {σ}))
- Configurations where the set Σ of candidate substitutions is
empty are final: T = {(w, r, σ, ∅, acc)}.
Intuitively, a configuration is made of the set of facts,
w, against which the rule is instantiated; the rule,
r, to be instantiated; the substitution, σ, that is
under evaluation as possibly instantiating r in such a way
that its condition matches w; the set, Σ, of the
candidate substitutions that are still to be evaluated, including
σ; and the instances accumulator, acc, that relates
the identifier, id, of the input rule,
rinput, to the set of the
substitutions that have been evaluated and with respect to which
the condition of rinput is known
to match w.
Given a rule r ∈ R, let Σr
denote the set of the restrictions to Var(r) of all the
subtitutions σ such that Var(r) ⊆ Dom(σ):
Σr = {σVar(r) | ∀ σ, Var(r) ⊆
Dom(σ)}.
The input function can now be defined as:
InstantiateRULE(w, r) → (w, r, ∅, Σr,
(id(r), ∅))
The output function is defined as:
(w, r, σ, ∅, (id, Σ')) → {(id, σ) | ∀ σ ∈
Σ'}
The role of the function InstantiateRULE is to loop
through all the possible substitutions for the variables of the
input rule, and to select the ones with respect to which all the
pattern FORMULAe in the Foralls of
rinput, if any, as well as the
if FORMULA, if there is one in
rinput, match w.
As a consequence, in the definition of the transition relation,
the first rule represents the initialisation of the process, when a
substitution σ is selected out of Σ for evaluation. The rules also
guarantees that each candidate substitution is evaluated once and
only once on each single path.
Rule 2 and 3 progress the instantiation through a rule's nested
Forall and guarantee that any pattern formula
associated with an enclosing Forall matches w with
respect to the substitution under consideration (rule 2) and that σ
is not further considered and rejected as soon as a
pattern formula does not match w with respect to
it; and that the process is re-initiated for another substitution
to be evaluated.
Rule 4 and 5 guarantee that a substitution that a substitution
is added to the ouput accumulator if (rule 4) and only if (rule 5)
the if FORMULA matches w with respect to
that substitution; and that the process is re-initiated for the
evaluation of another candidate substitution.
In complement to rule 4, rule 6 handles the trivial case where
the optional if FORMULA is missing, and thus
considered, by convention, matching every set of facts with respect
to any substitution and theory.
Editor's Note: There are certainly more elegant ways to make sure that all the possible instances have been found... Suggestion, anyone?The input function initializes the transition system with respect
to the state of facts and the rule, and the output function
transforms the set of selected substitutions in the accumulator in
the corresponding set of instances of the input rule.
Example.Example 3.3. TBD
The evaluation of the function INSTANTIATE(w, RS), where
w ⊆ W and RS ⊆ R, can now be specified
as a simple terminal transition system where:
- a configuration is a triple (w, rs, ri), where rs
⊆ RS and ri ⊆ P(Inst(RS - rs));
- the transition relation is defined by the single rule:
(w, rs, ri) → (w, a, rs - r, ri ∪
InstantiateRULE(w, r))
- configurations with an empty rule set component are final: T
= {(w, ∅, ri)}.
The input function is defined as:
INSTANTIATE(w, RS) → (w, RS, ∅)
The output function is defined as:
(w, ∅, ri) → ri
Editor's Note: To Be Added: textual explanation of the rules and the TTS (esp. re its confluence). Example.Example 3.4. TBD
3.4.2 Instances selection:
PICK
Editor's Note:
This section is still under discussion (see [ ISSUE-XX]).ISSUE-64).
This version of RIF-PRD specifies five elementary strategies, a way
of combining them, and a default combination. Future working drafts
may specify different and/or additional elementary strategies, and
no or a different default. The Working Group seeks feedback on
which instances selection strategies and which combinations of
strategies should be supported by RIF-PRD and/or required from
RIF-PRD implementations; and which strategy or combination should
be the default, if any.
A rule instance determines a sequences of ground actions, by
application of the associated substitution to the variables in the
ACTIONs in the then component of the instantiated
rule. The decision to implement the sequence of actions that a rule
instance determines is often called: firing the rule
instance.
Most implementations of production rule languages select the
rule instances to be fired, and, therefore, the sequence of actions
to be implemented, based on one or a combination of the following
strategies (under these or other, idiosyncratic names; and possibly
combined with additional, idiosyncratic rules):
- No-repetition. The no-repetition strategy
excludes from the selection of fireable rule instances, any rule
instance that has already been fired, unless the instantiation
environment has significantly changed since the actions have been
last implemented. This is usually taken to mean that there has been
at least one configuration where the state of facts did not satisfy
the rule instance, in the sense determined by the specification of
the INSTANTIATE function, since the rule instance has been
last fired;
- Priority. The rule instances are ordered by priority of
the instantiated rules, and only the rule instances with the
highest priority are selected. This requires that a priority be
associated with the RIF-PRD representation of each rule;
- Recency. the rule instances are ordered by how long a
rule instance has been continuously satisfied by the states of
facts of the traversed configurations, and only the most recent
ones are selected.
- Random. A singleton rule instance is selected at
random;
- All-at-once. All the rule instances are selected, and
they are fired in the order's sequence.
Let fireableINSTANCES: S(Inst(R)) ×
P(Inst(R)) × {no-repeat, priority, recency, random,
all} → S(Inst(R)) be a function that, given an ordered
set, ori, of candidate rule instances, a set, h, of
excluded rule instances, and a keyword, k, indicative of an
single selection strategy, return a subset fri ⊆ ori,
selected and ordered according to the strategy indicated by
k. The keywords "no-repeat"" and "all"
indicate, respectively, the no-repetition and
all-at-once selection strategies, and the other keywords
indicate each the strategy by the same name.
The function fireableINSTANCES is precisely specified in
the next subsection.
The function PICK(c, LS) can be specified with the help
of a terminal transition system where:
- a configuration is a triple (LS, ori, c) ⊆
S{priority, recency, all} × S(Inst(RS)) ×
CRS;
- the transition relation is completely specified by the
following two rules:
- if s = "all", then
(sLS', ori, c) → (∅, ori, c)
- if s ≠ "all", then
(sLS', ori, c) → (LS', fireableINSTANCES(ori,
history(c), s), c)
- a configurations (LS, ori, c) is final if and only if
LS = ∅.
The input function is defined as:
PICK(c, RS, sLS) → (LS"random",
fireableINSTANCES(instance(c), history(c), "no-repeat"),
c)
The output function against is defined as:
(∅, ori, c) → ori
Intuitively, the strategy for the selection of the rule
instances to be fired that is intended for the set of rules
represented by a RIF-PRD Ruleset, is :
- starting from the ordered set returned by INSTANTIATE in
the configuration, to remove the instances that were already fired,
as listed in the configuration's history. That is, the
no-repetition strategy is always applied first;
- successive subsets of instances are selected per the sequence
of selection strategies keywords associated with the
Ruleset;
- and, finally, a single rule instance is selected at random from
the resulting subset. That is, the random strategy is always
applied at the end of the selection process.
In other words, if the sequence of strategies provided with a
RIF-PRD Ruleset is LR, the intended selection
strategy is:
"no-repeat" LR "random"
The default, when no selection strategy is explicitely indicated
for a Ruleset, is, therefore:
"no-repeat" "random"
The exception is the all-at-once strategy, represented in
RIF-PRD by the keyword : "all". If that keyword appears
anywhere in the sequence, the intended strategy is that all the
rule instances that have been selected at that point be fired in
sequence, in the order of the selection. That is, if the sequence
of strategies provided with a RIF-PRD Ruleset is
LR1"all"LR2, the intended selection
strategy is :
"no-repeat" LR1
3.4.2.1 fireableINSTANCES
The operational semantics of the function
fireableINSTANCES depends on its third argument, the
elementary selection strategy. It is therefore specified separately
for each value of that parameter, that is, for each of the supportedindividual rule
instances selection strategy.strategy supported by RIF-PRD.
Editor's Note:
The precise operational semantics of the "no-repetition",
"priority" and "recency" strategies are still under discussion in
the working group. In addition, this working draft does not specify
a way to specify a non-defaultthe intended instance selection strategy for a
RIF-PRD ruleset in a RIF document. As a consequence, only
the elementary strategies that are required to implement the default"random" strategy areis precisely specified in this version.
No-Retition. The evaluation of the functionNo-Repetition. TBD
Priority. TBD
Recency. TBD
Random. fireableINSTANCES(ori, h, "no-repeat")"random"), where
ori ∈ S(Inst(R)) is an ordered set of candidate rule instancesand h ∈ P(Inst(R)) is, returns a
set of excluded rule instances, can be specified with the helprandomly selected singleton subset of a simple terminal transition system, where, a configuration is a triple (IN,ori:
fireableINSTANCES(ori, h, OUT) ⊆ S(Inst(R)) × P(Inst(R)) × S(Inst(R)) , where IN and OUT are two sequences of rule instances, and h is a set of rule instances; the transition relation is defined by the following two rules: if r ∈ h , then (rIN', h, OUT) → (IN', h, OUT) if r ∉ h , then, (rIN', h, OUT) → (IN', h, OUTr) a configration is final if and only if its first component, IN , is empty. The input function is specified as: fireableINSTANCES (ori, h, "no-repeat") → (ori, h, ∅) The output function is defined as: (∅, h, OUT) → OUT The system walks through the input ordered set of candidate rule instances ori and rewrite it in the output set, perserving the order (as guaranteed by rule 2) but removing any element that belongs to the input set of excluded rule instance h (as guaranteed by rule 1). Example. TBD Random. fireableINSTANCES(ori, h, "random") , where ori ∈ S(Inst(R)) and h ∈ P(Inst(R)) , returns a randomly selected singleton subset of ori : fireableINSTANCES(ori, h, "random") → {ri}"random") → {ri}, such
that ri ∈ ori.
3.4.3 Halting test: FINAL
Editor's Note:
This section is still under discussion (see [ ISSUE-XX]).ISSUE-65).
This version specifies a single, default halting test: future
version of this draft may specify additional halting tests, and/or
a different default. The WorkingWorking Group seeks feedback on which
halting tests and which combinations of tests should be supported
by RIF-PRD and/or required from RIF-PRD implementations; and which
halting test should be the default, if any.
By default, the specification for a terminal configuration that
is intended for a set of production rules, when no halting test is
explicitely associated to its representation as a RIF-PRD
Ruleset, is when no rule instance is fireable: this is the
case when INSTANTIATE returns an empty set of rule
instances, or when all the rule instances that are satisfied in the
configuration, according to the semantics of INSTANTIATE,
have already been fired in a configuration that has not since
changed significantly. That latter condition guarantees, in
particular, that the system halts when it reaches a fixpoint.
Formally, ∀ RS ⊆ R, ∀ c ∈ CRS,
PICK(c, RS) = true if and only if instance(c) - history(c) =
∅. Otherwise, PICK(c, RS) = false.
4 References
- [CIR04]
- Production
Systems and Rete Algorithm Formalisation, Cirstea H.,
Kirchner C., Moossen M., Moreau P.-E. Rapport de recherche n°
inria-00280938 − version 1 (2004).
- [CURIE]
- CURIE
Syntax 1.0 - A compact syntax for expressing URIs, W3C note
27 October 2005, M. Birbeck (ed.).
- [HAK07]
- Data
Models as Constraint Systems: A Key to the Semantic Web,
Hassan Ait-Kaci, Constraint Programming Letters, 1:33--88,
2007.
- [PLO04]
- A
Structural Approach to Operational Semantics, Gordon D.
Plotkin, Journal of Logic and Algebraic Programming, Volumes 60-61,
Pages 17-139 (July - December 2004).
- [PRR07]
- Production Rule
Representation (PRR), OMG specification, version 1.0,
2007.
- [RDF-CONCEPTS]
- Resource Description Framework (RDF): Concepts and Abstract
Syntax, Klyne G., Carroll J. (Editors), W3C Recommendation, 10
February 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/.
Latest version available at http://www.w3.org/TR/rdf-concepts/.
- [RDF-SCHEMA]
- RDF Vocabulary Description Language 1.0: RDF Schema,
Brian McBride, Editor, W3C Recommendation 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-schema-20040210/.
Latest version available at http://www.w3.org/TR/rdf-schema/.
- [RFC-3066]
- RFC 3066
- Tags for the Identification of Languages, H. Alvestrand,
IETF, January 2001, http://www.isi.edu/in-notes/rfc3066.txt.
- [RFC-3987]
- RFC 3987
- Internationalized Resource Identifiers (IRIs), M. Duerst and
M. Suignard, IETF, January 2005, http://www.ietf.org/rfc/rfc3987.txt.
- [XDM]
- XQuery 1.0 and XPath 2.0 Data Model (XDM), W3C
Recommendation, World Wide Web Consortium, 23 January 2007. This
version is http://www.w3.org/TR/2007/REC-xpath-datamodel-20070123/.
Latest version available at http://www.w3.org/TR/xpath-datamodel/.
- [XML-SCHEMA2]
- XML Schema Part 2: Datatypes Second Edition, W3C
Recommendation, World Wide Web Consortium, 28 October 2004,
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.
Latest version available at http://www.w3.org/TR/xmlschema-2/.
- [XPath-Functions]
- XQuery 1.0 and XPath 2.0 Functions and Operators, W3C
Recommendation, World Wide Web Consortium, 23 January 2007,
http://www.w3.org/TR/2007/REC-xpath-functions-20070123/.
Latest version available at http://www.w3.org/TR/xpath-functions/.
5 Appendix: XML Schema for
RIF-PRD
TBD
6 Appendix: Compatibility with
RIF-BLD
6.1 Syntactic compatibility between
RIF-PRD and RIF-BLD
RIF-PRD and RIF-BLD share essentially the same presentation syntax
and XML syntax.
The syntactic differences between the two dialects are
summarized below:
- RIF-BLD allows
logic and externally specified, fixed-interpretation functions as
TERM, whereas RIF-PRD accepts only externally specified
functions;
- RIF-BLD allows
ATOMIC or And(ATOMIC*) in rule conclusions,
whereas RIF-PRD allows ACTION or Do(ACTION*). In
RIF-PRD it is not possible to conclude equality or class
membership.
- RIF-PRD allows Not(FORMULA), which RIF-BLD does not
accept;
- RIF-PRD defines ASSERT and Retract actions that are not allowed
in RIF-BLD.
Below is a complete, construct by construct, comparison table of
RIF-PRD and RIF-BLD
presentation and XML syntaxes. A construct is tagged "BLD" or "PRD"
if it is specific to the dialect, or tagged "Core" if it is common
to both.
Editor's Note:
RIF-Core will be equal to or included in the intersection of
RIF-PRD and RIF-BLD. The exact scope of RIF-Core is still under
discussion. Until RIF-Core is specified more precisely, this
document assumes that it will be equal to the intersection of
RIF-PRD and RIF-BLD.
|
Presentation syntax |
XML syntax |
|
TERM ::= |
| BLD |
[Const | Var | Expr | External]
|
| PRD |
[Const | Var | External]
|
|
Const ::= |
| Core |
'"' UNICODESTRING '"^^' SYMSPACE
|
<Const type=xsd:anyURI [xml:lang=xsd:language]? >
Any Unicode string
</Const>
|
|
Var ::= |
| Core |
'?' Any Unicode string
|
<Var>
Any Unicode string
</Var>
|
|
Expr ::= |
| BLD |
Const '(' (TERM* | (Name '->' TERM)*) ')'
|
<Expr>
<op> Const </op>
[
<args rif:ordered="yes"> TERM* </args>?
|
<slot rif:ordered="yes">
<Name> Any Unicode string </Name>
TERM
</slot>*
]
</Expr>
|
| PRD |
Undefined except when wrapped in an External (as TERM), as follows.
|
|
External (as TERM) ::= |
| Core |
'External' '(' Expr ')'
|
<External>
<content>
Expr
</content>
</External>
|
|
ATOMIC ::= |
| Core |
[Atom | Equal | Member | Subclass | Frame]
|
|
Atom ::= |
| Core |
Const '(' (TERM* | (Name '->' TERM)*) ')'
|
<Atom>
<op> Const </op>
[
<args rif:ordered="yes"> TERM* </args>?
|
<slot rif:ordered="yes">
<Name> Any Unicode string </Name>
TERM
</slot>*
]
</Atom>
|
|
Equal ::= |
| Core |
TERM = TERM
|
<Equal>
<left> TERM </left>
<right> TERM </right>
</Equal>
|
|
Member ::= |
| Core |
TERM # TERM
|
<Member>
<instance> TERM </instance>
<class> TERM </class>
</Member>
|
|
Subclass ::= |
| Core |
TERM ## TERM
|
<Subclass>
<sub> TERM </sub>
<super> TERM </super>
</Subclass>
|
|
Frame ::= |
| Core |
TERM ' [ ' (TERM ' -> ' TERM)* ' ] '
|
<Frame>
<object> TERM </object>
<slot rif:ordered="yes"> TERM TERM </slot>*
</Frame>
|
|
FORMULA ::= |
| BLD |
[ATOMIC | External | And | Or | Exists]
|
| PRD |
[ATOMIC | External | And | Or | NmNot | Exists]
|
|
External (as FORMULA) ::= |
| Core |
'External '(' [Atom | Frame] ')'
|
<External>
<content>
[ Atom | Frame ]
</content>
</External>
|
|
And ::= |
| Core |
'And' '(' FORMULA* ')'
|
<And>
<formula> FORMULA </formula>*
</And>
|
|
Or ::= |
| Core |
'Or' '(' FORMULA* ')'
|
<Or>
<formula> FORMULA </formula>*
</Or>
|
|
NmNot ::= |
| BLD |
Undefined
|
| PRD |
'Not' '(' FORMULA ')'
|
<NmNot>
<formula> FORMULA </formula>
</NmNot>
|
|
Exists ::= |
| Core |
'Exists' Var+ '(' FORMULA ')'
|
<Exists>
<declare> Var </declare>+
<formula> FORMULA </formula>
</Exists>
|
|
ACTION ::= |
| BLD |
Undefined
|
| PRD |
[ ASSERT | Retract ]
|
|
ASSERT ::= |
| BLD |
Undefined
|
| PRD |
[ Atom | Frame ]
|
|
Retract ::= |
| BLD |
Undefined
|
| PRD |
'Retract' '(' Atom | Frame ' ) '
|
<Retract>
<target>
[ Atom | Frame ]
</target>
</Retract>
|
|
RULE ::= |
| BLD |
[ Forall | Implies | ATOMIC ]
|
| PRD |
[ Forall | Implies | ACTION ]
|
|
Forall ::= |
| BLD |
' Forall ' Var+ ' ( ' [Implies | ATOMIC] ' ) '
|
<Forall>
<declare> Var </declare>+
<formula>
[Implies | ATOMIC ]
</formula>
</Forall>
|
| PRD |
' Forall ' Var+ (' ( ' FORMULA ' ) ')* ' ( ' RULE ' ) '
|
<Forall>
<declare> Var </declare>+
<pattern> FORMULA </pattern>*
<formula> RULE </formula>
</Forall>
|
|
Implies ::= |
| BLD |
(ATOMIC | 'And' '(' ATOMIC* ')') ':-' FORMULA
|
<Implies>
<if> FORMULA </if>
<then>
[ ATOMIC
|
<And>
<formula>
ATOMIC
</formula>*
</And>
]
</then>
</Implies>
|
| PRD |
(ACTION | 'Do' '(' ACTION* ')') ':-' FORMULA
|
<Implies>
<if> FORMULA </if>
<then>
ACTION
ACTION*
</then>
</Implies>
|
|
Group ::= |
| Core |
METADATA? 'Group' '(' ([RULE | Group])* ')'
|
<Group>
<sentence> [ RULE | Group ] </sentence>*
</Group>
|
|
Import ::= |
| BLD |
'Import' '(' IRI Profile? ')'
|
<Import>
<location>lAny Unicode string</location>
<profile><Profile>Any Unicode String1</Profile></profile>
</Import>
|
| PRD |
Undefined in this version of the draft
|
|
Document ::= |
| BLD |
METADATA? 'Document' '(' [Import | Prefix | Base]* Group? ')'
|
<Document>
<directive>
[ Import | Prefix | Base]*
</directive>
<payload> Group seeks feedback on which halting tests and which combinations</payload>?
</Document>
|
| PRD |
METADATA? 'Document' '(' Group? ')'
|
<Document>
<payload> Group </payload>?
</Document>
|
|
METADATA ::= |
| Core |
'(*' Const? (Frame | 'And' '(' Frame* ')')? '*)'
|
<AnyClassTag>
<id> Const </declare>?
<meta>
[ Frame
|
<And>
<formula> Frame </formula>
</And>
]
</meta>?
other content of tests should be supported by RIF-PRD and/or required fromAnyClassTag
</AnyClassTag>
|
6.2 Semantic compatibility between
RIF-PRD implementations;and which halting test should be the default, if any. By default,RIF-BLD
The specification for a terminal configuration that isintended for a setsemantics of production rules, when no halting testany RIF XML document which is explicitely associated to its representation asboth a
syntactically valid RIF-PRD Ruleset , is when no rule instancedocument and a syntactically valid
RIF-BLD document is
fireable: thisthe same whether it is considered a RIF-PRD or a RIF-BLD document. For any
input set of facts, the case when INSTANTIATE returns an emptyset of rule instances,rules contained in the document must
produce the same output set of facts whether it is consumed as a
RIF-PRD or when alla RIF-BLD
document.
Proof. TBC
7 Appendix: UML-like diagram of RIF-PRD
syntax
The rule instances that are satisfied inpicture below represents the configuration,complete syntax of RIF-PRD,
according to the semanticsthis version of INSTANTIATE , have already been fired in a configuration that has not since changed significantly. That latter condition guarantees, in particular, thatthe system halts when it reaches a fixpoint. Formally, ∀ RS ⊆ R, ∀ c ∈ C RS , PICK(c, RS) = true if and only if instance(c) - history(c) = ∅ . Otherwise, PICK(c, RS) = false . 4 Compatibility with other RIF dialects TBD 5 Glossary TBDdraft, except for the
Metadata construct, which is omitted for readibility's
sake.
