PRD
From RIF
- Document title:
- RIF Production Rule Dialect
- Editors
- Christian de Sainte Marie, ILOG
- Adrian Paschke, Technical University Dresden
- Gary Hallmark, Oracle
- Abstract
-
This document specifies RIF-PRD, a Rule Interchange Format (RIF) dialect to enable the interchange of production rules.
- Status of this Document
- @@update This is an automatically generated Mediawiki page, made from some sort of W3C-style spec.
Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
1 Overview
1.1 Introduction
This document specifies the production rule dialect of the W3C rule interchange format (RIF-PRD). Production rules are rules with an "if" part and a "then" part. The "if" part, also called a "condition", is like the condition part of logic rules (as covered by the basic logic dialect of the W3C rule interchange format, RIF-BLD). The "then" part of production rules may contain actions, unlike the conclusion of logic rules that may contain only a logical statement. Actions can modify the knowledge base and have other side-effects.
Example 1.1. A customer becomes a "Gold" customer as soon as his cumulative purchases during the current year top $5000; Customers that become "Gold" customers must be notified immediately, and a golden customer card will be printed and sent to them within one week; For shopping carts worth more than $1000, "Gold" customers receive an additional discount of 10% of the total amount are all examples of production rules.
As a common XML serialisation format for many production rule languages, RIF-PRD specifies an XML syntax for the most widely used features (section 2 - Syntax), and the operational semantics that RIF-PRD constructs are intended to represent (section 3 - Operational semantics).
This document is mostly intended for the designers and developers of RIF-PRD implementations, that is, applications that serialize production rules as RIF-PRD XML (producer applications) and/or that deserialize RIF-PRD XML documents into production rules (consumer applications).
Editor's Note: This working draft specifies the RIF-PRD serialisation of a set of core constructs only. Future versions of this document will extend the set of RIF-PRD constructs to cover the most widely used features of production rule languages. The working group seeks feedback on what features should be supported by RIF-PRD and what constructs should or should not be required from conformant RIF-PRD implementations.
As a RIF dialect, RIF-PRD has also been designed to maximize interoperability between rule languages over the World Wide Web. In this draft, this is achieved by sharing the same syntax for the subset of RIF documents where the semantics intended for a production ruleset serialized in RIF-PRD, and the semantics intended for a logic rule base serialized in the basic logic dialect of RIF, RIF-BLD, agree. The correspondence between RIF-PRD and RIF-BLD is detailed in Appendix: Compatibility with RIF-BLD.
Editor's Note: Future versions of this working draft will draw on other RIF documents to maximize interoperability with other rule languages, most noticeably the RIF data types and builtins specification, RIF-DTB, and the RIF extensibility framework (currently being specified by the working group; see also the RIF framework for logic dialects, RIF-FLD, that specifies a framework for designing RIF logic dialects).
In the section 2, two related but distinct syntaxes for RIF-PRD components are introduced:
- XML syntax. This syntax is the normative XML serialization of RIF-PRD. It is meant, and has been designed, to work as a common XML serialisation for many production rule languages. It is also meant, and has been designed, to work as a common XML serialisation for production rule languages and logic rule languages, wherever they agree on the semantics: as a consequence, RIF-PRD and RIF-BLD share the same XML syntax wherever they agree on the semantics. The XML syntax is specified using textual descriptions and BNF pseudo-schemas. A normative XML schema will also be provided in future versions of the document;
- Presentation syntax. A presentation syntax is also specified, to allow a more easily readable presentation of RIF-PRD language fragments (such as examples etc). To make the overlap between RIF-PRD and RIF-BLD visible, RIF-PRD re-uses the presentation syntax of RIF-BLD wherever they share the same XML syntax (and agree on the semantics). The presentation syntax is non normative.
Example 1.2. In RIF-PRD presentation syntax, the first rule in example 1.1. might be represented as follows:
Prefix(ex1 http://rif.example.com/2008/prd#) (* ex1:rule_1 *) Forall ?customer ?purchasesYTD ( ex1:Gold(?customer) :- And( ?customer#ex1:Customer ?customer[ex1:purchasesYTD->?purchasesYTD] pred:numeric-greater-than(?purchasesYTD 5000) ))
Editor's Note: As a consequence of the re-use of RIF-BLD presentation syntax, examples and fragments written in RIF-PRD non-normative presentation syntax may have an unfamiliar look to production rules developers and users. The working group seeks feedback on this issue as well.
The overall structure of the syntax of RIF-PRD is also presented as an UML-like diagram in appendix: UML-like diagram of RIF-PRD syntax. The diagram provides an overview of RIF-PRD syntactic classes and shows at a glance how they relate to each others. It is provided for informative purposes only.
In the section 3, the intended semantics for RIF-PRD constructs is specified normatively. As can be seen from the examples above, production rules, in general, are not logic rules, and they are not amenable to a model theory: followingly, the intended semantics of rules and set of rules serialized as RIF-PRD is specified operationally, in this document. The compatibility with the model theoretic semantics of RIF-BLD for the contructs they share is explained and proven in appendix: Compatibility with RIF-BLD.
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#, the rdf: prefix stands for http://www.w3.org/1999/02/22-rdf-syntax-ns#, and rif: stands for the URI of the RIF namespace, http://www.w3.org/2007/rif#.
Syntax such as xsd:string should be understood as a compact URI (CURIE) -- a macro that expands to a concatenation of the character sequence denoted by the prefix xsd and the string string. The compact URI notation is used for brevity only, and xsd:string should be understood, in this document, as an abbreviation for http://www.w3.org/2001/XMLSchema#string.
1.2.2 BNF pseudo-schemas
The XML syntax of RIF-PRD is specified for each component as a pseudo-schema, as part of the description of the component. The pseudo-schemas use BNF-style conventions for attributes and elements: "?" denotes optionality (i.e. zero or one occurrences), "*" denotes zero or more occurrences, "+" one or more occurrences, "[" and "]" are used to form groups, and "|" represents choice. Attributes are conventionally assigned a value which corresponds to their type, as defined in the normative schema. Elements are conventionally assigned a value which is the name of the syntactic class of their content, as defined in the normative schema.
<!-- sample pseudo-schema -->
<defined_element
required_attribute_of_type_string="xs:string"
optional_attribute_of_type_int="xs:int"? >
<required_element />
<optional_element />?
<one_or_more_of_these_elements />+
[ <choice_1 /> | <choice_2 /> ]*
</defined_element>
1.2.3 Syntactic components
Three kinds of syntactic components are used to specify RIF-PRD:
- Abstract classes are defined only by their subclasses: they not visible in the XML markup and can be thought of as extension points. In this 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.
1.3 Running example
This section describes the fictious RIF-PRD use case of Joe the Hen Public, and the rule that will be used as a running example in this document.
Joe the Hen Public developed a very sophisticated program to grow feeble chicks into deliciously plump chickens for a minimal cost. Joe publishes his method on his Web site www.juicychicken.org. Since he is still experimenting to improve his method, the rules to follow change quite often, and Joe decided to publish them in RIF as well, so that his followers can easily, even automatically, implement the very latest version.
Joe's method is a complex exercise of behavioural hen psychology: one aspect that is 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.
Joe's latest addition to his knowledge base is an advice that: on a Monday, if a chicken over 8 months old owns a potato that weights (in decigrams) more than half its age, and if the fox is not in the hen house, then the potato should be mashed and the daily grain allowance of the chicken increased by 10%.
Joe calls it the "Chicken and Mashed Potatoes", or CMP, rule. The CMP rule is a production rule: that is, when the condition is satisfied and the rule is implemented (that is, fired), the consequence is that some actions are executed (mashing potatoes, modifying a chicken's diet, managing ownership relations etc). Therefore, it is best interchanged using RIF-PRD, the production rule dialect of RIF.
The CMP rule might be rephrased in RIF-PRD non-normative presentation syntax as follows:
(* joe:ChickenAndMashedPotatoes *)
// The identifier of the rule is the IRI "joe:ChickenAndMashedPotatoes"
Forall ?chicken ?potato ?allowance ?age ?weight (
// The Forall construct is used to declare the rule variables: "?chicken" etc
Do( // Rule actions list
Execute(joe:mash(?potato))
// The first action is to mash the potato that is bound to variable ?potato
Retract(?chicken[joe:allowance->?allowance])
?chicken[joe:allowance->External(func:numeric-multiply(?allowance 1.1))]
// The value of the "allowance" property of the chicken that is bound to ?chicken
// is increased by 10%
Retract(joe:owns(?chicken ?potato)) )
:- // IF
And( // Rule conditions
?chicken#joe:Chicken
// The object bound to ?chicken is a "Chicken" as specified in Joe's object model
?chicken[joe:age->?age joe:allowance->?allowance]
// The value of the "age" property of the "Chicken" object bound to ?chicken is
// equal to the value bound to the variable ?age, and the values of the "allowance"
// property is equal to the value bound to ?allowance
External(pred:numeric-greater-than(?age 8))
// The value bound to ?age is greater than 8, where the function "numeric-grater-than"
// is specified by RIF-PRD and must be supported by all implementations
?potato#joe:Potato
?potato[joe:weight->?weight]
joe:owns(?chicken ?potato)
External(pred:numeric-greater-than(?weight External(func:numeric-divide(?age 2))))
External(pred:string-not-equal(External(joe:today()) "Tuesday"))
Not(External(joe:foxAlarm())) ))
To make sure that his rules can be implemented unambiguously, Joe published a data model (e.g., an XML schema) that identifies Chicken and Potato as two classes of objects:
- instances of Chicken represent individual chickens. They have a property called age that represents the chicken's age in months as an xsd:decimal and a property called allowance that represent the chicken's daily grain allowance as an xsd:integer;
- instances of Potato represent individual potatoes. They have a property called weight that represents the potato's weight in decigram as an xsd:decimal.
Joe further specifies:
- a binary predicate owns(?o ?i) that denotes the ownership relation between owner ?o and owned item ?i;
- a nullary function today() that returns the day of the week as a xsd:string;
- a boolean fox sensor foxAlarm() that returns true if and only if the fox is in the hen house;
- and a command mash(?i), which execution results in the physical item that is denoted by ?i being reduced to a soft pulpy state by beating or pressure (and in the corresponding logical object being removed from the instances of its class, as a consequence).
All these (types and names) are defined in Joe's namespace http://rif.examples.com/2008/joe#.
The assumption is that a system that consumes a RIF document published by Joe knows how to map Joe's published data model and specification of predicates and functions to/from its own underlying data representation. What a consumer is expected to do when this is not the case is still under discussion and will be specified as a conformance clause in a future version of this document.
2 Conditions
This section specifies the language of the rule conditions that can be serialized using RIF-PRD, by specifying:
- the abstract syntax that all production rule languages interchanging rules using RIF-PRD must have in common for expressing conditions;
- the concrete XML syntax used to serialize production rule conditions in RIF-PRD;
- and the intended semantics of the condition formulas in a RIF-PRD document.
Note to the reader: this section depends on Section Constants, Symbol Spaces, and Datatypes of [RIF-DTB].
2.1 Abstract syntax
For a production rule language to be able to interchange rules using RIF-PRD, its alphabet for expressing the condition parts of a rule must, at the abstract syntax level, consist of:
- a countably infinite set of constant symbols Const;
- a countably infinite set of variable symbols Var (disjoint from Const;
- a countably infinite set of argument names, ArgNames (disjoint from Const and Var);
- syntactic constructs to denote:
- Function calls;
- Equality, class membership and subclass relationship;
- Arbitrary relationships;
- conjunction, disjunction and negation;
- existential conditions.
For the sake of readibility and simplicity, this specification introduces a notation for these constructs. That notation is not intended to be a concrete syntax and it leaves out many details that are not needed for its purpose: the only concrete syntax for RIF-PRD is the XML syntax.
Notice that the production rule systems for which RIF-PRD aims to provide a common XML serialization use only externally specified functions, e.g. builtins. This is one of two points where the syntaxes for conditions in RIF-PRD and RIF-BLD differ, since RIF-BLD specifies, in addition, a construct for serializing the logic functions that logic languages also use.
The second point of difference between the syntaxes for conditions in RIF-PRD and RIF-BLD is that, unlike RIF-PRD, RIF-BLD does not specify a construct for negation. This is because logic rule languages use many different kinds of negations, none of them prevalent enough to justify inclusion in the basic logic dialect of RIF (see also the RIF framework for logic dialects).
2.1.1 Terms
The most basic construct that can be serialized using RIF-PRD is the term. RIF-PRD provides for the representation and interchange of several kinds of terms: constants, variables, positional terms and terms with named arguments
Definition (Term).
- Constants and variables. If t ∈ Const or t ∈ Var then t is a simple term.
- Positional terms. If t ∈ Const and t1, ..., tn, n≥0, are terms then t(t1 ... tn) is a positional term.
Here, the constant t represents a function and t1, ..., tn represent argument values. - Terms with named arguments. A term with named arguments is of the form t(s1->v1 ... sn->vn), where n≥0, t ∈ Const and v1, ..., vn are terms and s1, ..., sn are pairwise distinct symbols from the set ArgNames.
The constant t here represents a function; s1, ..., sn represent argument names; and v1, ..., vn represent argument values. The argument names, s1, ..., sn, are required to be pairwise distinct. Terms with named arguments are like positional terms except that the arguments are named and their order is immaterial. Note that a term of the form f() is, trivially, both a positional term and a term with named arguments.
2.1.2 Atomics
The atomic truth-valued constructs that can be serialized using RIF-PRD are called atomics.
Definition (Atomic). An atomic can have several different forms and is defined as follows:
- Positional atomics. If t ∈ Const and t1, ..., tn, n≥0, are terms then t(t1 ... tn) is a positional atomic (or simply a positional atom).
- Atomics with named arguments. An atomic with named arguments (or simply a atom with named arguments) is of the form t(s1->v1 ... sn->vn), where n≥0, t ∈ Const and v1, ..., vn are terms and s1, ..., sn are pairwise distinct symbols from the set ArgNames.
The constant t here represents a predicate; s1, ..., sn represent argument names; and v1, ..., vn represent argument values. The argument names, s1, ..., sn, are required to be pairwise distinct. Atoms with named arguments are like positional Atoms except that the arguments are named and their order is immaterial. Note that an atom of the form t() is, trivially, both a positional atom and an atom with named arguments. - Equality atomics. t = s is an equality atomic, if t and s are terms.
- Class membership atomicss (or just membership atomics). t#s is a membership atomic if t and s are terms.
- Subclass atomics. t##s is a subclass atomic if t and s are terms.
- Frame atomics. t[p1->v1 ... pn->vn] is a frame atomic (or simply a frame) if t, p1, ..., pn, v1, ..., vn, n ≥ 0, are terms.
Membership, subclass, and frame atomics are used to describe objects and class hierarchies. - Externally defined atomics. If t is a positional, named-argument, or a frame atomic then External(t) is an externally defined atomic.
Such atomics are used for representing built-in predicates as well as "procedurally attached" predicates, which might exist in various rule-based systems or applications, but are not specified by RIF-PRD.
Note that not only predicates, but also frame atomics can be externally defined. Therefore, external information sources can be modeled in an object-oriented way via frames. For instance, External("http://example.com/acme"^^rif:iri["http://example.com/mycompany/president"^^rif:iri(?Year) -> ?Pres]) could be a representation of an externally defined method "http://example.com/mycompany/president"^^rif:iri in an external object "http://example.com/acme"^^rif:iri. ☐
Observe that the argument names of frames, p1, ..., pn, are terms and so, as a special case, can be variables. In contrast, atoms with named arguments can use only the symbols from ArgNames to represent their argument names. They cannot be constants from Const or variables from Var.
Note that atomics are sometimes also called terms, e.g. in the realm of logic languages: the specification of RIF-BLD, in particular, follows that usage. The abstract syntactic elements that are called terms in this specification, are called basic terms in the specification of RIF-BLD.
2.1.3 Formulas
Composite truth-valued constructs that can be serialized using RIF-PRD are called formulas.
Any atomic is also an atomic formula.
Note that terms (constants, variables and functions) are not formulas.
More general formulas are constructed out of the atomic formulas with the help of logical connectives.
Definition (Condition formula). A condition formula can have several different forms and is defined as follows:
- Atomic: If φ is an atomic formula then it is also a condition formula.
- Conjunction: If φ1, ..., φn, n ≥ 0, are condition formulas then so is And(φ1 ... φn), called a conjunctive formula. As a special case, And() is allowed and is treated as a tautology, i.e., a formula that is always true.
- Disjunction: If φ1, ..., φn, n ≥ 0, are condition formulas then so is Or(φ1 ... φn), called a disjunctive formula. As a special case, Or() is permitted and is treated as a contradiction, i.e., a formula that is always false.
- Negation: If φ is a condition formula, then so is Not(φ), called a negative formula.
- Existentials: If φ is a condition formula and ?V1, ..., ?Vn, n>0, are variables then Exists ?V1 ... ?Vn(φ) is an existential formula.
In the definition of a formula, the component formulas φ and φi are said to be subformulas of the respective condition formulas that are built using these components.
The function Var(e) that maps a term, atomic or formula e to the set of its free variables is defined as follows:
- if e ∈ Const, then Var(e) = {};
- if e ∈ Var, then Var(e) = {e};
- if p and argi, i = 0..n, are terms, then, Var(p(argi) = Var(p) ∪i=0..n Var(argi);
- if p and argi, i = 0..n, are terms, then, Var(External(p(argi)) = Var(p) ∪i=0..n Var(argi);
- if t1 and t2 are terms, then Var(t1 [=|#|##] t2) Var(t1) ∪ Var(t2);
- if o', ki, i = 1..n, and vi, i = 1..n, are terms, then Var(o[k1->v1 ... kn->vn]) Var(o) ∪i=1..n Var(ki) ∪i=1..n Var(vi);
- if fi, i = 0..n, are condition formulas, then Var([AND|OR|NOT](fi)) ∪i=0..n Var(fi);
- if f is a condition formula and xi ∈ Var for i = 1..n, then, Var(Exists x1 .. xn (f)) = Var(f) - {xi}.
Definition (Ground formula). A condition formula φ is a ground formula if and only if Varφ = {} and φ does not contain any existential subformula.
In other words, a ground formula does not contain any variable term.
2.1.4 Well-formed Formulas
The specification of RIF-PRD does not assign a standard meaning to all the formulas that can be serialized using its concrete XML syntax: formulas that can be meaningfully serialized are called well-formed. Not all formulas are well-formed with respect to RIF-PRD: it is required that no constant appear in more than one context. What this means precisely is explained below.
The set of all constant symbols, Const, is partitioned into several subsets as follows:
- A subset of individuals.
The symbols in Const that belong to the primitive datatypes are required to be individuals. - A number of subsets for predicate symbols such that there is one subset per symbol arity (defined below) for externally defined predicates and one for non-external predicates.
Note that this implies that symbols used for external predicate names cannot be used for other predicates. Also, the definition of arity, below, implies that the arities for positional predicate symbols and for predicate symbols with named arguments are distinct even if the numbers of arguments are the same. Therefore, symbols that are used for positional predicates cannot be used for predicates with named arguments, and vice versa. - A number of subsets of function symbols (remember that only procedurally attached function can be serialized using RIF-PRD). As with predicate symbols, there are separate subsets for symbols with different arities; function symbols with named arguments are in their own subsets.
Each predicate and function symbol has precisely one arity. For positional predicate and function symbols, an arity is a non-negative integer that tells how many arguments the symbol can take. For symbols that take named arguments, an arity is a set {s1 ... sk} of argument names (si ∈ ArgNames) that are allowed for that symbol.
An important point is that neither the above partitioning of constant symbols nor the arity are specified explicitly. Instead, the arity of a symbol and its type is determined by the context in which the symbol is used.
Definition (Context of a symbol). The context of an occurrence of a symbol, s∈Const, in a formula, φ, is determined as follows:
- If s occurs as a function symbol in a term of the form s(...) with arity α then s occurs in the context of an external function symbol with arity α (or simply the context of a function symbol with arity α, since RIF-PRD knows only external functions).
- If s occurs as a predicate in an atomic subformula of the form s(...) with arity α then s occurs in the context of a predicate symbol with arity α.
- If s occurs as a predicate in an atomic subformula External(s(...)) with arity α then s occurs in the context of an external predicate symbol with arity α.
Definition (Well-formed formula). A formula φ is well-formed iff:
- every constant symbol mentioned in φ occurs in exactly one context.
- Whenever a formula contains a function term t or an external atomic formula External(t), t must be an instance of the coherent set of external schemas (Section Schemas for Externally Defined Terms of [RIF-DTB]) associated with the language of RIF-PRD.
- If t is an instance of the coherent set of external schemas associated with the language then t can occur only as a function term t or as an external atomic formula External(t).
Definition (RIF-PRD condition language). The RIF-PRD condition language consists of the set of all well-formed formulas that can be serialized using the RIF-PRD XML syntax.
2.2 XML Syntax
This section specifies the concrete XML syntax that is used to serialize the condition language of RIF-PRD. Its specification follows closely the specification of the abstract syntax.
The most basic construct in RIF is the TERM. The TERM is an abstract construct, concretely visible, in RIF-PRD, as a Const, a Var or an External.
The ATOMIC is the basic building block of RIF. ATOMIC is an abstract class: it is visible in RIF-PRD as either an Atom, an Equal, a Member, a Subclass or a Frame. Each kind of ATOMIC is a composition of TERMs.
The next level of constructs are assemblies of ATOMICs. Together, the various kinds of assemblies form the abstract construct FORMULA. RIF-PRD knows six kinds of FORMULAs: the single ATOMIC, the Externally evaluated Atom or Frame, and the recursively specified And, Or, NmNot and Exists.
The following sections specify each construct separately, grouped by abstract syntactic classes.
2.2.1 TERM
The TERM class of constructs is used to represent constants, variables and the application of function symbols to other TERMs.
As an abstract class, TERM is not associated with specific XML markup in RIF-PRD instance documents.
[ Const | Var | External ]
2.2.1.1 Const
In RIF, the Const construct is used to represent a constant.
The Const element has a required type attribute and an optional xml:lang attribute:
- The value of the type attribute is the identifier of the Const symbol space. It must belong to the type xsd:anyURI;
- The xml:lang attribute, as defined by 2.12 Language Identification of XML 1.0 or its successor specifications in the W3C recommendation track, is optionally used to identify the language for the presentation of the Const to the user. It is allowed only in association with constants of the type rif:text. A compliant implementation MUST ignore the xml:lang attribute if the type of the Const is not rif:text.
The content of the Const element is the constant's litteral, which can be any Unicode character string.
<Const type=xsd:anyURI [xml:lang=xsd:language]? >
Any Unicode string
</Const>
Constant types. RIF requires that all dialects include the following builtin constant types. Rule sets that are exchanged through RIF can use additional symbol spaces.
- xs:string (http://www.w3.org/2001/XMLSchema#string)
- xs:time (http://www.w3.org/2001/XMLSchema#time)
- xs:date (http://www.w3.org/2001/XMLSchema#date)
- xs:dateTime (http://www.w3.org/2001/XMLSchema#dateTime)
- xs:double (http://www.w3.org/2001/XMLSchema#double)
- xs:integer (http://www.w3.org/2001/XMLSchema#integer)
- xs:decimal (http://www.w3.org/2001/XMLSchema#decimal)
The lexical spaces of the above symbol spaces are defined in the document [XML-SCHEMA2].
- xs:dayTimeDuration (http://www.w3.org/2001/XMLSchema#dayTimeDuration)
- xs:yearMonthDuration (http://www.w3.org/2001/XMLSchema#yearMonthDuration)
These two symbol spaces represent two subtypes of the XML Schema data type xs:duration with well-defined value spaces, since xs:duration does not have a well-defined value space (this may be corrected in later revisions of XML Schema data types, in which case the revised data type would be suitable for RIF DTB). The lexical spaces of the above symbol spaces are defined in the document [XDM].
- rdf:XMLLiteral (http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral).
This symbol space represents XML content. The lexical space of rdf:XMLLiteral is defined in the document [RDF-CONCEPTS].
- rif:text (http://www.w3.org/2007/rif#text, for text strings with language tags attached).
This symbol space represents text strings with a language tag attached. The lexical space of rif:text is the set of all Unicode strings of the form ...@LANG, i.e., strings that end with @LANG where LANG is a language identifier as defined in [RFC-3066].
- rif:iri (http://www.w3.org/2007/rif#iri, for internationalized resource identifiers or IRIs).
Constants in this symbol space are intended to be used in a way similar to RDF resources [RDF-SCHEMA]. The lexical space consists of all absolute IRIs as specified in [RFC-3987]; it is unrelated to the XML primitive type anyURI. A rif:iri constant must be interpreted as a reference to one and the same object regardless of the context in which that constant occurs.
- rif:local (http://www.w3.org/2007/rif#local, for constant symbols that are not visible outside of the RIF document in which they occur).
Constants in this symbol space are local to the RIF documents in which they occur. This means that occurrences of the same rif:local constant in different documents are viewed as unrelated distinct constants, but occurrences of the same rif:local constant in the same document must refer to the same object. The lexical space of rif:local is the same as the lexical space of xs:string.
Editor's Note: {{{text}}}
Editor's Note: The case of non-standard data types, that is, of constants that do not belong or cannot be cast in one of RIF builtin types for interchange purposes, is still under discussion in the WG. The WG seeks feedback on whether they should be allowed and why.
Symbols with an ill-formed lexical part. Constants that are represented in RIF in one of the aforesaid builtin types must be well-formed, i.e., their representation must belong to the lexical space associated with the type. For instance, 123^^xsd:long (that is, <Const type="xsd:long">123</Const>) has a correct lexical part, since 123 belongs to the lexical space of the data type xsd:long. In contrast, abc^^xsd:long (<Const type="xsd:long">abc</Const>) is ill-formed, as it does not have a correct lexical part. A compliant RIF-PRD translator MUST reject ill-formed symbols.
Example 2.1. In each of the examples below, a constant is first described, followed by its representation in RIF-PRD XML syntax.
a. A constant with builtin type xsd:integer and value 123:
<Const type="xsd:integer">123</Const>
b. A constant which symbol today is defined in Joe the Hen Public's namespace http://rif.examples.com/2008/joe#. The type of the constant is rif:iri:
<Const type="rif:iri"> http://rif.examples.com/2008/joe#today </Const>
c. A constant with symbol BigPotato that is local to the set of rules where it appears (e.g. a RuleSet specific to Paula's farm). The type of the constant is rif:local:
<Const type="rif:local">BigPotato</Const>
d. A constant with non-builtin type xsd:int and value 123:
<Const type="xsd:int">123</Const>
2.2.1.2 Var
In RIF, the Var construct is used to represent variables.
The content of the Var element is the variable's name, represented as an Unicode character string.
<Var> any Unicode string </Var>
Example 2.2. The example below shows the XML serialization of the variable ?chicken.
Notice that the content of the Var element is the Unicode string chicken: in the RIF presentation syntax, the ?-prefix is used as a syntactic marker to denote a variable identifier, but RIF leaves it to the implementations to use whatever prefix they choose or require, if any.
<Var> chicken <Var>
2.2.1.3 External
As a TERM, an External element is used to represent an externally specified function, e.g. a builtin, a user-defined function, a query to an external data source...
The External element contains one content element, which in turn contains one Expr element that contains one op element, followed zero or one args element or zero of more 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. When the External is a TERM, the content of the op element represents a function symbol;
- The optional args element contains zero or more constructs from the TERM abstract class. The order of the args sub-elements is significant and MUST be preserved. This is emphasized by the required value "yes" of the required attribute rif:ordered;
- Each optional slot element contains one required Name sub-element, that contains an Unicode string that represents the slot key, and a required TERM that represents its value.
<External>
<content>
<Expr>
<op> Const </op>
[ <args rif:ordered="yes"> TERM* </args>?
|
<slot rif:ordered="yes">
<Name> Any Unicode string </Name>
TERM
<slot>* ]
</Expr>
</content>
</External>
Editor's Note: The slotted, or named arguments form of the External TERM construct is still under discussion (see also ISSUE-68). The working group seeks feedback on whether or not it should be included in PRD.
Builtin functions. RIF-PRD specifies a subset of XPath/XQuery Functions and Operators (XPath-Functions) that any conformant RIF-PRD implementation MUST support. The RIF-PRD builtin functions are listed in the Data Type and Builtins document.
The op Const must represent a constant symbol of type rif:iri that must uniquely identify the evaluated function to be applied to the args TERMs. It can be one of the builtin functions specified for RIF-PRD, or it can be application specific. In the latter case, it is the responsibility of the producers and consumers of RIF-PRD rulesets that reference non-builtin functions to agree on their semantics.
Example 2.3.
a. The first example below shows one way to represent, in RIF-PRD, the sum of integer 1 and a variable ?x, where the addition conforms to the specification of the builtin fn:numeric-add.
The prefix fn is associated with the namespace http://www.w3.org/2007/rif-builtin-function#.
<External>
<content>
<Expr>
<op> <Const type="rif:iri"> fn:numeric-add </Const> </op>
<args rif:ordered="yes">
<Const type="xsd:integer"> 1 </Const>
<Var> x </Var>
</args>
</Expr>
</content>
</External>
b. Another example, that shows the RIF XML representation of a call to the application-specific nullary function today(), which symbol is defined in the example's namespace http://rif.examples.com/2008/joe#:
<External>
<content>
<Expr>
<op>
<Const type="rif:iri">
http://rif.examples.com/2008/joe#today
</Const>
</op>
</Expr>
</content>
</External>
2.2.2 ATOMIC
The ATOMIC class is used to represent atomic truth-valued statements. RIF-PRD covers rule languages in which the truth values of atomic statements can only be "true" or "false": that is, ATOMICs represent boolean statements. Dialects extending RIF-PRD may support additional truth values.
As an abstract class, ATOMIC is not associated with specific XML markup in RIF-PRD instance documents. It is specified in the normative schema as a substitution group.
[ Atom | Equal | Member | Subclass | Frame ]
2.2.2.1 Atom
In RIF, the Atom element is used to represent a relation (or predicate).
The Atom element contains one op element, followed by zero or one args element or zero or more slot arguments:
- The content of the op element must be a Const. It represents the predicate symbol (the name of a relation);
- The optional args element contains zero or more constructs from the TERM abstract class. The order of the arg's sub-elements is significant and MUST be preserved. This 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.
<Atom>
<op> Const </op>
[ <args rif:ordered="yes"> TERM* </args>?
|
<slot rif:ordered="yes">
<Name> Any Unicode string </Name>
TERM
<slot>* ]
</Atom>
Editor's Note: The slotted, or named arguments form of the Atom construct is still under discussion (see also ISSUE-68). The working group seeks feedback on whether or not it should be included in PRD.
Example 2.4. The example below shows the RIF XML representation of the predicate owns(?c ?p), where the predicate symbol owns is defined in the example namespace http://rif.examples.com/2008/joe#.
<Atom>
<op>
<Const type="rif:iri">
http://rif.examples.com/2008/joe#owns
</Const>
</op>
<args rif:ordered="yes">
<Var> c </Var>
<Var> p </Var>
</args>
</Atom>
2.2.2.2 Equal
In RIF, Equal is used to represent equality relations.
The Equal element must contain one left sub-element an done right sub-element. The content of the left and right elements must be a construct from the TERM abstract class. The order of the sub-elements is not significant.
<Equal>
<left> TERM </left>
<right> TERM </right>
</Equal>
2.2.2.3 Member
In RIF, the Member element is used to represent membership relations.
The Member element contains two unordered sub-elements:
- the instance elements must be a construct from the TERM abstract class. It is required;
- the class element must be a construct from the TERM abstract class. It is required as well.
<Member>
<instance> TERM </instance>
<class> TERM </class>
</Member>
Example 2.5. The example below shows the RIF XML representation of a boolean expression that tests whether the individual denoted by the variable ?c is a member of the class Chicken that is defined in the example namespace http://rif.examples.com/2008/joe#.
<Member>
<instance> <Var> c </Var> </instance>
<class>
<Const type="rif:iri">
http://rif.examples.com/2008/joe#Chicken
</Const>
</class>
</Member>
2.2.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;
- the super elements must be a construct from the TERM abstract class. It is required.
<Subclass>
<sub> TERM </sub>
<super> TERM </super>
</Subclass>
2.2.2.5 Frame
In RIF, the Frame construct is used to represent relations that hold between an individual, also called an object, and the values of some its properties or attributes: that is, object-attribute-value triples.
Accordingly, a Frame element must contain:
- 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 pair of elements of the TERM abstract class, the first one that represents the name of the attribute (or property); the second that represents the attribute's value. The order of the slot's sub-elements is significant and MUST be preserved. This is emphasized by the required value "yes" of the required attribute rif:ordered.
<Frame>
<object> TERM </object>
<slot rif:ordered="yes"> TERM TERM </slot>*
</Frame>
Example 2.6. The example below shows the RIF XML syntax of an expression that states that the object denoted by the variable ?c has the value denoted by the variable ?a for the property Chicken/age that is defined in the example namespace http://rif.examples.com/2008/joe#.
<Frame>
<object> <Var> c </Var> </object>
<slot rif:ordered="yes">
<Const type="rif:iri">
ttp://rif.examples.com/2008/joe#Chicken/age
</Const>
<Var> a </Var>
</slot>
</Frame>
Editor's Note: The example uses an XPath style for the key. How externally specified data models and their elements should be referenced is still under discussion (see ISSUE-37).
2.2.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 only represent boolean statements.
Dialects extending RIF-PRD may support additional truth values.
As an abstract class, FORMULA is not associated with specific XML markup in RIF-PRD instance documents.
[ ATOMIC | External | And | Or | NmNot | Exists ]
2.2.3.1 ATOMIC
A FORMULA can be a single ATOMIC statement. See specification of ATOMIC, above.
2.2.3.2 External
In RIF-PRD, an External represents an externally specified predicate when it is a FORMULA (as opposed to a TERM; that is, in particular, when it appears in a place where a FORMULA is required, and not a TERM).
The External element contains one content element that contains one Atom element:
<External>
<content>
Atom
</content>
</External>
Builtin predicates. RIF-PRD specifies a subset of XPath/XQuery Functions and Operators (XPath-Functions) that any conformant RIF-PRD implementation MUST support. The RIF-PRD builtin predicates are listed in the Data Types and Builtins document.
The op Const in the Atom element must be a symbol of type rif:iri that must uniquely identify the evaluated predicate to be applied to the args TERMs. It can be one of the builtin predicates specified for RIF-PRD, or it can be application specific. In the latter case, it is up to the producers and consumers of RIF-PRD rulesets that reference non-builtin predicates to agree on their semantics.
Example 2.7. The example below shows the RIF XML representation of a boolean expression that tests whether the value denoted by variable ?a (e.g. the age of a chicken) is greater than the integer value 8, where the test is intended to behave like the builtin predicate op:numeric-greater-than as specified in XQuery 1.0 and XPath 2.0 Functions and Operators.
In the example, the prefix op: is associated with the namespace http://www.w3.org/2007/rif-builtin-predicate#.
<External>
<content>
<Atom>
<op> <Const type="rif:iri"> op:numeric-greater-than </Const> </op>
<args rif:ordered="yes">
<Var> a </Var>
<Const type="xsd:decimal"> 8 </Const>
</args>
</Atom>
</content>
</External>
2.2.3.3 And
A FORMULA can represent the conjunction of zero of more statements, each of them represented by a FORMULA. This is represented by the And construct.
The And element contains zero or more formula elements, each containing an element of the FORMULA group.
<And>
<formula> FORMULA </formula>*
</And>
2.2.3.4 Or
A FORMULA can represent the disjunction of zero of more statements, each of them represented by a FORMULA. This is represented by the Or construct.
The Or element contains zero or more formula elements, each containing an element of the FORMULA group.
<Or>
<formula> FORMULA </formula>*
</Or>
2.2.3.5 NmNot
A FORMULA can represent the non-monotonic negation of a statement, itself represented by a FORMULA: this is represenetd by the NmNot construct.
The NnNot element contains exactly one formula element. The formula element contains an element of the FORMULA group, that represents the negated statement.
<NmNot>
<formula> FORMULA </formula>
</NmNot>
Editor's Note: The name of that construct may change, including the tag of the XML element.
2.2.3.6 Exists
In RIF, the Exists construct 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 one required 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 2.8. The example below shows the RIF XML representation of a boolean expression that tests whether the chicken denoted by variable ?c is older than 8 months, by testing the existence of a value, denoted by variable ?a, that is both the age of ?c, as represented by a Frame as in example 2.6, and greater than 8, as represented by an External ATOMIC as in example 2.7.
<Exists>
<declare> <Var> a </Var> </declare>
<formula>
<And>
<Frame>
<object> <Var> c </Var> </object>
<slot rif:ordered="yes">
<Const type="rif:iri">
http://rif.examples.com/2008/joe#Chicken/age
</Const>
<Var> a </Var>
</slot>
</Frame>
<External>
<content>
<Atom>
<op> <Const type="rif:iri"> op:numeric-greater-than </Const> </op>
<args rif:ordered="yes">
<Var> a </Var>
<Const type="xsd:decimal"> 8 </Const>
</args>
</Atom>
</content>
</External>
</And>
</formula>
</Exists>
2.3 Semantics of condition formulas
This section specifies the intended semantics of the condition formulas in a RIF-PRD document.
For compatibility with other RIF specifications (in particular, RIF data types and builtins), and to make the interoperability with RIF logic dialects (in particular RIF-Core and RIF-BLD), the intended semantics for RIF-PRD condition formulas is specified in terms of a model theory.
2.3.1 Semantic Structures
The key concept in a model-theoretic semantics of a logic language is the notion of a semantic structure [Enderton01, Mendelson97].
Definition (Semantic structure). A semantic structure, I, is a tuple of the form <TV, DTS, D, Dind, IC, IV, IP, INP, Iframe, Isub, Iisa, I=, Iexternal, Itruth>. Here D is a non-empty set of elements called the domain of I, and Dind is a nonempty subset of D. Dind is used to interpret the elements of Const that are individuals. As before, Const denotes the set of all constant symbols and Var the set of all variable symbols. TV denotes the set of truth values that the semantic structure uses and DTS is a set of identifiers for primitive datatypes (please refer to Section Datatypes of [RIF-DTB] for the semantics of datatypes).
As far as the assignement of a standard meaning to formulas in the RIF-PRD condition language is concerned, the set TV of truth values consists of just two values, t and f.
The other components of I are total mappings defined as follows:
- IC maps Const to D.
This mapping interprets constant symbols; - IV maps Var to Dind.
This mapping interprets variable symbols; - IP maps D to functions D*ind → D (here D*ind is a set of all sequences of any finite length over the domain Dind).
This mapping interprets positional predicate symbols; - INP maps D to the set of total functions of the form SetOfFiniteSets(ArgNames × Dind) → D.
This mapping interprets predicate symbols with named arguments. This is analogous to the interpretation of positional predicate symbols with two differences:- Each pair <s,v> ∈ ArgNames × Dind represents an argument/value pair instead of just a value in the case of a positional atom;
- The arguments of a term with named arguments constitute a finite set of argument/value pairs rather than a finite ordered sequence of simple elements. So, the order of the arguments does not matter;
- Iframe maps Dind to total functions of the form SetOfFiniteBags(Dind × Dind) → D.
This mapping interprets frame terms. An argument, d ∈ Dind, to Iframe represents an object and the finite bag {<a1,v1>, ..., <ak,vk>} represents a bag of attribute-value pairs for d. We will see shortly how Iframe is used to determine the truth valuation of frame terms.
Bags (multi-sets) are used here because the order of the attribute/value pairs in a frame is immaterial and pairs may repeat: o[a->b a->b]. Such repetitions arise naturally when variables are instantiated with constants. For instance, o[?A->?B ?C->?D] becomes o[a->b a->b] if variables ?A and ?C are instantiated with the symbol a and ?B, ?D with b. (We shall see later that o[a->b a->b] is equivalent to o[a->b];) - Isub gives meaning to the subclass relationship. It is a mapping of the form Dind × Dind → D.
The operator ## is required to be transitive, i.e., c1 ## c2 and c2 ## c3 must imply c1 ## c3. This is ensured by a restriction in Section Interpretation of condition formulas; - Iisa gives meaning to class membership. It is a mapping of the form Dind × Dind → D.
The relationships # and ## are required to have the usual property that all members of a subclass are also members of the superclass, i.e., o # cl and cl ## scl must imply o # scl. This is ensured by a restriction in Section Interpretation of condition formulas; - I= is a mapping of the form Dind × Dind → D.
It gives meaning to the equality operator; - Iexternal is a mapping from the coherent set of schemas for externally defined functions to total functions D* → D. For each external schema σ = (?X1 ... ?Xn; τ) in the coherent set of external schemas associated with the language, Iexternal(σ) is a function of the form Dn → D.
For every external schema, σ, associated with the language, Iexternal(σ) is assumed to be specified externally in some document (hence the name external schema). In particular, if σ is a schema of a RIF built-in predicate or function, Iexternal(σ) is specified in [RIF-DTB] so that:- If σ is a schema of a built-in function then Iexternal(σ) must be the function defined in the aforesaid document;
- If σ is a schema of a built-in predicate then Itruth ο (Iexternal(σ)) (the composition of Itruth and Iexternal(σ), a truth-valued function) must be as specified in [RIF-DTB];
- Itruth is a mapping of the form D → TV.
It is used to define truth valuation for formulas.
For convenience, we also define the following mapping I from terms to D:
- I(k) = IC(k), if k is a symbol in Const;
- I(?v) = IV(?v), if ?v is a variable in Var;
- I(p(t1 ... tn)) = IP(I(p))(I(t1),...,I(tn));
- I(p(s1->v1 ... sn->vn)) = INP(I(p))({<s1,I(v1)>,...,<sn,I(vn)>})
Here we use {...} to denote a set of argument/value pairs; - I(o[a1->v1 ... ak->vk]) = Iframe(I(o))({<I(a1),I(v1)>, ..., <I(an),I(vn)>})
Here {...} denotes a bag of attribute/value pairs. Jumping ahead, we note that duplicate elements in such a bag do not affect the value of Iframe(I(o)) -- see Section Interpretation of condition formulas. For instance, I(o[a->b a->b]) = I(o[a->b]); - I(c1##c2) = Isub(I(c1), I(c2));
- I(o#c) = Iisa(I(o), I(c));
- I(x=y) = I=(I(x), I(y));
- I(External(t)) = Iexternal(σ)(I(s1), ..., I(sn)), if t is an instance of the external schema σ = (?X1 ... ?Xn; τ) by substitution ?X1/s1 ... ?Xn/s1.
Note that, by definition, External(t) is well-formed only if t is an instance of an external schema. Furthermore, by the definition of coherent sets of external schemas, t can be an instance of at most one such schema, so I(External(t)) is well-defined.
The effect of datatypes. The set DTS must include the datatypes described in Section Primitive Datatypes of [RIF-DTB].
The datatype identifiers in DTS impose the following restrictions. Given dt ∈ DTS, let LSdt denote the lexical space of dt, VSdt denote its value space, and Ldt: LSdt → VSdt the lexical-to-value-space mapping (for the definitions of these concepts, see Section Primitive Datatypes of [RIF-DTB]. Then the following must hold:
- VSdt ⊆ Dind; and
- For each constant "lit"^^dt such that lit ∈ LSdt, IC("lit"^^dt) = Ldt(lit).
That is, IC must map the constants of a datatype dt in accordance with Ldt.
RIF-PRD does not impose restrictions on IC for constants in symbol spaces that are not datatypes included in DTS.
2.3.2 Interpretation of condition formulas
This section defines how a semantic structure, I, determines the truth value TValI(φ) of a condition formula, φ.
We define a mapping, TValI, from the set of all condition formulas to TV. Note that the definition implies that TValI(φ) is defined only if the set DTS of the datatypes of I includes all the datatypes mentioned in φ and Iexternal is defined on all externally defined functions and predicates in φ.
Definition (Truth valuation). Truth valuation for well-formed condition formulas in RIF-PRD is determined using the following function, denoted TValI:
- Positional atomic formulas: TValI(r(t1 ... tn)) = Itruth(I(r(t1 ... tn)));
- Atomic formulas with named arguments: TValI(p(s1->v1 ... sk->vk)) = Itruth(I(p(s1->v1 ... sk->vk)));
- Equality: TValI(x = y) = Itruth(I(x = y)).
To ensure that equality has precisely the expected properties, it is required that:- Itruth(I(x = y)) = t if and only if I(x) = I(y) and that Itruth(I(x = y)) = f otherwise. This is tantamount to saying that TValI(x = y) = t iff I(x) = I(y);
- Subclass: TValI(sc ## cl) = Itruth(I(sc ## cl)).
To ensure that the operator ## is transitive, i.e., c1 ## c2 and c2 ## c3 imply c1 ## c3, the following is required:- For all c1, c2, c3 ∈ D, if TValI(c1 ## c2) = TValI(c2 ## c3) = t then TValI(c1 ## c3) = t;
- Membership: TValI(o # cl) = Itruth(I(o # cl)).
To ensure that all members of a subclass are also members of the superclass, i.e., o # cl and cl ## scl implies o # scl, the following is required:- For all o, cl, scl ∈ D, if TValI(o # cl) = TValI(cl ## scl) = t then TValI(o # scl) = t;
- Frame: TValI(o[a1->v1 ... ak->vk]) = Itruth(I(o[a1->v1 ... ak->vk])).
Since the bag of attribute/value pairs represents the conjunctions of all the pairs, the following is required, if k > 0:- TValI(o[a1->v1 ... ak->vk]) = t if and only if TValI(o[a1->v1]) = ... = TValI(o[ak->vk]) = t;
- Externally defined atomic formula: TValI(External(t)) = Itruth(Iexternal(σ)(I(s1), ..., I(sn))), if t is an atomic formula that is an instance of the external schema σ = (?X1 ... ?Xn; τ) by substitution ?X1/s1 ... ?Xn/s1.
Note that, by definition, External(t) is well-formed only if t is an instance of an external schema. Furthermore, by the definition of coherent sets of external schemas, t can be an instance of at most one such schema, so I(External(t)) is well-defined; - Conjunction: TValI(And(c1 ... cn)) = t if and only if TValI(c1) = ... = TValI(cn) = t. Otherwise, TValI(And(c1 ... cn)) = f.
The empty conjunction is treated as a tautology, so TValI(And()) = t; - Disjunction: TValI(Or(c1 ... cn)) = f if and only if TValI(c1) = ... = TValI(cn) = f. Otherwise, TValI(Or(c1 ... cn)) = t.
The empty disjunction is treated as a contradiction, so TValI(Or()) = f; - Negation: TValI(Not(c)) = f if and only if TValI(c) = t. Otherwise, TValI(Not(c)) = t;
- Existence: TValI(Exists ?v1 ... ?vn (φ)) = t if and only if for some I*, described below, TValI*(φ) = t.
Here I* is a semantic structure of the form <TV, DTS, D, Dind, Dpred, IC, I*V, IP, Iframe, INP, Isub, Iisa, I=, Iexternal, Itruth>, which is exactly like I, except that the mapping I*V, is used instead of IV. I*V is defined to coincide with IV on all variables except, possibly, on ?v1,...,?vn.
2.3.3 Satisfaction of a condition
We now define what it means for a set of ground formulas to satisfy a condition formula. The satisfaction of condition formulas by a set of ground formulas provides formal underpinning to the operational semantics of rulesets interchanged using RIF-PRD.
Definition (Models).
A semantic structure I is a model of a condition formula, φ, written as I |= φ, iff TValI(φ) = t.
Definition (Logical entailment). Let φ and ψ be formulas. We say that φ entails ψ, written as φ |= ψ, if and only if for every semantic structure, I, for which both TValI(φ) and TValI(ψ) are defined, I |= φ implies I |= ψ.
By extension, in this document, a set of formulas, Φ = {φ1, ..., φn}, n ≥ 1, is said to entail a formula ψ, written as Φ |= ψ, if and only if for every semantic structure, I, for which TValI(φ0), ..., TValI(φn), and TValI(ψ) are defined, I |= φ0 and ... and I |= φn implies I |= ψ.
Definition (Condition Satisfaction). Let Φ = {φ1, ..., φm}, m ≥ 1, be a set of ground formulas and ψ be a condition formula. We say that Φ satisfies ψ if and only if, for every semantic structure I that is a model of all the ground formulas φi in Φ: I |= φi, i= 1..m, there is at least one semantic structure I* such that:
- I* |= ψ, and
- I* is exactly like I, except that a mapping I*V is used instead of IV, such that I*V is defined to coincide with IV on all variables except, possibly, on the variables ?v0 ... ?vn, n ≥ 0, that are free in ψ, that is, such that: Var(ψ) = {?v0 ... ?vn}.
In other words, a set of ground formulas Φ = {φ1, ..., φm}m ≥ 1 satisfies a condition formula ψ iff Φ |= Exists ?v0 ... ?vn (ψ), where {?v0, ..., ?vn}n ≥ 0 = Var(ψ).
2.3.4 Consistent substitution and Pattern Matching
At the syntactic level, the interpretation of the variables by a valuation function IV is realized by a substitution. The consistent substitution of constants to variables, as defined below, provides the formal link between the model-theoretic semantics of condition formulas and the operational semantics of rule sets in RIF-PRD.
Let Term be the set of the terms in the RIF-PRD condition language (as defined in section Terms).
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=0..n where Dom(σ) = {xi}i=0..n and σ(xi) = ti, i = 0..,n.
Definition (Ground Substitution). A ground substitution is a substitution σ that assigns only constants to the variables in Dom(σ): ∀ x ∈ Dom(σ), σ(x) ∈ Const.
Definition (Consistent Substitution). Let ψ be a condition formula; let σ be a ground substitution for the free variables of ψ, that is, such that: Var(ψ) ⊆ Dom(σ); and let Φ be a set of ground formulas that satisfies ψ. We say that σ is consistent with respect to Φ, or Φ-consistent (or simply, consistent, when there is no ambiguity with respect to Φ) if an only if, for every semantic structure I that is a model of all the ground formulas φi in Φ, there is at least one semantic structure I*, such that:
- I* is a model of ψ: I* |= ψ;
- I* is exactly like I, except that a mapping I*V is used instead of IV, such that I*V is defined to coincide with IV on all variables except, possibly, on the variables ?v0 ... ?vn that are free in ψ, that is, such that: Var(ψ) = {?v0 ... ?vn};
- I*V(?xi) = IC(σ(?xi)), for all ?xi in Var(ψ).
In the definition of a consistent substitution, conditions 1 and 2 are the same as in the definition of Condition Satisfaction, and they guarantee that the Φ-consistency of a substitution for the free variables in ψ is defined with respect to the same semantic structures that make Φ satisfy ψ. Condition 3 guarantees that Φ |= ψ[σ], where ψ[σ] denotes the ground condition formula obtained by substituting σ(?x) for every occurence of ?x in ψ, for every variable ?x in Var(ψ).
In other words, a formula ψ matches a ground formula And(φ1, ..., φn), n > 0, with respect to a ground substitution σ, in the usual sense of pattern matching algorithms, e.g. [REFERENCE], if and only if σ is a consistent substitution for the free variables of ψ with respect to the set of ground formulas Φ = {φ1, ..., φn}.
3 Actions
This section specifies the actions that can be serialized using RIF-PRD, by specifying:
- the abstract syntax that all production rule languages interchanging rules using RIF-PRD must have in common for expressing actions;
- the concrete XML syntax used to serialize the action part of production rule in RIF-PRD;
- and the intended semantics of the individual action formulas in a RIF-PRD document.
3.1 Abstract Syntax
For a production rule language to be able to interchange rules using RIF-PRD, its alphabet for expressing the action part of a rule must, at the abstract syntax level, consist of syntactic constructs to denote:
- the assertion of a positional atom, of an atom with named argument, or of a frame;
- the negation of a positional atom, of an atom with named argument, or of a frame;
- the addition of a new frame object;
- the removal of a frame object and the negation of the corresponding frame;
- A sequence of atomic actions.
Editor's Note: ... and/or others. These are the ones that are in the current version of the draft spec.
For the sake of readibility and simplicity, this specification introduces a notation for these constructs. That notation is not intended to be a concrete syntax and it leaves out many details that are not needed for its purpose: the only concrete syntax for RIF-PRD is the XML syntax.
3.1.1 Atomic actions
Atomic action constructs take constructs from the RIF-PRD condition language as their arguments.
Definition (Atomic action). An atomic action (or, simply, action) can have several different firms and is defined as follows:
- Assert: If φ is a positional atom, an atom with named arguments, or a frame in the RIF-PRD condition language, it is also an action formula. φ is called the target of the action;
- Retract: If φ is a positional atom, an atom with named arguments, or a frame in the RIF-PRD condition language, then Retract(φ) is an action formula. φ is called the target of the action;
- Remove: If t is a term in the RIF-PRD condition language, then Retract(t) is an action formula. t is called the target of the action;
- Create: if c is a constant in the RIF-PRD condition language, then New(c) is an action formula. c is called the target of the action.
Editor's Note: The possibility to bind a new frame object as part of the create action has not been included, pending further discussion on declaring and binding local variables in the action part.
Definition (Ground atomic action). An atomic action with target t is a ground atomic action (or, simply, a ground action) if and only if Var(t) = {}.
3.1.2 Action blocks
A sequence of actions that can be represented in RIF-PRD is called an action block.
Any atomic action is also an action block.
Sequences of atomic actions are constructed with the help of a sequencing connective.
Definition (Action block). An action block, or action formula can have several forms and is defined as follows:
- Atomic: If a is an atomic action, it is also an action block;
- Sequence: If a1, ..., an, n ≥ 1, are action blocks, then so is Do(a1, ..., an), n ≥ 1.
Definition (Well-formed action block). An action block is well-formed if and only if:
- every constant symbol mentioned in φ occurs in exactly one context.
- Whenever a formula contains a function term t or an external atomic formula External(t), t must be an instance of the coherent set of external schemas (Section Schemas for Externally Defined Terms of [RIF-DTB]) associated with the language of RIF-PRD.
- If t is an instance of the coherent set of external schemas associated with the language then t can occur only as a function term t or as an external atomic formula External(t).
Editor's Note: Not sure this is enough... Anyway, the definition of an action block is not complete until we progress on the issue of declaring and binding local constants in the RHS.
Definition (RIF-PRD action language). The RIF-PRD action language consists of the set of all the well-formed action blocks that can be serialized using the RIF-PRD XML syntax.
3.2 XML syntax
This section specifies the XML syntax that is used to serialize, in RIF-PRD, what can appear in the action part of a rule supported by RIF-PRD.
RIF-PRD defines one single abstract class for actions, ACTION, that is realized by:
- the ASSERT action, which is concretely represented by the Atom or the Frame to be asserted;
- the concrete Retract construct, which is associated with an Atom or a Frame that represents the target of the action.
The following sections specify each construct separately, grouped by abstract syntactic classes.
Editor's Note: This section is still under discussion in the working group (see ISSUE-62). The working group considers adding an Assign action to represent the modification of the value of an attribute in a fact represented by a Frame, and an Execute action to represent the execution of an arbitrary, externally specified procedure. The working group seeks feedback regarding the proposed syntax for the currently specified actions, as well as regarding which constructs for serializing individual actions should be supported by RIF-PRD and/or required from RIF-PRD implementations.
3.2.1 ACTION
The ACTION class of constructs is used to represent the individual actions in the action part of a production rule represented in RIF-PRD.
This version of RIF-PRD covers fourACTIONs: ASSERT, New, Retract and ACTION_BLOCK .
As an abstract class, ACTION is not associated with specific XML markup in RIF-PRD instance documents.
[ ASSERT | New | Retract | ACTION_BLOCK ]
3.2.1.1 ASSERT
An ASSERT construct is used to represent actions that result in asserting an Atom or a Frame.
For compatibility with RIF-BLD, ASSERT is not associated with specific XML markup in RIF-PRD instance documents, and it is represented only as the target Atom or Frame.
[ Atom | Frame ]
Editor's Note: The working group seeks feedback regarding whether a specific XML element, Assert, modeled after the Retract element, below, should be used to serialize assertions, instead, to the price of reducing the interoperability with RIF-BLD.
3.2.1.2 New
The New construct is used to create a new frame object with membership in a given class.
The New element has an optional instance sub-element that contains a Var and a class sub-element that contains a Const. A new instance of the given class is created and bound to the instance variable.
<New>
<instance> Var </instance>?
<class> Const </class>
</New>
Example 2.9. The example below shows the RIF XML representation of an action that asserts a new potato.
<New>
<class>
<Const type="rif:iri">http://rif.examples.com/2008/joe#Potato</Const>
</class>
</New>
3.2.1.3 Retract
The Retract construct is used to represent actions that result in negating an atomic statement.
An Atom, a Frame, or a frame object may be retracted. A frame object is denoted using a TERM. A frame object is retracted by removing it from the Member relation and removing all its Frames.
The Retract element has one target sub-element that contains an Atom, a Frame, or a TERM construct that represents the facts to be removed on implementing the action.
<Retract>
<target> [ Atom | Frame | TERM ] </target>
</Retract>
Example 2.10. The example below shows the RIF XML representation of an action that updates the chicken-potato ownership table by removing the predicate that states that the chicken denoted by variable ?c owns the potato denoted by variable ?p. The predicate is represented as in example 2.4.
<Retract>
<target>
<Atom>
<op>
<Const type="rif:iri">
http://rif.examples.com/2008/joe#owns
</Const>
</op>
<args rif:ordered="yes">
<Var> c </Var>
<Var> p </Var>
</args>
</Atom>
</target>
</Retract>
3.2.1.4 ACTION_BLOCK
An ACTION_BLOCK construct is used to represent an ordered list of ACTIONs. There are two kinds of ACTION_BLOCK. One uses a restricted And construct for compatibility with RIF-BLD. The other uses a Do construct that is specific to RIF-PRD and permits local variables to be declared.
[ And | Do ]
<And>
<formula> ASSERT </formula>*
</And>
<Do>
<declare> Var </declare>*
<action> ACTION </action>*
</Do>
Example 2.11. The example below shows the RIF XML representation of an action block that asserts a new 100 decigram potato.
<Do rif:ordered="yes">
<declare><Var>p</Var></declare>
<New>
<instance><Var>p</Var></instance>
<class>
<Const type="rif:iri">http://rif.examples.com/2008/joe#Potato</Const>
</class>
</New>
<Frame>
<object><Var>p</Var></object>
<slot rif:ordered="yes">
<Const type="rif:iri">http://rif.examples.com/2008/joe#weight</Const>
<Const type="xsd:decimal">100</Const>
</slot>
</Frame>
</Do>
3.3 Operational semantics of actions
This section specifies the intended semantics of the action blocks in a RIF-PRD document.
The effect intended of the ground actions in the RIF-PRD action language is to change the set of conditions that are satisfied before and after each action is implemented.
As a consequence, the intended semantics of the ground actions in the RIF-PRD action language determines a relation, called the RIF-PRD transition relation: →RIF-PRD ⊆ P(W) × L × P(W), where W denotes the set of all the ground condition formulas in the RIF-PRD condition languages; where P(W) denotes the power set of W; and where L denotes the set of all the ground atomic actions in the RIF-PRD action language.
Definition (RIF-PRD transition relation). The intended semantics of the actions that can be represented in RIF-PRD is completely specified by the transition relation →RIF-PRD ⊆ P(W) × L × P(W), defined as follows:
- if f is a ground positional predicate, a predicate with named arguments, or a frame, and (w, w') ∈ W × W, (w, f, w') ∈ →RIF-PRD if and only if, for every ground formula φ in W, w' |= φ if and only if And(w, f) |= φ;
- if f is a ground positional predicate, a predicate with named arguments, or a frame, and (w, w') ∈ W × W, (w, Retract(f), w') ∈ →RIF-PRD if and only if, for every ground formula φ in W, w' |= φ if and only if w |= φ and φ |≠ f;
- if o is a constant and if f0, ..., fn, n ≥ 0, are ground frames where o is the object, and (w, w') ∈ W × W, (w, Retract(o), w') ∈ →RIF-PRD if and only if, for every ground formula φ in W, w' |= φ if and only if w |= φ and φ |≠ Or(f0, ..., fn);
Editor's Note: How to say that 'o' itself is removed?
- if c is a constant, and (w, w') ∈ W × W, (w, New(c), w') ∈ →RIF-PRD if and only if there is a constant o such that
- w |≠ o#c; and
- for every ground formula φ in W, w' |= φ if and only if And(w, o#c) |= φ;
Rule 1 says that all the condition formulas that were satisfied before an assertion will be satisfied after, and that the condition formulas that are satisfied by the asserted ground formula will be satisfied after the assertion.
Rule 2 says that all the condition formulas that were satisfied before a retraction will be satisfied after, except if they are satisfied only by the retracted fact.
Rule 3 says that all the condition formulas that were satisfied before the removal of a frame object will be satisfied after, except if they are satisfied only by one of the frames about the removed object or a conjunction of such frames.
Rule 4 says that all the condition formulas that were satisfied before the creation of a frame object will be satisfied after, as well as the condition formulas that are satisfied by a new membership formula, denoting a new instance of class c, and that were not satisfied before the creation.
4 Production rules, rulesets and RIF-PRD documents
This section specifies the rules and rulesets that can be serialized using RIF-PRD, by specifying:
- the abstract syntax that all production rule languages interchanging rules using RIF-PRD must have in common for rules and rule sets;
- the concrete XML syntax used to serialize production rules and rulesets in RIF-PRD;
- and the intended semantics of the rules and ruleset in a RIF-PRD document.
In addition, this section specifies additional concrete XML syntax for wrapping a ruleset in a RIF-PRD document and for adding meta-data to elements in a RIF-PRD document.
4.1 Abstract syntax
For a production rule language to be able to interchange rules using RIF-PRD, in addition to the RIF-PRD condition and action languages, its alphabet must, at the abstract syntax level, consist of syntactic constructs:
- to declare rule variables;
- to relate a condition formula to an action block;
- to relate variable bindings
- the relation between variable declarations and bindings, conditions and action parts
4.2 XML syntax
This section specifies the RIF-PRD constructs that are required, in addition to the ones specified in the sections on Conditions and Actions, to serialize, and interchange, complete production rules and rule sets.
The RULE construct is an abstract class: in RIF-PRD instance documents, it is either visible as a Implies, as a Forall, or as a single ACTIONS:
- The Implies associates one optional condition FORMULA and one non-empty ordered list of ACTIONS.
- The Forall construct declares one or more Vars, and associates them with zero or more FORMULAs, as patterns that constrain the bindings of the variables, and with one RULE as the formula in its scope.
Editor's Note: This version of the draft does not specify a specific construct to serialize a ruleset in RIF-PRD: the generic Group construct can be used for that purpose - as specified in the next section, Groupings and metadata. Future versions of this draft may specify a specific-purpose construct, especially if semantically significant information has to be associated to rulesets (e.g. parameters etc). The working group seeks feedback on this (see also ISSUE-63).
The following sections specify each construct separately, grouped by abstract syntactic classes.
This section specifies the additional 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.
4.2.1 RULE
In RIF-PRD, the RULE class of constructs is used to represent rules.
As an abstract class, RULE is not associated with specific XML markup in RIF-PRD instance documents.