RIF - User contributions [en]

Errata

Sandro — Wed, 08 May 2013 14:01:39 GMT

Sandro:

For errata reported through January 2013, see: [[Errata First Edition]]. These were all addressed in Second Edition.

For errata on the Second Edition, see http://www.w3.org/2001/sw/wiki/RIF_Errata

Please report any suspected errors to [mailto:public-rif-comments@w3.org public-rif-comments@w3.org] ([http://lists.w3.org/Archives/Public/public-rif-wg/ public archive]).

Errata

Sandro — Wed, 08 May 2013 13:54:27 GMT

Sandro:

For errata reported through January 2013, see: [[Errata First Edition]]. These were all addressed in Second Edition.

For errata on the Second Edition, see http://www.w3.org/2010/rif/errata

Please report any suspected errors to [mailto:public-rif-comments@w3.org public-rif-comments@w3.org] ([http://lists.w3.org/Archives/Public/public-rif-wg/ public archive]).

Errata

Sandro — Wed, 06 Feb 2013 17:54:45 GMT

Sandro:

For errata reported through January 2013, see: [[Errata First Edition]]. These were all addressed in Second Edition.

Please report any suspected errors to [mailto:public-rif-comments@w3.org public-rif-comments@w3.org] ([http://lists.w3.org/Archives/Public/public-rif-wg/ public archive]). Confirmed errors will be documented on this page.

Errata

Sandro — Wed, 06 Feb 2013 17:53:35 GMT

Sandro: moved Errata to Errata First Edition

#REDIRECT [[Errata First Edition]]

Errata First Edition

Sandro — Wed, 06 Feb 2013 17:53:35 GMT

Sandro: moved Errata to Errata First Edition

Please report any suspected errors to [mailto:public-rif-comments@w3.org public-rif-comments@w3.org] ([http://lists.w3.org/Archives/Public/public-rif-wg/ public archive]). Confirmed errors will be documented on this page.

== Proposed Erratum 1 ==

Typos in [[BLD#Semantic_Structures]] ([http://lists.w3.org/Archives/Public/public-rif-wg/2011Jan/0000.html reported here])

* In item: <em>'''''I'''''(<tt>o[a<sub>1</sub>->v<sub>1</sub> ... a<sub>k</sub>->v<sub>k</sub>]</tt>) = '''''I'''''<sub>frame</sub>('''''I'''''(<tt>o</tt>))({<'''''I'''''(<tt>a<sub>1</sub></tt>),'''''I'''''(<tt>v<sub>1</sub></tt>)>, ..., <'''''I'''''(<tt>a<sub>n</sub></tt>),'''''I'''''(<tt>v<sub>n</sub></tt>)>})</em>
Thus, for instance, <tt>[a->b a->b]</tt> and <tt>o[a->b]</tt> always have the same truth value.
should read
Thus, for instance, <tt>o[a->b a->b]</tt> and <tt>o[a->b]</tt> always have the same truth value.

* Last sentence before '''''The effect of datatypes'''''
This implies that the equalities like t(a->1 b->2 c->3) = t(c->3 a->2 b->2) are tautologies in RIF-BLD.
should read
This implies that the equalities like t(a->1 b->2 c->3) = t(c->3 a->1 b->2) are tautologies in RIF-BLD.

'''Corrected'''

== Proposed Erratum 2 ==

XML serialization of <tt>rdf:PlainLitteral</tt> ([http://lists.w3.org/Archives/Public/public-rif-dev/2010Nov/0000.html reported here] and [http://lists.w3.org/Archives/Public/public-rif-comments/2009Nov/0000.html here]). See WG reply ([http://lists.w3.org/Archives/Public/public-rif-comments/2010Mar/0004.html here])

* PROPOSE to make it explicit (in DTB) that the <tt>xml:lang</tt> attribute must be used with value equal ''langTag'' for <tt>rdf:PlainLitteral</tt> constant where the ''langTag'' is not empty and that the content of a <tt>Const</tt> element with <tt>type="&rdf;PlainLitteral"</tt> is either the data value if the <tt>xml:lang</tt> attribute is not present, or the first element in the data value pair if the <tt>xml:lang</tt> attribute is present.

== Proposed Erratum 3 ==

Empty <tt>args</tt> tag must be omitted in RIF/XML ([http://lists.w3.org/Archives/Public/public-rif-dev/2010Sep/0000.html reported here])

* As discussed [http://lists.w3.org/Archives/Public/public-rif-dev/2010Sep/0002.html here] and [http://lists.w3.org/Archives/Public/public-rif-wg/2010Nov/0000.html] here, and as published to the dev community [http://lists.w3.org/Archives/Public/public-rif-dev/2012Feb/0000.html here]
* Requires corrections in BLD (as proposed by Harold [http://lists.w3.org/Archives/Public/public-rif-wg/2010Nov/0000.html here]) and in FLD

Added 10 July 2012 by csma:

We have the same pb with the <tt>items</tt> role sub-element in <tt>List</tt>. PRD says explicitely that an empty list has an empty <tt>items</tt> sub-element ([http://www.w3.org/2005/rules/wiki/PRD#List section 8.3.1.3]), but the XML schema says that the empty <tt>items</tt> sub-element must be omitted. BLD and FLD may have the same pb (I am not comfortable enough with the notation in the XML mapping to be sure :-).

PROPOSED: correct:
* section 8.3.1.3 in PRD '''corrected (see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14463&oldid=12718 here])
* the empty <tt>args</tt> XML mapping in BLD.
'''Corrected:''' http://www.w3.org/2005/rules/wiki/index.php?title=BLD&diff=14569&oldid=14564
* the empty <tt>args</tt> XML mapping in FLD.
'''Corrected:''' http://www.w3.org/2005/rules/wiki/index.php?title=FLD&diff=14572&oldid=14451

== Proposed Erratum 4 ==

Possible typo in all RIF documents ([http://lists.w3.org/Archives/Public/public-rif-dev/2010Jun/0000.html reported here])

* At the end of first paragraph in '''XML Schema Datatypes Dependency'''
required as otherwise specified
should read?
required unless otherwise specified

PROPOSED: remove the XML Schema Datatypes Dependency section in all documents.

== Proposed Erratum 5 ==

'''No action''': it looks like that one had been corrected before REC already...

----

XML Schema VS presentation syntax mismatch ([http://lists.w3.org/Archives/Public/public-rif-comments/2009Oct/0009.html reported here] and [http://lists.w3.org/Archives/Public/public-rif-comments/2009Nov/0000.html here])

* BLD and PRD presentation syntaxes say
Import ::= IRIMETA? 'Import' '(' LOCATOR PROFILE? ')'
LOCATOR ::= ANGLEBRACKIRI
PROFILE ::= ANGLEBRACKIRI
whereas the XML Schemata say
<xs:element name="Import">

<xs:complexType>
<xs:sequence>
<xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
<xs:element ref="location"/>
<xs:element ref="profile" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="location" type="xs:anyURI"/>

<xs:element name="profile" type="xs:anyURI"/>
* In BLD, [[BLD#Mapping_of_the_Rule_Language|the mapping of the rule language]] must be corrected as well
* PS: there is a note in [[BLD#Formulas|section 2.3]] in BLD that says:
Note that although Base, Prefix, and Import all use symbols of the form <iri> to indicate the connection of these symbols to IRIs, these symbols are not rif:iri constants, as semantically they are interpreted in a way that is quite different from constants.
So, it would be a clarification rather than an erratum properly said.

== Proposed Erratum 6 ==

PRD and BLD disagree on use of xml:base (see also the last item in [http://lists.w3.org/Archives/Public/public-rif-comments/2009Nov/0000.html this comment])
* PRD says ([[PRD#Relative_IRIs_and_XML_base|section 8.2]])
Relative IRIs are allowed in RIF-PRD XML syntax, anywhere IRIs are allowed, including constant types, symbol spaces, location, and profile. The attribute <tt>xml:base</tt> <nowiki>[</nowiki>[[#xml-base|XML-Base]]] is used to make them absolute.
while BLD says ([[BLD#Formulas|section 2.3]])
Like the Base directive, the Prefix directives define shorthands to allow more concise representation of constants that come from the symbol space rif:iri (we will call such constants rif:iri constants).
and ([[BLD#XML_for_the_Rule_Language|section 4.2]])
A Base directive in the presentation syntax becomes an xml:base attribute [XML-Base] in the XML Document tag. The base IRI specified as the value of that attribute applies to content of the RIF/XML element that deals with rif:iri constants, namely to relative-IRI content of the <Const type="&rif;iri"> element.
* DTB is not specific on this, and says only ([[DTB#Relative_IRIs|section 2.2.3]])
Relative IRIs in RIF documents are resolved with respect to the base IRI.
* Based on the discussion and resolution taken during the [http://lists.w3.org/Archives/Public/public-rif-wg/2010Feb/att-0010/2010-02-02-rif-minutes.html 2 Feb 2010 telecon], the intent seemed to be as specified in PRD:
RESOLVED: We clarify that relative IRIs are allowed in RIF syntaxes (anywhere IRIs are allowed, including Const rif:iri, symbol spaces, location, and profile), and that xml:base is used in making them absolute; the absolute form is seen and used internally, so that's the lexical space.
* So does [http://lists.w3.org/Archives/Public/public-rif-comments/2010Mar/0004.html WG reply to comments] say.

'''Corrected:''' http://www.w3.org/2005/rules/wiki/index.php?title=BLD&diff=14564&oldid=14558

== Proposed Erratum 7 ==

Remove editor's note in Core [http://www.w3.org/TR/rif-core/#Strong_Safeness_.28Informative.29 section 6.2] (reported [http://lists.w3.org/Archives/Public/public-rif-comments/2011Mar/0002.html here])

'''Corrected+:''' http://www.w3.org/2005/rules/wiki/index.php?title=Core&diff=14456&oldid=13188

== Proposed Errata for RIF-PRD ==

=== Proposed Erratum 8 ===

Handling of frame atomic formulas in RIF-PRD (reported [http://lists.w3.org/Archives/Public/public-rif-comments/2010Jun/0000.html here], item #1)

According to Definition of Matching Substitution (sect. 2.2.1) the empty substitution does not match the ground formula s[p1->v1] to { s[p1->v1 p2->v2] } since s[p1->v1] does not belong to { s[p1->v1 p2->v2] }.

Is this the intended behaviour?

A related problem is when the action is retract( s[p1->v1] ) applied to state { s[p1->v1 p2->v2] }.

The result according to the specification is apparently { s[p1->v1 p2->v2] }.

Is this the intended behaviour?

In summary, is { s[p1->v1 ... pn -> vn] } equivalent to { s[p1->v1], ..., s[pn->vn]} or not?

This not the intended behaviour: { s[p1->v1 ... pn -> vn] } is intended to behave exactly like { s[p1->v1], ..., s[pn->vn]}.

PROPOSED ('''corrected see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14468&oldid=14465 here]'''):
* to modify the definition of matching substitution, in [http://www.w3.org/TR/rif-prd/#Matching_substitution section 2.2.1], to read

'''Definition (Matching substitution).''' Let ''ψ'' be a RIF-PRD condition formula; let ''σ'' be a ground substitution such that ''Var(ψ) &sube; Dom(σ)''; and let ''Φ'' be a set of ground RIF-PRD atomic formulas.

We say that the ground substitution ''σ'' '''''matches''''' ''ψ'' to ''Φ'' if and only if one of the following is true:
* ''ψ'' is an atomic formula and either
** ''σ(ψ)'' ∈ ''Φ'', or
** ''ψ'' is a frame with multiple slots, <tt>o[s<sub>1</sub>->v<sub>1</sub>...s<sub>n</sub>->v<sub>n</sub>]</tt>, ''n > 1'', and there is one ''i, 1≤i≤n'', such that ''σ'' matches the conjunction <tt>And(o[s<sub>i</sub>->v<sub>i</sub>] o[s<sub>1</sub>->v<sub>1</sub>...s<sub>i-1</sub>->v<sub>i-1</sub> s<sub>i+1</sub>->v<sub>i+1</sub>...s<sub>n</sub>->v<sub>n</sub>]</tt> to ''Φ''; or
** ...

* to modify the definition of atomic action in [http://www.w3.org/TR/rif-prd/#Actions_2 section 3.1.1] to read

'''Definition (Atomic action).''' ...
# ''Assert simple fact'': If <tt>φ</tt> is ... a single slot [[#def-prd-atomic-formula|frame]] ...
# ''Retract simple fact'': If <tt>φ</tt> is ... a single slot [[#def-prd-atomic-formula|frame]] ...
# ...
* to modify the definition of compound action in [http://www.w3.org/TR/rif-prd/#Actions_2 section 3.1.1] to read

'''Definition (Compound action).''' A '''''compound action''''' is a construct that can be replaced equivalently by a pre-defined, and fixed, sequence of atomic actions. In RIF-PRD, a compound action can have three different forms, defined as follows:
# ''Assert compound fact'': If <tt>φ</tt> is a [[#def-prd-atomic-formula|frame]] with multiple slots: <tt>φ</tt> = <tt>o[s<sub>1</sub>->v<sub>1</sub>...s<sub>n</sub>->v<sub>n</sub>]</tt>, ''n > 1''; then <tt>Assert(φ)</tt> is a compound action, defined by the sequence <tt>Assert(o[s<sub>1</sub>->v<sub>1</sub>]) ... Assert(o[s<sub>n</sub>->v<sub>n</sub>])</tt>. <tt>φ</tt> is called the ''target'' of the action.
# ''Retract compound fact'': If <tt>φ</tt> is a [[#def-prd-atomic-formula|frame]] with multiple slots: <tt>φ</tt> = <tt>o[s<sub>1</sub>->v<sub>1</sub>...s<sub>n</sub>->v<sub>n</sub>]</tt>, ''n > 1''; then <tt>Retract(φ)</tt> is a compound action, defined by the sequence <tt>Retract(o[s<sub>1</sub>->v<sub>1</sub>]) ... Retract(o[s<sub>n</sub>->v<sub>n</sub>])</tt>. <tt>φ</tt> is called the ''target'' of the action.
# ''Modify fact'': if <tt>φ</tt> is a [[#def-prd-atomic-formula|frame]] in the RIF-PRD condition language: <tt>φ</tt> = <tt>o[s<sub>1</sub>->v<sub>1</sub>...s<sub>n</sub>->v<sub>n</sub>]</tt>, ''n > 0''; then <tt>Modify(φ)</tt> is a compound action, defined by the sequence: [[#def-atomic-action|<tt>Retract(o s<sub>1</sub>)</tt>]] ... <tt>Retract(o s<sub>n</sub>)</tt>, followed by [[#def-atomic-action|<tt>Assert(φ)</tt>]]. <tt>φ</tt> is called the ''target'' of the action.   ☐
* to modify the definition of state of the fact base, [http://www.w3.org/2005/rules/wiki/PRD#Condition_satisfaction section 2.2.2], to restrict Φ to contain only single-slot frames
* and to add a note in the definition of frame, [http://www.w3.org/2005/rules/wiki/PRD#Atomic_formulas section 2.1.2], to say that frames with multiple slots are a shortcut for, and semantically equivalent to conjunctions of single slot frames with the same object.

=== Proposed Erratum 9 ===

Definition of rule variables in RIF-PRD (section 4.2.3) (reported [http://lists.w3.org/Archives/Public/public-rif-comments/2010Jun/0000.html here], item #2)

The concept of rule variable is never formally defined (the notion of
rule variable appears afterwards in Section 7.3 and 8.5.1.3 Forall).
My interpretation is the following:
for unconditional action blocks, rule variables are empty (i.e. free
variables).
- for conditional action blocks, rule variables are the free variables.
- for rules with variable declarations, the rule variables are the
universally quantified variables.

Is this correct? Wouldn't it make more sense to equate rule variables
to free variables in all cases?
In this way, universally quantified variables would be ignored for
comparing instances of two rules, while free variables
would be used for that purpose in all cases. This behaviour is
probably more coherent and easier to explain to users.

The term "rule variables" is used to denote the variables that are universally quantified in a rule, to differentiate them from the variables that are existentially quantified in rule conditions, and from the action variables.

Equivalently, the rule variables are the free variables in the conditional action block in a rule after steps 2 and 3 of Core-ification.

'''Proposed modification (corrected see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14471&oldid=14468 here])''': Add the following sentence, after the definition of well-formed group, in [http://www.w3.org/TR/rif-prd/#Well-formed_rules_and_groups section 4.1.4]:

"The variables that are universally quantified in a rule are sometimes called ''rule variables'' in the remainder of this document, to distinguish them from the action variables and from the existentially quantified variables. The function ''CVar'', that maps a rule to the set of its rule variables is defined as follows:
* if ''r'' is a conditional or unconditional action block, ''CVar(r) = ∅''
* if ''r'' is a rule with variable declaration, <tt>Forall ?v<sub>1</sub>...?v<sub>n</sub> (r')</tt>, ''CVar(r) = CVar(r') ∪ {<tt>?v<sub>1</sub></tt>...<tt>?v<sub>n</sub></tt>}''.

=== Proposed Erratum 10 ===

Handling of variable name clashes in Core-ification of RIF-PRD rules (reported [http://lists.w3.org/Archives/Public/public-rif-comments/2010Jun/0000.html here], last paragraph in item #2)

A related problem occurs in Section 7.3, where in case 2 of the
algorithm clashes of names among rule variables are not taken care.

Name clashes are not taken care of in the RIF-PRD spec, indeed: the assumption was that the variables would be renamed to avoid them, I assume.

'''Proposed modification''': In step 2 of the Core-ification algorithm, section 7.3, change the sentence

"If the rule inside a rule with variable delcaration, r1, is also a rule with variable declaration, r2, all the rule variable delarations and all the patterns that occur in r1 (and not in r2) should be added to the rule variable declarations and the patterns that occur in r2, and, after the transform, r1 should be replaced by r2, in the rule set"

for (taking the opportunity to correct the typos as well)

"If the <tt>rule</tt> inside a rule with variable declaration, r1, is also a rule with variable declaration, r2, all the rule variable declarations and all the patterns that occur in r1 should be added to the rule variable declarations and the patterns that occur in r2, and, after the transform, r1 should be replaced by r2, in the rule set. If the names of some variables declared in r1 are the same as the names of some variables declared in r2, the former names must be changed prior to the transform."

'''Corrected (see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14488&oldid=14471 here])'''

=== Proposed Erratum 11 ===

Errors in the PS in the example 9.1 and issues wrt the PS EBNF (reported [http://lists.w3.org/Archives/Public/public-rif-comments/2011Jan/0000.html here])

The proposed corrections are valid (checked 10 July 2012). Here is a shorter valid version:

Document(

Prefix( ex1 <http://example.com/2009/prd2> )

(* ex1:CheckoutRuleset *)
Group (
(* ex1:GoldRule *)
Group (
Forall ?customer such that And(?customer # ex1:Customer
?customer[ex1:status -> "Silver"])
(Forall ?shoppingCart such that ?customer[ex1:shoppingCart -> ?shoppingCart]
(If Exists ?value (And(?shoppingCart[ex1:value -> ?value]
External(pred:numeric-greater-than-or-equal(?value 2000))))
Then Do(Modify(?customer[ex1:status -> "Gold"])))))

(* ex1:DiscountRule *)
Group (
Forall ?customer such that ?customer # ex1:Customer
(If Or( ?customer[ex1:status -> "Silver"]
?customer[ex1:status -> "Gold"])
Then Do ((?s ?customer[ex1:shoppingCart -> ?s])
(?v ?s[ex1:value -> ?v])
Modify(?s [ex1:value -> External(func:numeric-multiply (?v 0.95))]))))

(* ex1:NewCustomerAndWidgetRule *)
Group (
Forall ?customer such that And(?customer # ex1:Customer
?customer[ex1:status -> "New"] )
(If Exists ?shoppingCart ?item
(And(?customer[ex1:shoppingCart -> ?shoppingCart]
?shoppingCart[ex1:containsItem -> ?item]
?item # ex1:Widget ) )
Then Do( (?s ?customer[ex1:shoppingCart -> ?s])
(?val ?s[ex1:value -> ?val])
Retract(?customer ex1:voucher)
Modify(?s[ex1:value -> External(func:numeric-multiply(?val 0.90))]))))

(* ex1:UnknownStatusRule *)
Group (
Forall ?customer such that ?customer # ex1:Customer
(If Not(Exists ?status
(And(?customer[ex1:status -> ?status]
External(pred:list-contains(List("New" "Bronze" "Silver" "Gold") ?status)) )))
Then Do( Execute(act:print(External(func:concat("New customer: " ?customer))))
Assert(?customer[ex1:status -> "New"]))))
)
)

'''Corrected (see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14490&oldid=14488 here])'''

=== Proposed Erratum 12 ===

Error in comment in XML Schema for PRD (reported [http://lists.w3.org/Archives/Public/public-rif-comments/2011Jan/0002.html here])

In a comment of RIF PRD XML Schema

<xs:group name="RULE">


should be

<xs:group name="RULE">


'''Proposed modification''': correct the typo.

'''Corrected (see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14493&oldid=14490 here])'''

=== Proposed Erratum 13 ===

Unbindable action variable in RIF-PRD (reported [http://lists.w3.org/Archives/Public/public-rif-comments/2012Jun/0000.html here])

The RIF-PRD spec does not say what happens with a rule instance where the rule contains an action variable binding (?v ?o[?p->?v]) and there is no substitution for ?v that matches ?o[?p->?v] to the state of facts for the rule instance substitution of ?o and ?p.

PROPOSED (see also discussion [http://lists.w3.org/Archives/Public/public-rif-wg/2012Jul/0002.html here]):
Add a clarification, after the definition of action instance, in [http://www.w3.org/2005/rules/wiki/PRD#Definitions_and_notational_conventions section 4.2.3], to the effect that RIF-PRD does not specify a semantics for that case, because the specification of the context where an otherwise valid RIF-PRD rule is validly applicable is out os the scope of RIF-PRD.

'''Corrected (see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14496&oldid=14493 here])''': Added the following paragraph after the definiiton of action instance in section 4.2.3:

Notice that RIF-PRD does not specify semantics for the case where there is no matching substitution for the binding frame formula o[s->vi] in an action variable declaration (vi o[s->vi]). Indeed, although the rule might be valid from an interchange viewpoint, applying it in a context where object o has no value for attribute s is applying it outside the domain where it is meaningful, and the specification of the context where an otherwise valid RIF-PRD rule is validly applicable is out of the scope of RIF-PRD.

=== Proposed Erratum 14 ===

Errors in the semantics of Assert and Retract (reported [http://lists.w3.org/Archives/Public/public-rif-comments/2011Mar/0000.html here])

==== Erratum 14.1 ====

The semantics of the Assert atomic action is described as follows at:

Rule 1 says that *all the condition formulas that were satisfied before an
assertion will be satisfied after*, and that, in addition, the condition
formulas that are satisfied by the asserted ground formula will be satisfied
after the assertion. No other condition formula will be satisfied after the
execution of the action.

where, Rule 1 is formally defined as:
α is Assert(φ), where φ is a ground atomic formula, and *w' = w ∪ {φ}*;

But an assertion could change the satisfaction of negation formula,
right? ie. a negation formula may be satisfied in w but not in w'.

(A similar argument follows for Rule 2)

PROPOSED (see also reply [http://lists.w3.org/Archives/Public/public-rif-comments/2012Jul/0000.html here]): Modify the text explaining the effect of rule 1 and rule 2 to read:

'''Corrected (see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14498&oldid=14496 here])'''

''Rule 1 says that all the ''atomic'' condition formulas that were satisfied ..., and that, in addition the ''atomic'' condition formula that are satisfied ... No other ''atomic'' condition formula will be satisfied after the execution of the action.''

''Rule 2 says that all the ''atomic'' condition formulas that were satisfied ... No other ''atomic'' condition formula will be satisfied after the execution of the action.''

==== Erratum 14.2 ====

Furthermore, the formal definition doesn't mention conditional formula while
the description (referred above) does. Is something missing there?

PROPOSED (see also [http://lists.w3.org/Archives/Public/public-rif-comments/2012Jul/0000.html here]): modify the definition of the RIF-PRD transition relation, in [http://www.w3.org/TR/rif-prd/#Operational_semantics_of_atomic_actions section 3.2] to read:

'''Corrected (see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14500&oldid=14498 here])'''

'''Definition (RIF-PRD transition relation).''' The semantics of RIF-PRD atomic actions is specified by the '''transition relation →<sub><sub>RIF-PRD</sub></sub>''' &sube; ''W'' × ''L'' × ''W''. ''(w, <tt>α</tt>, w') ∈ →<sub><sub>RIF-PRD</sub></sub>'' if and only if ''w'' ∈ ''W'', ''w' ''∈ ''W'', <tt>α</tt> is a ground atomic action, and one of the following is true, where ''Φ'' is a set of ground atomic formulas that represents ''w'' and ''Φ' '' is a set of ground atomic formulas that represent ''w' '':
# <tt>α</tt> is <tt>Assert(φ)</tt>, where φ is a ground atomic formula, and ''Φ' = Φ ∪ {φ}'';
# <tt>α</tt> is <tt>Retract(φ)</tt>, where φ is a ground atomic formula, and ''Φ' = Φ \ {φ}'';
# <tt>α</tt> is <tt>Retract(o s)</tt>, where <tt>o</tt> and <tt>s</tt> are constants, and ''Φ' = (Φ \ {<tt>o[s->v]</tt> | for all the values of <tt>v</tt>});
# <tt>α</tt> is <tt>Retract(o)</tt>, where <tt>o</tt> is a constant, and ''Φ' = Φ \ {<tt>o[s->v]</tt> | for all the values of terms <tt>s</tt> and <tt>v</tt>} - {<tt>o#c</tt> | for all the values of term <tt>c</tt>}'';
# <tt>α</tt> is <tt>Execute(φ)</tt>, where φ is a ground atomic builtin action, and ''Φ' = Φ''.   ☐

=== Proposed Erratum 15 ===

In PRD, a matching substitution for an equality formula is defined wrt the value of ground terms ([http://www.w3.org/TR/rif-prd/#Matching_substitution section 2.2.1]). But the value of ground terms is not defined precisely, except for constants in a data types (reported [http://lists.w3.org/Archives/Public/public-rif-wg/2012Jul/0003.html here]).

'''Corrected''': see Erratum 16.2, infra.

=== Proposed Erratum 16 ===

Possibly inconsistent matching substitutions for equality formulas due to incomplete definition in PRD (reported by Jesse Weaver in a private email).

==== Erratum 16.1 ====

RIF-PRD says ([[PRD#Matching_substitution|section 2.2.1]]):

''Because RIF-PRD covers only externally defined interpreted functions, a ground functional term can always be replaced by its value. As a consequence, a ground substitution can always be restricted, without loss of generality, to assign only constants to the variable in its domain. In the remainder of this document, it will always be assumed that a ground substitution assigns only constants to the variables in its domain.''

But a ground list can be assigned to a variable as well! The purpose of the above sentence is, really, to say that ground external terms can always be replaced by the (non-external) ground term to which they evaluate, and that it will be assumed in the remainder of the document that ground formulas never contain external ground terms (that is, that external ground terms are always replaced by their evaluation in ground formulas). As a consequence, a variable is never assigned an external ground term.

PROPOSED: to replace above paragraph with the following:

'''Corrected (see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14503&oldid=14500 here])'''

''Because RIF-PRD covers only externally defined interpreted functions, a ground positional term can always be replaced by the (non-positional) ground term to which it evaluates. As a consequence, a ground RIF-PRD formula can always be restricted, without loss of generality, to contain no positional term; that is, to be such that any ground positional terms have been replaced with the non-positional ground terms to which they evaluate. In the remainder of this document, it will always be assumed that a ground condition formula never contains any positional term. As a consequence, a ground substitution never assigns a ground positional term to the variables in its domain.''

==== Erratum 16.2 ====

a set of facts \Phi representing a state of the fact base may include
ground, equality, atomic formulas. In that case, the definition of
matching substitution implies: \sigma matches t1=t2 to \Phi iff \sigma(t1)
and \sigma(t2) "have the same value" ***OR*** \sigma(t1=t2) \in \Phi.

So as things are currently defined, it seems there are two ways to match
t1=t2 to \Phi. One is for the two sides to be mapped to the same value,
and the other is to match a fact.

Correct. The problem is that the current definition of a state of the fact base ([[PRD#Condition_satisfaction|section 2.2.2]]) allows the two ways to match an equality to disagree (e.g. if the state of the fact base contains the atomic equality "1^^xs:integer=2^^xs:integer").

PROPOSED: change the definition of state of the fact base, [[PRD#Condition_satisfaction|section 2.2.2]], to read:

'''Corrected (see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14506&oldid=14503 here])'''

'''Definition (State of the fact base).''' A '''''state of the fact base''''', ''w<sub>Φ</sub>'', is associated to every set of ground atomic formulas, ''Φ'', that contains no frame with multiple slots and that satisfies all the following conditions:
* for every equality formula <tt>t<sub>1</sub>=t<sub>2</sub></tt> in ''Φ'', if ''t<sub>1</sub>'' and ''t<sub>2</sub>'' are, both, constants in symbol spaces that are data types, then they have the same value;
* for all triple of constants ''c<sub>1</sub>, c<sub>2</sub>'', ''c<sub>3</sub>''...'''

And clarify the definition of matching substitution in [[PRD#Matching_substitution|section 2.2.1]] to read:

'''Corrected (see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14508&oldid=14506 here])'''

...
* ''ψ'' is an atomic formula and either
** ''σ(ψ)'' ∈ ''Φ'', or
** ...
** ''ψ'' is an equality formula, <tt>t<sub>1</sub> = t<sub>2</sub></tt>, and the ground terms ''σ(t<sub>1</sub>)'' and ''σ(t<sub>2</sub>)'' ''are constants in symbol spaces that are data types and they'' have the same value;
* ...

==== Erratum 16.3 ====

Jesse Weaver noticed that, while the above modifications corrected previously raised issues, it did not guaranty symmetry and transitivity of equality, see [http://lists.w3.org/Archives/Public/public-rif-comments/2012Sep/0000.html here] (neither reflexivity, by the way).

PROPOSED ('''corrected [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14647&oldid=14551 here]'''): Adding the following constraints to the definition of state of the fact base, [[PRD#Condition_satisfaction|section 2.2.2]]:
* for every pair of constants ''c<sub>1</sub>'' and ''c<sub>2</sub>'', if ''c<sub>1</sub> = c<sub>2</sub>'' ∈ ''Φ'', then ''c<sub>2</sub> = c<sub>1</sub>'' ∈ ''Φ'';
* for every triple of constants ''c<sub>1</sub>'', ''c<sub>2</sub>'' and ''c<sub>3</sub>'', if ''c<sub>1</sub> = c<sub>2</sub>'' ∈ ''Φ'' and ''c<sub>2</sub> = c<sub>3</sub>'' ∈ ''Φ'', then ''c<sub>1</sub> = c<sub>3</sub>'' ∈ ''Φ'';"

and add the following condition in the definition of matching substitution in [[PRD#Matching_substitution|section 2.2.1]], under "''ψ'' is an equality formula, <tt>t<sub>1</sub> = t<sub>2</sub></tt> and either...":
** or the ground terms ''σ(t<sub>1</sub>)'' and ''σ(t<sub>2</sub>)'' are the same ground term;

==== Erratum 16.4 ====

While correcting erratum 16.1 and 16.2, I (csma) realized that, as they were defined, matching substitutions did not handle list equality.

PROPOSED: Modify the definition of matching substitution in [[PRD#Matching_substitution|section 2.2.1]] to read:

'''corrected ([http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14511&oldid=14508 here])'''

* ''ψ'' is an atomic formula and either
** ''σ(ψ)'' ∈ ''Φ'', or
** ...
** ''ψ'' is an equality formula, <tt>t<sub>1</sub> = t<sub>2</sub></tt>, and either
*** ''the ground terms ''σ(t<sub>1</sub>)'' and ''σ(t<sub>2</sub>)'' are list terms with the same length ''n≥0'' and, for all ''i, 0≤i≤n-1'', such that ''l<sub>1<sub>i</sub></sub>'' and ''l<sub>2<sub>i</sub></sub>'' are the ground terms of rank ''i'' in ''σ(t<sub>1</sub>)'' and ''σ(t<sub>2</sub>)'', respectively, either ''l<sub>1<sub>i</sub></sub>'' and ''l<sub>2<sub>i</sub></sub>'' are both constants in symbol spaces that are data types and they have the same value, or <tt>l<sub>1<sub>i</sub></sub> = l<sub>2<sub>i</sub></sub></tt> ∈ ''Φ'',''
*** or the ground terms ''σ(t<sub>1</sub>)'' and ''σ(t<sub>2</sub>)'' are constants in symbol spaces that are data types and they have the same value;
* ...

==== Erratum 16.5 ====

Jesse Weaver noticed that erratum 16.4 introduced the counter-intuitive possibility to equate a constant in a data type and a list, e.g. to a fact base may validly contain fact "3=List()" (see [http://lists.w3.org/Archives/Public/public-rif-comments/2012Sep/0000.html here])

PROPOSED: add the following constraint in the definition of state of the fact base, [[PRD#Condition_satisfaction|section 2.2.2]]:
* for every equality formula ''c<sub>1</sub> = c<sub>2</sub>'' ∈ ''Φ'', either c<sub>1</sub> is not a constant in a symbol space that is a data type, of c<sub>2</sub> is not a list term;.

'''Corrected ([http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14649&oldid=14647 here])

=== Proposed Erratum 17 ===

Propagation of membership through class hierarchy when asserting class membership (reported by Jesse Weaver, see reply [http://lists.w3.org/Archives/Public/public-rif-wg/2012Jul/0005.html here]).

Consider a set of facts \Phi = {c_2##c_1} which represents a state of a fact base.

Consider the following rule:

Do( (?y New()]) Assert(?y#c_2) ) )

By definition of RIF-PRD transition relation (section 3.2), assuming
that the new frame object is identified as _new, the next
state of the fact base is represented by \Phi* = \Phi \cup {_new#c_2},
which is \Phi* = { _new#c_2, c_2##c_1 } .

However,
since _new#c_2 \in \Phi and c_2##c_1 \in \Phi and _new#c_1 \notin \Phi,
then by definition of state of the fact base (section 2.2.2), \Phi*
cannot represent a state of the fact base.

PROPOSED: move the constraint that all members of a subclass must also be members of all the super classes from the definition of a state of the fact base to the definition of a matching substitution, that is

'''Corrected (see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14516&oldid=14511 here])'''

* remove from the definition of state of the fact base the condition that for all triple of constants ''c<sub>1</sub>, c<sub>2</sub>'', ''c<sub>3</sub>'', if ''c<sub>1</sub>#c<sub>2</sub> ∈ Φ'' and ''c<sub>2</sub>##c<sub>3</sub> ∈ Φ'', then ''c<sub>1</sub>#c<sub>3</sub> ∈ Φ''
* modify the definition of matching substitution ([[PRD#Matching_substitution|section 2.2.1]]) to say

...
* ''ψ'' is an atomic formula and either
** ''σ(ψ)'' ∈ ''Φ'', or
** ''ψ'' is a membership formula <tt>o # c</tt>, and there is a ground term ''c' '' such that ''σ'' matches the conjunction <tt>And(o#c' c'##c)</tt> to ''Φ'', or
** ...

=== Proposed Erratum 18 ===

Action variable binding to a (ground) list (report by Jesse Weaver, see [http://lists.w3.org/Archives/Public/public-rif-wg/2012Jul/0004.html here], last comment).

the definition of action instance requires that d
be a constant, which seems overly restrictive. What if a[p->List()]
\in \Phi, which is allowed by definition of frame atomic formula
(section 2.1.2) and definition of term (section 2.1.1).)

PROPOSED: change the second bullet in the definition of action instance ([[PRD#Definitions_and_notational_conventions|section 4.2.3]]) to read:

'''Corrected (see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14518&oldid=14516 here])'''

* if vi is assigned the value of a frame's slot by the action variable declaration: (vi o[s->vi]), then σ(vi) is a ''ground term'' such that the substitution σ matches the frame formula o[s->vi] to w.

=== Proposed Erratum 19 ===

In PRD, [[PRD#Import|section 8.6.1]] seems to restrict the use of the RIF/XML element <tt>Import</tt> to importing RDF or OWL, and to exclude the import of RIF PRD documents, as described in section 5.

PROPOSED: Modify the first sentence in [[PRD#Import|section 8.6.1]] to read:

'''Corrected (see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14520&oldid=14518 here])'''

The <tt>Import</tt> directive is used to serialize the reference to ''an RDF graph, an OWL ontology or another RIF document'' to be combined with a RIF document. The <tt>Import</tt> directive is inherited from <nowiki>[</nowiki>[[#ref-core|RIF-Core]]]. ''The abstract syntax and semantics of RDF graph and OWL ontology imports'' are specified in <nowiki>[</nowiki>[[#ref-rif-rdf-owl|RIF-RDF-OWL]]].

=== Typos, simplifications, clarifications ===

* Various typos '''corrected (see [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14551&oldid=14534 here])'''
* Remove the confusing and unnecessary condition that "there is at least one term, v, such that o[s->v] is a well-formed frame atomic formula", in the definition of a well-formed Retract with two arguments ('''see correction [http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=14535&oldid=14534 here]''')

== Proposed Erratum 20 ==

In SWC, [http://www.w3.org/TR/2010/PR-rif-rdf-owl-20100511/#Appendix:_Embeddings_.28Informative.29 section 9 Appendix: Embeddings]
it is stated that "Simple, RDF, and RDFS entailment for RIF-RDF combinations are embedded in RIF Core", therefore the above restriction holds.
This seems to be contradictory to "Forall ?x ?y (?x # ?y :- ?x[rdf:type -> ?y])" in SWC [http://www.w3.org/TR/2010/PR-rif-rdf-owl-20100511/#Embedding_Simple_Entailment section 9.1.3 Embedding simple entailment] (reported [http://lists.w3.org/Archives/Public/public-rif-comments/2010May/0004.html here]).

PROPOSED (Dave Reynolds): Change the second paragraph of section 9 from:

Simple, RDF, and RDFS entailment for RIF-RDF combinations are embedded
in RIF Core. RIF-OWL 2 RL combinations require reasoning with equality,
and thus could not be embedded in RIF Core; they are embedded in RIF BLD.

to

Simple, RDF, RDFS and OWL 2 RL entailment for RIF-RDF combinations are
embedded in RIF BLD.

Note that Simple, RDF and RDFS entailments are superficially embeddable
within RIF Core. However, condition 7 of the semantics of RIF-RDF
combinations cannot be axiomatized in RIF Core due to restrictions on
the use isa (#) in rule heads. OWL 2 RL is not embeddable in RIF Core
due the the need for equality reasoning.

'''Corrected (see [http://www.w3.org/2005/rules/wiki/index.php?title=SWC&diff=14487&oldid=12901 here])'''

== Proposed Erratum 21 ==

* In [[RIF-BLD]]: Definitions in Section [http://www.w3.org/TR/rif-bld#sec-interpretation-of-documents Interpretation of Documents] have been rewritten and significantly simplified.
* In Section[http://www.w3.org/TR/rif-bld#sec-bld-specialization-semantics The Semantics of RIF-BLD as a Specialization of RIF-FLD], a paragraph added about specialization from RIF-FLD semantic multi-structures.

'''corrected'''

== Proposed Errata for RIF-FLD ==

* Added anti-monotonicity requirement for <tt>~</tt> in [http://www.w3.org/TR/rif-fld#def-fld-truth-value Definition (set of truth values)].
* Changed [http://www.w3.org/TR/rif-fld#def-fld-truth-documents Definition (truth valuation of document formulas)] to define truth valuation of not only document formulas but other formulas as well.
* Acknowledgements added.
* The old notion of semantic multi-structures has been changed to fix the problems with the semantics of document formulas found in [http://www.w3.org/TR/rif-fld Recommendation of June 22 2010]. These problems were pointed out in <nowiki>[</nowiki>[http://www.w3.org/2005/rules/wiki/FLD#ref-rif-modularity DAA]]. As a result, sections [http://www.w3.org/TR/rif-fld#sec-interpretation-of-documents Interpretation of Documents] and [http://www.w3.org/TR/rif-fld#sec-logical-entailment Logical Entailment] have largely been rewritten.

'''Corrected:''' http://www.w3.org/2005/rules/wiki/index.php?title=FLD&diff=14451&oldid=14355

== Proposed Errata in DTB ==

(Proposed by Axel, who commented:
"Summarizing, I do understand that only 1)+5) are mandatory changes,
whereas the changes 2)- 4) are not necessarily mandatory, but would
make the RIF-DTB spec cleaner.")

Any remaining issues would in my opinion depend on whether the Xpath working group sees any effects on [XPath-Functions], since we don't have any other direct dependencies on [XML Schema Datatypes], but only indirectly by reuse of definitions from [XPath-Functions].

1. http://www.w3.org/TR/rif-dtb/

-----------------------------------------------

=== 1) ===
Firstly, a couple of references need to be fixed to the latest specs.

[XML Schema Datatypes] --> http://www.w3.org/TR/xmlschema11-2/ (now points to the CR from 30 April 2009)

'''Done:''' changed the template (see [http://www.w3.org/2005/rules/wiki/index.php?title=Template%3ARef-xml-schema2&diff=14615&oldid=10069 here])

Further,
[XDM] +
[XPath]
[XPath-Functions]
all point to the first edition recs and should probably be updated to the Dec 2010 Second Edition versions.

=== 2) ===
In fact, it seems that the reference to [XDM] could be removed, since we only needed it because the two subtypes of duration we are referring to didn't appear in the earlier version of [XML Schema Datatypes].

As far as I know, the main question was whether the latest changes in [XML Schema Datatypes] do affect us, as shown in http://www.w3.org/2001/sw/CG/docs/XSD1.1-diffs.html,
as the other docs only had minor updates, I assume.

=== 3) Section 2.2.1 Symbol Spaces ===

-----------------------
The lexical spaces of the above symbol spaces are defined in the document [XML Schema Datatypes].

.xs:dayTimeDuration (http://www.w3.org/2001/XMLSchema#dayTimeDuration), short name: dayTimeDuration
.xs:yearMonthDuration (http://www.w3.org/2001/XMLSchema#yearMonthDuration), short name: yearMonthDuration

These two symbol spaces represent two subtypes of the XML Schema datatype xs:duration. The lexical spaces of the above symbol spaces are defined in the document [XDM].
-----------------------

Although this is not wrong, the lexical spaces for these two datatypes are now defined in the last iteration of [XML Schema Datatypes], so this *could* be changed to simply

-----------------------
.xs:dayTimeDuration (http://www.w3.org/2001/XMLSchema#dayTimeDuration), short name: dayTimeDuration
.xs:yearMonthDuration (http://www.w3.org/2001/XMLSchema#yearMonthDuration), short name: yearMonthDuration

The lexical spaces of the above symbol spaces are defined in the document [XML Schema Datatypes].
-----------------------

'''Done''' (see [http://www.w3.org/2005/rules/wiki/index.php?title=DTB&diff=14605&oldid=13226 here])

=== 4) Section 2.3 ===

Similarly, the following could be changed/simplified, if we refer to the leatest [XML Schema Datatypes] version:

-----------------------
Their value spaces and the lexical-to-value-space mappings are defined as follows:

.For the XML Schema datatypes of RIF, namely all RIF datatypes within the xs: namespace, except xs:dayTimeDuration and xs:yearMonthDuration, the value spaces and the lexical-to-value-space mappings are defined in the XML Schema specification [XML Schema Datatypes].
.The value spaces and the lexical-to-value-space mappings for the datatypes xs:dayTimeDuration and xs:yearMonthDuration are defined in the XQuery 1.0 and XPath 2.0 Data Model [XDM].
-----------------------

to

-----------------------
Their value spaces and the lexical-to-value-space mappings are defined as follows:

.For the XML Schema datatypes of RIF, namely all RIF datatypes within the xs: namespace, the value spaces and the lexical-to-value-space mappings are defined in the XML Schema specification [XML Schema Datatypes].
-----------------------

'''Done''' (see [http://www.w3.org/2005/rules/wiki/index.php?title=DTB&diff=14607&oldid=14605 here])

=== 5) Section 2.3.1 XML Schema Datatypes ===

Although - again - it is not wrong, this section could be removed, I suppose.

'''Done''' (see [http://www.w3.org/2005/rules/wiki/index.php?title=DTB&diff=14611&oldid=14607 here])

== Proposed Errata in OWL2/RL ==

Fixed typos and syntactic errors in the Template Rules algorithm of appendix 8 identified by Henrick Marx, reported ([http://lists.w3.org/Archives/Public/public-rif-comments/2012May/0002.html here] and [http://lists.w3.org/Archives/Public/public-rif-comments/2012Apr/0000.html here]). Rules affected: prp-adp, cax-adc, prp-spo2, prp-key, scm-int, cls-maxqc2, eq-diff2 and eq-diff3.

== More To Investigate ==

# http://lists.w3.org/Archives/Public/public-rif-comments/2010Aug/0000.html (Not an error: Fitting's paper [1] is listed in the informative references but never cited in the spec => no erratum?
# http://lists.w3.org/Archives/Public/public-rif-comments/2011Mar/0001.html (Not an error: request for explanation => no erratum? Or should the spec be clarified?)

RIF FAQ

Sandro — Mon, 04 Feb 2013 17:27:44 GMT

Sandro: /* How do I serialize RIF rules in RDF? */

__NUMBEREDHEADINGS__

Please send comments or additional questions to [mailto:public-rif-comments@w3.org public-rif-comments@w3.org] ([http://lists.w3.org/Archives/Public/public-rif-wg/ public archive]).

Answers have not necessarily been reviewed by the Working Group. The question are real, having been asked via e-mail or in person.

Some questions here have not yet been answered.

== About RIF ==

=== What is RIF? ===

RIF is the W3C Rule Interchange Format. It's an XML language for expressing rules which computers can execute.

Because of the serious tradeoffs in the design of rule language, RIF provides multiple versions, called ''dialects''. If you're not sure which dialect to use, start with RIF Core. Then, if you need rule features that are not available in RIF Core, consider the other standard dialects and third-party dialects.

=== What is RIF-BLD? (and RIF-Core, PRD, FLD) ===

The standard RIF dialects are ''Core'', ''BLD'', and ''PRD'':

; Core
: This is the fundamental RIF language. It is designed to be the common subset of most rule engines. (It provides "safe" positive datalog with builtins.)
; BLD (Basic Logic Dialect)
: This adds a few things that Core doesn't have: logic functions, equality in the ''then''-part, and named arguments. Each of these features can sort of be simulated in Core. (This is positive Horn logic, with equality and builtins.)
; PRD (Production Rules Dialect)
: adds a notion of forward-chaining rules, where a rule ''fires'' and then performs some action, such as adding more information to the store or ''retracting'' some information.

Note that '''FLD''' (the Framework for Logic Dialects) provides a menu for coherently assembling dialects more expressive than BLD. Links to unofficial, community-contributed RIF dialects can be found
[http://www.w3.org/2005/rules/wiki/RIF_FLD_Dialects here].

More generally, the [[Overview]] provides a guide to the RIF architecture.

=== Is RIF only for interchange? ===

No. Although RIF dialects were designed primarily for interchange, each dialect is a standard rule language and can be used even when portability and interchange are not required.

=== "Reduction In Force"? ===

Yes, in some other situations, ''RIF'' stands for ''reduction in force'', a term for reducing headcount, downsizing, layoffs, etc. We're still waiting to hear a really good pun based on this double meaning.

=== Can I use RIF to map between vocabularies? ===

Yes. It should be good for this. It's [http://www.w3.org/TR/rif-ucr/#Vocabulary_Mapping_for_Data_Integration one of the use cases].

=== Which RIF syntax should I use? ===

The XML syntax is the only one defined as a standard for interchange.
Various presentation syntaxes are used in the specification, but they
are not recommended for sending between different systems.

=== Is there a mime type for RIF? ===

Yes, it's "application/rif+xml". See [http://www.w3.org/TR/rif-core/#Appendix:_RIF_Media_Type_Registration RIF Media Type Registration].

== RIF Software ==

=== What tools (open source and commercial) currently support RIF? ===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

=== How fast are RIF processors compared to RDFS inference and OWL inference? ===

Since RIF can often be implemented
by translation to other rule languages, we can speculate that the
performance will differ only by the time need for translation. Many
RDFS and OWL systems use underlying rule engines to do their
inference, so their performance is likely to be the same or better on
RIF. On the other hand, there are some OWL inference tasks which can
be much more efficiently handled by DL algorithms.

=== Are there any SPARQL stores that support RIF? ===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

We expect that SPARQL systems which currently include rule engines, such as Jena, will implement support for RIF.

=== Is there a Web Service for doing RIF? ===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

=== Does any major technology software vendor (or project) include RIF-related libraries in their stack? IBM, Google, Microsoft, Oracle, KDE, GNOME, Apache, ...===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

IBM & iLog, HP, Oracle, and TIBCO are active in the Working Group.

== Relation to Other Technologies ==

=== I'd like to know if it's possible to translate RIF into SPARQL Construct clause (and back) ===

Some people have used SPARQL Construct clauses as a rule language, although no formal semantics have been specified for this. Because SPARQL including non-monotonic features, the full language possible here would be very expressive and very hard to specify or implement correctly. (What happens if you use !bound with some data that is provided by related rules?)

There is a subset of SPARQL Construct clauses which corresponds to a subset of RIF Core. For this common subset, SPARQL can be seen as just another presentation syntax for RIF Core. It would probably be best to try to stay within this subset when using SPARQL Construct clauses as a rule language.

=== How do I serialize or store RIF rules in RDF? ===

See [http://www.w3.org/TR/rif-in-rdf RIF in RDF].

=== What are the relationships between the OWL 2 profiles and the RIF dialects? ===

There are several relationships between OWL 2 and RIF dialects.

Firstly, RIF defines the notion of RIF/OWL combinations, providing a semantics for them and a syntactic mechanism for defining such combinations by importing OWL documents into RIF documents. This is specified in [http://www.w3.org/TR/rif-rdf-owl/ RIF RDF and OWL Compatibility]. This mechanism defines import profiles for both OWL 2 DL and OWL 2 Full semantics. Thus each OWL 2 Profile can be used in combination with any RIF dialect using this mechanism. There are no separate import profiles corresponding to the separate OWL 2 profiles.

Secondly, OWL 2 defines a profile, OWL 2 RL, designed to be implementable by means of rule based systems. A partial axiomatization of the OWL 2 RL semantics is given in the [http://www.w3.org/TR/owl2-profiles/#Reasoning_in_OWL_2_RL_and_RDF_Graphs_using_Rules OWL Profiles document] as a set of first order rules. These rules can be translated into RIF Core rules either as a static rule set or on a per-ontology basis as discussed in [http://www.w3.org/2005/rules/wiki/OWLRL OWLRL]. This enables implementation of an OWL 2 RL entailment checker or query answering tool by using the RIF Core rule set in combination with the RDF document encoding an OWL 2 RL premise ontology to derive a set of entailed RDF assertions as RIF Frame formulae.

Thirdly, RIF provides and Informative description of an [http://www.w3.org/TR/rif-rdf-owl/#Embedding_RIF-OWL_2_RL_Combinations embedding] of OWL 2 RL within RIF BLD. This enables the translation of an OWL 2 RL document directly into a RIF BLD document.

=== What is the relationship between RuleML and RIF? ===

RuleML has provided input for RIF on several levels, including the
use of 'striped' XML as well as
the structuring of rule classes into a family of sublanguages with, e.g.,
Datalog RuleML partially mappable to the RIF Core Dialect,
Derivation RuleML to the RIF Basic Logic Dialect, and
the production-rule sublanguage of Reaction RuleML to the RIF Production Rule Dialect.
Conversely, RuleML adopted some features that were developed
as part of the RIF Working Group such as role tags
<if> ... <then> instead of <body> ... <head>.
Shared RIF RuleML implementations and use cases are projected to lead to further convergence.

=== How does RIF differ from SWRL? ===

RIF was designed as an interchange format for exchanging rules between rule systems, such as those that implement SWRL. SWRL is a rule language which was designed as an extension to OWL. It is one of the simpler rule languages and most SWRL features are covered by RIF-BLD with the exception of "different-from", thus it should be possible to exchange most SWRL rules via RIF.

When viewed as a rule language and compared to SWRL, RIF-BLD supports multiple-arity predicates, and SWRL is limited to unary and binary predicates. RIF-BLD has functions, SWRL is function-free. RIF-BLD has an extensive set of datatypes and builtins, SWRL supports most of the same datatypes but has no builtins. [??? Yes, it does! Under discussion.] RIF-BLD has a limited form of negation in datatype guard predicates (e.g. is-literal-not-integer), SWRL has a different limited form of negation in the "different-from" operator. RIF-BLD interoperates with OWL through a special combination semantics, SWRL is designed to be a syntactic extension to OWL. RIF-BLD allows disjunction in rules, SWRL does not.

=== How can I encode RIF in HTML? ===

RIF does not define a normative encoding in HTML. It was designed primarily for interchange of rules between rule engines, and the XML syntax is the only one defined as a standard for interchange.

However, various text-based presentation syntaxes are used in the specification: although they are not recommended for interchange between different rule systems, they can be used for rendering by HTML processors.

In general, any rule syntax that can be serialized in RIF XML in a semantics-preserving way can be used for that purpose. To avoid ambiguity, it is good practice to use only syntaxes for which a mapping to RIF XML is publicly available.

=== What's the difference between RIF and having an RDF 2.0 that moves beyond binary relations? ===

Such an RDF specification would probably look very much like RIF with RDF compatibility (see [http://www.w3.org/TR/rif-rdf-owl]). Of course, RIF also provides for if/then rules, not just ground facts like RDF.

=== Is RIF useful for reasoning about the provenance of claims expressed in RDF, eg. multiple named graphs in SPARQL that offer competing accounts of some situation? ===

If the differing named graphs are located in different web documents, then RIF with RDF compatibility (see [http://www.w3.org/TR/rif-rdf-owl]) has an import mechanism that can be directed to the specific web documents and reason about them. More refined notions of import that allow to explicitly refer to facts from different imported documents per rule could be covered in extended RIF dialects.

=== How do I embed RIF in an RDFS/OWL schema or ontology? ===

[http://www.w3.org/TR/rif-rdf-owl RIF RDF and OWL Compatibility] specifies, formally, what it means to use RIF with RDFS and/or OWL, and provides a way, in RIF, to import RDFS and OWL.

If you need to work in RDF triples, see [http://www.w3.org/TR/rif-in-rdf RIF In RDF]. This lets you physically embed RIF in an RDFS/OWL document, but notes that the embedded RIF is merely described, not asserted. There is not currently a standard vocabulary saying, in RDFS/OWL, that you also want some RIF rules as part of your ontology. Instead, for now, you must have RIF import RDFS/OWL.

=== What's the relation between RIF and Functional-Logic Programming? ===

Both are founded on Horn logic with equality. Functional-Logic Programming is built on Horn logic with ''oriented'' equations
in rule conclusions, used to define functions. In that sense it specializes RIF-BLD,
built on Horn logic with ''symmetric'' equations. However, Functional-Logic Programming permits higher-order functions, while RIF-BLD only permits first-order functions. For an introduction to functional-logic technology, with many examples, see
[http://www.cs.unb.ca/seminarseries/documents/Harold_Boley-03.17.10.pdf Visualizing Executable Functional-Logic Specifications].

== Documentation ==

=== Where are examples to the W3C semweb technology stack, using RIF properly along with RDF, RDFS, OWL[2], etc.? ===

The [http://www.w3.org/TR/rif-rdf-owl/ RIF RDF and OWL Compatibility] document specifies how RIF works in combination with RDF, RDFS, OWL 1, and OWL 2, and there are small examples throughout the document of RIF-RDF and RIF-OWL combinations, explaining what is entailed (or not) from them.

Two of the use cases presented in [http://www.w3.org/TR/rif-ucr/ RIF Use Cases and Requirements] provide motivating scenarios for RIF in combination with RDF and OWL: [http://www.w3.org/TR/rif-ucr/#Interchanging_Rule_Extensions_to_OWL Interchanging Rule Extensions to OWL] and [http://www.w3.org/TR/rif-ucr/#Publishing_Rules_for_Interlinked_Metadata Publishing Rules for Interlinked Metadata].

Also, see the [http://www.w3.org/2005/rules/wiki/Category:RIF-RDF_Combination RIF-RDF combination test cases] and the [http://www.w3.org/2005/rules/wiki/Category:RIF-OWL_Combination RIF-OWL combination test cases]. Among these,
[http://www.w3.org/2005/rules/wiki/YoungParentDiscount_1 Young Parent Discount] and [http://www.w3.org/2005/rules/wiki/UCR_4.7a UCR_4.7a] are in the style of small usage examples.

=== Where are examples to existing RIF rules written using the simplest, bare-minimum markup and easiest logic/math? ===

The set of RIF documents --- including the documents on [http://www.w3.org/2005/rules/wiki/BLD BLD], [http://www.w3.org/2005/rules/wiki/PRD PRD] and [http://www.w3.org/2005/rules/wiki/FLD FLD] --- and the set of [http://www.w3.org/2005/rules/wiki/Category:Test_Case test cases] both contain a variety of examples that involve almost no logic (sometimes not even modus ponens) and no math at all.

For instance, Example 1 in [http://www.w3.org/2005/rules/wiki/BLD BLD] involves just a single application of modus ponens and no math; Example 4 shows several different ways of writing business rules that do not involve math, and require only a basic knowledge of quantifiers.

Most of the examples in [http://www.w3.org/2005/rules/wiki/Category:Test_Case test cases] are quite simple, and involve nothing more than arithmetic. An example of a test case that involves simple inheritance is [http://www.w3.org/2005/rules/wiki/Classification-inheritance Classification-inheritance.]

=== Where can I find info on RIF for the "business rules" community, esp. to help convince management to start to consider RIF as the source format? ===
Half of the [http://www.w3.org/TR/rif-ucr/#Use_Cases RIF use cases] describe how RIF can serve the business rules community. RIF can help to avoid vendor lock-in, foster collaboration, support eBusiness and eCommerce, optimize the supply chain, and allow business rules to be bought, sold, and shared.
The [http://www.w3.org/TR/rif-prd production rule dialect] includes typical business rules features such as rule priority, negation, decimal numbers, and dates.

=== What interesting things have been built using RIF? ===

Support for RIF is just starting to become available (see [[Implementations]]), so there has not yet been much opportunity to develop applications that use RIF.

This [http://www.ibm.com/developerworks/wikis/display/db2xml/Rules IBM developerWorks article] discusses storing and querying rules in an XML database, and includes a live demo with RIF rules.

Some envisioned representative usage scenarios for RIF are outlined in the [http://www.w3.org/TR/rif-ucr/#Use_Cases RIF use cases].

Please report any applications or uses of RIF to public-rif-comments@w3.org.

== Acknowledements ==

Thanks to questions, comments, suggestions from:

* Lee Feigenbaum
* David Booth
* Richard Cyganiak
* Frank Manola
* "Collette Hagert geb. Nauluta"
* Dan Brickley

RIF FAQ

Sandro — Mon, 04 Feb 2013 17:27:28 GMT

Sandro: /* How do I put RIF rules in RDF, so I can reason about them with more rules? */

__NUMBEREDHEADINGS__

Please send comments or additional questions to [mailto:public-rif-comments@w3.org public-rif-comments@w3.org] ([http://lists.w3.org/Archives/Public/public-rif-wg/ public archive]).

Answers have not necessarily been reviewed by the Working Group. The question are real, having been asked via e-mail or in person.

Some questions here have not yet been answered.

== About RIF ==

=== What is RIF? ===

RIF is the W3C Rule Interchange Format. It's an XML language for expressing rules which computers can execute.

Because of the serious tradeoffs in the design of rule language, RIF provides multiple versions, called ''dialects''. If you're not sure which dialect to use, start with RIF Core. Then, if you need rule features that are not available in RIF Core, consider the other standard dialects and third-party dialects.

=== What is RIF-BLD? (and RIF-Core, PRD, FLD) ===

The standard RIF dialects are ''Core'', ''BLD'', and ''PRD'':

; Core
: This is the fundamental RIF language. It is designed to be the common subset of most rule engines. (It provides "safe" positive datalog with builtins.)
; BLD (Basic Logic Dialect)
: This adds a few things that Core doesn't have: logic functions, equality in the ''then''-part, and named arguments. Each of these features can sort of be simulated in Core. (This is positive Horn logic, with equality and builtins.)
; PRD (Production Rules Dialect)
: adds a notion of forward-chaining rules, where a rule ''fires'' and then performs some action, such as adding more information to the store or ''retracting'' some information.

Note that '''FLD''' (the Framework for Logic Dialects) provides a menu for coherently assembling dialects more expressive than BLD. Links to unofficial, community-contributed RIF dialects can be found
[http://www.w3.org/2005/rules/wiki/RIF_FLD_Dialects here].

More generally, the [[Overview]] provides a guide to the RIF architecture.

=== Is RIF only for interchange? ===

No. Although RIF dialects were designed primarily for interchange, each dialect is a standard rule language and can be used even when portability and interchange are not required.

=== "Reduction In Force"? ===

Yes, in some other situations, ''RIF'' stands for ''reduction in force'', a term for reducing headcount, downsizing, layoffs, etc. We're still waiting to hear a really good pun based on this double meaning.

=== Can I use RIF to map between vocabularies? ===

Yes. It should be good for this. It's [http://www.w3.org/TR/rif-ucr/#Vocabulary_Mapping_for_Data_Integration one of the use cases].

=== Which RIF syntax should I use? ===

The XML syntax is the only one defined as a standard for interchange.
Various presentation syntaxes are used in the specification, but they
are not recommended for sending between different systems.

=== Is there a mime type for RIF? ===

Yes, it's "application/rif+xml". See [http://www.w3.org/TR/rif-core/#Appendix:_RIF_Media_Type_Registration RIF Media Type Registration].

== RIF Software ==

=== What tools (open source and commercial) currently support RIF? ===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

=== How fast are RIF processors compared to RDFS inference and OWL inference? ===

Since RIF can often be implemented
by translation to other rule languages, we can speculate that the
performance will differ only by the time need for translation. Many
RDFS and OWL systems use underlying rule engines to do their
inference, so their performance is likely to be the same or better on
RIF. On the other hand, there are some OWL inference tasks which can
be much more efficiently handled by DL algorithms.

=== Are there any SPARQL stores that support RIF? ===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

We expect that SPARQL systems which currently include rule engines, such as Jena, will implement support for RIF.

=== Is there a Web Service for doing RIF? ===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

=== Does any major technology software vendor (or project) include RIF-related libraries in their stack? IBM, Google, Microsoft, Oracle, KDE, GNOME, Apache, ...===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

IBM & iLog, HP, Oracle, and TIBCO are active in the Working Group.

== Relation to Other Technologies ==

=== I'd like to know if it's possible to translate RIF into SPARQL Construct clause (and back) ===

Some people have used SPARQL Construct clauses as a rule language, although no formal semantics have been specified for this. Because SPARQL including non-monotonic features, the full language possible here would be very expressive and very hard to specify or implement correctly. (What happens if you use !bound with some data that is provided by related rules?)

There is a subset of SPARQL Construct clauses which corresponds to a subset of RIF Core. For this common subset, SPARQL can be seen as just another presentation syntax for RIF Core. It would probably be best to try to stay within this subset when using SPARQL Construct clauses as a rule language.

=== How do I serialize RIF rules in RDF? ===

See [http://www.w3.org/TR/rif-in-rdf RIF in RDF].

=== What are the relationships between the OWL 2 profiles and the RIF dialects? ===

There are several relationships between OWL 2 and RIF dialects.

Firstly, RIF defines the notion of RIF/OWL combinations, providing a semantics for them and a syntactic mechanism for defining such combinations by importing OWL documents into RIF documents. This is specified in [http://www.w3.org/TR/rif-rdf-owl/ RIF RDF and OWL Compatibility]. This mechanism defines import profiles for both OWL 2 DL and OWL 2 Full semantics. Thus each OWL 2 Profile can be used in combination with any RIF dialect using this mechanism. There are no separate import profiles corresponding to the separate OWL 2 profiles.

Secondly, OWL 2 defines a profile, OWL 2 RL, designed to be implementable by means of rule based systems. A partial axiomatization of the OWL 2 RL semantics is given in the [http://www.w3.org/TR/owl2-profiles/#Reasoning_in_OWL_2_RL_and_RDF_Graphs_using_Rules OWL Profiles document] as a set of first order rules. These rules can be translated into RIF Core rules either as a static rule set or on a per-ontology basis as discussed in [http://www.w3.org/2005/rules/wiki/OWLRL OWLRL]. This enables implementation of an OWL 2 RL entailment checker or query answering tool by using the RIF Core rule set in combination with the RDF document encoding an OWL 2 RL premise ontology to derive a set of entailed RDF assertions as RIF Frame formulae.

Thirdly, RIF provides and Informative description of an [http://www.w3.org/TR/rif-rdf-owl/#Embedding_RIF-OWL_2_RL_Combinations embedding] of OWL 2 RL within RIF BLD. This enables the translation of an OWL 2 RL document directly into a RIF BLD document.

=== What is the relationship between RuleML and RIF? ===

RuleML has provided input for RIF on several levels, including the
use of 'striped' XML as well as
the structuring of rule classes into a family of sublanguages with, e.g.,
Datalog RuleML partially mappable to the RIF Core Dialect,
Derivation RuleML to the RIF Basic Logic Dialect, and
the production-rule sublanguage of Reaction RuleML to the RIF Production Rule Dialect.
Conversely, RuleML adopted some features that were developed
as part of the RIF Working Group such as role tags
<if> ... <then> instead of <body> ... <head>.
Shared RIF RuleML implementations and use cases are projected to lead to further convergence.

=== How does RIF differ from SWRL? ===

RIF was designed as an interchange format for exchanging rules between rule systems, such as those that implement SWRL. SWRL is a rule language which was designed as an extension to OWL. It is one of the simpler rule languages and most SWRL features are covered by RIF-BLD with the exception of "different-from", thus it should be possible to exchange most SWRL rules via RIF.

When viewed as a rule language and compared to SWRL, RIF-BLD supports multiple-arity predicates, and SWRL is limited to unary and binary predicates. RIF-BLD has functions, SWRL is function-free. RIF-BLD has an extensive set of datatypes and builtins, SWRL supports most of the same datatypes but has no builtins. [??? Yes, it does! Under discussion.] RIF-BLD has a limited form of negation in datatype guard predicates (e.g. is-literal-not-integer), SWRL has a different limited form of negation in the "different-from" operator. RIF-BLD interoperates with OWL through a special combination semantics, SWRL is designed to be a syntactic extension to OWL. RIF-BLD allows disjunction in rules, SWRL does not.

=== How can I encode RIF in HTML? ===

RIF does not define a normative encoding in HTML. It was designed primarily for interchange of rules between rule engines, and the XML syntax is the only one defined as a standard for interchange.

However, various text-based presentation syntaxes are used in the specification: although they are not recommended for interchange between different rule systems, they can be used for rendering by HTML processors.

In general, any rule syntax that can be serialized in RIF XML in a semantics-preserving way can be used for that purpose. To avoid ambiguity, it is good practice to use only syntaxes for which a mapping to RIF XML is publicly available.

=== What's the difference between RIF and having an RDF 2.0 that moves beyond binary relations? ===

Such an RDF specification would probably look very much like RIF with RDF compatibility (see [http://www.w3.org/TR/rif-rdf-owl]). Of course, RIF also provides for if/then rules, not just ground facts like RDF.

=== Is RIF useful for reasoning about the provenance of claims expressed in RDF, eg. multiple named graphs in SPARQL that offer competing accounts of some situation? ===

If the differing named graphs are located in different web documents, then RIF with RDF compatibility (see [http://www.w3.org/TR/rif-rdf-owl]) has an import mechanism that can be directed to the specific web documents and reason about them. More refined notions of import that allow to explicitly refer to facts from different imported documents per rule could be covered in extended RIF dialects.

=== How do I embed RIF in an RDFS/OWL schema or ontology? ===

[http://www.w3.org/TR/rif-rdf-owl RIF RDF and OWL Compatibility] specifies, formally, what it means to use RIF with RDFS and/or OWL, and provides a way, in RIF, to import RDFS and OWL.

If you need to work in RDF triples, see [http://www.w3.org/TR/rif-in-rdf RIF In RDF]. This lets you physically embed RIF in an RDFS/OWL document, but notes that the embedded RIF is merely described, not asserted. There is not currently a standard vocabulary saying, in RDFS/OWL, that you also want some RIF rules as part of your ontology. Instead, for now, you must have RIF import RDFS/OWL.

=== What's the relation between RIF and Functional-Logic Programming? ===

Both are founded on Horn logic with equality. Functional-Logic Programming is built on Horn logic with ''oriented'' equations
in rule conclusions, used to define functions. In that sense it specializes RIF-BLD,
built on Horn logic with ''symmetric'' equations. However, Functional-Logic Programming permits higher-order functions, while RIF-BLD only permits first-order functions. For an introduction to functional-logic technology, with many examples, see
[http://www.cs.unb.ca/seminarseries/documents/Harold_Boley-03.17.10.pdf Visualizing Executable Functional-Logic Specifications].

== Documentation ==

=== Where are examples to the W3C semweb technology stack, using RIF properly along with RDF, RDFS, OWL[2], etc.? ===

The [http://www.w3.org/TR/rif-rdf-owl/ RIF RDF and OWL Compatibility] document specifies how RIF works in combination with RDF, RDFS, OWL 1, and OWL 2, and there are small examples throughout the document of RIF-RDF and RIF-OWL combinations, explaining what is entailed (or not) from them.

Two of the use cases presented in [http://www.w3.org/TR/rif-ucr/ RIF Use Cases and Requirements] provide motivating scenarios for RIF in combination with RDF and OWL: [http://www.w3.org/TR/rif-ucr/#Interchanging_Rule_Extensions_to_OWL Interchanging Rule Extensions to OWL] and [http://www.w3.org/TR/rif-ucr/#Publishing_Rules_for_Interlinked_Metadata Publishing Rules for Interlinked Metadata].

Also, see the [http://www.w3.org/2005/rules/wiki/Category:RIF-RDF_Combination RIF-RDF combination test cases] and the [http://www.w3.org/2005/rules/wiki/Category:RIF-OWL_Combination RIF-OWL combination test cases]. Among these,
[http://www.w3.org/2005/rules/wiki/YoungParentDiscount_1 Young Parent Discount] and [http://www.w3.org/2005/rules/wiki/UCR_4.7a UCR_4.7a] are in the style of small usage examples.

=== Where are examples to existing RIF rules written using the simplest, bare-minimum markup and easiest logic/math? ===

The set of RIF documents --- including the documents on [http://www.w3.org/2005/rules/wiki/BLD BLD], [http://www.w3.org/2005/rules/wiki/PRD PRD] and [http://www.w3.org/2005/rules/wiki/FLD FLD] --- and the set of [http://www.w3.org/2005/rules/wiki/Category:Test_Case test cases] both contain a variety of examples that involve almost no logic (sometimes not even modus ponens) and no math at all.

For instance, Example 1 in [http://www.w3.org/2005/rules/wiki/BLD BLD] involves just a single application of modus ponens and no math; Example 4 shows several different ways of writing business rules that do not involve math, and require only a basic knowledge of quantifiers.

Most of the examples in [http://www.w3.org/2005/rules/wiki/Category:Test_Case test cases] are quite simple, and involve nothing more than arithmetic. An example of a test case that involves simple inheritance is [http://www.w3.org/2005/rules/wiki/Classification-inheritance Classification-inheritance.]

=== Where can I find info on RIF for the "business rules" community, esp. to help convince management to start to consider RIF as the source format? ===
Half of the [http://www.w3.org/TR/rif-ucr/#Use_Cases RIF use cases] describe how RIF can serve the business rules community. RIF can help to avoid vendor lock-in, foster collaboration, support eBusiness and eCommerce, optimize the supply chain, and allow business rules to be bought, sold, and shared.
The [http://www.w3.org/TR/rif-prd production rule dialect] includes typical business rules features such as rule priority, negation, decimal numbers, and dates.

=== What interesting things have been built using RIF? ===

Support for RIF is just starting to become available (see [[Implementations]]), so there has not yet been much opportunity to develop applications that use RIF.

This [http://www.ibm.com/developerworks/wikis/display/db2xml/Rules IBM developerWorks article] discusses storing and querying rules in an XML database, and includes a live demo with RIF rules.

Some envisioned representative usage scenarios for RIF are outlined in the [http://www.w3.org/TR/rif-ucr/#Use_Cases RIF use cases].

Please report any applications or uses of RIF to public-rif-comments@w3.org.

== Acknowledements ==

Thanks to questions, comments, suggestions from:

* Lee Feigenbaum
* David Booth
* Richard Cyganiak
* Frank Manola
* "Collette Hagert geb. Nauluta"
* Dan Brickley

RIF FAQ

Sandro — Mon, 04 Feb 2013 17:27:12 GMT

Sandro: /* How do I store RIF rules in my triplestore? */

__NUMBEREDHEADINGS__

Please send comments or additional questions to [mailto:public-rif-comments@w3.org public-rif-comments@w3.org] ([http://lists.w3.org/Archives/Public/public-rif-wg/ public archive]).

Answers have not necessarily been reviewed by the Working Group. The question are real, having been asked via e-mail or in person.

Some questions here have not yet been answered.

== About RIF ==

=== What is RIF? ===

RIF is the W3C Rule Interchange Format. It's an XML language for expressing rules which computers can execute.

Because of the serious tradeoffs in the design of rule language, RIF provides multiple versions, called ''dialects''. If you're not sure which dialect to use, start with RIF Core. Then, if you need rule features that are not available in RIF Core, consider the other standard dialects and third-party dialects.

=== What is RIF-BLD? (and RIF-Core, PRD, FLD) ===

The standard RIF dialects are ''Core'', ''BLD'', and ''PRD'':

; Core
: This is the fundamental RIF language. It is designed to be the common subset of most rule engines. (It provides "safe" positive datalog with builtins.)
; BLD (Basic Logic Dialect)
: This adds a few things that Core doesn't have: logic functions, equality in the ''then''-part, and named arguments. Each of these features can sort of be simulated in Core. (This is positive Horn logic, with equality and builtins.)
; PRD (Production Rules Dialect)
: adds a notion of forward-chaining rules, where a rule ''fires'' and then performs some action, such as adding more information to the store or ''retracting'' some information.

Note that '''FLD''' (the Framework for Logic Dialects) provides a menu for coherently assembling dialects more expressive than BLD. Links to unofficial, community-contributed RIF dialects can be found
[http://www.w3.org/2005/rules/wiki/RIF_FLD_Dialects here].

More generally, the [[Overview]] provides a guide to the RIF architecture.

=== Is RIF only for interchange? ===

No. Although RIF dialects were designed primarily for interchange, each dialect is a standard rule language and can be used even when portability and interchange are not required.

=== "Reduction In Force"? ===

Yes, in some other situations, ''RIF'' stands for ''reduction in force'', a term for reducing headcount, downsizing, layoffs, etc. We're still waiting to hear a really good pun based on this double meaning.

=== Can I use RIF to map between vocabularies? ===

Yes. It should be good for this. It's [http://www.w3.org/TR/rif-ucr/#Vocabulary_Mapping_for_Data_Integration one of the use cases].

=== Which RIF syntax should I use? ===

The XML syntax is the only one defined as a standard for interchange.
Various presentation syntaxes are used in the specification, but they
are not recommended for sending between different systems.

=== Is there a mime type for RIF? ===

Yes, it's "application/rif+xml". See [http://www.w3.org/TR/rif-core/#Appendix:_RIF_Media_Type_Registration RIF Media Type Registration].

== RIF Software ==

=== What tools (open source and commercial) currently support RIF? ===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

=== How fast are RIF processors compared to RDFS inference and OWL inference? ===

Since RIF can often be implemented
by translation to other rule languages, we can speculate that the
performance will differ only by the time need for translation. Many
RDFS and OWL systems use underlying rule engines to do their
inference, so their performance is likely to be the same or better on
RIF. On the other hand, there are some OWL inference tasks which can
be much more efficiently handled by DL algorithms.

=== Are there any SPARQL stores that support RIF? ===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

We expect that SPARQL systems which currently include rule engines, such as Jena, will implement support for RIF.

=== Is there a Web Service for doing RIF? ===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

=== Does any major technology software vendor (or project) include RIF-related libraries in their stack? IBM, Google, Microsoft, Oracle, KDE, GNOME, Apache, ...===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

IBM & iLog, HP, Oracle, and TIBCO are active in the Working Group.

== Relation to Other Technologies ==

=== I'd like to know if it's possible to translate RIF into SPARQL Construct clause (and back) ===

Some people have used SPARQL Construct clauses as a rule language, although no formal semantics have been specified for this. Because SPARQL including non-monotonic features, the full language possible here would be very expressive and very hard to specify or implement correctly. (What happens if you use !bound with some data that is provided by related rules?)

There is a subset of SPARQL Construct clauses which corresponds to a subset of RIF Core. For this common subset, SPARQL can be seen as just another presentation syntax for RIF Core. It would probably be best to try to stay within this subset when using SPARQL Construct clauses as a rule language.

=== How do I serialize RIF rules in RDF? ===

See [http://www.w3.org/TR/rif-in-rdf RIF in RDF].

=== How do I put RIF rules in RDF, so I can reason about them with more rules? ===

At present you cannot do this in a standardized fashion.

If you map the RIF XML structure to an isomorphic RDF representation (for example, through use of GRDDL) then that RDF structure can be reasoned about with more rules. However, a normative such RDF representation has not be defined by the working group.

=== What are the relationships between the OWL 2 profiles and the RIF dialects? ===

There are several relationships between OWL 2 and RIF dialects.

Firstly, RIF defines the notion of RIF/OWL combinations, providing a semantics for them and a syntactic mechanism for defining such combinations by importing OWL documents into RIF documents. This is specified in [http://www.w3.org/TR/rif-rdf-owl/ RIF RDF and OWL Compatibility]. This mechanism defines import profiles for both OWL 2 DL and OWL 2 Full semantics. Thus each OWL 2 Profile can be used in combination with any RIF dialect using this mechanism. There are no separate import profiles corresponding to the separate OWL 2 profiles.

Secondly, OWL 2 defines a profile, OWL 2 RL, designed to be implementable by means of rule based systems. A partial axiomatization of the OWL 2 RL semantics is given in the [http://www.w3.org/TR/owl2-profiles/#Reasoning_in_OWL_2_RL_and_RDF_Graphs_using_Rules OWL Profiles document] as a set of first order rules. These rules can be translated into RIF Core rules either as a static rule set or on a per-ontology basis as discussed in [http://www.w3.org/2005/rules/wiki/OWLRL OWLRL]. This enables implementation of an OWL 2 RL entailment checker or query answering tool by using the RIF Core rule set in combination with the RDF document encoding an OWL 2 RL premise ontology to derive a set of entailed RDF assertions as RIF Frame formulae.

Thirdly, RIF provides and Informative description of an [http://www.w3.org/TR/rif-rdf-owl/#Embedding_RIF-OWL_2_RL_Combinations embedding] of OWL 2 RL within RIF BLD. This enables the translation of an OWL 2 RL document directly into a RIF BLD document.

=== What is the relationship between RuleML and RIF? ===

RuleML has provided input for RIF on several levels, including the
use of 'striped' XML as well as
the structuring of rule classes into a family of sublanguages with, e.g.,
Datalog RuleML partially mappable to the RIF Core Dialect,
Derivation RuleML to the RIF Basic Logic Dialect, and
the production-rule sublanguage of Reaction RuleML to the RIF Production Rule Dialect.
Conversely, RuleML adopted some features that were developed
as part of the RIF Working Group such as role tags
<if> ... <then> instead of <body> ... <head>.
Shared RIF RuleML implementations and use cases are projected to lead to further convergence.

=== How does RIF differ from SWRL? ===

RIF was designed as an interchange format for exchanging rules between rule systems, such as those that implement SWRL. SWRL is a rule language which was designed as an extension to OWL. It is one of the simpler rule languages and most SWRL features are covered by RIF-BLD with the exception of "different-from", thus it should be possible to exchange most SWRL rules via RIF.

When viewed as a rule language and compared to SWRL, RIF-BLD supports multiple-arity predicates, and SWRL is limited to unary and binary predicates. RIF-BLD has functions, SWRL is function-free. RIF-BLD has an extensive set of datatypes and builtins, SWRL supports most of the same datatypes but has no builtins. [??? Yes, it does! Under discussion.] RIF-BLD has a limited form of negation in datatype guard predicates (e.g. is-literal-not-integer), SWRL has a different limited form of negation in the "different-from" operator. RIF-BLD interoperates with OWL through a special combination semantics, SWRL is designed to be a syntactic extension to OWL. RIF-BLD allows disjunction in rules, SWRL does not.

=== How can I encode RIF in HTML? ===

RIF does not define a normative encoding in HTML. It was designed primarily for interchange of rules between rule engines, and the XML syntax is the only one defined as a standard for interchange.

However, various text-based presentation syntaxes are used in the specification: although they are not recommended for interchange between different rule systems, they can be used for rendering by HTML processors.

In general, any rule syntax that can be serialized in RIF XML in a semantics-preserving way can be used for that purpose. To avoid ambiguity, it is good practice to use only syntaxes for which a mapping to RIF XML is publicly available.

=== What's the difference between RIF and having an RDF 2.0 that moves beyond binary relations? ===

Such an RDF specification would probably look very much like RIF with RDF compatibility (see [http://www.w3.org/TR/rif-rdf-owl]). Of course, RIF also provides for if/then rules, not just ground facts like RDF.

=== Is RIF useful for reasoning about the provenance of claims expressed in RDF, eg. multiple named graphs in SPARQL that offer competing accounts of some situation? ===

If the differing named graphs are located in different web documents, then RIF with RDF compatibility (see [http://www.w3.org/TR/rif-rdf-owl]) has an import mechanism that can be directed to the specific web documents and reason about them. More refined notions of import that allow to explicitly refer to facts from different imported documents per rule could be covered in extended RIF dialects.

=== How do I embed RIF in an RDFS/OWL schema or ontology? ===

[http://www.w3.org/TR/rif-rdf-owl RIF RDF and OWL Compatibility] specifies, formally, what it means to use RIF with RDFS and/or OWL, and provides a way, in RIF, to import RDFS and OWL.

If you need to work in RDF triples, see [http://www.w3.org/TR/rif-in-rdf RIF In RDF]. This lets you physically embed RIF in an RDFS/OWL document, but notes that the embedded RIF is merely described, not asserted. There is not currently a standard vocabulary saying, in RDFS/OWL, that you also want some RIF rules as part of your ontology. Instead, for now, you must have RIF import RDFS/OWL.

=== What's the relation between RIF and Functional-Logic Programming? ===

Both are founded on Horn logic with equality. Functional-Logic Programming is built on Horn logic with ''oriented'' equations
in rule conclusions, used to define functions. In that sense it specializes RIF-BLD,
built on Horn logic with ''symmetric'' equations. However, Functional-Logic Programming permits higher-order functions, while RIF-BLD only permits first-order functions. For an introduction to functional-logic technology, with many examples, see
[http://www.cs.unb.ca/seminarseries/documents/Harold_Boley-03.17.10.pdf Visualizing Executable Functional-Logic Specifications].

== Documentation ==

=== Where are examples to the W3C semweb technology stack, using RIF properly along with RDF, RDFS, OWL[2], etc.? ===

The [http://www.w3.org/TR/rif-rdf-owl/ RIF RDF and OWL Compatibility] document specifies how RIF works in combination with RDF, RDFS, OWL 1, and OWL 2, and there are small examples throughout the document of RIF-RDF and RIF-OWL combinations, explaining what is entailed (or not) from them.

Two of the use cases presented in [http://www.w3.org/TR/rif-ucr/ RIF Use Cases and Requirements] provide motivating scenarios for RIF in combination with RDF and OWL: [http://www.w3.org/TR/rif-ucr/#Interchanging_Rule_Extensions_to_OWL Interchanging Rule Extensions to OWL] and [http://www.w3.org/TR/rif-ucr/#Publishing_Rules_for_Interlinked_Metadata Publishing Rules for Interlinked Metadata].

Also, see the [http://www.w3.org/2005/rules/wiki/Category:RIF-RDF_Combination RIF-RDF combination test cases] and the [http://www.w3.org/2005/rules/wiki/Category:RIF-OWL_Combination RIF-OWL combination test cases]. Among these,
[http://www.w3.org/2005/rules/wiki/YoungParentDiscount_1 Young Parent Discount] and [http://www.w3.org/2005/rules/wiki/UCR_4.7a UCR_4.7a] are in the style of small usage examples.

=== Where are examples to existing RIF rules written using the simplest, bare-minimum markup and easiest logic/math? ===

The set of RIF documents --- including the documents on [http://www.w3.org/2005/rules/wiki/BLD BLD], [http://www.w3.org/2005/rules/wiki/PRD PRD] and [http://www.w3.org/2005/rules/wiki/FLD FLD] --- and the set of [http://www.w3.org/2005/rules/wiki/Category:Test_Case test cases] both contain a variety of examples that involve almost no logic (sometimes not even modus ponens) and no math at all.

For instance, Example 1 in [http://www.w3.org/2005/rules/wiki/BLD BLD] involves just a single application of modus ponens and no math; Example 4 shows several different ways of writing business rules that do not involve math, and require only a basic knowledge of quantifiers.

Most of the examples in [http://www.w3.org/2005/rules/wiki/Category:Test_Case test cases] are quite simple, and involve nothing more than arithmetic. An example of a test case that involves simple inheritance is [http://www.w3.org/2005/rules/wiki/Classification-inheritance Classification-inheritance.]

=== Where can I find info on RIF for the "business rules" community, esp. to help convince management to start to consider RIF as the source format? ===
Half of the [http://www.w3.org/TR/rif-ucr/#Use_Cases RIF use cases] describe how RIF can serve the business rules community. RIF can help to avoid vendor lock-in, foster collaboration, support eBusiness and eCommerce, optimize the supply chain, and allow business rules to be bought, sold, and shared.
The [http://www.w3.org/TR/rif-prd production rule dialect] includes typical business rules features such as rule priority, negation, decimal numbers, and dates.

=== What interesting things have been built using RIF? ===

Support for RIF is just starting to become available (see [[Implementations]]), so there has not yet been much opportunity to develop applications that use RIF.

This [http://www.ibm.com/developerworks/wikis/display/db2xml/Rules IBM developerWorks article] discusses storing and querying rules in an XML database, and includes a live demo with RIF rules.

Some envisioned representative usage scenarios for RIF are outlined in the [http://www.w3.org/TR/rif-ucr/#Use_Cases RIF use cases].

Please report any applications or uses of RIF to public-rif-comments@w3.org.

== Acknowledements ==

Thanks to questions, comments, suggestions from:

* Lee Feigenbaum
* David Booth
* Richard Cyganiak
* Frank Manola
* "Collette Hagert geb. Nauluta"
* Dan Brickley

RIF FAQ

Sandro — Mon, 04 Feb 2013 17:26:37 GMT

Sandro: /* How do I serialize RIF rules in RDF? */ updated!

__NUMBEREDHEADINGS__

Please send comments or additional questions to [mailto:public-rif-comments@w3.org public-rif-comments@w3.org] ([http://lists.w3.org/Archives/Public/public-rif-wg/ public archive]).

Answers have not necessarily been reviewed by the Working Group. The question are real, having been asked via e-mail or in person.

Some questions here have not yet been answered.

== About RIF ==

=== What is RIF? ===

RIF is the W3C Rule Interchange Format. It's an XML language for expressing rules which computers can execute.

Because of the serious tradeoffs in the design of rule language, RIF provides multiple versions, called ''dialects''. If you're not sure which dialect to use, start with RIF Core. Then, if you need rule features that are not available in RIF Core, consider the other standard dialects and third-party dialects.

=== What is RIF-BLD? (and RIF-Core, PRD, FLD) ===

The standard RIF dialects are ''Core'', ''BLD'', and ''PRD'':

; Core
: This is the fundamental RIF language. It is designed to be the common subset of most rule engines. (It provides "safe" positive datalog with builtins.)
; BLD (Basic Logic Dialect)
: This adds a few things that Core doesn't have: logic functions, equality in the ''then''-part, and named arguments. Each of these features can sort of be simulated in Core. (This is positive Horn logic, with equality and builtins.)
; PRD (Production Rules Dialect)
: adds a notion of forward-chaining rules, where a rule ''fires'' and then performs some action, such as adding more information to the store or ''retracting'' some information.

Note that '''FLD''' (the Framework for Logic Dialects) provides a menu for coherently assembling dialects more expressive than BLD. Links to unofficial, community-contributed RIF dialects can be found
[http://www.w3.org/2005/rules/wiki/RIF_FLD_Dialects here].

More generally, the [[Overview]] provides a guide to the RIF architecture.

=== Is RIF only for interchange? ===

No. Although RIF dialects were designed primarily for interchange, each dialect is a standard rule language and can be used even when portability and interchange are not required.

=== "Reduction In Force"? ===

Yes, in some other situations, ''RIF'' stands for ''reduction in force'', a term for reducing headcount, downsizing, layoffs, etc. We're still waiting to hear a really good pun based on this double meaning.

=== Can I use RIF to map between vocabularies? ===

Yes. It should be good for this. It's [http://www.w3.org/TR/rif-ucr/#Vocabulary_Mapping_for_Data_Integration one of the use cases].

=== Which RIF syntax should I use? ===

The XML syntax is the only one defined as a standard for interchange.
Various presentation syntaxes are used in the specification, but they
are not recommended for sending between different systems.

=== Is there a mime type for RIF? ===

Yes, it's "application/rif+xml". See [http://www.w3.org/TR/rif-core/#Appendix:_RIF_Media_Type_Registration RIF Media Type Registration].

== RIF Software ==

=== What tools (open source and commercial) currently support RIF? ===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

=== How fast are RIF processors compared to RDFS inference and OWL inference? ===

Since RIF can often be implemented
by translation to other rule languages, we can speculate that the
performance will differ only by the time need for translation. Many
RDFS and OWL systems use underlying rule engines to do their
inference, so their performance is likely to be the same or better on
RIF. On the other hand, there are some OWL inference tasks which can
be much more efficiently handled by DL algorithms.

=== Are there any SPARQL stores that support RIF? ===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

We expect that SPARQL systems which currently include rule engines, such as Jena, will implement support for RIF.

=== Is there a Web Service for doing RIF? ===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

=== Does any major technology software vendor (or project) include RIF-related libraries in their stack? IBM, Google, Microsoft, Oracle, KDE, GNOME, Apache, ...===

Implementation plans continue to evolve. Please report any to public-rif-comments@w3.org. We try to maintain this
on the [[Implementations]] page.

IBM & iLog, HP, Oracle, and TIBCO are active in the Working Group.

== Relation to Other Technologies ==

=== I'd like to know if it's possible to translate RIF into SPARQL Construct clause (and back) ===

Some people have used SPARQL Construct clauses as a rule language, although no formal semantics have been specified for this. Because SPARQL including non-monotonic features, the full language possible here would be very expressive and very hard to specify or implement correctly. (What happens if you use !bound with some data that is provided by related rules?)

There is a subset of SPARQL Construct clauses which corresponds to a subset of RIF Core. For this common subset, SPARQL can be seen as just another presentation syntax for RIF Core. It would probably be best to try to stay within this subset when using SPARQL Construct clauses as a rule language.

=== How do I serialize RIF rules in RDF? ===

See [http://www.w3.org/TR/rif-in-rdf RIF in RDF].

=== How do I store RIF rules in my triplestore? ===

See 3.2 above.

=== How do I put RIF rules in RDF, so I can reason about them with more rules? ===

At present you cannot do this in a standardized fashion.

If you map the RIF XML structure to an isomorphic RDF representation (for example, through use of GRDDL) then that RDF structure can be reasoned about with more rules. However, a normative such RDF representation has not be defined by the working group.

=== What are the relationships between the OWL 2 profiles and the RIF dialects? ===

There are several relationships between OWL 2 and RIF dialects.

Firstly, RIF defines the notion of RIF/OWL combinations, providing a semantics for them and a syntactic mechanism for defining such combinations by importing OWL documents into RIF documents. This is specified in [http://www.w3.org/TR/rif-rdf-owl/ RIF RDF and OWL Compatibility]. This mechanism defines import profiles for both OWL 2 DL and OWL 2 Full semantics. Thus each OWL 2 Profile can be used in combination with any RIF dialect using this mechanism. There are no separate import profiles corresponding to the separate OWL 2 profiles.

Secondly, OWL 2 defines a profile, OWL 2 RL, designed to be implementable by means of rule based systems. A partial axiomatization of the OWL 2 RL semantics is given in the [http://www.w3.org/TR/owl2-profiles/#Reasoning_in_OWL_2_RL_and_RDF_Graphs_using_Rules OWL Profiles document] as a set of first order rules. These rules can be translated into RIF Core rules either as a static rule set or on a per-ontology basis as discussed in [http://www.w3.org/2005/rules/wiki/OWLRL OWLRL]. This enables implementation of an OWL 2 RL entailment checker or query answering tool by using the RIF Core rule set in combination with the RDF document encoding an OWL 2 RL premise ontology to derive a set of entailed RDF assertions as RIF Frame formulae.

Thirdly, RIF provides and Informative description of an [http://www.w3.org/TR/rif-rdf-owl/#Embedding_RIF-OWL_2_RL_Combinations embedding] of OWL 2 RL within RIF BLD. This enables the translation of an OWL 2 RL document directly into a RIF BLD document.

=== What is the relationship between RuleML and RIF? ===

RuleML has provided input for RIF on several levels, including the
use of 'striped' XML as well as
the structuring of rule classes into a family of sublanguages with, e.g.,
Datalog RuleML partially mappable to the RIF Core Dialect,
Derivation RuleML to the RIF Basic Logic Dialect, and
the production-rule sublanguage of Reaction RuleML to the RIF Production Rule Dialect.
Conversely, RuleML adopted some features that were developed
as part of the RIF Working Group such as role tags
<if> ... <then> instead of <body> ... <head>.
Shared RIF RuleML implementations and use cases are projected to lead to further convergence.

=== How does RIF differ from SWRL? ===

RIF was designed as an interchange format for exchanging rules between rule systems, such as those that implement SWRL. SWRL is a rule language which was designed as an extension to OWL. It is one of the simpler rule languages and most SWRL features are covered by RIF-BLD with the exception of "different-from", thus it should be possible to exchange most SWRL rules via RIF.

When viewed as a rule language and compared to SWRL, RIF-BLD supports multiple-arity predicates, and SWRL is limited to unary and binary predicates. RIF-BLD has functions, SWRL is function-free. RIF-BLD has an extensive set of datatypes and builtins, SWRL supports most of the same datatypes but has no builtins. [??? Yes, it does! Under discussion.] RIF-BLD has a limited form of negation in datatype guard predicates (e.g. is-literal-not-integer), SWRL has a different limited form of negation in the "different-from" operator. RIF-BLD interoperates with OWL through a special combination semantics, SWRL is designed to be a syntactic extension to OWL. RIF-BLD allows disjunction in rules, SWRL does not.

=== How can I encode RIF in HTML? ===

RIF does not define a normative encoding in HTML. It was designed primarily for interchange of rules between rule engines, and the XML syntax is the only one defined as a standard for interchange.

However, various text-based presentation syntaxes are used in the specification: although they are not recommended for interchange between different rule systems, they can be used for rendering by HTML processors.

In general, any rule syntax that can be serialized in RIF XML in a semantics-preserving way can be used for that purpose. To avoid ambiguity, it is good practice to use only syntaxes for which a mapping to RIF XML is publicly available.

=== What's the difference between RIF and having an RDF 2.0 that moves beyond binary relations? ===

Such an RDF specification would probably look very much like RIF with RDF compatibility (see [http://www.w3.org/TR/rif-rdf-owl]). Of course, RIF also provides for if/then rules, not just ground facts like RDF.

=== Is RIF useful for reasoning about the provenance of claims expressed in RDF, eg. multiple named graphs in SPARQL that offer competing accounts of some situation? ===

If the differing named graphs are located in different web documents, then RIF with RDF compatibility (see [http://www.w3.org/TR/rif-rdf-owl]) has an import mechanism that can be directed to the specific web documents and reason about them. More refined notions of import that allow to explicitly refer to facts from different imported documents per rule could be covered in extended RIF dialects.

=== How do I embed RIF in an RDFS/OWL schema or ontology? ===

[http://www.w3.org/TR/rif-rdf-owl RIF RDF and OWL Compatibility] specifies, formally, what it means to use RIF with RDFS and/or OWL, and provides a way, in RIF, to import RDFS and OWL.

If you need to work in RDF triples, see [http://www.w3.org/TR/rif-in-rdf RIF In RDF]. This lets you physically embed RIF in an RDFS/OWL document, but notes that the embedded RIF is merely described, not asserted. There is not currently a standard vocabulary saying, in RDFS/OWL, that you also want some RIF rules as part of your ontology. Instead, for now, you must have RIF import RDFS/OWL.

=== What's the relation between RIF and Functional-Logic Programming? ===

Both are founded on Horn logic with equality. Functional-Logic Programming is built on Horn logic with ''oriented'' equations
in rule conclusions, used to define functions. In that sense it specializes RIF-BLD,
built on Horn logic with ''symmetric'' equations. However, Functional-Logic Programming permits higher-order functions, while RIF-BLD only permits first-order functions. For an introduction to functional-logic technology, with many examples, see
[http://www.cs.unb.ca/seminarseries/documents/Harold_Boley-03.17.10.pdf Visualizing Executable Functional-Logic Specifications].

== Documentation ==

=== Where are examples to the W3C semweb technology stack, using RIF properly along with RDF, RDFS, OWL[2], etc.? ===

The [http://www.w3.org/TR/rif-rdf-owl/ RIF RDF and OWL Compatibility] document specifies how RIF works in combination with RDF, RDFS, OWL 1, and OWL 2, and there are small examples throughout the document of RIF-RDF and RIF-OWL combinations, explaining what is entailed (or not) from them.

Two of the use cases presented in [http://www.w3.org/TR/rif-ucr/ RIF Use Cases and Requirements] provide motivating scenarios for RIF in combination with RDF and OWL: [http://www.w3.org/TR/rif-ucr/#Interchanging_Rule_Extensions_to_OWL Interchanging Rule Extensions to OWL] and [http://www.w3.org/TR/rif-ucr/#Publishing_Rules_for_Interlinked_Metadata Publishing Rules for Interlinked Metadata].

Also, see the [http://www.w3.org/2005/rules/wiki/Category:RIF-RDF_Combination RIF-RDF combination test cases] and the [http://www.w3.org/2005/rules/wiki/Category:RIF-OWL_Combination RIF-OWL combination test cases]. Among these,
[http://www.w3.org/2005/rules/wiki/YoungParentDiscount_1 Young Parent Discount] and [http://www.w3.org/2005/rules/wiki/UCR_4.7a UCR_4.7a] are in the style of small usage examples.

=== Where are examples to existing RIF rules written using the simplest, bare-minimum markup and easiest logic/math? ===

The set of RIF documents --- including the documents on [http://www.w3.org/2005/rules/wiki/BLD BLD], [http://www.w3.org/2005/rules/wiki/PRD PRD] and [http://www.w3.org/2005/rules/wiki/FLD FLD] --- and the set of [http://www.w3.org/2005/rules/wiki/Category:Test_Case test cases] both contain a variety of examples that involve almost no logic (sometimes not even modus ponens) and no math at all.

For instance, Example 1 in [http://www.w3.org/2005/rules/wiki/BLD BLD] involves just a single application of modus ponens and no math; Example 4 shows several different ways of writing business rules that do not involve math, and require only a basic knowledge of quantifiers.

Most of the examples in [http://www.w3.org/2005/rules/wiki/Category:Test_Case test cases] are quite simple, and involve nothing more than arithmetic. An example of a test case that involves simple inheritance is [http://www.w3.org/2005/rules/wiki/Classification-inheritance Classification-inheritance.]

=== Where can I find info on RIF for the "business rules" community, esp. to help convince management to start to consider RIF as the source format? ===
Half of the [http://www.w3.org/TR/rif-ucr/#Use_Cases RIF use cases] describe how RIF can serve the business rules community. RIF can help to avoid vendor lock-in, foster collaboration, support eBusiness and eCommerce, optimize the supply chain, and allow business rules to be bought, sold, and shared.
The [http://www.w3.org/TR/rif-prd production rule dialect] includes typical business rules features such as rule priority, negation, decimal numbers, and dates.

=== What interesting things have been built using RIF? ===

Support for RIF is just starting to become available (see [[Implementations]]), so there has not yet been much opportunity to develop applications that use RIF.

This [http://www.ibm.com/developerworks/wikis/display/db2xml/Rules IBM developerWorks article] discusses storing and querying rules in an XML database, and includes a live demo with RIF rules.

Some envisioned representative usage scenarios for RIF are outlined in the [http://www.w3.org/TR/rif-ucr/#Use_Cases RIF use cases].

Please report any applications or uses of RIF to public-rif-comments@w3.org.

== Acknowledements ==

Thanks to questions, comments, suggestions from:

* Lee Feigenbaum
* David Booth
* Richard Cyganiak
* Frank Manola
* "Collette Hagert geb. Nauluta"
* Dan Brickley

UCR

Sandro — Mon, 04 Feb 2013 16:42:26 GMT

Sandro: remove extra explicit <P> tag

__NUMBEREDHEADINGS__
{{TR|title=RIF Use Cases and Requirements}}
<div id='editors'>
; Editors:
: Adrian Paschke, Freie Universitaet Berlin
: Leora Morgenstern, SAIC
: David Hirtle, National Research Council Canada
: Allen Ginsberg, Mitre
: Paula-Lavinia Patranjan, REWERSE
: Frank <nowiki>McCabe</nowiki>, Fujitsu
</div>
; Abstract
: <div id='abstract'><p></p> <p></p> <p></p> <p>This document, developed by the [http://www.w3.org/2005/rules/wg Rule Interchange Format (RIF) Working Group], specifies use cases and requirements for the W3C Rule Interchange Format, a family of rule interchange dialects that allows rules to be translated between rule languages and thus transferred between rule systems. </p> </div>
; Status of this Document
: 3rd revised version of the UCR document

[http://www.w3.org/Consortium/Legal/ipr-notice#Copyright Copyright] © 2010 [http://www.w3.org/ W3C]<sup>®</sup> ([http://www.csail.mit.edu/ MIT], [http://www.ercim.org/ ERCIM], [http://www.keio.ac.jp/ Keio]), All Rights Reserved. W3C [http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer liability], [http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks trademark] and [http://www.w3.org/Consortium/Legal/copyright-documents document use] rules apply.

<div id='docbody'>

<html>
<script type="text/javascript">/*<![CDATA[*/
/*
Written by Jonathan Snook, http://www.snook.ca/jonathan
Add-ons by Robert Nyman, http://www.robertnyman.com
Author says "The credit comment is all it takes, no license. Go crazy with it!:-)"
From http://www.robertnyman.com/2005/11/07/the-ultimate-getelementsbyclassname/
*/

var displayed = [];
displayed["bld"] = 1;
displayed["prd"] = 1;

function display(syntax,status) {
var howmany = 0;
if (status=='none') {
displayed[syntax] = 0;
} else {
displayed[syntax] = 1;
}
for ( i in displayed ) {
howmany = howmany + displayed[i];
}
set_display_by_class('p',syntax,status);
if ( howmany == 1 ) {
set_display_by_class('b','syntax-head','none');
} else {
set_display_by_class('b','syntax-head','');
}
}

function getElementsByClassName(oElm, strTagName, oClassNames){
var arrElements = (! (! (strTagName == "*") || ! (oElm.all)))? oElm.all : oElm.getElementsByTagName(strTagName);
var arrReturnElements = new Array();
var arrRegExpClassNames = new Array();
if(typeof oClassNames == "object"){
for(var i=0; !(i>=oClassNames.length); i++){ /*>*/
arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames[i].replace(/\-/g, "\\-") + "(\\s|$)"));
}
}
else{
arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames.replace(/\-/g, "\\-") + "(\\s|$)"));
}
var oElement;
var bMatchesAll;
for(var j=0; !(j>=arrElements.length); j++){ /*>*/
oElement = arrElements[j];
bMatchesAll = true;
for(var k=0; !(k>=arrRegExpClassNames.length); k++){ /*>*/
if(!arrRegExpClassNames[k].test(oElement.className)){
bMatchesAll = false;
break;
}
}
if(bMatchesAll){
arrReturnElements.push(oElement);
}
}
return (arrReturnElements)
}

function set_display_by_class(el, cls, newValue) {
var e = getElementsByClassName(document, el, cls);
if (e != null) {
for (var i=0; !(i>=e.length); i++) {
e[i].style.display = newValue;
}
}
}

function set_display_by_id(id, newValue) {
var e = document.getElementById(id);
if (e != null) {
e.style.display = newValue;
}
}
/*]]>*/
</script>

</html>

<div> 
== Introduction ==

<div><div lang="en" dir="ltr">

Rule-languages and rule-based systems have played seminal roles in the history of computer science and the evolution of information technology. From expert systems to deductive databases, the theory and practice of automating inference based on symbolic representations has had a rich history and continues to be a key technology driver.

Due to the innovations made possible by the Internet, the World Wide Web, and, most recently, the Semantic Web, there is now even greater opportunity for growth in this sector. While some of these opportunities may require advances in research, others can be addressed by enabling existing rule-based technologies to interoperate according to standards-based methodologies and processes. The primary goal of the Rule Interchange Format (RIF) Working Group has been to devise such standards and make sure that they are not only useful in the current environment, but are easily extensible in order to deal with the evolution of rule technology and other enabling technologies. RIF's mission is part of W3C's larger goal of enabling the sharing of information in forms suited to machine processing:

*# Rules themselves represent a valuable form of information for which there is not yet a standard interchange format, although significant progress has been made within the [http://www.ruleml.org/ RuleML Initiative] and elsewhere.
*# Rules provide a powerful business logic representation, as business rules, in many modern information systems.
*# Rules are often the technology of choice for creating maintainable adapters between information systems.
*# As part of the Semantic Web architecture, rules can extend or complement the [[#ref-owl-reference|OWL Web Ontology Language]] to more thoroughly cover a broader set of applications, with knowledge being encoded in OWL or rules or both.

The purpose of this RIF-UCR document is to describe the use cases that guided the design of RIF and to document the design requirements that were derived from both the use cases and from the basic goals of RIF. RIF-UCR also delivers a structured context for formulating future technical specifications of further RIF dialects. Each dialect targets a cluster of similar rule languages and enables platform-independent interoperation between them (via interchange of RIF rules). The use cases presented illustrate some of the principal ways in which RIF can provide benefits. RIF can promote innovation and development by fostering collaborative work and providing new opportunities for third-party services. RIF can promote e-commerce by providing interoperability across vendor platforms. RIF can promote efficient process management through reuse, sharing, and the ability to provide unified views across disparate platforms. Finally, RIF can promote the growth of knowledge by enabling reasoning with merged sets of rules originating from disparate knowledge sources.

The RIF-UCR document is structured as follows: Section 2 formulates the overall goals of RIF. Section 3 summarizes the released RIF dialects and the structure of RIF. Section 4 discusses several important requirements for RIF dialects. Section 5 presents a set of use cases that are representative of the types of application scenarios that RIF is intended to support. The use cases illustrate the utilization of the current RIF dialects. More importantly, the functionality specified in the use cases, together with the requirements discussed in the previous section, serves as input for both the technical specification for future RIF dialects and the implementation of various variants of these scenarios by RIF-compliant applications and systems.

Although in this document the discussion of requirements precedes the discussion of use cases, the development of the use cases preceded, and in fact motivated, the development of the requirements. For the most part, requirements were not established unless there was at least one use case, or straightforward modification of a use case, from which that requirement could be derived. There are some exceptions to this rule: for example, some requirements were already defined as constraints in the working group charter and were not necessarily derived from any specific use case. The fulfillment of such requirements is discussed with respect to the existing RIF dialects.

Note that in fact not all use cases can be represented in a straightforward manner within all RIF dialects. In particular, several use cases cannot be represented within the RIF dialect [[#ref-rif-bld|BLD]] . This is due first, to the fact that BLD is strictly less expressive than first-order logic (since negation is not expressible), and second, to the fact that some use cases are most naturally represented in languages more powerful than first-order logic, such as modal logics. Some use cases that cannot be represented within BLD can be represented within the RIF dialect [[#ref-rif-prd|PRD]], which includes the construct of negation as failure. Following the presentation of each use case in Section 5 is a note indicating in which of the current RIF dialects a use case can be represented naturally, sometimes accompanied by discussion.

It should be noted that even for use cases which cannot be represented in a straightforward manner within some RIF dialect, there may be other approaches that would enable representation. For example, although epistemic operators such as <tt>Know</tt> and <tt>Believe</tt> are most straightforwardly represented within a modal logic, it is generally possible to represent such operators in a first-order logic using a possible-worlds semantics. For certain use cases which cannot be naturally represented within some dialect, the extent to which this can be done will be discussed.

</div></div></div><div>

== Goals ==

<div><div lang="en" dir="ltr">
RIF is primarily intended to be an effective means of exchanging rules that has the potential to be widely adopted in industry and that is consistent with existing W3C technologies and specifications.

<span id="goal-exchange-of-rules" class="anchor"></span>
==== Exchange of Rules ====

The primary goal of RIF is to facilitate the exchange of rules.

<span id="goal-w3c-consistency" class="anchor"></span>
==== Consistency with W3C specifications ====

RIF is intended to be a W3C specification that builds on and further develops the existing range of specifications that have been developed by the W3C. This implies that existing W3C technologies should fit well with RIF.

<span id="goal-widescale-adoption" class="anchor"></span>
==== Widescale Adoption ====

It is an explicit goal of the W3C that RIF will have maximal potential for widescale adoption. The wider the adoption of the specification, the more effective rule interchange becomes. This is known as the "network effect."

These goals, along with the use cases in Section 5, motivate the requirements in Section 4.

</div></div></div><div>

== Structure of RIF ==

<div><div lang="en" dir="ltr">
RIF is described by a set of documents, each fulfilling a different purpose and catering to possibly different audiences. The three RIF dialects that are part of the W3C recommendation and that can be used to represent RIF use cases are:

* [[#ref-rif-core|RIF Core Dialect]], which provides a standard, base level of functionality for interchange.
* [[#ref-rif-bld|Basic Logic Dialect]] and [[#ref-rif-prd|Production Rule Dialect]] provide extended functionality matching two common classes of rule engines, namely derivation rules and production rules.

Along with these three dialects, RIF includes related documents: [http://www.w3.org/TR/rif-fld RIF Framework for Logic Dialects], [http://www.w3.org/TR/rif-dtb RIF Datatypes and Built-Ins 1.0], [http://www.w3.org/TR/rif-test RIF Test Cases], [http://www.w3.org/TR/rif-rdf-owl RIF RDF and OWL Compatibility], [http://www.w3.org/TR/rif-ucr/ RIF Use Cases and Requirements], [http://www.w3.org/TR/rif-owl-rl OWL 2 RL in RIF], [http://www.w3.org/2007/OWL/wiki/PlainLiteral rdf:PlainLiteral], [http://www.w3.org/TR/rif-xml-data RIF Combination with XML data], [http://www.w3.org/TR/rif-primer RIF Primer], and [http://www.w3.org/TR/rif-in-rdf/ RIF In RDF]. For an overview of RIF, see the [http://www.w3.org/TR/rif-overview RIF Overview].

RIF is designed as a family of RIF dialects as shown in the following Venn diagram:

[[Image: RIF_DIALECTS_VENN.jpg | Venn Diagram of RIF Dialects]]

Each dialect is a collection of components that work together, forming an interlingua. New dialects are needed for those cases in which no existing dialect provides the required rule-language features for interchange.

The RIF Framework for Logic-based Dialects ([http://www.w3.org/TR/rif-fld RIF-FLD]) describes mechanisms for specifying the syntax and semantics of logic-based RIF dialects through a number of generic concepts. In general, a logic-based RIF dialect should specialize these general mechanisms; justifications should be provided for cases where this is not done. This specialization may include leaving out some elements of RIF-FLD in order to produce a dialect's concrete syntax and model-theoretic semantics. The RIF dialects that are part of the W3C RIF recommendation are RIF Basic Logic Dialect (RIF-BLD), which is fully specified using RIF-FLD, and RIF Production Rules Dialect (RIF-PRD), which is partially specified using RIF-FLD and supplemented by an operational semantics.

[http://www.w3.org/TR/rif-bld RIF-BLD] (Basic Logic Dialect) is a specialization of RIF-FLD capable of representing definite Horn rules with equality and enhanced with a number of syntactic extensions to support expressive features such as objects and frames, internationalized resource identifiers (IRIs) as identifiers for concepts, and XML Schema data types.

[http://www.w3.org/TR/rif-prd RIF-PRD] (Production Rules Dialect) specifies a production rules dialect to enable the interchange of production rules. The condition language of RIF-PRD is defined in Core as a common subset of RIF-BLD and RIF-PRD.

[http://www.w3.org/TR/rif-core RIF-Core] (Core Dialect) specifies a common subset of RIF-BLD and RIF-PRD that includes RIF-DTB.

The normative syntax for RIF dialects is a concrete XML syntax. A non-normative presentation syntax is additionally specified for each dialect to allow a more easily readable and compact presentation of language fragments (such as examples).

</div></div></div><div>

== Requirements ==

<span id="req-semantic-tagging" class="anchor"></span>

<div><div lang="en" dir="ltr">
The goals and use cases motivate a number of requirements for a Rule Interchange Format. The Working Group has approved the following requirements:

<span id="req-implementability" class="anchor"></span>

=== Implementability ===

''RIF must be implementable using well understood techniques, and should not require new research in, e.g., algorithms or semantics in order to implement translators.''

<span id="req-semantic-precision" class="anchor"></span>

=== Semantic precision ===

''RIF-Core must have a clear and precise syntax and semantics. Each standard RIF dialect must have a clear and precise syntax and semantics that extend RIF-Core.''

<span id="req-extensible" class="anchor"></span>

=== Extensible Format ===

''It must be possible to create new RIF dialects that extend existing dialects (thus providing backward compatibility) and are handled gracefully by systems which support existing dialects (thus providing forward compatibility).''

<span id="req-translators" class="anchor"></span>

=== Translators ===

''For every standard RIF dialect it must be possible to implement translators between rule languages covered by that dialect and RIF without changing the rule language.''

<span id="req-standard-components" class="anchor"></span>

=== Standard components ===

''RIF implementations must be able to use standard support technologies such as XML parsers and other parser generators, and should not require special purpose implementations when reuse is possible.''

<span id="req-coverage" class="anchor"></span>

=== Rule language coverage ===

''Because of the great diversity of rule languages, no single interchange language is likely to be able to bridge between all. Instead, RIF provides dialects each of which targets a cluster of similar rule languages. RIF must allow intra-dialect interoperability, i.e. interoperability between semantically similar rule languages (via interchange of RIF rules) within one dialect, and should support inter-dialect interoperability, i.e. interoperability between dialects with maximum overlap.''

<span id="req-compliance-model" class="anchor"></span>

=== Compliance model ===

''The RIF specifications must provide clear conformance criteria that define what is and what is not a conformant RIF implementation.''

<span id="req-default-behavior" class="anchor"></span>

=== Default behavior ===

''RIF must specify at the appropriate level of detail the default behavior that is expected from a RIF compliant application that does not have the capability to process all or part of the rules described in a RIF document, or it must provide a way to specify such default behavior.''

<span id="req-different-semantics" class="anchor"></span>

=== Different semantics ===

''RIF must cover rule languages having different semantics.''

<span id="req-dialects" class="anchor"></span>

=== Limited number of dialects ===

''RIF must have a standard core, and a limited number of standard dialects based upon that core.''

<span id="req-comments" class="anchor"></span>

=== Embedded comments ===

''RIF must be able to pass comments.''

<span id="req-metadata" class="anchor"></span>

=== Embedded metadata ===

''RIF must support metadata such as author and rule name.''

<span id="req-owl-data" class="anchor"></span>

=== OWL data ===

''RIF must cover OWL knowledge bases as data where compatible with RIF semantics.''

<span id="req-rdf-data" class="anchor"></span>

=== RDF data ===

''RIF must cover RDF triples as data where compatible with RIF semantics.''

<span id="req-dialect-identification" class="anchor"></span>

=== Dialect Identification ===

''The semantics of a RIF document must be uniquely determined by the content of the document, without out-of-band data.''

<span id="req-xml-syntax" class="anchor"></span>

=== XML syntax ===

''RIF must have an XML syntax as its primary normative syntax.''

<span id="req-xml-types" class="anchor"></span>

=== XML types ===

''RIF must support an appropriate set of scalar datatypes and associated operations as defined in XML Schema part 2 and associated specifications.'' See the charter on [http://www.w3.org/2005/rules/wg/charter#datatype0 Datatype support].

<span id="req-merge" class="anchor"></span>

=== Merge Rule Sets ===

''RIF must support the ability to merge rule sets.''

<span id="req-rulesets" class="anchor"></span>

=== Identify Rule Sets ===

''RIF must support the identification of rule sets.''

<span id="req-xml-data" class="anchor"></span>

=== XML data ===

''RIF should be able to accept XML elements as data.''

<span id="req-rif-text" class="anchor"></span>

=== Internationalized text ===

''RIF must support internationalized text — that is, text that conveys additional information in terms of a language tag.''

</div></div></div><div>

== Use Cases ==

<div><div lang="en" dir="ltr">

A use case for RIF consists of a description of a problem together with a description of a solution. Most of these solutions often can be implemented using one of the existing RIF dialects in the W3C recommendation (Core, BLD, or PRD); others require the specification of a new RIF dialect.

The set of use cases is intended to do the following:
<ul>
<li>motivate the need for a rule interchange format in a broad range of application domains and industrial sectors;</li>
<li>provide scenarios that explain the benefits of a rule interchange format in such scenarios and motivate the design of RIF;</li>
<li>motivate the working group's set of requirements for a rule interchange format; and</li>
<li>guide users to RIF's specified dialects.</li>
</ul>

The set of use cases was developed over several years.
Nearly [http://www.w3.org/2005/rules/wg/wiki/Use_Cases fifty use cases] documenting the need for a RIF were originally submitted by RIF working group members. These were grouped into general categories and then synthesized as much as possible. The goal was to come up with a relatively small set of use cases that would refer to popular application domains and industrial sectors, and that would cover a broad range of possible requirements. Following the presentation of each use case, we briefly discuss whether it can be covered by the existing three RIF dialects (Core, BLD, and PRD). All use cases except for 5.2 and 5.4 can be covered at least in part by at least one of the dialects. The reader will note that several cases which require negation are covered only by PRD; negation is not expressible in either BLD or Core.



</div></div>

<div>

=== Negotiating eBusiness Contracts Across Rule Platforms ===

<div><div lang="en" dir="ltr">

This use case illustrates a fundamental use of RIF: to supply a vendor-neutral representation of rules. This enables rule-system developers and stakeholders to do their work: for example, to make product investments without concern for vendor lock-in, and without concern that a business partner does not have the same vendor technology. It also illustrates the fact that RIF can be used to foster collaborative work. Each developer and stakeholder can make a contribution to the joint effort without being forced to adopt the tools or platforms of the other contributors.

John is negotiating an electronic business contract regarding the supply of various types of items that Jane's company is manufacturing. Jane and John interchange the contract-related data and rules involved in the negotiation in electronic form so that they can run simulations. Both agree on a standard Business Object Model / data model (i.e., vocabulary / ontology) for the goods and services involved. In this case an XML schema and appropriate test XML documents are interchanged with their rules. Since John and Jane run applications based on different vendors' rule engines and rule languages, they interchange the rules using RIF; both vendors used can interpret the XML schema and data, and produce the results as an amended XML document. John's company defines its purchase orders in terms of an XML description of goods, packaging, delivery location, and date with delivery and payment rules. A rule proposed by John might be the following:

<pre width=130>
If an item is perishable and is delivered to John more than 10 days after the scheduled delivery date, then he will reject the item.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
This rule set can be adequately represented in RIF-Core using (ordered) relations as e.g. in standard Logic Programming, or using unordered relations using named arguments, or in a more object-oriented encoding using frames.<br />
<br />
''Ordered representation in RIF Core presentation syntax using relations:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
ex:reject("John" ?item) :-
ex:perishable(?item)
ex:delivered(?item ?deliverydate "John")
ex:scheduled(?item ?scheduledate)
?diffdays = External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
External(pred:numeric-greater-than(?diffdays 10))
)
)
)
</code>
<br />
Note, the nesting of external built-in functions and operations and the assignment/binding of (intermediate) result (sets) from functions to variables by equality in this example.<br />
<br />
''Unordered representation in RIF Core presentation syntax using namened arguments:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
ex:reject(ex:ware -> ?item ex:receiver -> "John") :-
ex:perishable(ex:ware -> ?item)
ex:delivered(ex:ware -> ?item ex:datetime -> ?deliverydate ex:receiver -> "John")
ex:scheduled(ex:datetime -> ?scheduledate ex:ware -> ?item)
?diffdays = External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
External(pred:numeric-greater-than(?diffdays 10))
)
)
)
</code>
<br />
Note, the arbitrarily unordered named argument arguments of the user-defined relations, in contrast to external built-in functions and operations, which must have a predefined order. <br />
<br />
''Object-Oriented Representation in RIF Core presentation syntax using frames:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
?item[ex:status -> "rejected"] :-
?item[ex:perishable -> true]
?item[ex:deliveredOn -> ?deliverydate ex:delivered -> "John"]
?item[ex:scheduledOn -> ?scheduledate ex:delivered -> "John"]
External(pred:numeric-greater-than(
External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
10
)
)
)
)
</code>
</p>

Jane replies with some suggested rule changes:

<pre width=130>
If an item is perishable and it is delivered to John more than 7 days after the scheduled delivery date but less than 14 days after the scheduled delivery date then a discount of 18.7% will be applied to the delivered item.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
''Representation in RIF Core presentation syntax using positional relations:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
ex:discount("John" ?item 18.7 ) :-
ex:perishable(?item)
ex:delivered(?item ?deliverydate "John")
ex:scheduled(?item ?scheduledate)
?diffdays = External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
External(pred:numeric-greater-than(?diffdays 7))
External(pred:numeric-less-than(?diffdays 14))
)
)
)
</code>
<br />

The binding of the intermeditate results to the variable "?diffdays" avoids repetition, as it used twice in the subsequent rule conditions. As demonstrated in the previous examples, similar representations for this rule can be given using slots or frames and as a production rule which asserts the conclusion as a new fact.
</p>

John considers this and agrees with Jane. Both organizations utilize these rules in their operational systems using disparate rule representations internally to compute prices for this order and determine contract compliance.

Future requests for the supply of items by John's company are defined on their purchasing web site, as the appropriate XML schema and a RIF rule set (or rule sets). This allows Jane's company and its competitors to respond electronically with XML cost sheets. Suppliers respond with multiple cost sheets with different variations on the RIF rules proposed by John's company, allowing John's company to review the alternative rules with their associated costs to determine whether they, as a business, would benefit by relaxing or adding new rules as proposed by suppliers.

'''Supported by: RIF-Core, RIF-BLD, RIF-PRD'''

The rules of this use case can be adequately represented in RIF-Core (and likewise, in RIF-BLD and RIF-PRD) by using (ordered) relations, as e.g. in standard Logic Programming, or by using unordered relations and named arguments, or in a more object-oriented encoding using frames.

</div></div></div><div>

=== Negotiating eCommerce Transactions Through Disclosure of Buyer and Seller Policies and Preferences ===

<div><div lang="en" dir="ltr">

This use case concerns the ability of parties involved in formal transactions or procedures, e.g., credit card authorization of a purchase or access of private medical records, to express and protect their interests within a policy-governed framework. The goal is to formally encode the preferences, priorities, and responses of the parties in such a way that the overall policy can work as intended while still providing opportunity for automatic negotiation of terms as long as it is allowed by the policy. Utilizing RIF in this use case would extend the scope of this technology, affording a higher degree of interoperability, as well as enabling re-use and sharing of preferences through interchange. The detailed scenario below shows how this would work.

Alice wants to buy a device at an online site called "eShop." Alice employs software called "Emptor" that functions as automated negotiating agent for buyers. eShop employs software called "Venditor" as automated negotiating agent for sellers.

Alice's and eShop's policies describe whom they trust and for what purposes. The negotiation is based both on their policies, which are specified as rules, and on Emptor's and Venditor's credentials. These policies and credentials are disclosed (interchanged) in order to automatically establish trust with the goal of successfully completing the transaction.

Policies are themselves subject to access control. Thus, rule interchange is necessarily done during negotiation and in general depends on the current level of mutual trust. Since Emptor and Venditor might use different rule languages and/or engines for evaluating their own as well as imported rules, a standard rule interchange format needs to be employed for enabling the rule interchange between the two systems.

When Alice clicks on a "buy it" button at eShop's Web site, Emptor takes over and sends a request to eShop's site. Venditor receives the request and sends parts of its policy (i.e. a set of rules) back to Emptor. Among other things, the policy states that:

<pre width=130>
In order to grant access a buyer must provide valid credit card information together with delivery information (address, postal code, city, and country).
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF-Core presentation syntax using relations and frames in combination: <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?buyer ?creditCard ?address (
ex:permit_access("eShop" ?buyer) :-
ex:provide("eShop" ?buyer)
?buyer[ex:card -> ?creditCard ex:deliveryAddr -> ?address]
ex:valid_payment_method(?creditCard)
ex:valid_delivery_address(?address)
)

Forall ?type ?person ?first ?last ?number ?code ?date ?month ?year (
ex:valid_payment_method(?card) :-
?card[type -> ?type
ex:holder -> ?person
ex:number -> ?number
ex:code -> ?code
ex:expiry -> ?date]
?person[ex:lastname -> ?last ex:firstname -> ?first]
?date[ex:month -> ?month ex:year -> ?year]
ex:credential(?type ?person ?number ?code ?date)
)

Forall ?address ?last ?first ?street ?strname ?number ?code ?city ?country (
ex:valid_delivery_address(?address) :-
?address[ex:name -> ?person ex:street -> ?street ex:postal_code -> ?code ex:city -> ?city ex:country -> ?country ]
?person[ex:lastname -> ?last ex:firstname -> ?first]
?street[name -> ?strname ex:number -> ?number]
ex:declaration(?person ?street ?number ?code ?city ?country)
)

)
)
</code>

Note that in this example relational representation is used in combination with frame representation. Such mixing of representation styles is supported by RIF.
</p>

Rules compactly express possible ways in which a resource can be accessed; by exchanging them negotiations are shorter and privacy protection is improved. In this example, Venditor reveals part of its policy in the form of rules to enable Emptor to choose how to answer, i.e., to decide which credentials and required information to disclose.

To determine whether Venditor's request for information is consistent with Alice's policy, Emptor takes its own rules into account. One of these rules states:

<pre width=130>
Disclose Alice's credit card information only to online shops belonging to the Better Business Bureau.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF Core presentation syntax:

<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?Shop ?card ?Credential ?Buyer (
ex:provide(?Shop ?Buyer ) :-
?Buyer[ex:card -> ?creditCard ex:deliveryAddr -> ?address]
ex:belongs_to(?Shop "Better Business Bureau")
)

Forall ?deliveryAddr ?card ?Date ?Person ?Street (
ex:Alice[ex:card -> ?card ex:deliveryAddr -> ?deliveryAddr] :-
?Date = ex:Date[ex:month -> 12 ex:year -> 2012]
?Person = ex:Person[ex:lastname -> "Sure" ex:firstname -> "Alice"]
?Street = ex:Street[name -> "North Street" number -> 111]
?card= ex:Card[ ex:type -> "Visa"
ex:holder -> ?Person
ex:number -> "123456789"
ex:code -> "123"
ex:expiry -> ?Date
]
?deliveryAddr = ex:DeliveryAddress[ ex:name -> ?Person
ex:street -> ?Street
ex:postal_code -> "NE3456"
ex:city -> "New York"
ex:country -> "USA"
]
)

)
)
</code>

</p>

By disclosing (interchanging) the above rule, Emptor asks Venditor to provide credentials saying that it belongs to the Better Business Bureau, Alice's most trusted source of information on online shops. eShop has these credentials. Moreover, its policy contains a rule authorizing release of this credential to any potential purchaser. Hence, Venditor passes the credential to Emptor. However, before Emptor can disclose Alice's credit card information to Venditor, it must still check whether disclosing all requested information breaks Alice's denial constraints. Alice has stated the following constraint:

<pre width=130>
For purposes of anonymity, never provide both the person's birth date and postal code.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
The current RIF dialects do not specify explicit constructs for integrity constraints.
</p>

Since for this purchase, Alice birth date is not necessary, Alice's constraints are respected. Emptor therefore provides Alice's credit card information to Venditor.

Companies that provide software such as Venditor and Emptor can make use of RIF in several ways. First, the rules expressing Alice's and/or eShop's policies could be expressed in different rule languages but still work with a common software, using RIF-based interchanges. Second, RIF would enable
Venditor and Emptor to work together in real time, even if these automated agents are products of different companies using different internal rule languages. When these two systems would need to exchange policy or preference information of their respective clients, they would use RIF to enable the interchange in real time. When Venditor sends its initial policy information to Emptor, it would use RIF; likewise, Emptor would take that policy and translate it from RIF to its internal representation in order to determine what it needs to do.

'''Not currently supported by existing RIF dialects (Core, BLD, PRD) '''

Current RIF dialects do not specify explicit constructs for integrity constraints; thus, this use case is not adequately supported by any of these dialects.

</div></div></div><div>

=== Collaborative Policy Development for Dynamic Spectrum Access ===

<div><div lang="en" dir="ltr">

This use case demonstrates how RIF leads to increased flexibility in matching the goals of end-users of a service/device, with the goals of providers and regulators of such services/devices. RIF can do that because it enables deployment of third party systems that can generate various suitable interpretations and/or translations of the sanctioned rules governing a service/device.

This use case concerns ''Dynamic Spectrum Access for wireless communication devices''. Recent technological and regulatory trends are converging toward a more flexible architecture in which reconfigurable devices may operate legally in various regulatory and service environments. The ability of a device to absorb the rules defining the policies of a region, or the operational protocols required to dynamically access available spectrum, is contingent upon those rules being in a form that the device can use, as well as their being tailored to work with devices in the same class having different capabilities.

In this use-case we suppose a region adopts a policy that allows certain wireless devices to opportunistically use frequency bands that are normally reserved for certain high-priority users. The decision by the European Union to allow "Dynamic Frequency Selection" (DFS) use of the 5 GHz frequency band by wireless systems, a band intermittently used by military and weather radar, is a recent example.)

Suppose the policy states:

<pre width=130>
A wireless device can transmit on a 5 GHz band if no priority user is currently using that band.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>

<br />Note, since default negation (not) such as negation as failure is not supported by RIF-BLD there is no adequate way to represent that "no priority user is currently using the band".
</p>

How does a device know that no priority user is currently using a band it wants to use? The answer will depend on the specific capabilities of the device. One type of device may answer this question by sensing the amount of energy it is receiving on that band. That is, it might employ the rule:

<pre width=130>
If no energy is detected on a desired band then assume no other device is using the band.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF-BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
Forall ?device ?band ?level (<br />
ex:used(?device ?band) :- <br />
ex:detect(ex:energy(?level ?band))<br />
External(pred:numeric-greater-than(?level 0))<br />
)<br />
)<br />
)<br />
</code>
<br />Note, the engergy detection function would require an external call for sensing the level of energy. Such procedural attachments cannot be specified in BLD. Reaction rules provide event detection capabilities.
</p>

A second type of device may get information from a control channel that lets it know whether the desired band is being used by a priority user. That is, it might employ the rule:

<pre width=130>
If no control signal indicating use of a desired band by a priority user is detected then assume the band is available.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
Forall ?device ?band ?user (<br />
ex:used(?device ?band) :- <br />
ex:detect(ex:signal(?user ?band))<br />
ex:priority(?user,"high").<br />
)<br />
)<br />
)<br />
</code>
<br />
</p>

So each type of device will need to employ different "interpretations" or "operational definitions" of the policy in question.

Now assume that there are 10 manufacturers of these 2 different types of wireless devices. Suppose that each of these manufacturers uses a distinct rule-based platform in designing its devices. Each manufacturer needs to write 2 interpretations of the policy (for each of the two types of device). That means that 20 different versions of the policy must be written, tested, and maintained.

Enter RIF. The 10 manufacturers form a consortium. This is a third-party group that is responsible for translating regional policies into RIF. When it does so, however, it provides different versions corresponding to the possible interpretations (operational definitions) of the policy. So in this case, 2 RIF versions of the DFS policy are provided for the 2 types of device mentioned above. Each of these RIF specifications can be automatically translated into the appropriate rule-platform provided that a RIF-Compiler for the target device architecture exists. Clearly it will be in the interest of each device manufacturer to develop such compilers. That is because the manufacturer only needs to develop such a compiler ''once'' for every architecture it owns. Contrast that investment with having to produce, test, and maintain different versions of various policies over the lifetime of a product.

This arrangement also allows the overall process to be organized in a fashion that maintains the natural division of labor in the corresponding division of artifacts produced by that labor. The policy and its various interpretations are written and maintained in platform-independent artifacts (RIF); knowledge about how to translate from RIF to a particular device architecture is maintained in the compilers. A change in policy is inserted at the top level in the policy artifact hierarchy where it should be; possible operational interpretations of that change are inserted at the next level down; and the implementation implications for the various device architectures is generated automatically at the lowest level.

'''Partly supported by: RIF-PRD'''

The energy detection function specified in this use case would require an external call to a device that would sense the level of energy. Such procedural attachments cannot be specified in the current RIF dialects. Reaction rules support (complex) event detection capabilities on, e.g., event streams over sensor data.

This use case is not supported at all by RIF-BLD, and by extension, by RIF-Core. These dialects do not support negation, and
the use case makes explicit mention of negation, e.g. for representing that "no priority user is currently using the band."<br />

</div></div></div><div>

=== Access to Business Rules of Supply Chain Partners ===

<div><div lang="en" dir="ltr">

A business process (BP) designer designs processes that can span multiple departments in the same business as well as other business partners. A classic example of this is the integration of supply chain business processes which typically involve multiple partners. Supply chain integration involves exposing a certain amount of business logic between partners as well as integrating processes across partners. In such activities it is therefore often necessary to access or invoke rules that originate in other ownership domains.

A key part of a business process is the logic used to make decisions within the process. Such logic is often coded in rules because rule languages are easier for BP designers to understand and manipulate than procedural code (as in Java) -- although both forms of business logic are prevalent. When business logic is represented in different rule languages, designing an integrated process presents a significant burden to the BP designer.

Two primary integration modalities are possible: importing the different rule sets into a single engine and processing them in a uniform manner, or accessing the rule sets by querying remote engines and processing the results. Each modality has its uses and contra-indications. Merging rule sets of partners may not be permitted in cases where there are strong ownership boundaries.

For example, in an insurance adjustment process, the inspection of a damaged vehicle is often performed by independent inspectors. The critical factor in determining how an insurance claim will proceed is whether the damage results in a total loss or whether a repair is feasible:

<pre width=130>
If an inspector believes a vehicle is repairable then process the claim as a repair; otherwise process the claim as a total loss.
</pre>

Determining whether a vehicle is repairable depends on the processes executed by the inspector and therefore cannot be directly integrated into the insurance company's own adjustment process. The insurance company effectively queries the inspector's logic rather than incorporating the inspector's logic into its rule set. Moreover, within the adjustment process, the overall flow will be quite different for repairable claims and total loss claims.

Even in the case of a single company, which is nominally under a common ownership domain, information and business logic are often controlled by multiple stakeholders. For example, a large company will often be organized into semi-independent profit centers (often known as business units). Each unit will be motivated differently, will have different ontologies and business logic, and may use different rule languages to represent their logic. This is particularly the case when one company acquires another company.

RIF could be used to permit the BP designer a unified view of the different partners' business rules in designing the process, while at the same time permitting the partners to continue to leverage their own business rules and their own technologies.

Realizing this sort of unified view of business rules in a deployed BP will depend on both technical and non-technical factors. Even when all parties are required to use a common rule language, there may be compelling ownership issues that mitigate against a simple merge of rule sets. When merging rule sets is not possible, a query-style access to partners' business rules may be used. In this way, RIF permits a unified dynamic view of the business rule logic independent of the rules' original form.

For this to be viable from a business perspective the semantics of the rules and query exchange must be completely predictable and should be loss-less.

'''Not supported, in a straightforward manner, by the current RIF dialects'''

The example business rule in this use case makes explicit reference to belief, which as the discussion below indicates, is not supported by either BLD or PRD (and thus by implication not supported by Core). The reader may note that this business rule could be changed to use another term such as "determine": e.g.,
<pre width=130>
If an inspector determines that a vehicle is repairable then process the claim as a repair; otherwise process the claim as a total loss.
</pre>
Using another term that has a similar semantics --- i.e., indicating in some way the inspector's thought process and mental state --- does not alleviate the problem.

BLD and PRD do not support modal operators or predicates on quoted sentences; therefore standard representations of knowledge, belief, and/or uncertainty cannot be specified in BLD and PRD. Even without such constructs, it can be possible to represent knowledge or belief using the semantics of possible worlds <nowiki>[</nowiki>[[#moore|Moore1980]]]. That is, one can get the effect of saying that an agent A believes proposition P by saying that P holds in all worlds that are belief-accessible to P. For example, to get the effect of saying

<pre width=130>Believe(john,overCreditLimit(bill,t))
</pre>

one says instead

<pre width=130>
holds(overCreditLimit(bill),t1) :- beliefAccessible(john,t,t1)
</pre>

The translation between sentences involve operators such as Know and Believe and sentences that make direct use of possible worlds relies on the possible-worlds semantics, which posits properties on the knowledge-accessibility or belief-accessibility relation. These relations correspond to axioms on the Know and Believe operators.

Such a strategy could work, to a certain extent, in RIF-PRD, but would not work in RIF-BLD. This is because expressing the standard axioms on belief or knowledge would require the use of negation, which is not supported by BLD.

For both PRD and BLD there is an additional consideration, which is that the notion of reification is in general not supported by the dialects of RIF.

</p>
</div></div><div>

=== Managing Inter-Organizational Business Policies and Practices ===

<div><div lang="en" dir="ltr">

This use case concerns organizations that acquire rule sets from external sources and have to integrate these new rule sets into their existing rule bases. Such rule sets may be acquired in the following ways:

* An organization may buy rule sets from expert sources
* An organization may use rule sets from shared interest groups such as trade associations
* A component of a distributed organization may acquire rules when a rule set is distributed across a distributed organization. In such case, there may be different localization requirements in different regions and locations, entailing a variety of integration challenges in these various locations and component organizations.

The following scenario examines these different methods of acquisition and the various types of integration and management issues that may arise.

''This scenario uses the (fictitious) car rental company, EU-Rent, used as the case study in the [http://www.omg.org/spec/SBVR/1.0/ Semantics of Business Vocabulary and Business Rules Specification]. The EU legislation discussed is also fictitious, as are the consulting companies CarWise and AutoLaw.''

EU-Rent's corporate HQ deals with CarWise, a consulting company with expertise in managing fleets of vehicles. One service CarWise offers to its clients is negotiating with EU regulators to clarify regulations.

An EU regulator issues a directive dealing with insurance for vehicles owned by corporations. CarWise agrees with the regulator on an acceptable interpretation, and provides EU-Rent (and its other car rental clients) with two sets of rules:

* A business policy, stating that every car rental must be insured for damages to third parties.
* A supporting rule set, addressing levels of required coverage, tax calculation in different EU countries, liabilities in rentals that span multiple countries, and reporting of compliance with this business policy.

EU-Rent decides that it will maintain its compliance documentation electronically. CarWise then provides EU-Rent with an additional rule set for electronic compliance documentation, including such rules as:

<pre width=130>
Each tax schedule must have electronic signatures from two EU-Rent employees who are at least at the level of manager.
</pre>

Before it can use the two general rule sets, EU-Rent needs to connect them to the relevant data sets in its IT systems, e.g. relate the EU country-specific taxation rules to the relevant record types in its databases.

EU-Rent corporate HQ subsequently decides that the cost of third-party insurance will be built into the basic cost of each rental and not shown as a separate item on the rental contract; this will ensure that it can never be omitted from rentals or disputed by renters. It then sends three rule sets to its operating companies in the EU:

* The rule set for car rental insurance (from CarWise), including the basic policy and the supporting rule set.
* The rule set for electronic compliance documentation (also from CarWise).
* Its own rule set for building insurance into the basic rental cost.

The operating companies then have to localize the rule sets for their countries of operation. For example, in the UK, another consulting company, AutoLaw, advises EU-Rent of rules for placing aggregate insurance for large fleets with more than one insurer in order to spread the risk:

<pre width=130>
For fleets of more than 200 vehicles, fleet insurance policies must be placed with at least 3 insurers, each of whom covers at least 25% of the risk.
</pre>

A timing issue makes it difficult for EU-Rent UK to strictly comply with this directive. EU-Rent UK has some existing insurance policies in place, which provide third-party insurance as an explicit item, and it cannot get refunds on early termination. It therefore asks corporate HQ for a temporary dispensation: that it can continue its existing insurance until it expires, and then switch to the new rules.

EU-Rent HQ permits this, not just for the UK but for any of its operating companies that have similar insurance arrangements. To ensure that this dispensation is temporary, it adds a new rule:

<pre width=130>
Insurance policies that provide separate third-party coverage must not be renewed.
</pre>

EU-Rent HQ is also concerned about meeting deadlines for electronic filing. It introduces a new rule that it distributes to operating companies:

<pre width=130>
Each electronic compliance document must have its required electronic signatures 48 hours before its filing deadline.
</pre>

This rule is meant to be implemented as follows: If '48 hours before its filing deadline' passes, and the electronic signatures are not present, then the operating company's rules system must report the out-of-compliance situation, and subsequently wait for the responsible managers to provide the signatures.

'''Partially supported by RIF-PRD'''

The business rules in this use case express norms which requires the representation of deontic operators for obligations and permissions. Deontic operators are generally represented by modal operators, as in <nowiki>[</nowiki>[[#ref-Horty-deontic-logic|Horty2001]]]. As was discussed above for knowledge and belief, it is not possible to express modal operators directly within RIF dialects. However, one can use the technique discussed above, of reasoning directly within possible worlds. This is possible within PRD though not within BLD or Core.

Moreover, in a meta programming approach it is possible to express deontic reasoning rules with RIF-PRD. Using this approach, too, one would not be able to use BLD or Core, since some business rules express negated deontic norms.

=== Rule set Integration for Medical Decision Support ===

<div><div lang="en" dir="ltr">

Decision support systems aid in the process of human decision making, especially decision making that relies on expertise. Reasoning with rules is an important part of this expert decision making. For complex decision support systems, it is expected that rules will be furnished by a variety of different sources, including ontologies, knowledge bases, and other expert systems. This use case illustrates how RIF makes it possible to merge rule sets from diverse sources in diverse formats into one rule-based system, thereby enabling inferences that might otherwise have remained implicit.

Medical decision support systems, such as the ones discussed below, might use rules from pharmaceutical knowledge bases, laboratory knowledge bases, patient databases, and medical ontologies. For example, a large amount of information on therapeutic medications (drug taxonomies, indications, contraindications, and clearance times) and diseases (disease taxonomies, etiologies, and symptoms) is contained in existing ontologies such as [http://www.snomed.org SNOMED] Clinical Terms®. Rules can be used to express therapeutic recommendations, to formulate queries about relevant prescriptions for a patient, and to assess the effectiveness of a treatment.

The following scenario illustrates how rule-interchange would be used in various medical decision support systems to support the following functionalities:

* Improving situation assessment, e.g., determining when a patient needs to be put on medication, or have his medication switched.
* Prescribing a course of action, e.g., determining which drug is best for a patient in a particular circumstance.
* Improving event planning, e.g., determining whether a patient can be scheduled for a procedure given the medication that he is currently taking.

Bob, 62 years old and reasonably healthy, has been going to his internist, Dr. Rosen, for several years for control of his Type II diabetes. Dr. Rosen has been using the <tt>AutoDoc</tt> system to help him decide when to switch to medications and which drugs to prescribe. The <tt>AutoDoc</tt> system uses two sources when making its recommendations: a laboratory knowledge base giving particular results for patients and specifying when these results are out of normal range, and a pharmaceutical knowledge base giving guidelines for the use of medications. Automated reasoning with rules from these combined sources is possible if the rules are first mapped to RIF. Here are two specific examples of such synergistic effects.

''This scenario discusses the fictitious expert systems <tt>AutoDoc</tt> and MEDIC. In the interest of readability and brevity, the information and rules presented in the following scenario may not precisely capture the current state of medical knowledge and best practices in this field, but may be somewhat simplified.''

Originally Bob's diabetes was controlled through diet and moderate exercise. In time, however, Bob's blood glucose level began to rise, even under this regimen. Due to Bob's elevated <tt>HbA1c</tt> level (which indicates one's average blood sugar level over the last several months), Dr. Rosen prescribed oral medication for Bob. He was forced to change Bob's medication a number of times over the course of a year. He first prescribed Precose, an oral alpha-glucosidase inhibitor, but had to discontinue this medication due to undesired side effects. He then prescribed several sulfonylurea drugs, Micronase and Glucotrol, to no avail. Bob's lab results still indicated an elevated <tt>HbA1c</tt> level. The following rule from the ''laboratory knowledge base'' suggests that Bob's treatment at that time was not effective:

<pre width=130>
If a Type II diabetes patient's current level of HbA1c is high, then the patient's current treatment is considered to be ineffective.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations and an event calculus axiomatization:<br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
Forall ?Patient ?Treatment ?Level ?T (<br />
ex:holdsAt(ex:ineffective(?Patient ?Treatment) ?T) :-<br />
ex:holdsAt(ex:hasDisease(?Patient "diabetesTypeII") ?T)<br />
ex:holdsAt(ex:elevated(levelOf(?Patient "hbA1c" ?Level)) ?T)<br />
ex:holdsAt(ex:treatmentPlan(?Treatment ?Patient) ?T)<br />
)<br />
)<br />
)<br />
</code>
<br />Note, the example requires the formalization of changeable states which can be represented by an event calculus axiomatization. [[#event-calculus|KS86]]] The EC axioms can then be represented using RIF BLD.
</p>

To deal with this problem, Dr. Rosen was about to prescribe Glucophage (metformin, one of the biguanides) 850 mg, 3 times a day, when as usual, he double checked his prescription with the <tt>AutoDoc</tt> system. The system, based on the following guidelines from the ''pharmaceutical knowledge base'', informed Dr. Rosen that he should have prescribed an oral bitherapy (two medications, each of which controls blood sugar levels) instead of a monotherapy.

<pre width=130>
If an oral monotherapy at recommended doses of a sulfonylurea or biguanide, combined with lifestyle changes, is ineffective, then the monotherapy should be replaced by an oral bitherapy.
</pre>

Based on the recommendation from <tt>AutoDoc</tt>, Dr. Rosen switched Bob's prescription to Glucophage and Avandia (rosiglitazone, one of the thiazolidinediones).

Bob recently suffered a concussion and has become increasingly forgetful. He went to see a neurologist, Dr. Cervello, who prescribed a contrast MRI (Magnetic Resonance Imaging). When asked about current medication, Bob told Dr. Cervello that he was taking Glucotrol to control his diabetes, forgetting that he had been switched to Glucophage. This was potentially problematic, since Glucophage should not be taken close to the administration of a contrast injection.

Fortunately, when Bob went to the lab to schedule his MRI, the medical receptionist pulled up MEDIC (Medical Event and Drug Interaction Consultant), the hospital's new automated system, which checks for incompatible medical events and/or drugs (e.g., liposuction scheduled during pregnancy, blood thinners prescribed before surgery, etc.).

MEDIC uses a variety of sources in its reasoning, including:

* the pharmaceutical knowledge base, described above
* the patient databases, which gives the patient record, including the medications a patient is currently taking
* the hospital medical event protocol knowledge base, which details the protocol used for different medical procedures

In this case, MEDIC uses all three sources and pulls up the following information:

* Metformin is contraindicated with contrast dye.
* Metformin is the generic form of Glucophage.
* Bob is taking Glucophage.
* The contrast MRI requires as one of its steps injecting the patient with contrast dye.

MEDIC therefore determines that Bob should not be taking the contrast MRI at this time.

For MEDIC to work, the rules from these different sources must be mapped to a unified interchange format.

'''Supported by RIF-PRD'''

The use case requires the formalization of changeable states (fluents) which can be represented by e.g. an event calculus axiomatization <nowiki>[</nowiki>[[#event-calculus|KS86]]]. However, to formulate the classical event calculus as a set of Horn clause rules so that it could be run as a Prolog program, negation as failure is needed, which is not supported by RIF-BLD or Core.
The use case can be represented in RIF-PRD which supports changeable states (modifications) and assertions and retractions of knowledge.

</div></div></div><div>

=== Interchanging Rule Extensions to OWL ===

<div><div lang="en" dir="ltr">

Rules are often used in conjunction with other declarative knowledge representation formalisms, such as ontology languages (e.g. RDF and OWL), in order to provide greater expressive power than is provided by either formalism alone. Ontology languages, for example, typically provide a richer language for describing classes (unary predicates). Rules, on the other hand, typically provide a richer language for describing dependencies between properties (binary predicates), and may also support higher-arity predicates.

Rich domain models combining both rules and ontologies are often needed in domains such as medicine, biology, e-Science, and Web services. In such domains, several actors and/or agents may need to interchange the data, ontologies, and rules that they work with. An example is the use of such a domain model in an application that aims at assisting the labeling of brain cortex structures in MRI images. In this case, an OWL ontology is used to capture knowledge about the most important brain cortex anatomical structures, and a rule base is used to capture knowledge about mereological and spatial dependencies between properties.

For example, a rule is used to express the dependency between the ontology properties isMAEConnectedTo and isMAEBoundedBy, in particular (a simplified form of) the knowledge that two Material Anatomical Entities having a shared boundary are connected:

<pre width=130>
If MAE X is bounded by Z and MAE Y is also bounded by Z then X is connected to Y.
</pre>

Benefits of interchange via RIF include the ability to collaboratively develop and share valuable knowledge, the ability to integrate anatomical images, possibly from distributed image sources, and the ability to use large-scale federated systems for statistical analysis of brain images of major brain pathologies.

'''Supported by RIF-Core, RIF-BLD and RIF-PRD'''

The use case uses RIF-SWC to combine RIF Rules with OWL ontologies.
</div></div></div><div>

=== Vocabulary Mapping for Data Integration ===

<div><div lang="en" dir="ltr">

This use case concerns the integration of information from multiple data sources. The Semantic Web provides a common data representation and query language, which greatly simplifies access to diverse sources but does not directly address the problem that independent data sources may have rather divergent information models.

Rules are an effective way to express mappings between such information models. However, rules locked within local proprietary systems cannot be reused. With a common rule representation, such mappings can be published across the Semantic Web, enabling an enterprise or community to progressively build up a rich network of mappings unifying the information models.

Information mapping and integration problems like this arise in many diverse domains including health care, travel planning, IT management, and customer information management. The following scenario comes from the world of IT systems management.

Vlad has been given the job of analyzing how exposed his division's business processes are to changes in their IT maintenance contracts. He has three sources of information to combine:

* a report on application services and associated servers, databases, and networks (from the IT department)
* a maintenance contracts database (from the finance department)
* a registry indicating which business processes use which IT services (from the business planning group)

Each of these sources is in a different form but can be mapped into RDF to simplify access. However, they all have different information models. The IT report is too fine-grained: it talks about routers and interface cards while Vlad only needs to identify servers and pick out some generic dependency relations. On the other hand, the finance database models the world in terms of physical assets such as racks, which is too coarse-grained.

First, Vlad creates simple mapping rules to create a uniform, simplified view of the data in terms of a small number of concepts -- Server, Business<tt></tt>Process, and Dependency. This involves rules such as:

<pre width=130>
If x is a ComputeNode in Rack r
and Rack r is in Cage c
and mc is a MaintenanceContract for Cage c
then x is a Server with MaintenanceContract mc

If x is a ComputeNode with a NetworkInterface with Port p
and app is an Application running on Port p
then x is a Server that hosts app

If bp is a BusinessProcess that uses Application app
then bp has a Dependency on app
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF-BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Forall ?X ?MC ?R ?C(
?X[rdf:type->ex:Server ex:maintenanceContract->?MC] :- And(
?X[rdf:type->ex:ComputeNode ex:location->?R] ?R#ex:Rack
?R[ex:location->?C] ?C#ex:Cage
?C[ex:maintenanceContract->?MC] ?MC#ex:MaintenanceContract ))

Forall ?X ?Ni ?P ?App (
?X[rdf:type->ex:Server ex:hosts->?App] :- And(
?X[rdf:type->ex:ComputeNode ex:networkInterface->?Ni]
?Ni[ex:port->?P] ?P#ex:Port
?App[rdf:type->ex:Application ex:onPort->?P]))

Forall ?App ?BP (
?BP[ex:dependsOn->?App] :-
?BP[rdf:type->ex:BusinessProcess ex:processUses->?App] ))
</code>
<br />
</p>

He then creates rules that combine the data across his now simplified data sources, e.g.

<pre width=130>
If bp is a BusinessProcess that has a Dependency on Application app
and x is a Server with MaintenanceContract mc that hosts Application app
then bp has a Dependency on mc
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF-BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Forall ?App ?BP ?App ?MC(
?BP[ex:dependsOn->?MC] :- <
?BP[rdf:type->ex:BusinessProcess ex:dependsOn->?App] ?App#ex:Application
?X[rdf:type->ex:Server ex:hosts->?App ex:maintenanceContract->?MC] ))
</code>
<br />
</p>

This gives him a uniform view that links from business processes through to the IT and finance data. Vlad publishes these rules so that other people across the company can reuse them to construct similar views.

'''Supported by RIF-BLD, RID-PRD, and RIF-Core'''

</div></div></div><div>

=== BPEL Orchestration of Rule-Based Web Services ===

<div><div lang="en" dir="ltr">

Rule-based Web services depend on the use of XML data for their request and response format. The involved rules must be able to access and compare XML data in their conditions and modify and generate XML data in their actions.

An existing commercial credit approval service deployed as a Web service takes an applicant credit request document as input and returns an approval or denial (with reason). It is implemented as a BPEL orchestration of two Web services -- a credit history providing service and a decision service containing a rules engine. BPEL first passes the credit request document to the decision service to determine, using rules, whether enough information (Social Security number, mother's maiden name, etc.) is available to request a credit history. If so, BPEL then requests a credit history from the history providing service and passes the credit history document to the decision service to be evaluated. Based on the evaluation, credit is approved or denied.

Because the rule engine is part of a Web service, existing BPEL diagramming and execution facilities can be used to integrate rules into this credit approval service. The credit evaluation model can be changed easily using GUI tools to customize rules. Using RIF would further improve the situation. First, the credit history vendor could supply a default set of rules for evaluating its histories. Second, there would be several rule editing and customization tools from different RIF-compatible vendors to tailor the rules to meet specific business objectives.

The credit evaluation rules are themselves grouped into three rule sets that are executed sequentially. Rules in the first rule set apply thresholds to several "red flag" quantities in the credit report, such as:

* number of times a payment was 60 days late
* debt-to-income ratio
* number of foreclosures or repossessions
* number of garnishments
* number of liens
* bankruptcy

A red flag above the threshold results in denial of credit.

Rules in the second rule set increment a credit score variable. For example:

<pre width=130>
If applicant owns residence then add 40.
If applicant rents then add 30.
If applicant has lived at current address 2 to 4 years then add 20.
If applicant's income is under 20000 then add 10.
If applicant's income is between 40000 and 50000 then add 40.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;">Document(<br />
<br />
Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(prolog_func <nowiki>http:</nowiki>//example.org/2007/rif-prolog-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
ex:score(0)<br />
<br />
ex:score(?Applicant ?Score) :-<br />
ex:increment(?Applicant)<br />
ex:score(?Score)<br />
prolog_func:retract(ex:score(?Score))<br />
prolog_func:assert(ex:score(0)). <br />
<br />
ex:increment(?Applicant) :- <br />
ex:owns(?Applicant)<br />
ex:score(?Score)<br />
prolog_func:retract(ex:score(?Score))<br />
?NewScore = ?Score + 40<br />
prolog_func:assert(ex:score(?NewScore)).<br />
<br />
ex:increment(?Applicant):- <br />
ex:rents(?Applicant)<br />
ex:score(?Score)<br />
ex:retract(score(?Score))<br />
?NewScore = ?Score + 30<br />
prolog_func:assert(score(?NewScore)).<br />
<br />
ex:increment(?Applicant):-<br />
ex:lives(?Applicant ?Date),<br />
$sysTime(?CurrentDateTime)<br />
?CurrentYear = $fn:year-from-dateTime(?CurrentDateTime)<br />
?Year = $fn:year-from-dateTime(?Date)<br />
?Diff = ?CurrentYear - ?Year<br />
?Diff > 1<br />
?Diff < 5<br />
ex:score(?Score)<br />
prolog_func:retract(score(?Score))<br />
?NewScore = ?Score + 20<br />
prolog_func:assert(ex:score(?NewScore)).<br />
<br />
ex:increment(?Applicant):- <br />
ex:income(?Applicant ?Income)<br />
?Income < 20000<br />
ex:score(?Score)<br />
prolog_func:retract(score(?Score))<br />
?NewScore = ?Score + 10<br />
prolog_func:assert(ex:score(?NewScore)).<br />
<br />
ex:increment(?Applicant):-<br />
ex:income(?Applicant ?Income)<br />
?Income < 50000<br />
?Income > 40000<br />
ex:score(?Score)<br />
prolog_func:retract(ex:score(?Score))<br />
?NewScore = ?Score + 40<br />
prolog_func:assert(ex:score(?NewScore)).<br />
</code>
<br />A goal-driven solution which makes use of assert and retract (not supported by BLD) to update a global score value, which is stored in a fact.
</p>

The third and final rule set compares the applicant's credit score and income to threshold values, and makes the final decision to approve or deny credit to the applicant.

The decision and supporting rationale is returned from the decision service as an XML document. This decision document is then used to construct the reply to the original credit approval request.

'''Supported by RIF-PRD'''

This use case requires a goal-driven solution which makes use of assert and retract to update a global score value. Assert and retract are not supported by BLD or Core; indeed, there is no such similar notion within BLD or Core.

</div></div></div><div>

=== Publishing Rules for Interlinked Metadata ===

<div><div lang="en" dir="ltr">

The Semantic Web includes technologies (e.g., RDF) that allow metadata to be published in machine-readable form. Currently, this information is mostly enumerated as a set of facts. It is often desirable, however, to supplement such facts with rules that ''capture implicit knowledge''. To maximize the usefulness of such published rules, a standard rule format such as RIF is necessary.

One case involves extending current standards for metadata publication with rules in order to express implicit knowledge. Suppose that the International Movie Database (IMD) publishes its metadata and rules in a machine readable format at <nowiki>http://</nowiki>imd.example.org. Besides the ground facts, which can be expressed in RDF, the metadata might also have general rules like the following:

<pre width=130>
Every science fiction movie is a movie.
Every movie produced before 1930 is black and white.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD (Abridged) Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> ?Movie#ex:Movie :-<br />
?Movie#ex:ScienceFictionMovie.<br />
<br />
?Movie#ex:BlackWhiteMovie :-<br />
?Movie#ex:Movie[ex:date -> ?Date]<br />
?Date < "1930"^^xs:dateTime.<br />
</code>
<br />
</p>

Such rules allow data to be published more concisely by expressing knowledge that, without these rules, is implicit. This can greatly simplify the maintenance of data, guard against inadvertently introduced inconsistencies, and reduce storage requirements.

Published rules also allow combining data from different sources to exploit this knowledge. Consider an alternative database of movies published at <nowiki>http://</nowiki>altmd.example.org. In addition to metadata, it again publishes its own rules:

<pre width=130>
All movies listed at <nowiki>http://</nowiki>altmd.example.org but not listed at <nowiki>http://</nowiki>imd.example.org are independent movies.
All movies with budgets below 5 million USD are low-budget movies.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD (Abridged) Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> ?Movie#ex:IndependentMovie :-<br />
listed(?Movie#ex:Movie,<<nowiki>http:</nowiki>//altmd.example.org>)<br />
not(listed(?Movie#ex:Movie,<<nowiki>http:</nowiki>//imd.example.org>)). <br />
<br />
?Movie#ex:LowBudgetMovie :-<br />
?Movie#ex:Movie [date -> ?Date, budget -> ?Budget]<br />
?Budget < 5000000^^xs:long.<br />
</code>
<br />
</p>

Publication of rules with explicit references to other rule sets allows the definition of knowledge dependent on explicitly specified remote sources. Such explicitly specified ''scope'' is important in the Web environment, since it can reduce the danger of unintended interference from rules published at other remote sources, which may be exporting their own predicates.

Another example of such explicit referencing, which also illustrates implicit person-centric metadata, involves published rules being used to specify how to use other metadata, e.g. in the form of a widespread vocabulary such as FOAF or a standard exchange format like iCalendar. For example, FOAF user Charlie might choose to complement his normal FOAF profile with his preferences about which of his phone numbers should be used depending on his iCalendar schedule:

<pre width=130>
If Charlie is currently attending a public talk according to <nowiki>http://</nowiki>charlie.example.org/calender.ical
then leave him a voicemail message

If Charlie is currently in a meeting according to <nowiki>http://</nowiki>charlie.example.org/calender.ical
and the importance is high
then call his cell number

If Charlie currently has no appointments according to <nowiki>http://</nowiki>charlie.example.org/calender.ical
then call his office number
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD (Abridged) Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> contactInfo("Charlie" ?ContactInfo) :-<br />
sysTime(?Time)<br />
attending("Charlie" "talk" ?Time)<br />
contact("Charlie" "voicemail" ?ContactInfo).<br />
<br />
contactInfo("Charlie" ?ContactInfo) :-<br />
sysTime(?Time)<br />
attending("Charlie" "meeting" ?Time)<br />
contact("Charlie" "cell number" ?ContactInfo).<br />
<br />
contactInfo("Charlie", ?ContactInfo) :-<br />
sysTime(?Time),<br />
not(attending("Charlie",?Event, ?Time)),<br />
contact("Charlie", "office number", ?ContactInfo).<br />
<br />
<br />
sysTime(?Time) :-<br />
% get the actual system time e.g. via a built-in<br />
% or procedural attachment call to Java or C++.<br />
?Time = External(call(java.util.Calendar().getInstance())).<br />
<br />
<br />
attending("Charlie","talk", ?CurrentTime) :-<br />
% getEventData would implement the functionality to dynamically access and query<br />
% <nowiki>http:</nowiki>//charlie.example.org/calender.ical<br />
getEventData(<<nowiki>http:</nowiki>//charlie.example.org/calender.ical>,?EventTitle,?Type,?StartDate,?EndDate),<br />
?Type = "talk",<br />
External(op:dateTime-less-than(?CurrentTime,?EndDate),<br />
External(op:dateTime-greater-than(?CurrentTime,?StartDate).<br />
<br />
<br />
attending("Charlie","meeting", ?CurrentTime) :-<br />
getEventData(<<nowiki>http:</nowiki>//charlie.example.org/calender.ical>,?EventTitle,?Type,?StartDate,?EndDate),<br />
?Type = "meeting",<br />
External(op:dateTime-less-than(?CurrentTime,?EndDate),<br />
External(op:dateTime-greater-than(?CurrentTime,?StartDate).<br />
<br />
<br />
<br />
contact("Charlie", "voicemail", ?ContactInfo) :-<br />
% retrieve the Voice mail number, e.g. from<br />
% Charlie's vCard, <br />
% e.g. xmlns:vCard = "<nowiki>http://www.w3.org/2001/vcard-rdf/3.0#"</nowiki><br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard:FN> -> "Charlie"],<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard_TEL> -> ?Telephone],<br />
?Telephone[<rdf:type> -> <nowiki><http://www.w3.org/2001/vcard-rdf/3.0#voice></nowiki>],<br />
?Telephone[<rdf_value> -> ?ContactInfo].<br />
<br />
contact("Charlie", "cell number", ?ContactInfo) :-<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard:FN> -> "Charlie"],<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard_TEL> -> ?Telephone],<br />
?Telephone[<rdf:type> -> <nowiki><http://www.w3.org/2001/vcard-rdf/3.0#cell></nowiki>],<br />
?Telephone[<rdf_value> -> ?ContactInfo].<br />
<br />
contact("Charlie", "office number", ?ContactInfo) :-<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard:FN> -> "Charlie"],<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard_TEL> -> ?Telephone],<br />
?Telephone[<rdf:type> -> <nowiki><http://www.w3.org/2001/vcard-rdf/3.0#work></nowiki>],<br />
?Telephone[<rdf_value> -> ?ContactInfo]. <br />
</code>
<br />
</p>

RIF should allow extending current standards for metadata publication by enabling such implicit knowledge to be captured via rules and allowing metadata and rules distributed over different sources to be interlinked. In a manner similar to how HTML links human-readable Web pages, RIF should permit linking metadata on the Web to support new kinds of "intelligent" crawling and search.

'''Supported by RIF-PRD'''

Since negation is not supported by RIF-BLD or RIF-Core it is not possible to express ''... but not listed at ...''.

</div></div></div></div><div>

== Conclusion ==

<div><div lang="en" dir="ltr">

The goal of the RIF working group is to provide representational interchange formats for processes based on the use of rules and rule-based systems. These formats act as interlingua to interchange rules and integrate with other languages, in particular (Semantic) Web mark-up languages.

As can be seen by studying the use-cases presented in this document, rules are used to perform a wide variety of tasks, and therefore rule-based systems are not monolithic. Rules have been used, for example, to perform and validate inference, perform calculations, direct the flow of information, enforce integrity constraints on databases, represent and enforce policies, control devices and processes in real time, and determine the need for human intervention.

In light of this diversity, rather than being a single all-encompassing format, RIF consists of several dialects, each dialect serving a particular set of related rule languages. The key idea is to attain the goal of interoperability (via interchange of RIF rules) ''within'' each dialect. This should allow the main benefits of RIF to be realized.

RIF has been designed in such a way that it is possible to create new dialects (extensibility) according to the overall goals and the general requirements of RIF, as well as to update existing dialects (upwardly compatible). This is in keeping with the working group charter's call for an extensible format.

</div></div></div>

</div><div>

== References ==

; [Horty2001]
: ''Agency and Deontic Logic'', John F. Horty, Oxford University Press, 2001.

<span id="event-calculus" class="anchor"></span>
; [KS86]
: Kowalski, R.A. and M.J. Sergot, ''A logic-based calculus of events.'' New Generation Computing, 1986. 4: p. 67-95.

<span id="moore" class="anchor"></span>
; [Moore80]
: Moore, R.C., ''Reasoning about Knowledge and Action,'' SRI TR-191, 1980.

<span id="ref-owl-reference"></span>
; [OWL-Reference]
: ''OWL Web Ontology Language Reference'', M. Dean, G. Schreiber, Editors, W3C Recommendation, 10 February 2004. Latest version available at http://www.w3.org/TR/owl-ref/.
<span id="ref-Horty-deontic-logic" class="anchor"></span>

<span id="ref-rif-bld" class="anchor"></span>
; [RIF-BLD]
: ''RIF Basic Logic Dialect'', Boley H. and Kifer M. (Editors), W3C Rule Interchange Format Working Group Draft. Latest Version available at http://www.w3.org/2005/rules/wiki/BLD.

<span id="ref-rif-core" class="anchor"></span>
; [RIF-Core]
: ''RIF Core Dialect'', Harold Boley, Gary Hallmark, Michael Kifer, Adrian Paschke, Axel Polleres and Dave Reynolds (Editors), W3C Rule Interchange Format Working Group Draft. Latest Version available at http://www.w3.org/2005/rules/wiki/Core.

<span id="ref-rif-prd" class="anchor"></span>
; [RIF-PRD]
: ''RIF Production Rule Dialect'', de Sainte Marie C., Paschke A., and Hallmark G. (Editors), W3C Rule Interchange Format Working Group Draft. Latest Version available at http://www.w3.org/2005/rules/wiki/PRD.

</div></div></div>

<div>

== Appendix: Change Log (Informative) ==

<div><div lang="en" dir="ltr">

This appendix summarizes the main changes to this document since its publication as a Working Draft.

Changes since the [http://www.w3.org/TR/rif-ucr/ draft of December 18th, 2008]:
* [[#Structure_of_RIF|the section describing the structure of RIF]] has been updated with newer RIF documents;
* all code examples have been removed from the document;
* each use case concludes by indicating the support of the use case by the current RIF dialects Core, BLD, and PRD. In addition, a brief discussion of the features of the use case that may affect a dialect's support for that use case is sometimes included;
* an informative change log section has been added;
* the distinction between general and basic requirements has been removed, thereby flattening the list of requirements.

</div></div></div></div>

XML-Data

Sandro — Mon, 04 Feb 2013 16:36:59 GMT

Sandro: added changelog id, needed for SOTD

__NUMBEREDHEADINGS__
{{TR|title=RIF Combination with XML data}}
<div id='editors'>
; Editors:
: Christian de Sainte Marie, IBM
</div>
; Abstract
: <div id='abstract'><p></p> <p></p> <p></p> <p>This document, developed by the [http://www.w3.org/2005/rules/wiki/RIF_Working_Group Rule Interchange Format (RIF) Working Group], specifies how a RIF document can be combined with XML data. </p> <p></p></div>
; Status of this Document
: @@update This is an automatically generated Mediawiki page, made from some sort of W3C-style spec.

[http://www.w3.org/Consortium/Legal/ipr-notice#Copyright Copyright] © 2009 [http://www.w3.org/ W3C]<sup>®</sup> ([http://www.csail.mit.edu/ MIT], [http://www.ercim.eu/ ERCIM], [http://www.keio.ac.jp/ Keio]), All Rights Reserved. W3C [http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer liability], [http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks trademark] and [http://www.w3.org/Consortium/Legal/copyright-documents document use] rules apply.

<div id='docbody'>

<span id="sec-overview" class="anchor"></span>

== Overview ==

The Rule Interchange Format (RIF) is a format for interchanging rules over the Web. Rules that are exchanged using RIF may refer to external data sources and may be based on data models that are represented using a language different from RIF. This document specifies how combinations of RIF documents and XML data, possibly associated with XML schemas, are interpreted.

Extensible Markup Language (XML) is a simple, flexible text format derived from SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere. The XML Schema Definition Language offers facilities for describing the structure and constraining the contents of XML documents. The schema language, which is itself represented in an XML vocabulary, provides a way to describe and to share the data model that is associated with the data in an XML document.

This document specifies a standard semantics for combinations of RIF documents and XML data, with or without an associated XML schema. The specification relies on the abstract XQuery 1.0 and XPath 2.0 Data Model <nowiki>[</nowiki>[[#ref-xdm|XDM]]] to specify what information is accessible in the data, and on XPath 2.0 expressions <nowiki>[</nowiki>[[#ref-xpath-20|XPath 2.0]]] to select pieces of that information. It relies on XML Schema Component Designators <nowiki>[</nowiki>[[#ref-xsd-cd|XSD-CD]]] expressions to provide unambiguous designators for XML schema types and schema elements in combinations where the XML data is associated with an XML schema.

[[#ref-xpath-20|XPath 2.0]] is a non-XML expression language that allows the processing of values conforming to the data model defined in <nowiki>[</nowiki>[[#ref-xdm|XDM]]]. The result of an XPath expression may be a selection of nodes from the input data model, or an atomic value, or more generally, any sequence allowed by the data model. The name of the language derives from its most distinctive feature, the path expression, which provides a means of hierarchic addressing of the nodes in an XML tree.

[[#ref-xsd-cd|XML Schema Component Designators]] (XSD-CD) is a non-XML expression language that provides reliable and unambiguous designators for XML schema components. The specification divides the problem of constructing schema component designators into two parts: defining a designator for an assembled schema, and defining a designator for a particular schema component or schema components, understood relative to a designated schema. This specification uses only a limited subset of the schema component path expression language, from the second part.

According to this specification, XPath and component designator expressions are represented as string constants in RIF formulas. Although the semantics of RIF and XML data combinations is specified with respect to any valid [[#ref-xpath-20|XPath 2.0]] expression, conforming implementations are required to support only a limited subset. Future versions of this specification may extend that subset.

The [[#ref-xdm|XQuery 1.0 and XPath 2.0 Data Model]] (XDM) is based on the ''infoset'' <nowiki>[</nowiki>[[#ref-infoset|Infoset]]], possibly augmented with information resulting from the validation of the XML data against an XML schema, or ''post-schema validation infoset'' (PSVI), according to the specification W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures <nowiki>[</nowiki>[[#ref-xsd11-1|XSD 1.1 Part 1]]]. An instance of the data model can also be constructed directly through application APIs, or from non-XML sources such as relational tables in a database. The semantics for the combination of RIF documents with XML data applies, therefore, to the combination of RIF documents with non-XML data as well, where the XML binding of the data is only used to refer to it in the interchanged rules. This is likely to be of particular interest when an XML schema is interchanged along with the RIF document.

Like the [[#ref-xdm|XQuery 1.0 and XPath 2.0 Data Model]], the semantics of combinations of RIF documents and XML data that is specified in this document supports the following classes of XML data:
* Well-formed documents conforming to [Namespaces in XML] or [Namespaces in XML 1.1].
* DTD-valid documents conforming to [Namespaces in XML] or [Namespaces in XML 1.1], and
* W3C XML Schema-validated documents.

Accordingly, this document specifies how a RIF document is combined with well-formed -- and, where an XML schema is specified, schema-valid -- XML documents. The semantics is independent on the provenance of the XML data in a combination: it can be imported explicitly in a RIF document, or combined on the consumer-side, or a combination of both. However, only XML schemas that are explicitly imported in the RIF document are taken into account for the interpretation of the combination. This provides a way to communicate the data model that is intended, in a RIF document, for the data source, without specifying an actual data source.

Section 2 specifies a normative standard semantics for RIF combinations with XML data: first, an XPath 2.0 and XSD-CD based syntax is specified, that is used to relate RIF formulas to XML data items in a combinations (section 2.1). Then, a model-theoretics semantics is given to RIF BLD combination with XML data, with and without associated XML schema (section 2.2); the operational semantics of RIF PRD combinations with XML data is, then, defined, based on the definition of a RIF BLD+XML data combined interpretation (section 2.3); finally, the semantics of RIF Core combinations with XML data is defined with respect to the model-theoretic semantics of the combination of RIF BLD and XML data and the operational semantics of the combination of RIF PRD and XML data (section 2.4).

Section 3 specifies how the <tt>rif:Import</tt> directive is extended to support the import of XML data and XML schemas in a RIF document.



Combination with XML data and/or schema constrains the interpretation of RIF formulas and give them special semantics. As a result, the semantics of RIF when XML data and schema is imported is not the same as the semantics of RIF alone, even if the imported XML data and schema are empty.

Section 4 specifies the conformance criteria for this specification.

Implementation of this specification requires a good understanding of [[#ref-xpath-20|XPath 2.0]] and the [[#ref-xdm|XQuery 1.0 and XPath 2.0 Data Model]]. However, this document can be read and understood without a deep knowledge of these two specifications. For the convenience of the reader, the definition of terms from the [[#ref-xpath-20|XPath 2.0]], [[#ref-xsd-cd|XSD-CD]] and the [[#ref-xdm|XDM]] specifications, that are of particular importance for this document, are repeated in the [[#appendix-glossary|Appendix A: Glossary]]. However, the definition in the glossary are non-normative: the only normative definitions are as specified in the <nowiki>[</nowiki>[[#ref-xpath-20|XPath 2.0]]] and the <nowiki>[</nowiki>[[#ref-xdm|XDM]]] recommendations, and in the [[#ref-xsd-cd|XSD-CD]] specification.
Such terms are shown in square bracket, with a superscript indicating ''XP'' if the term is defined in [[#ref-xpath-20|XPath 2.0]]: [thus]<sup><small>XP</small></sup>; or with a superscript indicating ''XDM'' if the term is defined in [[#ref-xdm|XDM]]: [thus]<sup><small>XDM</small></sup>; or with a superscript indicating ''CD'' if the term is defined in [[#ref-xsd-cd|XSD-CD]]: [thus]<sup><small>CD</small></sup>.

This document follows the convention used in other RIF specifications, to start definition with: '''Definition''' and end them with the symbol ☐. In the same way, examples start with: '''Example''' and end with ☐. The end symbol may be omitted if the definition or example ends with the section.

Several prefixes are used throughout this document for notational convenience. The following bindings are assumed.

# <tt>rif</tt> bound to <tt><nowiki>http://www.w3.org/2007/rif</nowiki></tt>
# <tt>xs</tt> bound to <tt><nowiki>http://www.w3.org/2001/XMLSchema</nowiki></tt>
# <tt>xml</tt> bound to <tt><nowiki>http://www.w3.org/XML/1998/namespace</nowiki></tt>
# <tt>fn</tt> bound to <tt><nowiki>http://www.w3.org/2005/xpath-functions</nowiki></tt>
# <tt>pred</tt> bound to <tt><nowiki>http://www.w3.org/2007/rif-builtin-predicate</nowiki></tt>
# <tt>func</tt> bound to <tt><nowiki>http://www.w3.org/2007/rif-builtin-function</nowiki></tt>
# <tt>xscd</tt> bound to <tt><nowiki>http://www.w3.org/2009/xmlschema-ref</nowiki></tt>

<span id="sec-combination" class="anchor"></span>

== RIF combination with XML data ==

This section specifies the normative semantics of the combination of RIF formulas and XML data, for RIF Core, RIF PRD and RIF BLD, where the XML data may be associated with an XML schema.

<span id="def-rif+xml-data-combination" class="anchor"></span>
'''Definition (RIF+XML data combination).''' A '''''RIF+XML data combination''''' is a triple <''R'', ''E'', ''S''>, where ''R'' is a RIF formula (document or non-document), ''E'' is a, possibly empty, set of data model [nodes]<sup><small>XDM</small></sup> that contains the information that is represented in the XML data, and ''S'' is a, possibly empty, set of XML schema definitions.  ☐

For the purpose of evaluating the XPath 2.0 expressions that are used, in ''R'', to access the XML data that is represented in ''E'', the [in-scope schema definitions]<sup><small>XP</small></sup> are the schema definitions in ''S'' and all their components.

This specification does not describe or prescribe how the set of data model [nodes]<sup><small>XDM</small></sup>, in a RIF+XML data combination, is obtained: it may result from parsing one or more XML documents and/or validating them against one or more XML schemas, or it may be created by methods other than parsing and/or schema-validating XML documents.

However, in a RIF+XML data combination <''R, E, S''>, any information item in ''E'' that represents an instance of a schema definition that is an element of ''S'' or a component in an element of ''S'', must be valid with respect to that schema definition.

This specification does not prescribe the behaviour of a conformant implementation when the set of data model [nodes]<sup><small>XDM</small></sup> in a RIF+XML data combination does not satisfy the above validity constraint, or any relevant constraint from the XPath 2.0, XDM or XSD-CD specifications.

=== Syntax ===

This section addresses how a RIF formula interacts with the XML data, in a RIF+XML data combination; that is, this section specifies how the access to XML data, and to XML schema information, if available, is represented in RIF formulas, for the purpose of combining them.

The basic idea is that the object-attribute-value semantics of RIF frame formulas is used, in the combination of RIF formulas and XML data, to exploit the intended semantics of the relation between a [context node]<sup><small>XP</small></sup>, an XPath 2.0 expression and the sequence that the expression matches in the context of the node: in the context of a RIF+XML data combination <''R, E, S''>, frame formulas of the form <tt>object["''some XPath expression''"->val]</tt>, where the <tt>object</tt> term is interpreted as an data model [node]<sup><small>XDM</small></sup> in ''E'', mean that <tt>val</tt> can be derived, in a way to be specified in this document, from the sequence of items that the XPath expression matches in the context of the node denoted by <tt>object</tt>.

This document specifies the semantics of RIF+XML data combinations, in general terms, for any valid XPath 2.0 expression. But some of the details are specified normatively for a limited subset of XPath 2.0 expressions only. Namely, conforming implementations must support the XPath 2.0 expressions specified by the following EBNF grammar:
RIFexpr ::= StepExpr | ValueExpr | AbbreviatedExpr
AbbreviatedExpr ::= ElementName | '@' AttributeName
ValueExpr ::= 'fn:data(' ( StepExpr | '.' ) ')'
StepExpr ::= StepAxis ( NameTest | KindTest ) ('[' Position ']')?
StepAxis ::= 'self::' | 'child::' | 'attribute::'
NameTest ::= ElementName | AttributeName
KindTest ::= ElementTest
| AttributeTest
| SchemaElementTest
| SchemaAttributeTest
ElementTest ::= 'element' '(' (ElementNameOrWildcard (',' TypeName '?'?)?)? ')'
SchemaElementTest ::= 'schema-element' '(' ElementDeclaration ')'
ElementDeclaration ::= ElementName
AttributeTest ::= 'attribute' '(' (AttribNameOrWildcard (',' TypeName)?)? ')'
SchemaAttributeTest ::= 'schema-attribute' '(' AttributeDeclaration ')'
AttributeDeclaration ::= AttributeName
ElementNameOrWildcard ::= ElementName | '*'
ElementName ::= QName
AttribNameOrWildcard ::= AttributeName | '*'
AttributeName ::= QName
TypeName ::= QName
Position ::= [1..9] [0..9]*

Future versions of this specification may extend that subset.

XPath expressions are represented in RIF as <tt>xs:string</tt> constants.

{{EdNote|text=Alternatively, an additional symbol space, <tt>rif:xpath</tt>, could be added to [[#ref-dtb|RIF built-in data types]]: in that case, XPath expressions would be represented as <tt>rif:xpath</tt> constants.}}

XPath 2.0 unabbreviated syntax must be used in the normative RIF/XML syntax, except when the expression is a simple <tt>StepExpr</tt> and the test is a <tt>NameTest</tt>: in that case, the abbreviated syntax must be used in the normative RIF/XML syntax.

Both syntaxes, abbreviated and unabbreviated, are allowed in the non-normative RIF presentation syntax.

When a string constant is evaluated as an XPath expression, the [statically known namespaces]<sup><small>XP</small></sup> are the in-scope namespaces for the containing element in the RIF formula.

Likewise, the object-class and subclass-superclass semantics of RIF member and subclass formulas is used to exploit the intended semantics of the relation between an XML element and its XML schema type, and of the relation between two XML schema types, when information on classes and types definitions is available from imported XML schemas. RIF member formulas of the form: <tt>object #  "''an XSD-CD component path expression''"</tt>, where the <tt>object</tt> term is interpreted as a element [node]<sup><small>XDM</small></sup> ''e ∈ E'', mean that the XML fragment represented by ''e'' satisfies the XML schema definition designated by the XSD-CD component path expression.

In the same way, subclass expressions of the form: <tt>"''sub''" ## "''SUP''"</tt> where, both, <tt>"''sub''"</tt> and <tt>"''SUP''"</tt> are XSD-CD schema component path expressions, mean that the schema types ''T<sub>sub</sub>'' and ''T<sub>SUP</sub>'', whose definitions are designated by the XSD-CD expressions <tt>"''sub''"</tt> and <tt>"''SUP''"</tt>, respectively, satisfy ''[derived-from]<sup><small>XP</small></sup>(T<sub>sub</sub>, T<sub>SUP</sub>)'', where the pseudo-function ''derives-from'' is defined as in [[#ref-xpath-20|XPath 2.0, section 2.5.4 - Sequence type matching]].

This specification specifies the semantics of RIF+XML data combinations that contains such member or subclass formulas for a limited subset of XSD-CD expressions, only. Namely, conforming implementations must support absolute XSD-CD expressions that designate schema types, as specified by the following EBNF grammar:

<span id="def-RIFSchemaComponentPath" class="anchor"></span>

RIFSchemaComponentPath ::= StepSepator RelativeSchemaComponentPath
RelativeSchemaComponentPath ::= Step (StepSeparator RelativeSchemaComponentPath)?
StepSeparator ::= '/'
Step ::= AbbrevStep
AbbrevStep ::= AbbrevElementStep | AbbrevTypeStep
AbbrevElementStep ::= NameTest
AbbrevTypeStep ::= '~' NameTest
NameTest ::= QName | '0'

XSD-CD component path expressions are represented in RIF as <tt>xs:string</tt> constants.

{{EdNote|text=Alternatively, an additional symbol space, <tt>rif:xsd-cd</tt>, could be added to [[#ref-dtb|RIF built-in data types]]: in that case, XSD-CD expressions would be represented as <tt>rif:xsd-cd</tt> constants.}}

XSD-CD abbreviated syntax must be used in the normative RIF/XML syntax. Both abbreviated and unabbreviated syntaxes are allowed in the non-normative RIF presentation syntax.



For the purpose of expanding QNames in <tt>NameTest</tt>s, the in-scope namespace bindings are defined as all the namespace declaration in the scope of which the string is.



<span id="ex21" class="anchor"></span>
'''Example 2.1.''' Consider, for instance, the following rule, that says that an ''EarlyCustomer'' is a ''Customer'' whose ''Account'' number is lower than 1000 (using the RIF presentation syntax and XPath abbreviated syntax):
Forall ?x, ?y
(_EarlyCustomer(?y) :-
And( ?x["ex:Name" -> ?y]
Exists ?z (And ?x["ex:Account" -> ?z]
External(pred:numeric-less-or-equal(External(xs:integer(?z)) 1000)))))

Consider, further, the following XML fragment, representing data about customers:

<CustomerTable xmlns="<nowiki>http://example.org/customertable</nowiki>"
xmlns:xml="<nowiki>http://www.w3.org/XML/1998/namespace</nowiki>">
<Customer xml:lang="en">
<Name> John </Name>
<Account> 111 </Account>
</Customer>
<Customer xml:lang="fr">
<Name> Jane </Name>
<Account> 222 </Account>
<PIN> 222 </PIN>
</Customer>
</CustomerTable>

Assuming, like in all further examples, that the pair ''(<tt>ex</tt>, <tt><<nowiki>http://example.org/customertable</nowiki>></tt>)'' belongs to the statically known namespaces when the XPath expressions are evaluated, the combination, under the semantics described below, of the above rule and XML data, with no associated XML schema, will entail two new facts, namely:
_EarlyCustomer("John")
_EarlyCustomer("Jane")

This rule shows how an XPath expression is used, in the rule, as an <tt>xs:string</tt> constant, e.g.: <tt>"ex:Name"</tt> or <tt>"ex:Account"</tt>, to access the children of an element [node]<sup><small>XDM</small></sup> as frame slots.

Notice that, in the absence of classes and types definitions as would be provided by an associated XML schema, <tt>NameTest</tt> are enough to exploit all the information that is avalable in the XML data, in the combination. Notice further that, with no typing information available, atomic values retrieved from the XML data can only be interpreted as strings. A consequence is that such values have to be cast into the required types when used as arguments to RIF buit-in functions and predicates.

Notice, also, that, for the same reason, member (or subclass) formulas cannot be used in combination with the XML data: the only way (based only on the information that is available in the example) to ensure that only the <tt>ex:Name</tt> and <tt>ex:Account</tt> sub-elements of <tt>ex:Customer</tt> elements are taken into account would be to add a frame formula to the condition, to check that the variable <tt>?x</tt> is bound to an element that is, itself, named <tt>ex:Customer"</tt>:
Forall ?x, ?y
(_EarlyCustomer(?y) :-
And( ?x["ex:Name" -> ?y]
?x["self::ex:Customer"->?x]
Exists ?z (And ?x["ex:Account" -> ?z]
External(pred:numeric-less-or-equal(External(xs:integer(?z)) 1000)))))

Notice that, in the absence of an XML schema against which the data must be valid, the fact <tt>?x["self::ex:Customer"->?x]</tt> does not entail anything with respect to other properties of <tt>?x</tt>.

Now, assume that the following XML schema is associated with the above XML fragment:

<xs:schema xmlns:xs="<nowiki>http://www.w3.org/2001/XMLSchema</nowiki>"
xmlns:xml="<nowiki>http://www.w3.org/XML/1998/namespace</nowiki>"
targetNamespace="<nowiki><nowiki>http://</nowiki>example.org/customertable</nowiki>"
xmlns="<nowiki><nowiki>http://</nowiki>example.org/customertable</nowiki>">

<xs:simpleType name="PIN">
<xs:restriction base="xs:integer">
<xs:minInclusive value="100"/>
<xs:maxExclusive value="1000"/>
</xs:restriction>
</xs:simpleType>

<xs:element name="Name" type="xs:string"/>
<xs:element name="Account" type="xs:integer"/>
<xs:element name="PIN" type="PIN"/>

<xs:element name="Customer">
<xs:complexType>
<xs:sequence>
<xs:element ref="Name"/>
<xs:element ref="Account"/>
<xs:element ref="PIN" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:attribute ref="xml:lang"/>
</xs:element>

<xs:element name="CustomerTable">
<xs:complexType>
<xs:all>
<xs:element ref="Customer" minOccurs="0"/>
</xs:all>
</xs:complexType>
</xs:element>

</xs:schema>

When the XML schema is associated with the data, in the RIF+XML data combination, typing information can be taken into account, both, to focus on the data that represent customer information (that is, information represented in <tt>ex:Customer</tt> elements), and to ensure that arguments to built-in functions and predicates are properly typed. The example rule could, then, be written as follows (notice that this version of the rule uses unabbreviated XPath syntax):

Forall ?x, ?y
(_EarlyCustomer(?y) :-
And( ?x # "/ex:Customer"
?x["child::schema-element(ex:Name)" -> ?y]
Exists ?z (And ?x["child::schema-element(ex:Account)" -> ?z]
External(pred:numeric-less-or-equal(?z 1000)))))

In that case, the assertion of the class membership: <tt>?x # "/ex:Customer"</tt>, entails that <tt>?x</tt> has all the properties that are required to validate against the schema definition of the element <tt>ex:Customer</tt>.

Another rule example, below, shows how another kind of XPath expression, used as an <tt>xs:string</tt> constant: <tt>"@xml:lang"</tt>, is used, in a RIF+XML data combination, to access an attribute [node]<sup><small>XDM</small></sup> as a frame slot:
Forall ?x, ?y
(_SpeaksEnglish(?y) :-
And( ?x["@xml:lang" -> "en"^^xs:language])
?x["ex:Name" -> ?y])

Assuming that the pair ''(<tt>xml</tt>, <tt><<nowiki>http://www.w3.org/XML/1998/namespace</nowiki>></tt>)'' is also in the statically known namespaces, that rule, combined with the example XML data and XML schema, entails a single new fact:
_SpeaksEnglish("John")

Notice that all the rules, above, are well-formed RIF formulas, that can be validly consumed without being combined with any XML data and/or XML schemas. In that case, of course, this specification adds nothing to the specification of the [[#ref-core|RIF Core Dialect]], as regards the semantics of the rules.

<span id="sec-model-theoretic-semantics-of-rif-bld+xml-data-combinations" class="anchor"></span>

=== Model-theoretic semantics of RIF BLD+XML data combinations ===

The specification of the model-theoretic semantics of a RIF BLD+XML data combination -- a [[#def-rif+xml-data-combination|RIF+XML data combination]], ''<R, E, S>'' where ''R'' is a RIF-BLD (document or non-document) formula -- follows closely the specification of the semantics of a RIF BLD formula, except that the notion of semantic structures is replaced by the notion of ''RIF BLD+XML data combined interpretations'': informally, RIF BLD+XML data combined interpretations are [[BLD#Semantic_Structures|RIF BLD semantic structures]], extended with an additional mapping, '''''I'''''<sub>DM</sub>, that interprets data model [nodes]<sup><small>XDM</small></sup>, and constrained with additional conditions, derived from the information in ''E'' and ''S''.

<span id="sec-semantic-structures" class="anchor"></span>
==== Semantic structures ====

<span id="def-semantic-structure" class="anchor"></span>
'''Definition (Semantic structure).''' For the purpose of defining the model-theoretic semantics of a RIF BLD+XML data combination <''R, E, S''>, a semantic structure is as a tuple ''I'' =
<'''''TV''''', '''''DTS''''', '''''D''''', '''''D'''''<sub>ind</sub>,
'''''D'''''<sub>func</sub>, '''''I'''''<sub>DM</sub>, '''''I'''''<sub>C</sub>, '''''I'''''<sub>V</sub>,
'''''I'''''<sub>F</sub>, '''''I'''''<sub>NF</sub>, '''''I'''''<sub>list</sub>, '''''I'''''<sub>tail</sub>, '''''I'''''<sub>frame</sub>,
'''''I'''''<sub>sub</sub>, '''''I'''''<sub>isa</sub>, '''''I'''''<sub>=</sub>,
'''''I'''''<sub>external</sub>, '''''I'''''<sub>truth</sub>>, where '''''TV''''', '''''DTS''''', '''''D''''', '''''D'''''<sub>ind</sub>,
'''''D'''''<sub>func</sub>, '''''I'''''<sub>C</sub>, '''''I'''''<sub>V</sub>,
'''''I'''''<sub>F</sub>, '''''I'''''<sub>NF</sub>, '''''I'''''<sub>list</sub>, '''''I'''''<sub>tail</sub>, '''''I'''''<sub>frame</sub>,
'''''I'''''<sub>sub</sub>, '''''I'''''<sub>isa</sub>, '''''I'''''<sub>=</sub>,
'''''I'''''<sub>external</sub> and '''''I'''''<sub>truth</sub> are defined as in RIF-BLD (<nowiki>[</nowiki>[[#ref-bld|RIF-BLD]]], section 3.2, Semantic structures), and where
* '''''I'''''<sub>DM</sub> is a total mapping from ''E'' to '''''D'''''<sub>ind</sub>, that interprets data model [nodes]<sup><small>XDM</small></sup>.

<span id="sec-combined-interpretation-of-rif-bld+schemaless-xml-data" class="anchor"></span>

==== Combined interpretation of RIF BLD non-document formulas and XML data ====

Let ''Classifiers(S)'' denote the set of all the well-formed [[#def-RIFSchemaComponentPath|<tt>RIFSchemaComponentPath</tt>]] expressions, ''expr'', such that one of the following holds, where ''c'' is the component selected by ''expr'' in the context of ''S'':
* either ''c'' defines a named complex type, that is, the [component-kind()]<sup><small>CD</small></sup> of ''c'' is <tt>xscd:complex-type-definition</tt> and its [component-name()]<sup><small>CD</small></sup> is a QName;
* or ''c'' is the declaration of or a reference to an element with an anonymous complex type, that is: the [component-kind()]<sup><small>CD</small></sup> of ''c'' is <tt>xscd:element-declaration</tt>, its [component-name()]<sup><small>CD</small></sup> is a QName, the [component-kind()]<sup><small>CD</small></sup> of the child component of ''c'' along the [type axis]<sup><small>CD</small></sup> is <tt>xscd:complex-type-declaration</tt> and its [component-name()]<sup><small>CD</small></sup> is '0' (indicating an anonymous component).

Let, further, ''Classes(S) &sube; Classifiers(S)'' denote the subset of classifier XSD-CD expressions that select the declarations of named complex types.

<span id="def-rif-bld+xml-data+schema-combined-interpretation" class="anchor"></span>
'''Definition (RIF BLD+XML data combined interpretation).''' A '''''RIF BLD+XML data combined interpretation''''' is a triple (''E'', ''I'', ''S''), where ''E'' is a set of data model [nodes]<sup><small>XDM</small></sup>, possibly empty; ''S'' is a set of XML schema definitions, possibly empty; and ''I'' is a [[#def-semantic-structure|semantic structure]], such that all the following holds:
# For all the [nodes]<sup><small>XDM</small></sup> ''e ∈ E'', '''''I'''''<sub>truth</sub>(''I''<sub>frame</sub>(''I''<sub>DM</sub>(''e''))(''I''<sub>C</sub>(<tt>"</tt>''expr''<tt>"^^xs:string</tt>), ''RIFValue(e, expr)'')) = '''t''' (true) for any well-formed XPath expression, ''expr'', for which ''RIFValue(e, expr)'' is defined; and
# For all the individuals ''o ∈ D<sub>Ind</sub>'', there is an element [node]<sup><small>XDM</small></sup> with a complex type, ''e ∈ E'', such that ''I''<sub>DM</sub>(''e'') = ''o'', if and only if there is an XSD-CD component path expression, ''expr ∈ Classifiers(S)'', such that '''''I'''''<sub>truth</sub>(''I''<sub>isa</sub>(''o'', ''I''<sub>C</sub>(<tt>"</tt>''expr''<tt>"^^xs:string</tt>))) = '''t''' (true) and
#* either ''expr ∈ Classes(S)'' and the expanded QName of the type in the selected definition is equal to the [declared type]<sup><small>XDM</small></sup> of ''e'';
#* or ''e'' represents an XML element that satisfies the element definition selected by ''expr'';
# '''''DTS''''' is extended to include all the named atomic types defined in the [in-scope schema definitions]<sup><small>XP</small></sup>;
# '''''I'''''<sub>truth</sub>(''I''<sub>sub</sub>(''I''<sub>C</sub>(<tt>"</tt>''T<sub>1</sub>''<tt>"^^xs:string</tt>), ''I''<sub>C</sub>(<tt>"</tt>''T<sub>2</sub>''<tt>"^^xs:string</tt>)) = '''t''' (true) for all the pairs of XSD-CD component expressions, ''(T<sub>1</sub>, T<sub>2</sub>) ∈ Classes(S) × Classes(S)'', that select two complex types, ''t<sub>1</sub>'' and ''t<sub>2</sub>'', such that ''[derives-from]<sup><small>XP</small></sup>(t<sub>1</sub>, t<sub>2</sub>)'' is true;

☐

Notice that clause 2, in the above definition, implies that, if the class membership of an object that interprets the [context node]<sup><small>XP</small></sup> ''e'', in a classifier amongst the schema definitions in the combined interpretation is asserted, then the object must have all the properties that are mandated by the classifier, and no property that the definition of the classifier does not allow. This is a consequence of the constraint that all the schema element [node]<sup><small>XDM</small></sup>, in ''E'', must be schema valid.

{{EdNote|text=Another possibility, to resolve the issue of incomplete instances, would be to introduce one or more null values in the RIF vocabulary, e.g. <tt>rif:null</tt>.}}

''RIFValue'' is a total mapping from ''E × EXPR'' to ''D''<sub>ind</sub>, where ''EXPR'' is the set of all the well-formed XPath expressions. ''RIFValue(e, expr)'' associates a value in ''D''<sub>ind</sub> to the sequence of data model [nodes]<sup><small>XDM</small></sup>, in ''E'', that are matched by the XPath expression ''expr'' when the [context node]<sup><small>XP</small></sup> is ''e'' and ''S'' contains the [in-scope schema definitions]<sup><small>XP</small></sup>.

''RIFValue'' is defined as follows.

Let ''seq = (i<sub>1</sub>,...,i<sub>n</sub>)'' be the sequence of items matched by ''expr ∈ EXPR'' in the context of ''e ∈ E'', where ''n ≥ 0'' is the number of items in ''seq'':
* if ''n > 1'', ''val'' = ''I''<sub>list</sub>(''Val(i<sub>1</sub>)'',...,''Val(i<sub>n</sub>)'')
* if ''n = 1'',
*# if ''seq = (i)'' is the [typed value]<sup><small>XDM</small></sup> of an element or attribute [node]<sup><small>XDM</small></sup> with a list type, then ''val'' = ''I''<sub>list</sub>(''Val(i)'');
*# else, if ''expr'' selects an schema attribute or child element that is optional (that is, zero or one occurrence) in the context of ''e'', then ''val = Val(i)'';
*# else, if ''i'' is a schema element [node]<sup><small>XDM</small></sup>, and the schema definition of ''e'' allows for multiple occurrences of that schema element, then ''val'' = ''I''<sub>list</sub>(''Val(i)'');
*# otherwise, ''val'' = ''I''<sub>list</sub>(''Val(i)'') or ''val = Val(i)'': according to the XPath 2.0 specification, an item is identical to a singleton sequence containing that item. Except for the multiple occurences and list type cases, that must be handled as specified above, the decision to handle a singleton as a single item or as a singleton sequence that contains that item is left to the implementation, but it must be consistent: that is, the sequence matched by the same XPath expression, ''expr ∈ EXPR'', must be handled the same way, as a sequence or as an item, for all the [context nodes]<sup><small>XP</small></sup>, ''e ∈ E'';
* if ''n = 0'', that is, if ''expr'' matches no item in the context of ''e'',
*# if ''expr'' selects a schema element for which the schema allows zero to more than one occurences in the context of ''e'', then ''val'' = ''I''<sub>list</sub>(''∅'');
*# otherwise, ''RIFValue(e, expr)'' is undefined.



''Val'' interprets items as follows:
* if ''i'' is an atomic value with type <tt>xs:untypedAtomic</tt>, then ''Val(i)'' is the value of ''i'' as an <tt>xs:string</tt>;
* else, if ''i'' is an atomic value, ''Val(i) = i'';
* else, if ''i'' is a [node]<sup><small>XDM</small></sup> without a type name, or whose type name is <tt>xs:untyped</tt> or <tt>xs:untypedAtomic</tt>, with no attributes and with no or only text [node]<sup><small>XDM</small></sup> children, then ''Val(i)'' is the [string value]<sup><small>XDM</small></sup> of ''i'': ''Val(i)'' = <tt>fn:string(</tt>''i''<tt>)</tt>;
* else, if ''i'' is a [node]<sup><small>XDM</small></sup> with a simple type, then
** if ''i'' is a [node]<sup><small>XDM</small></sup> with a list type, then ''val'' is the [typed value]<sup><small>XDM</small></sup> of ''i'' as a RIF list: ''Val(i) = I''<sub>list</sub>(<tt>fn:data(</tt>''i''<tt>)</tt>);
** otherwise ''Val(i)'' is the [typed value]<sup><small>XDM</small></sup> of ''i'': ''Val(i)'' = <tt>fn:data(</tt>''i''<tt>)</tt>;
* otherwise, that is, if ''i'' is a [node]<sup><small>XDM</small></sup> with a complex type, then ''Val(i)'' is the interpretation of ''i'' according to ''I''<sub>DM</sub>: ''Val(i)'' = ''I''<sub>DM</sub>(''i'').

In the above, <tt>fn:string</tt> and <tt>fn:data</tt> are the accessors defined in the [[#ref-xfo|Xpath 2.0 and XQuery 1.0 Functions and Operators]] recommendation <nowiki>[</nowiki>[[#ref-xfo|XFO]]], sections 2.3 and 2.4 (for the reader's convenience, the definitions are copied, non-normatively, in the [[#appendix-glossary|Glossary]].)

A RIF BLD+XML data combined interpretation (''E, I, S'') determines the truth value, ''TVal<sub>(E,I,S)</sub>(φ)'', of a RIF-BLD non-document formula φ combined with the XML data in ''E'' and XML schema definitions in ''S'', like a RIF BLD semantic structure, ''I<sub>BLD</sub>'', determines the truth value ''TVal<sub>I<sub>BLD</sub></sub>(φ)'', of a RIF-BLD non-document formula φ. The mapping ''TVal<sub>(E,I,S)</sub>'' is defined from the set of all non-document formulas to '''TV''', the set of truth values in ''I'', as follows.

'''Definition (Truth valuation of RIF BLD non-document formulas combined with XML data).''' '''''Truth valuation''''' of RIF BLD non-document formulas combined with XML data is determined using the function ''TVal<sub>(E,I,S)</sub>'', such that for all RIF BLD+XMl data combination, <''φ, E, S''>, where ''φ'' is a non-document RIF BLD formula, ''TVal<sub>(E,I,S)</sub>(φ) = TVal<sub>I</sub>(φ)'', where ''TVal<sub>I</sub>'' is as defined in <nowiki>[</nowiki>[[#ref-bld|RIF-BLD]]], section 3.4 - Interpretation of non-document formulas, with ''I'' being the semantic structure in the RIF BLD+XML data combined interpretation (''E, I, S'').  ☐

<span id="ex22" class="anchor"></span>
'''Example 2.2.''' Assuming that ''E'' contains all the data model [nodes]<sup><small>XDM</small></sup> in the data model instance that describes the XML sample fragment in [[#ex21|example 2.1]]; that ''e<sub>table</sub>'' denotes the element node, in ''E'', that represents the information that is serialized in the <tt>CustomerTable</tt> element, in the example XML fragment; and that ''e<sub>John</sub>'' denotes the element node, in ''E'', that represents the information that is serialized in the first <tt>Customer</tt> sub-element (the one whose <tt>Name</tt> sub-element contains ''John''), the following ground frames must be true in all the RIF BLD+XML data combined interpretations, (''E, I, ∅''), that is, where ''E'' is constructed from the infoset only, and where ''I''<sub>C</sub>(<tt>_John</tt>) = ''I''<sub>DM</sub>(''e<sub>John</sub>'') and ''I''<sub>C</sub>(<tt>_Table</tt>) = ''I''<sub>DM</sub>(''e<sub>table</sub>''):

# <tt>_John ["@xml:lang" -> "en"]</tt>
# <tt>_John ["ex:Name" -> "John"]</tt>
# <tt>_John ["ex:Account" -> "111" ]</tt>
# <tt>_Table ["ex:Customer[1]" -> _John ]</tt>

Assuming that ''S'' contains all the top-level schema definitions in the sample schema in [[#ex21|example 2.1]], ground frames #1 and #3 above must be false in all the RIF BLD+XML data combined interpretations, (''E, I, S''), everything else being equal; instead, ground frames #1 and #2, below, must be true:

# <tt>_John ["@xml:lang" -> "en"^^xs:language]</tt>
# <tt>_John ["ex:Account" -> 111 ]</tt>

The class membership formula #1, below, may be true in a RIF BLD+XML data combined interpretation, (''E, I, ∅''), but, in the absence of an associated schema definition, the string <tt>/ex:Customer</tt> does not represent a component designator, and the class membership formula has no meaning specific to the RIF BLD+XML data combined interpretation. However, that same class membership formula must be true in every RIF BLD+XML data combined interpretations, (''E, I, S''):
# <tt>_John # "/ex:Customer"</tt>

On the other hand, the class membership formula: <tt>_PIN_Jane # "/ex:PIN"</tt> must never be true as a consequence of being interpreted under a RIF BLD+XML data combined interpretations, (''E, I, S''). Indeed, <tt>ex:PIN</tt> is defined as a simple type: as such it is not in ''Classes(S)'' (nor in ''Classifiers(S)''); but it is, instead, added to '''''DTS'''''.

<span id="ex23" class="anchor"></span>
'''Example 2.3.''' Consider the following element with mixed-content, where the prefix <tt>ex</tt> is associated with the IRI ''<nowiki>http://example.org/</nowiki>'', and assume that an element [node]<sup><small>XDM</small></sup>, ''e'', that represents it is included in ''E''.

<ex:letterBody>
Thank you for ordering the <ex:item>widget</ex:item>.
It should arrive by <ex:arrivalDate>09-09-09</ex:arrivalDate>
</ex:letterBody>

The following fact must be true in any RIF BLD+XML data combined interpretation, ''(E, I, S)'', such that ''I''<sub>C</sub>(<tt>_myLetter</tt>) = ''I''<sub>DM</sub>(''e''):
* <tt>_myLetter["fn:data(.)" -> "Thank you for ordering the Widget. It should arrive by 09-09-09"]</tt>

Indeed, the element has a mixed content: per <nowiki>[</nowiki>[[#ref-xdm|XDM]]] (section 6.2), its [typed value]<sup><small>XDM</small></sup> is, therefore, its string value as an <tt>xs;untypedAtomic</tt>, which is represented, per the definition of ''RIFValue'', above, by that same [string value]<sup><small>XDM</small></sup> as an <tt>xs:string</tt>.

<span id="sec-combined-interpretation-rif-bld-document+xml-data" class="anchor"></span>

==== Combined interpretation of RIF BLD documents and XML data ====

For the purpose of the interpretation of imported documents, RIF BLD defines the notion of semantic multi-structures, which are nonempty sets, {''J,I; I<sup>i<sub>1</sub></sup>, I<sup>i<sub>2</sub></sup>, ...''}, of semantic structures that differ only in interpretation of local constants.

In the same way, a RIF-BLD+XML data combination <''R, E, S''>, is interpreted using a RIF BLD+XML data combined multi-interpretation (''E'', ''Î'', ''S''), where ''Î'' is a nonempty set, {''J,I; I<sup>i<sub>1</sub></sup>, I<sup>i<sub>2</sub></sup>, ...''}, of semantic structures that determine a non-empty set, {(''E, J, S''), (''E, I, S''); (''E, I<sup>i<sub>1</sub></sup>, S''), (''E, I<sup>i<sub>2</sub></sup>, S''), ...} of RIF BLD+XML data combined interpretations that differ only in the interpretation of local constants.

To keep this document simple, and in the same way the definition of truth valuation of RIF BLD formulas combined with XML data, above, refers to the definition of truth valuation in the [[#ref-bld|RIF-BLD recommendation]], the definition of a RIF BLD+XML data combined multi-interpretation refers to the definition of a semantic multi-structure in <nowiki>[</nowiki>[[#ref-bld|RIF-BLD]]].

'''Definition (RIF BLD+XML data combined multi-interpretation).'''
A '''''RIF BLD+XML data combined multi-interpretation''''' is a triple, (''E'', ''Î'', ''S''), where ''Î'' is a [http://www.w3.org/TR/rif-bld/#def-bld-semantic-multistruct semantic multi-structures] as defined in <nowiki>[</nowiki>[[#ref-bld|RIF-BLD]]] (section 3.5 - Interpretation of documents), with the additional condition that for each semantic suctrure, ''i ∈ Î'', (''E, i, S'') is a RIF BLD+XML data combined interpretation.  ☐

Similarly, the truth valuation of a RIF+XML data combination <''R, E, S''>, is specified with reference to the truth valuation of a RIF BLD document formulas, using the RIF BLD+XML data combined multi-interpretation (''E'', ''Î'', ''S'') in place of a RIF-BLD semantic multi-structure.

'''Definition (Truth valuation of RIF BLD document formulas combined with XML data).''' '''''Truth valuation''''' of RIF BLD document formulas combined with XML data is determined using the function ''TVal<sub>(E,Î,S)</sub>'', such that for all RIF BLD+XML data combination <''Ρ, E, S''>, where ''Ρ'' is a document RIF BLD formula, ''TVal<sub>(E,Î,S)</sub>(Ρ) = TVal<sub>Î</sub>(Ρ)'', where ''TVal<sub>Î</sub>'' is as defined in <nowiki>[</nowiki>[[#ref-bld|RIF-BLD]]], section 3.5 - Interpretation of documents, with ''Î'' being the semantic multi-structure in the RIF BLD+XML data combined multi-interpretation (''E, Î, S'').  ☐

The notions of model and of logical entailment can be defined for a RIF BLD+XML data combination, based on the definitions of model and of logical entailment for RIF BLD (document and non-document) formulas: (''E, Î, S'') is a model of a RIF BLD+XML data combination <''R, E, S''>, if and only if ''Î'' is a model of ''R'', in the sense defined in <nowiki>[</nowiki>[[#ref-bld|RIF-BLD]]] (section 3.6 - Logical entailment), and (''E, Î, S'') is a RIF BLD+Xml data combined multi-interpretation.

'''Definition (Model of a RIF BLD+XML data combination).''' A RIF BLD+XML data combined multi-interpretation (''E'', ''Î'', ''S'') is a '''''model''''' of a RIF BLD+XML data combination <''R, E, S''>, where ''R'' is a RIF BLD document or non-document formula, if and only if ''TVal<sub>(E,Î,S)</sub>(R)'' = '''t''' (true).  ☐

'''Definition (Logical entailment of a RIF BLD+XML data combination).'''
Let <tt>φ</tt> and <tt>ψ</tt> be (document or non-document) formulas. We say that a RIF BLD+XML data combination <''φ, E, S''> <i><b>entails</b></i> the RIF BLD+XML data combination <''ψ, E, S''>, denoted <''φ, E, S''> |= <''ψ, E, S''>, if and only if every model of the RIF BLD+XML data combination <''φ, E, S''> is also a model of the RIF BLD+XML data combination <''ψ, E, S''>.  ☐

Notice that, in the case where ''E'' and ''S'' are empty, that is, if a RIF-BLD formula is combined with an empty XML data set and an empty set of XML schema definitions, the interpretation of that RIF BLD formula under a RIF BLD+XML data combined multi-interpretation (''∅'', ''Î'', ''∅'') is still different from its interpretation under the standard RIF BLD semantics as defined in <nowiki>[</nowiki>[[#ref-bld|RIF BLD]]].

<span id="ex24" class="anchor"></span>
'''Example 2.4.''' Let ''expr'' be a well-formed XPath 2.0 expression, and let
* φ = <tt>Forall ?x ?y ?z (?x["fn:data(expr)"->?z] :- ?x["expr"->?y])</tt>
* ψ = <tt>Forall ?x ?y ?z (?y["fn:data(.)"->?z] :- ?x["expr"->?y])</tt>
Notice that <''φ, ∅, ∅''> |= <''ψ, ∅, ∅''>, provided that the pair ''(<tt>fn</tt>, <tt><nowiki>http://www.w3.org/2005/xpath-functions</nowiki></tt>)'' belongs to the statically known namespaces when the XPath expressions are evaluated; but ''φ'' |≠ ''ψ''. This is because the <tt>xs:string</tt> constants <tt>"expr"</tt>, <tt>"fn:data(expr)"</tt> and <tt>"fn:data(.)"</tt> are interpreted as simple string constants under the standard RIF BLD semantics, whereas they are interpreted according to the XPath 2.0 semantics under the semantics of RIF+XML data combination.

{{EdNote|text=An alternative, less conservative definition for logical entailment in a RIF BLD+XML data combination would be: ''Let <tt>φ</tt> and <tt>ψ</tt> be (document or non-document) formulas. We say that <tt>φ</tt> entails <tt>ψ</tt> in a RIF BLD+XML data combination if and only if every model (''E, Î, S'') of any RIF BLD+XML data combination <''φ, E, S''> is also a model of the RIF BLD+XML data combination <''ψ, E, S''>.''☐ The use cases for the broader definition remain to be examined.}}

<span id="sec-semantics-of-rif-prd+xml-data-combinations" class="anchor"></span>

=== Operational semantics of RIF PRD+XML data combinations ===

The effect on the operational semantics of a RIF PRD formula of the combination with XML data, with or without an associated XML schema, is that all the ground facts that must be true under a [[#def-rif-bld+xml-data+schema-combined-interpretation|RIF BLD+XML data combined interpretation]], must be added to the set of ground facts that represents the [[PRD#def-state|state of the fact base]].

Notice that, whereas the other clauses affect only the initial state of the fact base, clause 2 in the definition of a [[#def-rif-bld+xml-data+schema-combined-interpretation|RIF BLD+XML data combined interpretation]] modifies the semantics of the <tt>Assert</tt> action, when the action asserts the membership of a new object in a class that is interpreted as a schema classifier. Indeed, clause 2, in the definition, implies that the object in a membership relationship with an XML schema classifier (element or type) must interpret an instance of the class: that is, the new member object must validate against the schema definition associated to the class. As a consequence, in the context of a RIF PRD+XML data combination, <''R, E, S''>,
Assert( object # ClassExpr )
where ''<tt>ClassExpr</tt> ∈ Classifiers(S)'', requires, as a prerequisite, that, for all the XPath 2.0 expressions, ''<tt>expr</tt>'', that select a mandatory sub-element or attribute of the class, the following fact be true:
object [ "expr" -> value ]
where <tt>value</tt> has a value that is valid with respect to the schema definition of the selected sub-element or attribute.

Formally, that means that the definition of the RIF-PRD transition relation, defined in <nowiki>[</nowiki>[[#ref-prd|RIF-PRD]]] (section 3.2, Operational semantics of atomic actions), is modified as follows.

Let ''W'' denote the set of all the states of the fact base, and ''L'' denote the set of all the ground atomic actions in the RIF-PRD action language, as defined in <nowiki>[</nowiki>[[#ref-prd|RIF-PRD]]].

Let, further, ''expr''-valid<sub><''R,E,S''></sub>, denote a property of a constant, ''<tt>o</tt> ∈ <tt>Const</tt>'', with respect to a state of the fact base, ''w ∈ W'', in the context of a RIF PRD+XML data combination <''R, E, S''>. We say that <tt>o</tt> is ''expr''-valid<sub><''R,E,S''></sub> in ''w'' if and only if ''expr ∈ Classifiers(S)'' and all the following are true, where ''Φ'' is a set of ground atomic formulas that represents ''w'':
* for each child element, ''c'', with QName: ''<tt>name</tt>'', that is required in the content model defined by the schema definition designated by ''expr'' in ''S'', there is a frame: ''<tt>o["child::</tt>''<tt>name</tt>''<tt>"->value]</tt>'', in ''Φ'', such that ''<tt>value</tt>'' has a value that is valid for ''c'' according to the schema definition;
* for each attribute, ''a'', with QName: ''<tt>name</tt>'', that is required in the content model defined by the schema definition designated by ''expr'' in ''S'', there is a frame: ''<tt>o["attribute::</tt>''<tt>name</tt>''<tt>"->value]</tt>'', in ''Φ'', such that ''<tt>value</tt>'' has a value that is valid for ''a'' according to the schema definition;
* there is no subset, ''F = { <tt>o["e"->v<sub>1</sub>],..., o["e"->v<sub>n</sub>]</tt>} &sube; Φ, n ≥ 0'', of frames with object: ''<tt>o</tt>'', and slot name: ''<tt>"e"</tt>'', where ''e'' is an XPath 2.0 child or attribute step expression, such that
** either the child element or attribute designated by ''e'' is not allowed by the schema definition;
** or the set of values, {''v<sub>i</sub>''}, contains a value that is not valid, according to the schema definition, for the child element or attribute designated by ''e'';
** or the number of facts in ''F'', ''n'', is not within the bounds set in the schema definition for the multiplicity of the child element or attribute designated by ''e''.

'''Definition (RIF-PRD transition relation in a RIF-PRD+XML data combination).''' In a RIF-PRD+XML data combination <''R, E, S''>, the semantics of RIF-PRD atomic actions is specified by the transition relation →<sub><''R,E,S''></sub> &sube; ''W × L × W''. A triple ''(w, <tt>α</tt>, w')'' ∈ →<sub><''R,E,S''></sub> if and only if ''w ∈ W'', ''w' ∈ W'', <tt>α</tt> is a ground atomic action, and
* if <tt>α</tt> is <tt>Assert(φ)</tt>, where φ = <tt>o # "''expr''"</tt> and ''expr ∈ Classifiers(S)'', then <tt>o</tt> is ''expr''-valid<sub><''R,E,S''></sub> in ''w'' and ''w' = w ∪ {φ};
* Otherwise, that is, if <tt>α</tt> is an <tt>Assert</tt> whose target has a different form, or a <tt>Retract</tt>, <tt>Modify</tt> or <tt>Execute</tt> ground atomic action, then ''(w, <tt>α</tt>, w')'' ∈ →<sub><''R,E,S''></sub> if and only if ''(w, <tt>α</tt>, w')'' ∈ →<sub>RIF-PRD</sub>, where →<sub>RIF-PRD</sub> is the standard RIF-PRD transition relation as defined in <nowiki>[</nowiki>[[#ref-prd|RIF-PRD]]] (section 3.2, Operational semantics of atomic actions).

☐

The operational semantics of a RIF PRD+XML data combination is, then, exactly as specified in <nowiki>[</nowiki>[[#ref-prd|RIF-PRD]]], except that →<sub><''R,E,S''></sub> replaces →<sub>RIF-PRD</sub> in the definition of the transition relation, →<sub>PRS</sub>, that is one of the components of a RIF-PRD production rule system, ''PRS'' (cf. <nowiki>[</nowiki>[[#ref-prd|RIF-PRD]]], Section 4.2.4, Operation semantics of a production rule system).

Notice, further, that, since RIF-PRD, unlike RIF-BLD, allows class membership to be asserted for new objects only, the object in such an assertion cannot have some or all the required properties already. As a consequence, all the mandatory properties must be asserted in the same action block where the class membership is asserted.

Formally, the consequence is that the combination with schema-valid XML data puts an additional well-formedness constraints on RIF-PRD action blocks.

'''Definition (Well-formed action block in a RIF-PRD+XML data combination).''' In a RIF-PRD+XML data combination <''R, E, S''>, an action block is '''''well-formed''''' if and only if it is a well-formed RIF-PRD action block, according to the definition in <nowiki>[</nowiki>[[#ref-prd|RIF-PRD]]] (section 3.1.3 - Well-formed action blocks) and it satisfies the following additional constraint:
* if an action in the action block asserts a membership atomic formula, <tt>Assert(o # "expr")</tt>, where ''expr ∈ Classifiers(S)'', then the other actions in the action block are sufficient to make <tt>o</tt> ''expr''-valid<sub><''R,E,S''></sub> in any state of facts resulting from the execution of the action block, that is: all the ground frame formulas that are required to make <tt>o</tt> ''expr''-valid<sub><''R,E,S''></sub> in a state of facts, are asserted in the action block.

☐

{{EdNote|text=Strictly speaking, since actions are ordered in RIF-PRD action blocks, and since the operational semantics of atomic actions is defined with respect to a production rule system state, independently from the system state being a system cycle state or a system transitional state, the ground frame formulas that are required to make <tt>o</tt> ''expr''-valid<sub><''R,E,S''></sub> in a state of facts should be asserted before the membership formula is. However, it is conjectured that the atomic actions in an action block that satisfies the weaker constraint can, always, be re-ordered to satisfy the stronger constraint, without otherwise affecting the semantics of the action block as a whole; whence the absence of the ordering constraint in the above definition.}}

See also the (non-normative) appendix on embedding XML data as RIF facts for an exhaustive description of the facts to be added to the initial state of the fact base that is to be combined with the XML data.

'''Example 2.5.''' In a RIF-PRD+XML data combination <''R, E, S''>, where ''S'' contains all the top-level definitions in the XML schema in [[#ex21|example 2.1]] (all the examples assume that the pair ''(<tt>ex</tt>, <tt><nowiki><http://example.org/customertable></nowiki></tt>)'' belongs to the [statically known namespaces]<sup>small>XP</small></sup> when the XPath and XSD-CD expressions are evaluated):
* the following action blocks are well-formed as the action part of rules in ''R''
Do ((?newPin New())
Assert(?newPin["self::ex:PIN"->999]) )

Do ((?newPin New())
Assert(?newPin["self::ex:PIN"->"999"^^ex:PIN]) )
''(<tt>ex:PIN</tt> is an atomic type defined in ''S''. As a consequence, it is included, per clause 3 in the definition of a RIF BLD+XML data combined interpretation, in the set of data types that are taken into account to interpret RIF formulas.)''
Do ((?newPin New())
Assert(?newPIN # "/ex:PIN") )
''(Since <tt>ex:PIN</tt> is a simple type, the XSD-CD expression ''/ex:PIN'' is not in ''Classifiers(S)''. As a consequence, the class membership assertion, in the example above, adds no well-formedness constraint that is specific to the RIF PRD+XML data combination: its semantics are standard.)''
Do ((?newCust New())
Assert(?newCust # "/ex:Customer")
Assert(?newCust["ex:Name"->"Jojo"])
Assert(?newCust["ex:Account"->1111])
Assert(?newPin["ex:PIN"->999])
Assert(?newCust["@xml/lang"->"fr"^^xs:language]) )

Do ((?newCust New())
Assert(?newCust # "/ex:Customer")
Assert(?newCust["ex:Name"->"Jojo"])
Assert(?newCust["ex:Account"->1111])
Assert(?newCust["@xml/lang"->"fr"^^xs:language]) )
* the following action blocks are not well-formed as the action part of rules in ''R''
Do ((?newCust New())
Assert(?newCust # "/ex:Customer")
Assert(?newCust["ex:Name"->"Jojo"])
Assert(?newCust["ex:Account"->1111])
Assert(?newPin["ex:PIN"->-5])
Assert(?newCust["@xml/lang"->"fr"^^xs:language]) )
''(-5 is out of range for an <tt>ex:PIN</tt> value)''
Do ((?newCust New())
Assert(?newCust # "/ex:Customer")
Assert(?newCust["ex:Name"->"Jojo"])
Assert(?newCust["ex:Name"->"Le balafré"])
Assert(?newCust["ex:Account"->1111])
Assert(?newCust["@xml/lang"->"fr"^^xs:language]) )
''(The schema definition requires a single <tt>ex:Name</tt> value for each <tt>ex:Customer</tt> information item)''.

<span id="sec-semantics-of-rif-core+xml-data-combinations" class="anchor"></span>

=== Semantics of RIF Core+XML data combinations ===

RIF Core is a syntactic subset of RIF BLD, and the semantics of RIF Core+XML data combinations is identical to the semantics of RIF BLD+XML data combinations for that subset.

RIF Core is also a syntactic subset of RIF PRD, and the semantics of RIF Core+XML data combinations is also identical to the semantics of RIF PRD+XML data combinations for that subset.

<span id="sec-importing" class="anchor"></span>

== Importing XML data and XML schemas in RIF ==

In RIF, the <tt>Import</tt> directive is used to communicate the location of an external document to be combined with the RIF document that contains the directive and, optionally, a profile that governs the combination.

In <nowiki>[</nowiki>[[#ref-core|RIF-Core]]], <nowiki>[</nowiki>[[#ref-prd|RIF-PRD]]] and <nowiki>[</nowiki>[[#ref-bld|RIF-BLD]]], the use of the <tt>Import</tt> directive is limited to identifying an imported RIF document. <nowiki>[</nowiki>[[#ref-swc|RIF-RDF-OWL]]] extends it to permit the identification of an RDF graph or an OWL ontology to be combined with a RIF document. An optional profile that governs the combination of a RIF document with an RDF graph or an OWL ontology can also be provided, as specified in <nowiki>[</nowiki>[[#ref-swc|RIF-RDF-OWL]]].

This specification extends the <tt>Import</tt> directive further to permit the identification of XML data and/or XML schemas to be combined with a RIF document.

One use case for the combination of RIF and XML data is when a RIF document imports explicitly the data with which the rules are to be combined: in that case, the combination is imposed by the producer of the RIF document, as well as the data to be combined with the rules that the RIF document contains. We call that case: ''producer-side combination'', and the XML data to be combined with the RIF document: ''imported XML data''.

However, a significant use case for RIF is rules being published or shared as a RIF document for consumers to combine them with their own data: in that case, the consumer of a RIF document decides independently of the producer to combine the rules contained in the RIF document with the data of his choice. We refer to that case as: ''consumer-side combination'', and to the data that is combined with a RIF document as: ''consumer-side data''.

=== The extended <tt>Import</tt> directive ===

Specifically, the <tt>Import</tt> directive is extended as follows:
* The import of any XML document is allowed; that is, the IRI of any XML document is allowed in the <tt>location</tt> sub-element of the <tt>Import</tt> directive. The IRI identifies the imported data document);
* Two new profiles are defined:
*# the value <tt><nowiki>http://www.w3.org/2007/rif-import-profile#xml-data</nowiki></tt> is allowed in the <tt>profile</tt> sub-element of the <tt>import</tt> directive, to indicate that no XML schema is associated with the imported XML data;
*# any IRI that identifies an XML schema is allowed in the <tt>profile</tt> sub-element of the <tt>import</tt> directive, to indicate that the schema definitions in the XML schema are part of the combination;
* Finally, a new value: <tt><nowiki>http://www.w3.org/2007/rif-import-location#consumer-side-data</nowiki></tt>, is allowed for the location of an import. That value indicates that the <tt>profile</tt> in the <tt>Import</tt> directive applies to consumer-side data only.

The following constraints must be satisfied:
* If the content of the <tt>location</tt> in an <tt>Import</tt> directive is <tt><nowiki>http://www.w3.org/2007/rif-import-location#consumer-side-data</nowiki></tt>, the <tt>profile</tt> must contain the IRI of an XML schema;
* Conversely, if the profile is <tt>rif:xml-data</tt>, the <tt>location</tt> must identify an XML document;
* If the <tt>profile</tt> of an <tt>Import</tt> directive contains the IRI of an XML Schema and if the XML document identified in the <tt>location</tt> sub-element of that <tt>Import</tt> directive provides a <tt>schema-location</tt>, the <tt>profile</tt> must identify the same XML schema as the <tt>schema-location</tt> IRI.

This specification does not prescribe the behaviour of a conformant implementation when one of the above constraints is not satisfied.

This specification does not prescribe the behaviour of a conformant implementation when an <tt>Import</tt> directive contains a <tt>location</tt> that is neither <tt><nowiki>http://www.w3.org/2007/rif-import-location#consumer-side-data</nowiki></tt> nor an IRI that identifies an XML document. And this specification does not prescribe the behaviour of a conformant implementation when an <tt>Import</tt> directive contains a <tt>profile</tt> that is neither <tt><nowiki>http://www.w3.org/2007/rif-import-profile#xml-data</nowiki></tt> nor an IRI that identifies an XML schema.

'''Example 3.1.''' The first three import directives, below, are valid; the fourth is not:
# <tt>Import(<nowiki>http://</nowiki>example.org/customertable.xml <nowiki>http://</nowiki>www.w3.org/2007/rif-import-profile#xml-data)</tt>
# <tt>Import(<nowiki>http://</nowiki>example.org/customertable.xml <nowiki>http://</nowiki>example.org/customertable.xsd)</tt>
# <tt>Import(<nowiki>http://</nowiki>www.w3.org/2007/rif-import-location#consumer-side-data <nowiki>http://</nowiki>example.org/customertable.xsd)</tt>
# <tt>Import(<nowiki>http://www.w3.org/2007/rif-import-location#consumer-side-data</nowiki> <nowiki>http://www.w3.org/2007/rif-import-profile#xml-data</nowiki>)</tt>

The first directive says that the rules in the importing RIF document are to be combined with the data in the XML document identified by the IRI: <tt><nowiki>http://</nowiki>example.org/customertable.xml</tt> and that there is no data model associated with the imported data in the form of an XML schema.

The second directive says that the rules in the importing RIF document are to be combined with the data in the XML document identified by the IRI: <tt><nowiki>http://</nowiki>example.org/customertable.xml</tt> and that there is a data model associated with the imported data, in the form of the XML schema that is identified by the IRI: <tt><nowiki>http://</nowiki>example.org/customertable.xsd</tt>.

The third directive says the data that is combined with the rules is expected to be an instance of the data model that is imported as the XML schema identified by the IRI: <tt><nowiki>http://</nowiki>example.org/customertable.xsd</tt>; but the directive does not say what data is to be combined with the rules.

The fourth directive violates the first and second constraints: the dummy location <tt>consumer-side-data</tt>, that indicates that the profile is to be applied to consumer-side data, is incompatible with the profile <tt>xml-data</tt>. Therefore, the directive is out of the scope of this specification.

=== Interpretation of Imports ===

For the purpose of interpreting the combination of a RIF document, ''R'', and XML data, let ''dataLocation(R)'' denote the set of the URIs in the <tt>location</tt> sub-elements of the <tt>import</tt> directives, in ''R'' and in the RIF documents that are imported, directly or indirectly, in ''R'', whose <tt>profile</tt> is either <tt>rif:xml-data</tt> or identifies an XML schema; and let ''dataDocuments(R)'' denote the set of the document [nodes]<sup><small>XDM</small></sup> in the instances of the data model that encapsulate the information in all the XML documents that are identified by an URI in ''dataLocation(R)''. If ''dataLocation(R)'' contains the dummy URI <tt><nowiki>http://www.w3.org/2007/rif-import-location#consumer-side-data</nowiki></tt>, ''dataDocuments(R)'' includes, also, the document [node]<sup><small>XDM</small></sup> in an instance of the data model that encapsulates the consumer-side data. In the absence of consumer-side data, the document node bears no information.

If an <tt>Import</tt> directive identifies an XML schema as its <tt>profile</tt>, the corresponding instance of the data model includes the information from the PSVI that results from validating the XML data referenced in the <tt>location</tt> against that schema. Otherwise, the instance of the data model is built from the infoset.

If an <tt>Import</tt> directive has the value: <tt><nowiki>http://www.w3.org/2007/rif-import-location#consumer-side-data</nowiki></tt> as a locator, the instance of the data model that encapsulates the consumer-side data, if any, includes the information from the PSVI that results from validating the data against the XML schema identified in the profile of that directive.

As a consequence, if different <tt>Import</tt> directives associate different XML schemas to the consumer-side data, the instance of the data model that encapsulates the consumer-side data, if any, includes the information from the PSVI that results from validating the data against the XML schema that results from importing or including, into an otherwise empty schema, all the XML schemas identified in the <tt>profile</tt> sub-elements of <tt>Import</tt> directives with the value: <tt><nowiki>http://www.w3.org/2007/rif-import-location#consumer-side-data</nowiki></tt> as a locator.

Given a RIF document, ''R'', the set of data model nodes, ''E'', in the RIF+XML data combination <''R, E, S''> is the set of all the document nodes in ''dataDocuments(R)'', and of all the data model nodes that can be reached from those document nodes.

In the same way, ''S'', the schema definitions component in the RIF+XML data combination <''R, E, S''>, includes all the top level schema definitions found in the XML schemas that are imported as the <tt>profile</tt> of an <tt>import</tt> directive in ''R'' or in a RIF document that is imported, directly or indirectly, in ''R''.

For the purpose of evaluating XPath 2.0 expressions, when interpreting a RIF+XML data combination <''R, E, S''>, the [in-scope schema definitions]<sup><small>XP</small></sup> include all the schema definitions in ''S'', all the schema type, schema element and schema attribute definitions that are components of the top level definitions in ''S'', and all the schema types defined in [XSD 1.1 Part2].

'''Example 3.2.''' Continuing example 3.1, above, notice that none of the three valid directives is incompatible with the other two, but that combining the first two is confusing and error-prone, since directive #2 supersedes directive #1. Including effectively useless directives should be avoided.

Combining directive #2 and #3 says that the rules in the importing document are meant to be applied only to data that validates against the XML schema in example 2.1, where the data is imported or from the consumer-side.

== References ==

<span id="ref-infoset" class="anchor"></span>

; [Infoset]
: ''[http://www.w3.org/TR/xml-infoset/ XML Information Set (Second Edition)]'', John Cowan and Richard Tobin, Editors. World Wide Web Consortium, 04 Feb 2004. This version is http://www.w3.org/TR/2004/REC-xml-infoset-20040204/. The latest version is available at http://www.w3.org/TR/xml-infoset/.

<span id="ref-uri" class="anchor"></span>

; [RFC 3986]
: ''[http://www.ietf.org/rfc/rfc3986.txt RFC 3986: Uniform Resource Identifier (URI): Generic Syntax]'', T. Berners-Lee, R. Fielding, and L. Masinter. January 2005. Available at: http://www.ietf.org/rfc/rfc3986.txt

<span id="ref-iri" class="anchor"></span>

; [RFC 3987]
: ''[http://www.ietf.org/rfc/rfc3987.txt RFC 3987: Internationalized Resource Identifiers (IRIs)]'', M. Duerst and M. Suignard. January 2005. Available at: http://www.ietf.org/rfc/rfc3987.txt

<span id="ref-core" class="anchor"></span>

; [RIF-Core]
: ''[http://www.w3.org/TR/rif-core/ RIF Core Dialect]'', H. Boley, G. Hallmark, M. Kifer, A. Paschke, A. Polleres, D. Reynolds, Editors. W3C Recommendation 22 June 2010. This version is http://www.w3.org/TR/2009/WD-rif-core-20090703/. The latest version is available at http://www.w3.org/TR/rif-core/.

<span id="ref-bld" class="anchor"></span>

; [RIF-BLD]
: ''[http://www.w3.org/TR/rif-bld/ RIF Basic Logic Dialect]'', H. Boley, M. Kifer, Editors. W3C Recommendation 22 June 2010. This version is http://www.w3.org/TR/2009/WD-rif-bld-20090703/. The latest version is available at http://www.w3.org/TR/rif-bld/.

<span id="ref-dtb" class="anchor"></span>

; [RIF-DTB]
: ''[http://www.w3.org/TR/rif-dtb/ RIF Datatypes and Built-Ins 1.0]'', Polleres A., Boley H. and Kifer M. (Editors), W3C Rule Interchange Format Working Group Draft. This version is http://www.w3.org/TR/2010/REC-rif-dtb-20100622/. The latest Version is available at http://www.w3.org/TR/rif-dtb/.

<span id="ref-prd" class="anchor"></span>

; [RIF-PRD]
: ''[http://www.w3.org/TR/rif-prd/ RIF Production Rule Dialect]'', Ch. de Sainte Marie, A. Paschke, G. Hallmark, Editors. W3C Recommendation 22 June 2010. This version is http://www.w3.org/TR/2009/WD-rif-prd-20090703/. The latest version is available at http://www.w3.org/TR/rif-prd/.

<span id="ref-swc" class="anchor"></span>

; [RIF-RDF-OWL]
: ''[http://www.w3.org/TR/rif-rdf-owl/ RIF RDF and OWL Compatibility]'', J. de Bruijn, Editor. W3C Recommendation 22 June 2010. This version is http://www.w3.org/TR/2009/WD-rif-rdf-owl-20090703/. The latest version is available at http://www.w3.org/TR/rif-rdf-owl/.

<span id="ref-xdm" class="anchor"></span>

; [XDM]
: ''[http://www.w3.org/TR/xpath-datamodel/ XQuery 1.0 and XPath 2.0 Data Model (XDM)]'', M. Fernández, A. Malhotra, J. Marsh, M. Nagy, N. Walsh, Editors. W3C Recommendation 23 January 2007. This version is http://www.w3.org/TR/2007/REC-xpath-datamodel-20070123/. The latest version is available at http://www.w3.org/TR/xpath-datamodel/.

<span id="ref-xfo" class="anchor"></span>

; [XFO]
: ''[http://www.w3.org/TR/xpath-functions/ XQuery 1.0 and XPath 2.0 Functions and Operators]'', Ashok Malhotra, Jim Melton, and Norman Walsh, Editors. World Wide Web Consortium, 23 Jan 2007. This version is http://www.w3.org/TR/2007/REC-xpath-functions-20070123/. The latest version is available at http://www.w3.org/TR/xpath-functions/.

<span id="ref-xml" class="anchor"></span>

; [XML]
: ''[http://www.w3.org/TR/REC-xml/ Extensible Markup Language (XML) 1.0 (Fifth Edition)]'', T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau, Editor. W3C Recommendation 26 November 2008. This version is http://www.w3.org/TR/2005/REC-xml-id-20050909/. The latest version is available at http://www.w3.org/TR/REC-xml/.

<span id="ref-xml-id" class="anchor"></span>

; [xml<nowiki>:</nowiki>id]
: ''[http://www.w3.org/TR/xml-id/ xml:id Version 1.0]'', J. Marsh, D. Veillard, N. Walsh, Editors. W3C Recommendation 9 September 2005. This version is http://www.w3.org/TR/2008/REC-xml-20081126/. The latest version is available at http://www.w3.org/TR/xml-id/.

<span id="ref-xpath-20" class="anchor"></span>

; [XPath 2.0]
: ''[http://www.w3.org/TR/xpath20/ XML Path Language (XPath) 2.0]'', D. Chamberlin , A. Berglund, S. Boag, et. al., Editors. W3C Recommendation 23 Jan 2007. This version is http://www.w3.org/TR/2007/REC-xpath20-20070123/. The latest version is available at http://www.w3.org/TR/xpath20/.

<span id="ref-xquery" class="anchor"></span>

; [XQuery 1.0]
: ''[http://www.w3.org/TR/xquery/ XQuery 1.0: An XML Query Language]'', D. Chamberlin , A. Berglund, S. Boag, et. al., Editors. W3C Recommendation 23 Jan 2007. This version is http://www.w3.org/TR/2007/REC-xquery-20070123/. The latest version is available at http://www.w3.org/TR/xquery/.

<span id="ref-xsd11-1" class="anchor"></span>

; [XSD 1.1 Part 1]
: <cite>[http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/ W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures]</cite>, D. Beech, M. Maloney, H. S. Thompson, C. M. Sperberg-McQueen, S. Gao Gao, N. Mendelsohn, Editors, W3C Recommendation, 5 April 2012, http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/. Latest version available at http://www.w3.org/TR/xmlschema11-1.

<span id="ref-xsd11-2" class="anchor"></span>

; [XSD 1.1 Part 2]
: <cite>[http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/ W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes]</cite>, D. Peterson, S. Gao Gao, H. S. Thompson, P. V. Biron, A. Malhotra, A. Malhotra, C. M. Sperberg-McQueen, Editors, W3C Recommendation, 5 April 2012, http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/. Latest version available at http://www.w3.org/TR/xmlschema11-2/.

<span id="ref-xsd-cd" class="anchor"></span>

; [XSD-CD]
: ''[http://www.w3.org/TR/2010/CR-xmlschema-ref-20100119/ W3C XML Schema Definition Language (XSD): Component Designators]'', , Editors. W3C Candidate Recommandation 19 January 2010. W3C Recommendation 23 Jan 2007. This version is http://www.w3.org/TR/2010/CR-xmlschema-ref-20100119/. The latest version is available at http://www.w3.org/TR/xmlschema-ref/.

<span id="appendix-glossary" class="anchor"></span>

== Appendix A: Glossary (non-normative) ==



<span id="glos-component-kind" class="anchor"></span>

; '''component-kind()''' ''(from <nowiki>[</nowiki>[[#ref-xsd-cd|XSD-CD]]], section 4.5.1)''
: The component-kind accessor returns an expanded name identifying the kind of the schema component.

<span id="glos-component-name" class="anchor"></span>

; '''component-name()''' ''(from <nowiki>[</nowiki>[[#ref-xsd-cd|XSD-CD]]], section 4.5.2)''
: The component-name accessor returns zero or one xs:QName values giving the name of the component.

<span id="glos-context-node" class="anchor"></span>

; '''Context node''' ''(from <nowiki>[</nowiki>[[#ref-xpath-20|XPath 2.0]]], section 2.1.1)''
: The context item is the item currently being processed. An item is either an atomic value or a node. When the context item is a node, it can also be referred to as the context node.

<span id="glos-declared-type" class="anchor"></span>

; '''Declared type''' ''(from <nowiki>[</nowiki>[[#ref-xdm|XDM]]], section 3.3.1.1)''
: The precise definition of the schema type of an element or attribute information item depends on the properties of the PSVI. In the PSVI, [[#ref-xsd11-1|Schema Part 1]] defines a '''[type definition]''' property as well as the '''[type definition namespace]''', '''[type definition name]''' and '''[type definition anonymous]''' properties, which are effectively short-cut terms for properties of the type definition. Further, the '''[element declaration]''' and '''[attribute declaration]''' properties are defined for elements and attributes, respectively. These declarations in turn will identify the '''[type definition]''' declared for the element or attribute. To distinguish the '''[type definition]''' given in the PSVI for the element or attribute instance from the '''[type definition]''' associated with the declaration, the former is referred to below as the '''actual type''' and the latter as the '''declared type''' of the element or attribute instance in question.

<span id="glos-derived-from" class="anchor"></span>

; '''derived-from''' ''(from <nowiki>[</nowiki>[[#ref-xpath-20|XPath 2.0]]], section 2.5.4)''
: [The] pseudo-function named ''derives-from(AT, ET)'' [...] takes an actual simple or complex schema type ''AT'' and an expected simple or complex schema type ''ET'', and either returns a boolean value or raises [an error].
:* ''derives-from(AT, ET)'' returns ''true'' if ''ET'' is a known type and any of the following three conditions is true:
:*# ''AT'' is a schema type found in the [in-scope schema definitions]<sup><small>XP</small></sup>, and is the same as ''ET'' or is derived by restriction or extension from ''ET''
:*# ''AT'' is a schema type not found in the [in-scope schema definitions]<sup><small>XP</small></sup>, and an implementation-dependent mechanism is able to determine that ''AT'' is derived by restriction from ''ET''
:*# There exists some schema type ''IT'' such that ''derives-from(IT, ET)'' and ''derives-from(AT, IT)'' are ''true''.
:* ''derives-from(AT, ET)'' returns ''false'' if ''ET'' is a known type and either the first and third or the second and third of the following conditions are true:
:*# ''AT'' is a schema type found in the [in-scope schema definitions]<sup><small>XP</small></sup>, and is not the same as ''ET'', and is not derived by restriction or extension from ''ET''
:*# ''AT'' is a schema type not found in the [in-scope schema definitions]<sup><small>XP</small></sup>, and an implementation-dependent mechanism is able to determine that ''AT'' is not derived by restriction from ''ET''
:*# No schema type ''IT'' exists such that ''derives-from(IT, ET)'' and ''derives-from(AT, IT)'' are ''true''.
:* ''derives-from(AT, ET)'' raises [an error] if:
:*# ''ET'' is an unknown type, or
:*# ''AT'' is an unknown type, and the implementation is not able to determine whether ''AT'' is derived by restriction from ''ET''.

<span id="glos-document-order" class="anchor"></span>

; '''Document order''' ''(derived from <nowiki>[</nowiki>[[#ref-xdm|XDM]]], section 2.4)''
: A document order is defined among all the element information items that describe a given XML document. Document order is a total ordering. Informally, document order is the order in which nodes appear in the XML serialization of a document.

<span id="glos-fn-data" class="anchor"></span>

; '''<tt>fn:data</tt>''' ''(from <nowiki>[</nowiki>[[#ref-xfo|XFO]]], section 2.4)''
: <tt>fn:data</tt> takes a sequence of items and returns a sequence of atomic values.
: The result of fn:data is the sequence of atomic values produced by applying the following rules to each argument:
:* If the item is an atomic value, it is returned.
:* If the item is a [node]<sup><small>XDM</small></sup>:
:** If the [node]<sup><small>XDM</small></sup> does not have a [typed value]<sup><small>XDM</small></sup> an error is raised.
:** Otherwise, <tt>fn:data()</tt> returns the [typed value]<sup><small>XDM</small></sup> of the [node]<sup><small>XDM</small></sup>.

<span id="glos-fn-string" class="anchor"></span>

; '''<tt>fn:string</tt>''' ''(from <nowiki>[</nowiki>[[#ref-xfo|XFO]]], section 2.3)''
: <tt>fn:string</tt> returns the value of its arguments represented as a <tt>xs:string</tt>. If no argument is supplied, the [context item]<sup><small>XP</small></sup> is used as the default argument. The behavior of the function if the argument is omitted is exactly the same as if the [context item]<sup><small>XP</small></sup> had been passed as the argument.
: If the [context item]<sup><small>XP</small></sup> is undefined, an error is raised.
: If the list of arguments is the empty sequence, the zero-length string is returned.
: If the argument is a node, the function returns the [string-value]<sup><small>XDM</small></sup> of the node.
: If the argument is an atomic value, then the function returns the value of the argument cast as a <tt>xs:string</tt>.

<span id="glos-governing-type-definition" class="anchor"></span>

; '''Governing type definition''' ''(from <nowiki>[</nowiki>[[#ref-xsd11-1|XSD 1.1 Part 1]]], section 3.2.4.2 for an attribute, section 3.3.4.6 for an element)''
: The governing type definition of an attribute, in a given schema-validity ·assessment· episode, is the {type definition} of the ·governing attribute declaration·, unless the processor has stipulated another type definition at the start of ·assessment· (see Assessing Schema-Validity (§5.2)), in which case it is the stipulated type definition.
: The governing type definition of an element information item E, in a given schema-validity ·assessment· episode, is the first of the following which applies:
:# An ·instance-specified type definition· which ·overrides· a type definition stipulated by the processor (see Assessing Schema-Validity (§5.2)).
:# A type definition stipulated by the processor (see Assessing Schema-Validity (§5.2)).
:# An ·instance-specified type definition· which ·overrides· the ·selected type definition· of E.
:# The ·selected type definition· of E.
:# The value ·absent· if E is ·skipped·.
:# An ·instance-specified type definition· which ·overrides· the ·locally declared type·.
:# The ·locally declared type·.
:# An ·instance-specified type definition·.
: If none of these apply, there is no ·governing type definition· (or, in equivalent words, it is ·absent·).



<span id="glos-in-scope-schema-definitions" class="anchor"></span>

; '''In-scope schema definitions''' ''(from <nowiki>[</nowiki>[[#ref-xpath-20|XPath 2.0]]], section 2.1.1)''
: This is a generic term for all the element declarations, attribute declarations, and schema type definitions that are in scope during processing of an expression.] It includes ''[the In-scope schema types, the In-scope element declarations, the substitution groups and the In-scope attribute declarations]''.



<span id="glos-node" class="anchor"></span>

; '''Node''' ''(from <nowiki>[</nowiki>[[#ref-xdm|XDM]]], section 2.1)''
: ''(from <nowiki>[</nowiki>[[#ref-xdm|XDM]]], section 2.1)'' There are seven kinds of Nodes in the data model: document, element, attribute, text, namespace, processing instruction, and comment.
: ''(from <nowiki>[</nowiki>[[#ref-xpath-20|XPath 2.0]]], section 2)'' Each node has a unique node identity, a typed value, and a string value. In addition, some nodes have a name. The typed value of a node is a sequence of zero or more atomic values. The string value of a node is a value of type <tt>xs:string</tt>. The name of a node is a value of type <tt>xs:QName</tt>.

<span id="glos-normalized-value" class="anchor"></span>

; '''Normalized value ''' ''(from <nowiki>[</nowiki>[[#ref-xsd11-1|XSD 1.1 Part 1]]], section 3.1.4)
: The normalized value of an element or attribute information item is an initial value which has been normalized according to the value of the whiteSpace facet, and the values of any other pre-lexical facets, associated with the simple type definition used in its validation.
: The initial value of an attribute information item is the normalized attribute value, as specified in <nowiki>[</nowiki>[[#ref-xml|XML]]], section 3.3.3 (Attribute-value normalization). Similarly, the initial value of an element information item is the string composed of, in [[#glos-document-order|document order]], the character code of each character information item in the [children]<sub><small>info</small></sub> of that element information item.

<span id="glos-schema-normalized-value" class="anchor"></span>

; '''Schema normalized value''' ''(from <nowiki>[</nowiki>[[#ref-xsd11-1|XSD 1.1 Part 1]]], section 3.2.5.4 for attributes, section 3.3.5.4 for elements)''
: If an attribute's [[#glos-normalized-value|normalized value]] is valid with respect to the governing type definition, then the schema normalized value of the attribute is the [[#glos-normalized-value|normalized value]] as validated, otherwise it is absent.
: If an element information item is not nilled and either the [[#glos-governing-type-definition|governing type definition]] is a simple type definition or its {content type} has {variety} ''simple'', then the schema normalized value of the element is the lexical form of its value constraint if applicable; else, if the element's [[#glos-normalized-value|initial value]] is valid with respect to the simple type definition as defined by String Valid (<nowiki>[</nowiki>[[#ref-xsd11-1|XSD 1.1 Part 1]]], section 3.16.4), then the schema normalized value is the [[#glos-normalized-value|normalized value]] of the item as validated; otherwise it is absent.

<span id="glos-statically-known-namespaces" class="anchor"></span>

; '''Statically-known namespaces''' ''(from <nowiki>[</nowiki>[[#ref-xpath-20|XPath 2.0]]], section 2.1.1)''
: This is a set of (prefix, URI) pairs that define all the namespaces that are known during static processing of a given expression.

<span id="glos-string-value" class="anchor"></span>

; '''String value'''
: The string value of a node is a string and can be extracted by applying the <tt>fn:string</tt> function to the node.
: ''(from <nowiki>[</nowiki>[[#ref-xdm|XDM]]], section 3.3.1.3)'' Element and attribute nodes have both typed-value and string-value properties. However, implementations are allowed some flexibility in how these properties are stored. An implementation may choose to store the string-value only and derive the typed-value from it, or to store the typed-value only and derive the string-value from it, or to store both the string-value and the typed-value.
: In order to permit these various implementation strategies, some variations in the string value of a node are defined as insignificant. Implementations that store only the typed value of a node are permitted to return a string value that is different from the original lexical form of the node content.

<span id="glos-type-axis" class="anchor"></span>

; '''type-axis()''' ''(from <nowiki>[</nowiki>[[#ref-xsd-cd|XSD-CD]]], section 4.4.5)''
: The type axis contains simple type definition and complex type definition components linked to the current component through {type definition}, {type definitions}, {content type}, or {simple type definition} arcs

<span id="glos-typed-value" class="anchor"></span>

; '''Typed value'''
: The typed value of a node is a sequence of atomic values and can be extracted by applying the <tt>fn:data</tt> function to the node.
: ''(from <nowiki>[</nowiki>[[#ref-xdm|XDM]]], section 3.3.1.2)'' This section describes how the typed value of an Element or Attribute Node is computed from an element or attribute PSVI information item, where the information item has either a simple type or a complex type with simple content. [...]
: The typed value of Attribute Nodes and some Element Nodes is a sequence of atomic values. The types of the items in the typed value of a node may differ from the type of the node itself. [...]
: The types of the items in the typed value of a node are determined as follows. The process begins with T, the schema type of the node itself, as represented in the PSVI. For each primitive or ordinary simple type T, the W3C XML Schema specification defines a function M mapping the lexical representation of a value onto the value itself.
: The typed value is determined as follows:
:* If the nilled property of the node in question is true, then the typed value is the empty sequence.
:* If T is xs:anySimpleType or xs:anyAtomicType, the typed value is the [[#glos-schema-normalized-value|schema normalized value]] as an instance of xs:untypedAtomic.
:* Otherwise, the typed value is the result of applying M to the string value as an instance of the appropriate value type, where the appropriate value type is the [member type definition] if T is a union type, otherwise it is simply T.
: The typed value determination process is guaranteed to result in a sequence of atomic values, each having a well-defined atomic type.

<span id="appendix-embedding" class="anchor"></span>

== Appendix B: Change Log (non-normative) ==

<span id="changelog"></span>

* Complete rework of the semantics

Since the [http://www.w3.org/TR/2010/WD-rif-xml-data-20100622/ WD published 22 June 2010]:

* Completed the semantics
* Replaced the ad hoc syntax with [[#ref-xpath-20|XPath 2.0]] and [[#ref-xsd-cd|XML schema component designator syntaxes]]

</div>

Template:TR

Sandro — Mon, 04 Feb 2013 16:14:15 GMT

Sandro: Adding "Second Edition" to everything's title.

{{#css:CSS/tr.css}}

;Document title''':'''
:<span id="full-title"><span id="short-title">{{{title}}} (Second Edition)</span></span>

Round 16

Sandro — Mon, 04 Feb 2013 16:10:53 GMT

Sandro: /* Per-Document "Summary of Changes" */ change to "none" except for UCR

This page has information about a round of publication of
working group documents.

{{#css:CSS/datatable.css}}
__TOC__

== General Information ==

{| class="open-data-table form-table"
!{{snapper|Target_Date|Target Date}}
|2013-02-05
|-
![http://opendatatables.org/property/selfLink This Round]
|[http://www.w3.org/2005/rules/wiki/Round_16 Round 16]
|-
!{{snapper|Previous_Round|Previous Round}}
|[http://www.w3.org/2005/rules/wiki/Round_15 Round 15]
|-
|}

== Announcements ==

=== Included in All Documents ===

<em>The following text (if any), with its header, will be included in the status
section of each document. This may be left empty.</em>

<div id="all-status">

</div>

<em>(Nothing for this round.)</em>

=== Per-Document "Summary of Changes" ===

<em>The text provided here for each document will be extracted, during publication, and
placed in the "status of the document" section, under the sub-heading
"First Public Draft" or "Summary of Changes" (as appropriate). This
text should usually be one or two paragraphs, and link into the body
of the draft (make it a working link, please) for more details on the
changes.</em>

<div id="each-status">

==== [[Overview]] ====

auto/none

==== [[UCR]] ====

The document was reorganized, sections were re-written, and an analysis was added of how the use cases are addressed by the current RIF specifications.

==== [[Core]] ====

auto/none

==== [[BLD]] ====

auto/none

==== [[FLD]] ====

auto/none

==== [[SWC]] ====

auto/none

==== [[DTB]] ====

auto/none

==== [[PRD]] ====

auto/none

==== [[Test]] ====

auto/none

==== [[XML-Data]] ====

auto/none

==== [[OWLRL]] ====

auto/none

==== [[RIF_In_RDF]] ====

auto/none

==== [[Primer]] ====

auto/none

=== Announcements of the Round ===

<em>This text can be used as is, or modified to suit the particular forum
where an announcement is sent. Feel free to add an other versions
that might be useful.</em>

==== For W3C News ====

'''Draft:'''

RIF Supports Data Integration, Enterprise Agility

W3C is pleased to publish the Rule Interchange Format (RIF), an extensible interlingua for rule systems, as a W3C Recommendation. RIF was developed with participation from the Business Rules, Logic Programming, and Semantic Web communities to provide interoperability and portability between many different systems using declarative technologies. Today's publication is the largest milestone since the [http://www.w3.org/2004/12/rules-ws/ W3C Workshop on Rule Languages for Interoperability] initially surveyed the field, five years ago.

The specification consists of six Recommendations: [http://www.w3.org/TR/2010/REC-rif-core-20100622/ RIF Core Dialect] provides a standard, base level of functionality for interchange; [http://www.w3.org/TR/2010/REC-rif-bld-20100622/ RIF Basic Logic Dialect] and [http://www.w3.org/TR/2010/REC-rif-prd-20100622/ RIF Production Rule Dialect] provided extended functionality matching two common classes of rule engines; [http://www.w3.org/TR/2010/REC-rif-fld-20100622/ RIF Framework for Logic Dialects] describes how to extend RIF for use with a large class of systems; [http://www.w3.org/TR/2010/REC-rif-dtb-20100622/ RIF Datatypes and Built-Ins 1.0] borrows heavily from XQuery and XPath for a set of basic operations; and [http://www.w3.org/TR/2010/REC-rif-rdf-owl-20100622/ RIF RDF and OWL Compatibility] specifies how RIF works with RDF data and OWL ontologies.

Along with these documents, the RIF Working Group is today publishing five other documents: [http://www.w3.org/TR/2010/NOTE-rif-overview-20100622/ RIF Overview], [http://www.w3.org/TR/2010/WD-rif-test-20100622/ RIF Test Cases], [http://www.w3.org/TR/2010/NOTE-rif-owl-rl-20100622/ OWL 2 RL in RIF], [http://www.w3.org/TR/2010/WD-rif-xml-data-20100622/ RIF Combination with XML data], and [http://www.w3.org/TR/2010/WD-rif-in-rdf-20100622/ RIF In RDF].
The group is also preparing a primer and a revision of its outdated [http://www.w3.org/TR/2008/WD-rif-ucr-20081218/ Use Cases and Requirements].
For more information see the [[RIF FAQ]] and the [http://www.w3.org/2001/sw Semantic Web Activity].

== Publicity Tracking ==

<em>Please record all publicity activities here. This is useful to avoid
overlap and help ensure that we've announced the round in all the
appropriate places. Copied and modified from [[Round 6#Publicity]].</em>

{| class="open-data-table form-table"
!{{snapper|Forum}}
!{{snapper|Coordinator}}
!{{snapper|Posting|Date or Link-to-Posting}}
|-
|[http://www.w3.org/News/ W3C News]
|[[Sandro]]
|
|-
|-
|
* [http://lists.w3.org/Archives/Public/semantic-web semantic-web@w3.org]
* [http://lists.w3.org/Archives/Public/public-owl-dev public-owl-dev@w3.org]
|[[Sandro]]
|
|}
[[Category:Publication Round]]

Round 16

Sandro — Mon, 04 Feb 2013 15:47:13 GMT

Sandro: /* General Information */

This page has information about a round of publication of
working group documents.

{{#css:CSS/datatable.css}}
__TOC__

== General Information ==

{| class="open-data-table form-table"
!{{snapper|Target_Date|Target Date}}
|2013-02-05
|-
![http://opendatatables.org/property/selfLink This Round]
|[http://www.w3.org/2005/rules/wiki/Round_16 Round 16]
|-
!{{snapper|Previous_Round|Previous Round}}
|[http://www.w3.org/2005/rules/wiki/Round_15 Round 15]
|-
|}

== Announcements ==

=== Included in All Documents ===

<em>The following text (if any), with its header, will be included in the status
section of each document. This may be left empty.</em>

<div id="all-status">

</div>

<em>(Nothing for this round.)</em>

=== Per-Document "Summary of Changes" ===

<em>The text provided here for each document will be extracted, during publication, and
placed in the "status of the document" section, under the sub-heading
"First Public Draft" or "Summary of Changes" (as appropriate). This
text should usually be one or two paragraphs, and link into the body
of the draft (make it a working link, please) for more details on the
changes.</em>

<div id="each-status">

==== [[Overview]] ====

auto/minor

==== [[UCR]] ====

The document was reorganized, sections were re-written, and an analysis was added of how the use cases are addressed by the current RIF specifications.

==== [[Core]] ====

auto/minor

==== [[BLD]] ====

auto/minor

==== [[FLD]] ====

auto/minor

==== [[SWC]] ====

auto/minor

==== [[DTB]] ====

auto/minor

==== [[PRD]] ====

auto/minor

==== [[Test]] ====

auto/none

==== [[XML-Data]] ====

auto

==== [[OWLRL]] ====

auto/minor

==== [[RIF_In_RDF]] ====

auto/none

==== [[Primer]] ====

auto/none

=== Announcements of the Round ===

<em>This text can be used as is, or modified to suit the particular forum
where an announcement is sent. Feel free to add an other versions
that might be useful.</em>

==== For W3C News ====

'''Draft:'''

RIF Supports Data Integration, Enterprise Agility

W3C is pleased to publish the Rule Interchange Format (RIF), an extensible interlingua for rule systems, as a W3C Recommendation. RIF was developed with participation from the Business Rules, Logic Programming, and Semantic Web communities to provide interoperability and portability between many different systems using declarative technologies. Today's publication is the largest milestone since the [http://www.w3.org/2004/12/rules-ws/ W3C Workshop on Rule Languages for Interoperability] initially surveyed the field, five years ago.

The specification consists of six Recommendations: [http://www.w3.org/TR/2010/REC-rif-core-20100622/ RIF Core Dialect] provides a standard, base level of functionality for interchange; [http://www.w3.org/TR/2010/REC-rif-bld-20100622/ RIF Basic Logic Dialect] and [http://www.w3.org/TR/2010/REC-rif-prd-20100622/ RIF Production Rule Dialect] provided extended functionality matching two common classes of rule engines; [http://www.w3.org/TR/2010/REC-rif-fld-20100622/ RIF Framework for Logic Dialects] describes how to extend RIF for use with a large class of systems; [http://www.w3.org/TR/2010/REC-rif-dtb-20100622/ RIF Datatypes and Built-Ins 1.0] borrows heavily from XQuery and XPath for a set of basic operations; and [http://www.w3.org/TR/2010/REC-rif-rdf-owl-20100622/ RIF RDF and OWL Compatibility] specifies how RIF works with RDF data and OWL ontologies.

Along with these documents, the RIF Working Group is today publishing five other documents: [http://www.w3.org/TR/2010/NOTE-rif-overview-20100622/ RIF Overview], [http://www.w3.org/TR/2010/WD-rif-test-20100622/ RIF Test Cases], [http://www.w3.org/TR/2010/NOTE-rif-owl-rl-20100622/ OWL 2 RL in RIF], [http://www.w3.org/TR/2010/WD-rif-xml-data-20100622/ RIF Combination with XML data], and [http://www.w3.org/TR/2010/WD-rif-in-rdf-20100622/ RIF In RDF].
The group is also preparing a primer and a revision of its outdated [http://www.w3.org/TR/2008/WD-rif-ucr-20081218/ Use Cases and Requirements].
For more information see the [[RIF FAQ]] and the [http://www.w3.org/2001/sw Semantic Web Activity].

== Publicity Tracking ==

<em>Please record all publicity activities here. This is useful to avoid
overlap and help ensure that we've announced the round in all the
appropriate places. Copied and modified from [[Round 6#Publicity]].</em>

{| class="open-data-table form-table"
!{{snapper|Forum}}
!{{snapper|Coordinator}}
!{{snapper|Posting|Date or Link-to-Posting}}
|-
|[http://www.w3.org/News/ W3C News]
|[[Sandro]]
|
|-
|-
|
* [http://lists.w3.org/Archives/Public/semantic-web semantic-web@w3.org]
* [http://lists.w3.org/Archives/Public/public-owl-dev public-owl-dev@w3.org]
|[[Sandro]]
|
|}
[[Category:Publication Round]]

Round 16

Sandro — Mon, 04 Feb 2013 15:46:25 GMT

Sandro: /* Primer */

This page has information about a round of publication of
working group documents.

{{#css:CSS/datatable.css}}
__TOC__

== General Information ==

{| class="open-data-table form-table"
!{{snapper|Target_Date|Target Date}}
|2012-12-11
|-
![http://opendatatables.org/property/selfLink This Round]
|[http://www.w3.org/2005/rules/wiki/Round_15 Round 15]
|-
!{{snapper|Previous_Round|Previous Round}}
|[http://www.w3.org/2005/rules/wiki/Round_14 Round 14]
|-
|}

== Announcements ==

=== Included in All Documents ===

<em>The following text (if any), with its header, will be included in the status
section of each document. This may be left empty.</em>

<div id="all-status">

</div>

<em>(Nothing for this round.)</em>

=== Per-Document "Summary of Changes" ===

<em>The text provided here for each document will be extracted, during publication, and
placed in the "status of the document" section, under the sub-heading
"First Public Draft" or "Summary of Changes" (as appropriate). This
text should usually be one or two paragraphs, and link into the body
of the draft (make it a working link, please) for more details on the
changes.</em>

<div id="each-status">

==== [[Overview]] ====

auto/minor

==== [[UCR]] ====

The document was reorganized, sections were re-written, and an analysis was added of how the use cases are addressed by the current RIF specifications.

==== [[Core]] ====

auto/minor

==== [[BLD]] ====

auto/minor

==== [[FLD]] ====

auto/minor

==== [[SWC]] ====

auto/minor

==== [[DTB]] ====

auto/minor

==== [[PRD]] ====

auto/minor

==== [[Test]] ====

auto/none

==== [[XML-Data]] ====

auto

==== [[OWLRL]] ====

auto/minor

==== [[RIF_In_RDF]] ====

auto/none

==== [[Primer]] ====

auto/none

=== Announcements of the Round ===

<em>This text can be used as is, or modified to suit the particular forum
where an announcement is sent. Feel free to add an other versions
that might be useful.</em>

==== For W3C News ====

'''Draft:'''

RIF Supports Data Integration, Enterprise Agility

W3C is pleased to publish the Rule Interchange Format (RIF), an extensible interlingua for rule systems, as a W3C Recommendation. RIF was developed with participation from the Business Rules, Logic Programming, and Semantic Web communities to provide interoperability and portability between many different systems using declarative technologies. Today's publication is the largest milestone since the [http://www.w3.org/2004/12/rules-ws/ W3C Workshop on Rule Languages for Interoperability] initially surveyed the field, five years ago.

The specification consists of six Recommendations: [http://www.w3.org/TR/2010/REC-rif-core-20100622/ RIF Core Dialect] provides a standard, base level of functionality for interchange; [http://www.w3.org/TR/2010/REC-rif-bld-20100622/ RIF Basic Logic Dialect] and [http://www.w3.org/TR/2010/REC-rif-prd-20100622/ RIF Production Rule Dialect] provided extended functionality matching two common classes of rule engines; [http://www.w3.org/TR/2010/REC-rif-fld-20100622/ RIF Framework for Logic Dialects] describes how to extend RIF for use with a large class of systems; [http://www.w3.org/TR/2010/REC-rif-dtb-20100622/ RIF Datatypes and Built-Ins 1.0] borrows heavily from XQuery and XPath for a set of basic operations; and [http://www.w3.org/TR/2010/REC-rif-rdf-owl-20100622/ RIF RDF and OWL Compatibility] specifies how RIF works with RDF data and OWL ontologies.

Along with these documents, the RIF Working Group is today publishing five other documents: [http://www.w3.org/TR/2010/NOTE-rif-overview-20100622/ RIF Overview], [http://www.w3.org/TR/2010/WD-rif-test-20100622/ RIF Test Cases], [http://www.w3.org/TR/2010/NOTE-rif-owl-rl-20100622/ OWL 2 RL in RIF], [http://www.w3.org/TR/2010/WD-rif-xml-data-20100622/ RIF Combination with XML data], and [http://www.w3.org/TR/2010/WD-rif-in-rdf-20100622/ RIF In RDF].
The group is also preparing a primer and a revision of its outdated [http://www.w3.org/TR/2008/WD-rif-ucr-20081218/ Use Cases and Requirements].
For more information see the [[RIF FAQ]] and the [http://www.w3.org/2001/sw Semantic Web Activity].

== Publicity Tracking ==

<em>Please record all publicity activities here. This is useful to avoid
overlap and help ensure that we've announced the round in all the
appropriate places. Copied and modified from [[Round 6#Publicity]].</em>

{| class="open-data-table form-table"
!{{snapper|Forum}}
!{{snapper|Coordinator}}
!{{snapper|Posting|Date or Link-to-Posting}}
|-
|[http://www.w3.org/News/ W3C News]
|[[Sandro]]
|
|-
|-
|
* [http://lists.w3.org/Archives/Public/semantic-web semantic-web@w3.org]
* [http://lists.w3.org/Archives/Public/public-owl-dev public-owl-dev@w3.org]
|[[Sandro]]
|
|}
[[Category:Publication Round]]

Round 16

Sandro — Mon, 04 Feb 2013 15:16:29 GMT

Sandro: copy 15; now edit....

This page has information about a round of publication of
working group documents.

{{#css:CSS/datatable.css}}
__TOC__

== General Information ==

{| class="open-data-table form-table"
!{{snapper|Target_Date|Target Date}}
|2012-12-11
|-
![http://opendatatables.org/property/selfLink This Round]
|[http://www.w3.org/2005/rules/wiki/Round_15 Round 15]
|-
!{{snapper|Previous_Round|Previous Round}}
|[http://www.w3.org/2005/rules/wiki/Round_14 Round 14]
|-
|}

== Announcements ==

=== Included in All Documents ===

<em>The following text (if any), with its header, will be included in the status
section of each document. This may be left empty.</em>

<div id="all-status">

</div>

<em>(Nothing for this round.)</em>

=== Per-Document "Summary of Changes" ===

<em>The text provided here for each document will be extracted, during publication, and
placed in the "status of the document" section, under the sub-heading
"First Public Draft" or "Summary of Changes" (as appropriate). This
text should usually be one or two paragraphs, and link into the body
of the draft (make it a working link, please) for more details on the
changes.</em>

<div id="each-status">

==== [[Overview]] ====

auto/minor

==== [[UCR]] ====

The document was reorganized, sections were re-written, and an analysis was added of how the use cases are addressed by the current RIF specifications.

==== [[Core]] ====

auto/minor

==== [[BLD]] ====

auto/minor

==== [[FLD]] ====

auto/minor

==== [[SWC]] ====

auto/minor

==== [[DTB]] ====

auto/minor

==== [[PRD]] ====

auto/minor

==== [[Test]] ====

auto/none

==== [[XML-Data]] ====

auto

==== [[OWLRL]] ====

auto/minor

==== [[RIF_In_RDF]] ====

auto/none

==== [[Primer]] ====

This is the first publication of this material.

=== Announcements of the Round ===

<em>This text can be used as is, or modified to suit the particular forum
where an announcement is sent. Feel free to add an other versions
that might be useful.</em>

==== For W3C News ====

'''Draft:'''

RIF Supports Data Integration, Enterprise Agility

W3C is pleased to publish the Rule Interchange Format (RIF), an extensible interlingua for rule systems, as a W3C Recommendation. RIF was developed with participation from the Business Rules, Logic Programming, and Semantic Web communities to provide interoperability and portability between many different systems using declarative technologies. Today's publication is the largest milestone since the [http://www.w3.org/2004/12/rules-ws/ W3C Workshop on Rule Languages for Interoperability] initially surveyed the field, five years ago.

The specification consists of six Recommendations: [http://www.w3.org/TR/2010/REC-rif-core-20100622/ RIF Core Dialect] provides a standard, base level of functionality for interchange; [http://www.w3.org/TR/2010/REC-rif-bld-20100622/ RIF Basic Logic Dialect] and [http://www.w3.org/TR/2010/REC-rif-prd-20100622/ RIF Production Rule Dialect] provided extended functionality matching two common classes of rule engines; [http://www.w3.org/TR/2010/REC-rif-fld-20100622/ RIF Framework for Logic Dialects] describes how to extend RIF for use with a large class of systems; [http://www.w3.org/TR/2010/REC-rif-dtb-20100622/ RIF Datatypes and Built-Ins 1.0] borrows heavily from XQuery and XPath for a set of basic operations; and [http://www.w3.org/TR/2010/REC-rif-rdf-owl-20100622/ RIF RDF and OWL Compatibility] specifies how RIF works with RDF data and OWL ontologies.

Along with these documents, the RIF Working Group is today publishing five other documents: [http://www.w3.org/TR/2010/NOTE-rif-overview-20100622/ RIF Overview], [http://www.w3.org/TR/2010/WD-rif-test-20100622/ RIF Test Cases], [http://www.w3.org/TR/2010/NOTE-rif-owl-rl-20100622/ OWL 2 RL in RIF], [http://www.w3.org/TR/2010/WD-rif-xml-data-20100622/ RIF Combination with XML data], and [http://www.w3.org/TR/2010/WD-rif-in-rdf-20100622/ RIF In RDF].
The group is also preparing a primer and a revision of its outdated [http://www.w3.org/TR/2008/WD-rif-ucr-20081218/ Use Cases and Requirements].
For more information see the [[RIF FAQ]] and the [http://www.w3.org/2001/sw Semantic Web Activity].

== Publicity Tracking ==

<em>Please record all publicity activities here. This is useful to avoid
overlap and help ensure that we've announced the round in all the
appropriate places. Copied and modified from [[Round 6#Publicity]].</em>

{| class="open-data-table form-table"
!{{snapper|Forum}}
!{{snapper|Coordinator}}
!{{snapper|Posting|Date or Link-to-Posting}}
|-
|[http://www.w3.org/News/ W3C News]
|[[Sandro]]
|
|-
|-
|
* [http://lists.w3.org/Archives/Public/semantic-web semantic-web@w3.org]
* [http://lists.w3.org/Archives/Public/public-owl-dev public-owl-dev@w3.org]
|[[Sandro]]
|
|}
[[Category:Publication Round]]

Round 15

Sandro — Tue, 11 Dec 2012 14:19:58 GMT

Sandro:

This page has information about a round of publication of
working group documents.

{{#css:CSS/datatable.css}}
__TOC__

== General Information ==

{| class="open-data-table form-table"
!{{snapper|Target_Date|Target Date}}
|2012-12-11
|-
![http://opendatatables.org/property/selfLink This Round]
|[http://www.w3.org/2005/rules/wiki/Round_15 Round 15]
|-
!{{snapper|Previous_Round|Previous Round}}
|[http://www.w3.org/2005/rules/wiki/Round_14 Round 14]
|-
|}

== Announcements ==

=== Included in All Documents ===

<em>The following text (if any), with its header, will be included in the status
section of each document. This may be left empty.</em>

<div id="all-status">

</div>

<em>(Nothing for this round.)</em>

=== Per-Document "Summary of Changes" ===

<em>The text provided here for each document will be extracted, during publication, and
placed in the "status of the document" section, under the sub-heading
"First Public Draft" or "Summary of Changes" (as appropriate). This
text should usually be one or two paragraphs, and link into the body
of the draft (make it a working link, please) for more details on the
changes.</em>

<div id="each-status">

==== [[Overview]] ====

auto/minor

==== [[UCR]] ====

The document was reorganized, sections were re-written, and an analysis was added of how the use cases are addressed by the current RIF specifications.

==== [[Core]] ====

auto/minor

==== [[BLD]] ====

auto/minor

==== [[FLD]] ====

auto/minor

==== [[SWC]] ====

auto/minor

==== [[DTB]] ====

auto/minor

==== [[PRD]] ====

auto/minor

==== [[Test]] ====

auto/none

==== [[XML-Data]] ====

auto

==== [[OWLRL]] ====

auto/minor

==== [[RIF_In_RDF]] ====

auto/none

==== [[Primer]] ====

This is the first publication of this material.

=== Announcements of the Round ===

<em>This text can be used as is, or modified to suit the particular forum
where an announcement is sent. Feel free to add an other versions
that might be useful.</em>

==== For W3C News ====

'''Draft:'''

RIF Supports Data Integration, Enterprise Agility

W3C is pleased to publish the Rule Interchange Format (RIF), an extensible interlingua for rule systems, as a W3C Recommendation. RIF was developed with participation from the Business Rules, Logic Programming, and Semantic Web communities to provide interoperability and portability between many different systems using declarative technologies. Today's publication is the largest milestone since the [http://www.w3.org/2004/12/rules-ws/ W3C Workshop on Rule Languages for Interoperability] initially surveyed the field, five years ago.

The specification consists of six Recommendations: [http://www.w3.org/TR/2010/REC-rif-core-20100622/ RIF Core Dialect] provides a standard, base level of functionality for interchange; [http://www.w3.org/TR/2010/REC-rif-bld-20100622/ RIF Basic Logic Dialect] and [http://www.w3.org/TR/2010/REC-rif-prd-20100622/ RIF Production Rule Dialect] provided extended functionality matching two common classes of rule engines; [http://www.w3.org/TR/2010/REC-rif-fld-20100622/ RIF Framework for Logic Dialects] describes how to extend RIF for use with a large class of systems; [http://www.w3.org/TR/2010/REC-rif-dtb-20100622/ RIF Datatypes and Built-Ins 1.0] borrows heavily from XQuery and XPath for a set of basic operations; and [http://www.w3.org/TR/2010/REC-rif-rdf-owl-20100622/ RIF RDF and OWL Compatibility] specifies how RIF works with RDF data and OWL ontologies.

Along with these documents, the RIF Working Group is today publishing five other documents: [http://www.w3.org/TR/2010/NOTE-rif-overview-20100622/ RIF Overview], [http://www.w3.org/TR/2010/WD-rif-test-20100622/ RIF Test Cases], [http://www.w3.org/TR/2010/NOTE-rif-owl-rl-20100622/ OWL 2 RL in RIF], [http://www.w3.org/TR/2010/WD-rif-xml-data-20100622/ RIF Combination with XML data], and [http://www.w3.org/TR/2010/WD-rif-in-rdf-20100622/ RIF In RDF].
The group is also preparing a primer and a revision of its outdated [http://www.w3.org/TR/2008/WD-rif-ucr-20081218/ Use Cases and Requirements].
For more information see the [[RIF FAQ]] and the [http://www.w3.org/2001/sw Semantic Web Activity].

== Publicity Tracking ==

<em>Please record all publicity activities here. This is useful to avoid
overlap and help ensure that we've announced the round in all the
appropriate places. Copied and modified from [[Round 6#Publicity]].</em>

{| class="open-data-table form-table"
!{{snapper|Forum}}
!{{snapper|Coordinator}}
!{{snapper|Posting|Date or Link-to-Posting}}
|-
|[http://www.w3.org/News/ W3C News]
|[[Sandro]]
|
|-
|-
|
* [http://lists.w3.org/Archives/Public/semantic-web semantic-web@w3.org]
* [http://lists.w3.org/Archives/Public/public-owl-dev public-owl-dev@w3.org]
|[[Sandro]]
|
|}
[[Category:Publication Round]]

UCR

Sandro — Tue, 11 Dec 2012 14:14:44 GMT

Sandro: fix pre inside p

__NUMBEREDHEADINGS__
{{TR|title=RIF Use Cases and Requirements}}
<div id='editors'>
; Editors:
: Adrian Paschke, Freie Universitaet Berlin
: Leora Morgenstern, SAIC
: David Hirtle, National Research Council Canada
: Allen Ginsberg, Mitre
: Paula-Lavinia Patranjan, REWERSE
: Frank <nowiki>McCabe</nowiki>, Fujitsu
</div>
; Abstract
: <div id='abstract'><p></p> <p></p> <p></p> <p>This document, developed by the [http://www.w3.org/2005/rules/wg Rule Interchange Format (RIF) Working Group], specifies use cases and requirements for the W3C Rule Interchange Format, a family of rule interchange dialects that allows rules to be translated between rule languages and thus transferred between rule systems. </p> </div>
; Status of this Document
: 3rd revised version of the UCR document

[http://www.w3.org/Consortium/Legal/ipr-notice#Copyright Copyright] © 2010 [http://www.w3.org/ W3C]<sup>®</sup> ([http://www.csail.mit.edu/ MIT], [http://www.ercim.org/ ERCIM], [http://www.keio.ac.jp/ Keio]), All Rights Reserved. W3C [http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer liability], [http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks trademark] and [http://www.w3.org/Consortium/Legal/copyright-documents document use] rules apply.

<div id='docbody'>

<html>
<script type="text/javascript">/*<![CDATA[*/
/*
Written by Jonathan Snook, http://www.snook.ca/jonathan
Add-ons by Robert Nyman, http://www.robertnyman.com
Author says "The credit comment is all it takes, no license. Go crazy with it!:-)"
From http://www.robertnyman.com/2005/11/07/the-ultimate-getelementsbyclassname/
*/

var displayed = [];
displayed["bld"] = 1;
displayed["prd"] = 1;

function display(syntax,status) {
var howmany = 0;
if (status=='none') {
displayed[syntax] = 0;
} else {
displayed[syntax] = 1;
}
for ( i in displayed ) {
howmany = howmany + displayed[i];
}
set_display_by_class('p',syntax,status);
if ( howmany == 1 ) {
set_display_by_class('b','syntax-head','none');
} else {
set_display_by_class('b','syntax-head','');
}
}

function getElementsByClassName(oElm, strTagName, oClassNames){
var arrElements = (! (! (strTagName == "*") || ! (oElm.all)))? oElm.all : oElm.getElementsByTagName(strTagName);
var arrReturnElements = new Array();
var arrRegExpClassNames = new Array();
if(typeof oClassNames == "object"){
for(var i=0; !(i>=oClassNames.length); i++){ /*>*/
arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames[i].replace(/\-/g, "\\-") + "(\\s|$)"));
}
}
else{
arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames.replace(/\-/g, "\\-") + "(\\s|$)"));
}
var oElement;
var bMatchesAll;
for(var j=0; !(j>=arrElements.length); j++){ /*>*/
oElement = arrElements[j];
bMatchesAll = true;
for(var k=0; !(k>=arrRegExpClassNames.length); k++){ /*>*/
if(!arrRegExpClassNames[k].test(oElement.className)){
bMatchesAll = false;
break;
}
}
if(bMatchesAll){
arrReturnElements.push(oElement);
}
}
return (arrReturnElements)
}

function set_display_by_class(el, cls, newValue) {
var e = getElementsByClassName(document, el, cls);
if (e != null) {
for (var i=0; !(i>=e.length); i++) {
e[i].style.display = newValue;
}
}
}

function set_display_by_id(id, newValue) {
var e = document.getElementById(id);
if (e != null) {
e.style.display = newValue;
}
}
/*]]>*/
</script>

</html>

<div> 
== Introduction ==

<div><div lang="en" dir="ltr">

Rule-languages and rule-based systems have played seminal roles in the history of computer science and the evolution of information technology. From expert systems to deductive databases, the theory and practice of automating inference based on symbolic representations has had a rich history and continues to be a key technology driver.

Due to the innovations made possible by the Internet, the World Wide Web, and, most recently, the Semantic Web, there is now even greater opportunity for growth in this sector. While some of these opportunities may require advances in research, others can be addressed by enabling existing rule-based technologies to interoperate according to standards-based methodologies and processes. The basic goal of the Rule Interchange Format (RIF) Working Group is to devise such standards and make sure that they are not only useful in the current environment, but are easily extensible in order to deal with the evolution of rule technology and other enabling technologies. This mission of RIF is part of W3C's larger goal of enabling the sharing of information in forms suited to machine processing:

*# Rules themselves represent a valuable form of information for which there is not yet a standard interchange format, although significant progress has been made within the [http://www.ruleml.org/ RuleML Initiative] and elsewhere.
*# Rules provide a powerful business logic representation, as business rules, in many modern information systems.
*# Rules are often the technology of choice for creating maintainable adapters between information systems.
*# As part of the Semantic Web architecture, rules can extend or complement the OWL Web Ontology Language to more thoroughly cover a broader set of applications, with knowledge being encoded in OWL or rules or both.

The purpose of this RIF-UCR document is to describe the use cases that guided the design of RIF and to document the design requirements that were derived from both the use cases and from the basic goals of RIF. RIF-UCR also delivers a structured context for formulating future technical specifications of further RIF dialects. Each dialect targets at a cluster of similar rule languages and enables platform-independent interoperation between them (via interchange of RIF rules). The presented use cases illustrate some of the principal ways in which RIF can provide benefits. RIF can promote innovation and development by fostering collaborative work and providing new opportunities for third-party services. RIF can promote e-commerce by providing interoperability across vendor platforms. RIF can promote efficient process management through reuse, sharing, and the ability to provide unified views across disparate platforms. Last, but not least, RIF can promote the growth of knowledge by enabling reasoning with merged sets of rules originating from disparate knowledge sources.

The RIF-UCR document is structured as follows: Section 2 formulates the overall goals of RIF. Section 3 summarizes the released RIF dialects and the current structure of RIF. Section 4 discusses several important requirements for RIF dialects. Section 5 presents a set of use cases that are representative of the types of application scenarios that RIF is intended to support. The use cases illustrate the utilization of the current RIF dialects. More importantly, the functionality specified in the use cases, together with the requirements discussed in the previous section, serves as input for both the technical specification of future RIF dialects and for the implementation of various variants of these scenarios by RIF-compliant applications and systems.

Although in this document the discussion of requirements precedes the discussion of the use cases in this document, the development of the use cases preceded, and in fact motivated, the development of the requirements. In general, it is intended that for each requirement, there is at least one use case, or straightforward modification of a use case, from which that requirement was derived. There are some exceptions to this rule: some requirements were already defined as constraints in the working group charter, and were not necessarily derived from any specific use case. The fulfillment of such requirements is discussed with respect to the existing RIF dialects.

Note that in fact not all use cases can be represented in a straightforward manner within all RIF dialects. In particular, several use cases cannot be represented within the RIF dialect BLD. This is due first, to the fact that BLD is strictly less expressive than first-order logic (since negation is not expressible), and second, to the fact that some use cases are most naturally represented in languages more powerful than first-order logic, such as modal logics. Following the presentation of each use case in Section 5 is a note indicating in which of the current RIF dialects a use case can be represented naturally, sometimes accompanied by discussion.

It should be noted that even use cases which cannot be represented in a straightforward manner within some RIF dialect, such as BLD, there may be other approaches which will enable representation. For example, although epistemic operators such as <tt>Know</tt> and <tt>Believe</tt> are most straightforwardly represented within a modal logic, it is generally possible to represent such operators in a first-order logic using a possible-worlds semantics. For certain use cases which cannot be naturally represented within some dialect, the extent to which this can be done will be discussed.

</div></div></div><div>

== Goals ==

<div><div lang="en" dir="ltr">
The primary goal of RIF is to be an effective means of exchanging rules that has the potential to be widely adopted in industry and that is consistent with existing W3C technologies and specifications.

<span id="goal-exchange-of-rules" class="anchor"></span>
==== Exchange of Rules ====

The primary goal of RIF is to facilitate the exchange of rules.

<span id="goal-w3c-consistency" class="anchor"></span>
==== Consistency with W3C specifications ====

RIF is intended to be a W3C specification that builds on and develops the existing range of specifications that have been developed by the W3C. This implies that existing W3C technologies should fit well with RIF.

<span id="goal-widescale-adoption" class="anchor"></span>
==== Widescale Adoption ====

It is an explicit goal of the W3C that the Rules Interchange Format will have the maximum potential for widescale adoption. Rules interchange becomes more effective the wider adoption there is of the specification -- the so-called "network effect".

Along with the use cases in the next section, these goals motivate the requirements in Section 5.

</div></div></div><div>

== Structure of RIF ==

<div><div lang="en" dir="ltr">
RIF is described by a set of documents, each fulfilling a different purpose, and catering to a different audience. The three RIF dialects which can be used to represent RIF use cases are:

* [http://www.w3.org/TR/rif-core RIF Core Dialect], which provides a standard, base level of functionality for interchange
* [http://www.w3.org/TR/rif-bld RIF Basic Logic Dialect] and [http://www.w3.org/TR/2010/REC-rif-prd-20100622/ RIF Production Rule Dialect] provide extended functionality matching two common classes of rule engines, namely derivation rules and production rules.

Along with these three dialects, RIF consists of related documents: [http://www.w3.org/TR/rif-fld RIF Framework for Logic Dialects], [http://www.w3.org/TR/rif-dtb RIF Datatypes and Built-Ins 1.0], [http://www.w3.org/TR/rif-test RIF Test Cases], [http://www.w3.org/TR/rif-rdf-owl RIF RDF and OWL Compatibility], [http://www.w3.org/TR/rif-ucr/ RIF Use Cases and Requirements], [http://www.w3.org/TR/rif-owl-rl OWL 2 RL in RIF], [http://www.w3.org/2007/OWL/wiki/PlainLiteral rdf:PlainLiteral], [http://www.w3.org/TR/rif-xml-data RIF Combination with XML data], [http://www.w3.org/TR/rif-primer RIF Primer] and [http://www.w3.org/TR/rif-in-rdf/ RIF In RDF]. For an overview on RIF see the [http://www.w3.org/TR/rif-overview RIF Overview].

RIF is designed as a family of RIF dialects as shown in the following Venn diagram:

[[Image: RIF_DIALECTS_VENN.jpg | Venn Diagram of RIF Dialects]]

Each dialect is a collection of components that works together, forming an interlingua. New dialects are needed when no existing dialect provides the required rule-language features for interchange.

The RIF Framework for Logic-based Dialects ([http://www.w3.org/TR/rif-fld RIF-FLD]) describes mechanisms for specifying the syntax and semantics of logic-based RIF dialects through a number of generic concepts. Every logic-based RIF dialect should specialize these general mechanisms or justify why it does not. This specialization may include leaving out some elements of RIF-FLD, to produce its concrete syntax and model-theoretic semantics. Currently, the first two existing RIF dialects are the RIF Basic Logic Dialect (RIF-BLD) and the RIF Production Rules Dialect (RIF-PRD) which is a partial specialization of FLD.

[http://www.w3.org/TR/rif-bld RIF-BLD] (Basic Logic Dialect) is a specialization of RIF-FLD capable of representing definite Horn rules with equality enhanced with a number of syntactic extensions to support expressive features such as objects and frames, internationalized resource identifiers (IRIs) as identifiers for concepts, and XML Schema data types.

[http://www.w3.org/TR/rif-prd RIF-PRD] (Production Rules Dialect) specifies a production rules dialect to enable the interchange of production rules. The condition language of RIF PRD is defined in Core as a common subset of RIF BLD and RIF PRD.

[http://www.w3.org/TR/rif-core RIF-Core] (Core Dialect) specifies a common subset of RIF-BLD and RIF-PRD which includes RIF-DTB.

The normative syntax for RIF dialects is a concrete XML syntax. A non-normative presentation syntax is additionally specified for each dialect, to allow a more easily readable and compact presentation of language fragments (such as examples).

</div></div></div><div>

== Requirements ==

<span id="req-semantic-tagging" class="anchor"></span>

<div><div lang="en" dir="ltr">
The goals and use cases motivate a number of requirements for a Rule Interchange Format. The Working Group has approved the following requirements.

<span id="req-implementability" class="anchor"></span>

=== Implementability ===

''RIF must be implementable using well understood techniques, and should not require new research in, e.g., algorithms or semantics in order to implement translators.''

<span id="req-semantic-precision" class="anchor"></span>

=== Semantic precision ===

''RIF core must have a clear and precise syntax and semantics. Each standard RIF dialect must have a clear and precise syntax and semantics that extend RIF core.''

<span id="req-extensible" class="anchor"></span>

=== Extensible Format ===

''It must be possible to create new RIF dialects which extend existing dialects (thus providing backward compatibility) and are handled gracefully by systems which support existing dialects (thus providing forward compatibility).''

<span id="req-translators" class="anchor"></span>

=== Translators ===

''For every standard RIF dialect it must be possible to implement translators between rule languages covered by that dialect and RIF without changing the rule language.''

<span id="req-standard-components" class="anchor"></span>

=== Standard components ===

''RIF implementations must be able to use standard support technologies such as XML parsers and other parser generators, and should not require special purpose implementations when reuse is possible.''

<span id="req-coverage" class="anchor"></span>

=== Rule language coverage ===

''Because of the great diversity of rule languages, no single interchange language is likely to be able to bridge between all. Instead, RIF provides dialects each of which is targeted at a cluster of similar rule languages. RIF must allow intra-dialect interoperation, i.e. interoperability between semantically similar rule languages (via interchange of RIF rules) within one dialect, and should support inter-dialect interoperation, i.e. interoperation between dialects with maximum overlap.''

<span id="req-compliance-model" class="anchor"></span>

=== Compliance model ===

''The RIF specifications must provide clear conformance criteria that define what is or is not a conformant RIF implementation.''

<span id="req-default-behavior" class="anchor"></span>

=== Default behavior ===

''RIF must specify at the appropriate level of detail the default behavior that is expected from a RIF compliant application that does not have the capability to process all or part of the rules described in a RIF document, or it must provide a way to specify such default behavior.''

<span id="req-different-semantics" class="anchor"></span>

=== Different semantics ===

''RIF must cover rule languages having different semantics.''

<span id="req-dialects" class="anchor"></span>

=== Limited number of dialects ===

''RIF must have a standard core, and a limited number of standard dialects based upon that core.''

<span id="req-comments" class="anchor"></span>

=== Embedded comments ===

''RIF must be able to pass comments.''

<span id="req-metadata" class="anchor"></span>

=== Embedded metadata ===

''RIF must support metadata such as author and rule name.''

<span id="req-owl-data" class="anchor"></span>

=== OWL data ===

''RIF must cover OWL knowledge bases as data where compatible with RIF semantics.''

<span id="req-rdf-data" class="anchor"></span>

=== RDF data ===

''RIF must cover RDF triples as data where compatible with RIF semantics.''

<span id="req-dialect-identification" class="anchor"></span>

=== Dialect Identification ===

''The semantics of a RIF document must be uniquely determined by the content of the document, without out-of-band data.''

<span id="req-xml-syntax" class="anchor"></span>

=== XML syntax ===

''RIF must have an XML syntax as its primary normative syntax.''

<span id="req-xml-types" class="anchor"></span>

=== XML types ===

''RIF must support an appropriate set of scalar datatypes and associated operations as defined in XML Schema part 2 and associated specifications.'' See the charter on [http://www.w3.org/2005/rules/wg/charter#datatype0 Datatype support].

<span id="req-merge" class="anchor"></span>

=== Merge Rule Sets ===

''RIF must support the ability to merge rule sets.''

<span id="req-rulesets" class="anchor"></span>

=== Identify Rule Sets ===

''RIF must support the identification of rule sets.''

<span id="req-xml-data" class="anchor"></span>

=== XML data ===

''RIF should be able to accept XML elements as data.''

<span id="req-rif-text" class="anchor"></span>

=== Internationalized text ===

''RIF must support internationalized text — that is, text that additionally conveys information in terms of a language tag.''

</div></div></div><div>

== Use Cases ==

<div><div lang="en" dir="ltr">

A use case for RIF consists of a description of a problem together with a solution that either uses an existing RIF dialect or requires the specification of a new RIF dialect.

The set of use cases is intended to do the following:
<ul>
<li>motivate the need for a RIF in a broad range of application domains and industrial sectors;</li>
<li>provide scenarios that motivate the design of RIF and explain the benefits of a RIF in such scenarios;</li>
<li>guide users to RIF's specified dialects; and</li>
<li>motivate the working group's set of requirements for a RIF.</li>
</ul>

The set of use cases were developed over several years.
Nearly [http://www.w3.org/2005/rules/wg/wiki/Use_Cases fifty use cases] documenting the need for a RIF were originally submitted by the working group members. These were grouped into general categories and then synthesized as much as possible. The goal was to come up with a relatively small set of use cases that would cover a broad range of possible requirements. In addition, it was desired that the use cases refer to popular application domains and industrial sectors. For every use case we will briefly discuss the coverage of the use case by the existing three RIF dialects (Core, BLD, and PRD).



</div></div>

<div>

=== Negotiating eBusiness Contracts Across Rule Platforms ===

<div><div lang="en" dir="ltr">

This use case illustrates a fundamental use of RIF: to supply a vendor-neutral representation of rules, so that rule-system developers and stakeholders can do their work and make product investments without concern about vendor lock-in, and in particular without concern that a business partner does not have the same vendor technology. It also illustrates the fact that RIF can be used to foster collaborative work. Each developer and stakeholder can make a contribution to the joint effort without being forced to adopt the tools or platforms of the other contributors.

John is negotiating an electronic business contract regarding the supply of various types of items that Jane's company is manufacturing. Jane and John interchange the contract-related data and rules involved in the negotiation in electronic form so that they can run simulations. Both agree on a standard Business Object Model / data model (i.e., vocabulary / ontology) for the goods and services involved - in this case an XML schema and appropriate test XML documents are interchanged with their rules. Since John and Jane run applications based on different vendors' rule engines and rule languages, they interchange the rules using RIF; both vendors used can interpret the XML schema and data, and produce the results as an amended XML document. John's company defines its purchase orders in terms of an XML description of goods, packaging, delivery location and date with delivery and payment rules. A rule proposed by John might be the following:

<pre width=130>
If an item is perishable and it is delivered to John more than 10 days after the scheduled delivery date then the item will be rejected by him.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
This rule set can be adequately represented in RIF Core either using (ordered) relations as e.g. in standard Logic Programming, unordered relations using named arguments, or in a more object-oriented encoding using frames.<br />
<br />
''Ordered representation in RIF Core presentation syntax using relations:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
ex:reject("John" ?item) :-
ex:perishable(?item)
ex:delivered(?item ?deliverydate "John")
ex:scheduled(?item ?scheduledate)
?diffdays = External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
External(pred:numeric-greater-than(?diffdays 10))
)
)
)
</code>
<br />
Note, the nesting of external built-in functions and operations and the assignment/binding of (intermediate) result (sets) from functions to variables by equality in this example.<br />
<br />
''Unordered representation in RIF Core presentation syntax using namened arguments:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
ex:reject(ex:ware -> ?item ex:receiver -> "John") :-
ex:perishable(ex:ware -> ?item)
ex:delivered(ex:ware -> ?item ex:datetime -> ?deliverydate ex:receiver -> "John")
ex:scheduled(ex:datetime -> ?scheduledate ex:ware -> ?item)
?diffdays = External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
External(pred:numeric-greater-than(?diffdays 10))
)
)
)
</code>
<br />
Note, the arbitrarily unordered named argument arguments of the user-defined relations, in contrast to external built-in functions and operations, which must have a predefined order. <br />
<br />
''Object-Oriented Representation in RIF Core presentation syntax using frames:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
?item[ex:status -> "rejected"] :-
?item[ex:perishable -> true]
?item[ex:deliveredOn -> ?deliverydate ex:delivered -> "John"]
?item[ex:scheduledOn -> ?scheduledate ex:delivered -> "John"]
External(pred:numeric-greater-than(
External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
10
)
)
)
)
</code>
</p>

Jane replies with some suggested rule changes:

<pre width=130>
If an item is perishable and it is delivered to John more than 7 days after the scheduled delivery date but less than 14 days after the scheduled delivery date then a discount of 18.7% will be applied to the delivered item.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
''Representation in RIF Core presentation syntax using positional relations:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
ex:discount("John" ?item 18.7 ) :-
ex:perishable(?item)
ex:delivered(?item ?deliverydate "John")
ex:scheduled(?item ?scheduledate)
?diffdays = External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
External(pred:numeric-greater-than(?diffdays 7))
External(pred:numeric-less-than(?diffdays 14))
)
)
)
</code>
<br />

The binding of the intermeditate results to the variable "?diffdays" avoids repetition, as it used twice in the subsequent rule conditions. As demonstrated in the previous examples, similar representations for this rule can be given using slots or frames and as a production rule which asserts the conclusion as a new fact.
</p>

John considers this and agrees with Jane. Both organizations utilize these rules in their operational systems using disparate rule representations internally to compute prices for this order and determine contract compliance.

Future requests for the supply of items by John's company are defined on their purchasing web site, as the appropriate XML schema and a RIF ruleset (or rulesets). This allows Jane's company and its competitors to respond electronically with XML cost sheets. Suppliers respond with multiple cost sheets with different variations on the RIF rules proposed by John's company, allowing John's company to review the alternative rules with their associated costs to determine whether they, as a business, would benefit by relaxing or adding new rules as proposed by suppliers.

'''Supported by: RIF Core, RIF BLD, RIF PRD'''

The rules of this use case can be adequately represented in RIF Core (and BLD and PRD) either using (ordered) relations, as e.g. in standard Logic Programming, unordered relations, using named arguments, or in a more object-oriented encoding using frames.

</div></div></div><div>

=== Negotiating eCommerce Transactions Through Disclosure of Buyer and Seller Policies and Preferences ===

<div><div lang="en" dir="ltr">

This use case concerns the ability of parties involved in formal transactions or procedures, e.g., credit card authorization of a purchase, access of private medical records, etc., to express and protect their interests within a policy-governed framework. The goal is to formally encode the preferences, priorities, responses, etc., of the parties in such a way that the overall policy can work as intended while providing opportunity for automatic negotiation of terms when allowed by the policy. Utilization of RIF in this use case would extend the scope of this technology, affording a higher degree of interoperability, as well as enabling re-use and sharing of preferences, etc., through interchange. The detailed scenario below shows how this would work.

Alice wants to buy a device at an online site called "eShop." Alice employs software called "Emptor" that functions as automated negotiating agent for buyers. eShop employs software called "Venditor" as automated negotiating agent for sellers.

Alice's and eShop's policies describe who they trust and for what purposes. The negotiation is based on the policies, which are specified as rules, and credentials Emptor and Venditor have. These policies and credentials are disclosed (interchanged) so as to automatically establish trust with the goal of successfully completing the transaction.

Policies are themselves subject to access control. Thus, rule interchange is necessarily done during negotiation and (in general) depends on the current level of trust that the systems have on each other. Since Emptor and Venditor might use different rule languages and/or engines for evaluating (own and imported) rules, a (standard) rule interchange format (RIF) needs to be employed for enabling the rule interchange between the two systems.

When Alice clicks on a "buy it" button at the eShop's Web site, Emptor takes over and sends a request to eShop's site. Venditor receives the request and sends parts of its policy (i.e. a set of rules) back to Emptor. Among other things, the policy states that:

<pre width=130>
In order to grant access a buyer must provide valid credit card information together with delivery information (address, postal code, city, and country).
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF Core presentation syntax using relations and frames in combination: <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?buyer ?creditCard ?address (
ex:permit_access("eShop" ?buyer) :-
ex:provide("eShop" ?buyer)
?buyer[ex:card -> ?creditCard ex:deliveryAddr -> ?address]
ex:valid_payment_method(?creditCard)
ex:valid_delivery_address(?address)
)

Forall ?type ?person ?first ?last ?number ?code ?date ?month ?year (
ex:valid_payment_method(?card) :-
?card[type -> ?type
ex:holder -> ?person
ex:number -> ?number
ex:code -> ?code
ex:expiry -> ?date]
?person[ex:lastname -> ?last ex:firstname -> ?first]
?date[ex:month -> ?month ex:year -> ?year]
ex:credential(?type ?person ?number ?code ?date)
)

Forall ?address ?last ?first ?street ?strname ?number ?code ?city ?country (
ex:valid_delivery_address(?address) :-
?address[ex:name -> ?person ex:street -> ?street ex:postal_code -> ?code ex:city -> ?city ex:country -> ?country ]
?person[ex:lastname -> ?last ex:firstname -> ?first]
?street[name -> ?strname ex:number -> ?number]
ex:declaration(?person ?street ?number ?code ?city ?country)
)

)
)
</code>

Note that in this example relational representation is used in combination with frame representation. Such mixing of representation styles is supported by RIF.
</p>

Rules express compactly possible ways in which a resource can be accessed; by exchanging them negotiations are shorter and privacy protection is improved. In the example, Venditor reveals part of its policy in form of rules to enable Emptor to choose how to answer, i.e. to decide which credentials and required information to disclose.

For determining whether Venditor's request for information is consistent with Alice's policy, Emptor takes its rules into account, which state for example:

<pre width=130>
Disclose Alice's credit card information only to online shops belonging to the Better Business Bureau.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF Core presentation syntax:

<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?Shop ?card ?Credential ?Buyer (
ex:provide(?Shop ?Buyer ) :-
?Buyer[ex:card -> ?creditCard ex:deliveryAddr -> ?address]
ex:belongs_to(?Shop "Better Business Bureau")
)

Forall ?deliveryAddr ?card ?Date ?Person ?Street (
ex:Alice[ex:card -> ?card ex:deliveryAddr -> ?deliveryAddr] :-
?Date = ex:Date[ex:month -> 12 ex:year -> 2012]
?Person = ex:Person[ex:lastname -> "Sure" ex:firstname -> "Alice"]
?Street = ex:Street[name -> "North Street" number -> 111]
?card= ex:Card[ ex:type -> "Visa"
ex:holder -> ?Person
ex:number -> "123456789"
ex:code -> "123"
ex:expiry -> ?Date
]
?deliveryAddr = ex:DeliveryAddress[ ex:name -> ?Person
ex:street -> ?Street
ex:postal_code -> "NE3456"
ex:city -> "New York"
ex:country -> "USA"
]
)

)
)
</code>

</p>

By disclosing (interchanging) the above given rule, Emptor asks Venditor to provide credentials saying that it belongs to the Better Business Bureau, Alice's most trusted source of information on online shops. eShop has such a credential and its policy contains a rule stating to release it to any potential purchaser. Hence, Venditor passes the credential to Emptor. Emptor is now ready to disclose Alice's credit card information to Venditor but it still must check whether disclosing all the information does not break Alice's denial constraints. Alice has stated two constraints stating:

<pre width=130>
For anonymity reasons, never provide both her birth date and postal code.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
The current RIF dialects do not specify explicit constructs for integrity constraints.
</p>

For this purchase, Alice birthdate is no issue. Thus, Alice's constraints are respected. Emptor therefore provides Alice's credit card information to Venditor.

Companies that provide software such as Venditor and Emptor would make use of RIF in a number of ways. The rules expressing Alice's and/or eShop's policies could be expressed in different rule languages but still work with the software, using RIF-based interchanges. Secondly, assuming Venditor and Emptor are products of different companies using different internal rule languages, it would still be possible for them to work together in real-time. When these two systems need to exchange policy or preference information of their respective clients they would use RIF to enable the interchange in real-time. When Venditor sends its initial policy information to Emptor it uses RIF. Emptor takes that policy and translates it from RIF to its internal representation in order to determine what it needs to do.

'''Not supported by the current RIF dialects (Core, BLD, PRD) '''

Current RIF dialects do not specify explicit constructs for integrity constraints; thus, this use case is not adequately supported by any of these dialects.

</div></div></div><div>

=== Collaborative Policy Development for Dynamic Spectrum Access ===

<div><div lang="en" dir="ltr">

This use case demonstrates how RIF leads to increased flexibility in matching the goals of end-users of a service/device, with the goals of providers and regulators of such services/devices. RIF can do that because it enables deployment of third party systems that can generate various suitable interpretations and/or translations of the sanctioned rules governing a service/device.

This use case concerns ''Dynamic Spectrum Access for wireless communication devices''. Recent technological and regulatory trends are converging toward a more flexible architecture in which reconfigurable devices may operate legally in various regulatory and service environments. The ability of a device to absorb the rules defining the policies of a region, or the operational protocols required to dynamically access available spectrum, is contingent upon those rules being in a form that the device can use, as well as their being tailored to work with devices in the same class having different capabilities.

In this use-case we suppose a region adopts a policy that allows certain wireless devices to opportunistically use frequency bands that are normally reserved for certain high-priority users. ([http://europa.eu.int/eur-lex/lex/LexUriServ/site/en/oj/2005/l_187/l_18720050719en00220024.pdf The decision] by the European Union to allow "Dynamic Frequency Selection" (DFS) use of the 5 GHz frequency band by wireless systems, a band intermittently used by military and weather radar, is a recent example.)

Suppose the policy states:

<pre width=130>
A wireless device can transmit on a 5 GHz band if no priority user is currently using that band.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>

<br />Note, since default negation (not) such as negation as failure is not supported by RIF BLD there is no adequate way to represent that "no priority user is currently using the band".
</p>

How does a device know that no priority user is currently using a band it wants to use? The answer will depend on the specific capabilities of the device. One type of device may answer this question by sensing the amount of energy it is receiving on that band. That is, it might employ the rule:

<pre width=130>
If no energy is detected on a desired band then assume no other device is using the band.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
Forall ?device ?band ?level (<br />
ex:used(?device ?band) :- <br />
ex:detect(ex:energy(?level ?band))<br />
External(pred:numeric-greater-than(?level 0))<br />
)<br />
)<br />
)<br />
</code>
<br />Note, the engergy detection function would require an external call for sensing the level of energy. Such procedural attachments cannot be specified in BLD. Reaction rules provide event detection capabilities.
</p>

A second type of device, may get information from a control channel that lets it know whether the desired band is being used by a priority user. That is, it might employ the rule:

<pre width=130>
If no control signal indicating use of a desired band by a priority user is detected then assume the band is available.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
Forall ?device ?band ?user (<br />
ex:used(?device ?band) :- <br />
ex:detect(ex:signal(?user ?band))<br />
ex:priority(?user,"high").<br />
)<br />
)<br />
)<br />
</code>
<br />
</p>

So each type of device will need to employ different "interpretations" or "operational definitions" of the policy in question.

Now assume that there are 10 manufacturers of these 2 different types of wireless devices. Suppose that each of these manufacturers uses a distinct rule-based platform in designing its devices. Each manufacturer needs to write 2 interpretations of the policy (for each of the two types of device). That means that 20 different versions of the policy must be written, tested and maintained.

Enter RIF. The 10 manufacturers form a consortium. This is a third-party group that is responsible for translating regional policies into RIF. When it does so, however, it provides different versions corresponding to the possible interpretations (operational definitions) of the policy. So in this case, 2 RIF versions of the DFS policy are provided for the 2 types of device mentioned above. Each of these RIF specifications can be automatically translated into the appropriate rule-platform provided a RIF-Compiler for the target device architecture exists. Clearly it will be in the interest of each device manufacturer to develop such compilers. That is because the manufacturer only needs to develop such a compiler ''once'' for every architecture it owns. Contrast that investment with having to produce, test, and maintain different versions of various policies over the lifetime of a product.

This arrangement also allows the overall process to be organized in a fashion that maintains the natural division of labor in the corresponding division of artifacts produced by that labor: the policy and its various interpretations are written and maintained in platform-independent artifacts (RIF); knowledge about how to translate from RIF to a particular device architecture is maintained in the compilers. A change in policy is inserted at the top level in the policy artifact hierarchy where it should be; possible operational interpretations of that change are inserted at the next level down; the implementation implications for the various device architectures is generated automatically at the lowest level.

'''Partly supported by: RIF PRD'''

The energy detection function specified in this use case would require an external call to a device that would sense the level of energy. Such procedural attachments cannot be specified in the current RIF dialects. Reaction rules support (complex) event detection capabilities on, e.g., event streams over sensor data.

This use case is not supported at all by RIF BLD, and by extension, by RIF Core. These dialects do not support negation, and
the use case makes explicit mention of negation, e.g. for representing that "no priority user is currently using the band."<br />

</div></div></div><div>

=== Access to Business Rules of Supply Chain Partners ===

<div><div lang="en" dir="ltr">

A business process (BP) designer designs processes that can span multiple departments in the same business as well as other business partners. A classic example of this is the integration of supply chain business processes which typically involve multiple partners. Supply chain integration involves exposing a certain amount of business logic between partners as well as integrating processes across partners. In such activities it is therefore often necessary to access or invoke rules that originate in other ownership domains.

A key part of a business process is the logic used to make decisions within the process. Such logic is often coded in rules because rule languages are easier for BP designers to understand and manipulate than procedural code (as in Java) -- although both forms of business logic are prevalent. Where business logic is represented in different rule languages this presents a significant burden to the BP designer in designing an integrated process.

Two primary integration modalities are possible: importing the different rulesets into a single engine and processing them in a uniform manner, or accessing the rulesets by querying remote engines and processing the results. Each modality has its uses and contra-indications. Where there are strong ownership boundaries involved it may not be permitted to merge rule sets of partners.

For example, in an insurance adjustment process, the inspection of a damaged vehicle is often performed by independent inspectors. The critical decision in how an insurance claim will proceed is whether the damage results in a total loss or whether a repair is feasible:

<pre width=130>
If inspector believes vehicle is repairable then process as repair otherwise process as total loss.
</pre>

The question of whether a vehicle is repairable is one that is dependent on the processes executed by the inspector and cannot be directly integrated into the insurance companies own adjustment process. The insurance company effectively queries the inspector's logic. Within the adjustment process, the overall flow will be quite different for repairable claims and total loss claims.

Even in the case of a single company, which is nominally under a common ownership domain, information and business logic is often controlled by multiple stakeholders. For example, a large company will often be organized into semi-independent profit centers (business units). Each unit will be motivated differently, will have different ontologies and business logic and may use different rule languages to represent their logic (this is particularly the case where one company acquires another company).

RIF should be used to permit the BP designer a unified view of the different partners' business rules in designing the process, while at the same time permitting the partners to continue to leverage their own business rules without changing their own technologies.

How such a unified view of the business rules can be realized in a deployed BP will depend on both technical and non-technical factors. Even where all the parties are required to use a common rule language, there may be compelling ownership issues that mitigate against a simple merge of the rule sets. In the situation where merging of rulesets is not possible, then a query-style access to partners' business rules may be used. In this way, RIF permits a unified dynamic view of the business rule logic no matter what the original form of the rules.

For this to be viable from a business perspective it is critical that the semantics of the rules and query exchange be completely predictable and preferably loss-less.

'''Not supported, in a straightforward manner, by the current RIF dialects'''

BLD and PRD do not support modal operators or predicates on quoted sentences; therefore standard representations of knowledge, belief, and/or uncertainty cannot be specified in BLD and PRD. Even without such constructs, it can be possible to represent knowledge or belief using the semantics of possible worlds <nowiki>[</nowiki>[[#moore|Moore1980]]]. That is, one can get the effect of saying that an agent A believes proposition P by saying that P holds in all words that are belief-accessible to P. For example, to get the effect of saying

<pre width=130>Believe(john,overCreditLimit(bill,t))
</pre>

one says instead

<pre width=130>
holds(overCreditLimit(bill),t1) :- beliefAccessible(john,t,t1)
</pre>

The translation between sentences involve operators such as Know and Believe and sentences that make direct use of possible worlds relies on the possible-worlds semantics, which posits properties on the knowledge-accessibility or belief-accessibility relation. These relations correspond to axioms on the Know and Believe operators.

<p>
Such a strategy could work, to a certain extent, in RIF PRD, but would not work in RIF BLD. This is because expressing the standard axioms on belief or knowledge would require the use of negation, which is not supported by BLD.

For both PRD and BLD there is an additional consideration, which is that the notion of reification is in general not supported by the dialects of RIF.

</p>

</div></div></div><div>

=== Managing Inter-Organizational Business Policies and Practices ===

<div><div lang="en" dir="ltr">

This use case concerns organizations that acquire rule sets from external sources and that have to integrate these new rule sets into their existing rule bases. Such rule sets may be acquired in the following ways:

* An organization may buy rule sets from expert sources
* An organization may use rule sets from shared interest groups such as trade associations
* A component of a distributed organization may acquire rules when a rule set is distributed across a distributed organization. In such case, there may be different localization requirements in different regions and locations, entailing a variety of integration challenges in these various locations and component organizations.

The following scenario examines these different methods of acquisition and the various types of integration and management issues that may arise.

''This scenario uses the (fictitious) car rental company, EU-Rent, used as the case study in the [http://www.omg.org/spec/SBVR/1.0/ Semantics of Business Vocabulary and Business Rules Specification]. The EU legislation discussed is also fictitious, as are the consulting companies CarWise and AutoLaw.''

EU-Rent's corporate HQ deals with CarWise, a consulting company with expertise in managing fleets of vehicles. One service CarWise offers to its clients is negotiating with EU regulators to clarify regulations.

An EU regulator issues a directive dealing with insurance for vehicles owned by corporations. CarWise agrees with the regulator on an acceptable interpretation, and provides EU-Rent (and its other car rental clients) with two sets of rules:

* A business policy, stating that every car rental must be insured for damages to third parties.
* A supporting rule set, addressing levels of required coverage, tax calculation in different EU countries, liabilities in rentals that span multiple countries, and reporting of compliance with this business policy.

EU-Rent decides that it will maintain its compliance documentation electronically. CarWise then provides EU-Rent with an additional rule set for electronic compliance documentation, including such rules as:

<pre width=130>
Each tax schedule must have electronic signatures from two EU-Rent employees who are at least at the level of manager.
</pre>

Before it can use the two general rule sets, EU-Rent needs to connect them to the relevant data sets in its IT systems, e.g. relate the EU country-specific taxation rules to the relevant record types in its databases.

EU-Rent corporate HQ subsequently decides that the cost of third-party insurance will be built into the basic cost of each rental, and not shown as a separate item on the rental contract, to ensure that it can never be omitted from rentals or disputed by renters. It then sends three rule sets to its operating companies in the EU:

* The rule set for car rental insurance (from CarWise), including the basic policy and the supporting rule set.
* The rule set for electronic compliance documentation (also from CarWise).
* Its own rule set for building insurance into the basic rental cost.

The operating companies then have to localize the rule sets for their countries of operation. For example, in the UK, another consulting company, AutoLaw, advises EU-Rent of rules for placing aggregate insurance for large fleets with more than one insurer in order to spread the risk, for example:

<pre width=130>
For fleets of more than 200 vehicles, fleet insurance policies must be placed with at least 3 insurers, each of whom covers at least 25% of the risk.
</pre>

A timing issue makes it difficult for EU-Rent UK to strictly comply with this directive. EU-Rent UK has some existing insurance policies in place, which provide third-party insurance as an explicit item, and it cannot get refunds on early termination. It therefore asks corporate HQ for a temporary dispensation: that it can continue its existing insurance until it expires, and then switch to the new rules.

EU-Rent HQ permits this, not just for the UK, but for any of its operating companies that have similar insurance arrangements. To ensure that this dispensation is temporary, it adds a new rule:

<pre width=130>
Insurance policies that provide separate third-party coverage must not be renewed.
</pre>

EU-Rent HQ is also concerned about meeting deadlines for electronic filing. It introduces a new rule that it distributes to operating companies:

<pre width=130>
Each electronic compliance document must have its required electronic signatures 48 hours before its filing deadline.
</pre>

This rule is meant to be implemented as follows: If '48 hours before filing deadline' passes, and the electronic signatures are not present, then the operating company's rules system must report the out-of-compliance situation, and subsequently wait for the responsible managers to provide the signatures.

'''Partially supported by RIF PRD'''

The business rules in this use case express norms which requires the representation of deontic operators for obligations and permissions. Deontic operators are generally represented by modal operators, as in <nowiki>[</nowiki>[[#ref-Horty-deontic-logic|Horty2001]]]. As was discussed above, for Know and Belief, it is not possible to express modal operators directly within RIF dialects. However, one can use the technique discussed above, of reasoning directly within possible worlds. This is possible within PRD though not within BLD or Core.

Moreover, in a meta programming approach it is possible to express deontic reasoning rules with RIF PRD. Using this approach, too, one would not be able to use BLD or Core, since some business rules express negated deontic norms.

=== Ruleset Integration for Medical Decision Support ===

<div><div lang="en" dir="ltr">

Decision support systems aid in the process of human decision making, especially decision making that relies on expertise. Reasoning with rules is an important part of this expert decision making. For complex decision support systems, it is expected that rules will be furnished by a variety of different sources, including ontologies, knowledge bases, and other expert systems. This use case illustrates how RIF makes it possible to merge rulesets from diverse sources in diverse formats into one rule-based system, thereby enabling inferences that might otherwise have remained implicit.

Medical decision support systems, such as the ones discussed below, might use rules from pharmaceutical knowledge bases, laboratory knowledge bases, patient databases, and medical ontologies. For example, a large amount of information on therapeutic medications (drug taxonomies, indications, contraindications, and clearance times) and diseases (disease taxonomies, etiologies, and symptoms) is contained in existing ontologies such as [http://www.snomed.org SNOMED] Clinical Terms®. Rules can be used to express therapeutic recommendations, to formulate queries about relevant prescriptions for a patient, and to assess the effectiveness of a treatment.

The following scenario illustrates how rule-interchange would be used in various medical decision support systems to support the following functionalities:

* Improving situation assessment, e.g., determining when a patient needs to be put on medication, or have his medication switched.
* Prescribing a course of action, e.g., determining which drug is best for a patient in a particular circumstance.
* Improving event planning, e.g., determining whether a patient can be scheduled for a procedure given the medication that he is currently taking.

Bob, 62 years old and reasonably healthy, has been going to his internist, Dr. Rosen, for several years for control of his Type II diabetes. Dr. Rosen has been using the <tt>AutoDoc</tt> system to help him decide when to switch to medications and which drugs to prescribe. The <tt>AutoDoc</tt> system uses two sources when making its recommendations: a laboratory knowledge base giving particular results for patients and specifying when these results are out of normal range, and a pharmaceutical knowledge base giving guidelines for the use of medications. Automated reasoning with rules from these combined sources is possible if the rules are first mapped to RIF. Here are two specific examples of such synergistic effects.

''This scenario discusses the fictitious expert systems <tt>AutoDoc</tt> and MEDIC. In the interest of readability and brevity, the information and rules presented in the following scenario may not precisely capture the current state of medical knowledge and best practices in this field, but may be somewhat simplified.''

Originally Bob's diabetes was controlled through diet and moderate exercise. In time, however, Bob's blood glucose level began to rise, even under this regimen. Due to Bob's elevated <tt>HbA1c</tt> level (which indicates one's average blood sugar level over the last several months), Dr. Rosen prescribed oral medication for Bob. He was forced to change Bob's medication a number of times over the course of a year. He first prescribed Precose, an oral alpha-glucosidase inhibitor, but had to discontinue this medication due to undesired side effects. He then prescribed several sulfonylurea drugs, Micronase and Glucotrol, to no avail. Bob's lab results still indicated an elevated <tt>HbA1c</tt> level. The following rule from the ''laboratory knowledge base'' suggests that Bob's treatment at that time was not effective:

<pre width=130>
If a Type II diabetes patient's current level of HbA1c is high, then the patient's current treatment is considered to be ineffective.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations and an event calculus axiomatization:<br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
Forall ?Patient ?Treatment ?Level ?T (<br />
ex:holdsAt(ex:ineffective(?Patient ?Treatment) ?T) :-<br />
ex:holdsAt(ex:hasDisease(?Patient "diabetesTypeII") ?T)<br />
ex:holdsAt(ex:elevated(levelOf(?Patient "hbA1c" ?Level)) ?T)<br />
ex:holdsAt(ex:treatmentPlan(?Treatment ?Patient) ?T)<br />
)<br />
)<br />
)<br />
</code>
<br />Note, the example requires the formalization of changeable states which can be represented by an event calculus axiomatization. [[#event-calculus|KS86]]] The EC axioms can then be represented using RIF BLD.
</p>

To deal with this problem, Dr. Rosen was about to prescribe Glucophage (metformin, one of the biguanides) 850 mg, 3 times a day, when as usual, he double checked his prescription with the <tt>AutoDoc</tt> system. The system, based on the following guidelines from the ''pharmaceutical knowledge base'', informed Dr. Rosen that he should have prescribed an oral bitherapy (two medications, each of which controls blood sugar levels) instead of a monotherapy.

<pre width=130>
If an oral monotherapy at recommended doses of a sulfonylurea or biguanide, combined with lifestyle changes, is ineffective, then the monotherapy should be replaced by an oral bitherapy.
</pre>

Based on the recommendation from <tt>AutoDoc</tt>, Dr. Rosen switched Bob's prescription to Glucophage and Avandia (rosiglitazone, one of the thiazolidinediones).

Bob recently suffered a concussion and has become increasingly forgetful. He went to see a neurologist, Dr. Cervello, who prescribed a contrast MRI (Magnetic Resonance Imaging). When asked about current medication, Bob told Dr. Cervello that he was taking Glucotrol to control his diabetes, forgetting that he had been switched to Glucophage. This was potentially problematic, since Glucophage should not be taken close to the administration of a contrast injection.

Fortunately, when Bob went to the lab to schedule his MRI, the medical receptionist pulled up MEDIC (Medical Event and Drug Interaction Consultant), the hospital's new automated system, which checks for incompatible medical events and/or drugs (e.g., liposuction scheduled during pregnancy, blood thinners prescribed before surgery, etc.).

MEDIC uses a variety of sources in its reasoning, including:

* the pharmaceutical knowledge base, described above
* the patient databases, which gives the patient record, including the medications a patient is currently taking
* the hospital medical event protocol knowledge base, which details the protocol used for different medical procedures

In this case, MEDIC uses all three sources, and pulls up the following information:

* Metformin is contraindicated with contrast dye.
* Metformin is the generic form of Glucophage.
* Bob is taking Glucophage.
* The contrast MRI requires as one of its steps injecting the patient with contrast dye.

MEDIC therefore determines that Bob should not be taking the contrast MRI at this time.

For MEDIC to work, the rules from these different sources must be mapped to a unified interchange format.

'''Supported by RIF PRD'''

The use case requires the formalization of changeable states (fluents) which can be represented by e.g. an event calculus axiomatization <nowiki>[</nowiki>[[#event-calculus|KS86]]]. However, to formulate the classical event calculus as a set of Horn clause rules, so that it could be run as a Prolog program, negation as failure is needed, which is not supported by RIF BLD.
The use case can be represented in RIF PRD which supports changeable states (modifications) and assertions and retractions of knowledge.

</div></div></div><div>

=== Interchanging Rule Extensions to OWL ===

<div><div lang="en" dir="ltr">

Rules are often used in conjunction with other declarative knowledge representation formalisms, such as ontology languages (e.g. RDF and OWL), in order to provide greater expressive power than is provided by either formalism alone. Ontology languages, for example, typically provide a richer language for describing classes (unary predicates). Rules, on the other hand, typically provide a richer language for describing dependencies between properties (binary predicates), and may also support higher-arity predicates.

Rich domain models combining both rules and ontologies are often needed in domains such as medicine, biology, e-Science and Web services. In such domains, several actors and/or agents are involved that have to interchange the data, ontologies, and rules that they work with. An example is the use of such a domain model in an application that aims at assisting the labeling of brain cortex structures in MRI images. In this case, an OWL ontology is used to capture knowledge about the most important brain cortex anatomical structures, and a rule base is used to capture knowledge about mereological and spatial dependencies between properties.

For example, a rule is used to express the dependency between the ontology properties isMAEConnectedTo and isMAEBoundedBy, in particular (a simplified form of) the knowledge that two Material Anatomical Entities having a shared boundary are connected:

<pre width=130>
If MAE X is bounded by Z and MAE Y is also bounded by Z then X is connected to Y.
</pre>

Benefits of interchange via RIF include the ability to collaboratively develop and share valuable knowledge, the ability to integrate anatomical images, possibly from distributed image sources, and the ability to use large-scale federated systems for statistical analysis of brain images of major brain pathologies.

'''Supported by RIF Core, RIF BLD and RIF PRD'''

The use case uses RIF SWC to combine RIF Rules with OWL ontologies.
</div></div></div><div>

=== Vocabulary Mapping for Data Integration ===

<div><div lang="en" dir="ltr">

This use case concerns the integration of information from multiple data sources. The Semantic Web provides a common data representation and query language, which greatly simplifies access to diverse sources but does not directly address the problem that independent data sources may have rather divergent information models.

Rules are an effective way to express mappings between such information models. However, rules locked within local proprietary systems cannot be reused. With a common rule representation, such mappings can be published across the Semantic Web, enabling an enterprise or community to progressively build up a rich network of mappings unifying the information models.

Information mapping and integration problems like this arise in many diverse domains including health care, travel planning, IT management and customer information management. The following scenario comes from the world of IT systems management.

Vlad has been given the job of analyzing how exposed his division's business processes are to changes in their IT maintenance contracts. He has three sources of information to combine:

* a report on application services and associated servers, databases and networks (from the IT department)
* a maintenance contracts database (from the finance department)
* a registry indicating which business processes use which IT services (from the business planning group)

Each of these sources is in a different form but can be mapped into RDF to simplify access. However, they all have different information models. The IT report is too fine-grained: it talks about routers and interface cards whereas Vlad only needs to identify servers and pick out some generic dependency relations. On the other hand, the finance database models the world in terms of physical assets such as racks, which is too coarse-grained.

First, Vlad creates simple mapping rules to create a uniform, simplified view of the data in terms of a small number of concepts -- Server, Business<tt></tt>Process and Dependency. This involves rules such as:

<pre width=130>
If x is a ComputeNode in Rack r
and Rack r is in Cage c
and mc is a MaintenanceContract for Cage c
then x is a Server with MaintenanceContract mc

If x is a ComputeNode with a NetworkInterface with Port p
and app is an Application running on Port p
then x is a Server that hosts app

If bp is a BusinessProcess that uses Application app
then bp has a Dependency on app
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Forall ?X ?MC ?R ?C(
?X[rdf:type->ex:Server ex:maintenanceContract->?MC] :- And(
?X[rdf:type->ex:ComputeNode ex:location->?R] ?R#ex:Rack
?R[ex:location->?C] ?C#ex:Cage
?C[ex:maintenanceContract->?MC] ?MC#ex:MaintenanceContract ))

Forall ?X ?Ni ?P ?App (
?X[rdf:type->ex:Server ex:hosts->?App] :- And(
?X[rdf:type->ex:ComputeNode ex:networkInterface->?Ni]
?Ni[ex:port->?P] ?P#ex:Port
?App[rdf:type->ex:Application ex:onPort->?P]))

Forall ?App ?BP (
?BP[ex:dependsOn->?App] :-
?BP[rdf:type->ex:BusinessProcess ex:processUses->?App] ))
</code>
<br />
</p>

He then creates rules that combine the data across his now simplified data sources, e.g.

<pre width=130>
If bp is a BusinessProcess that has a Dependency on Application app
and x is a Server with MaintenanceContract mc that hosts Application app
then bp has a Dependency on mc
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Forall ?App ?BP ?App ?MC(
?BP[ex:dependsOn->?MC] :- <
?BP[rdf:type->ex:BusinessProcess ex:dependsOn->?App] ?App#ex:Application
?X[rdf:type->ex:Server ex:hosts->?App ex:maintenanceContract->?MC] ))
</code>
<br />
</p>

This gives him a uniform view that links from business processes through to the IT and finance data. Vlad publishes these rules so that other people across the company can reuse them to construct similar views.

'''Supported by RIF BLD and RID PRD'''

</div></div></div><div>

=== BPEL Orchestration of Rule-Based Web Services ===

<div><div lang="en" dir="ltr">

Rule-based Web services depend on the use of XML data for their request and response format. The involved rules must be able to access and compare XML data in their conditions and modify and generate XML data in their actions.

An existing commercial credit approval service deployed as a Web service takes an applicant credit request document as input and returns an approval or denial (with reason). It is implemented as a BPEL orchestration of two Web services -- a credit history providing service and a decision service containing a rules engine. BPEL first passes the credit request document to the decision service to determine, using rules, whether enough information (SSN, mother's maiden name, etc.) is available to request a credit history. If so, BPEL then requests a credit history from the history providing service and passes the credit history document to the decision service to be evaluated. Based on the evaluation, credit is approved or denied.

Because the rule engine is part of a Web service, existing BPEL diagramming and execution facilities can be used to integrate rules into this credit approval service. The credit evaluation model can be changed easily using GUI tools to customize rules. Use of RIF would improve the situation further. First, the credit history vendor could supply a default set of rules for evaluating its histories. Second, there would be several rule editing and customization tools from different RIF compatible vendors to tailor the rules to meet specific business objectives.

The credit evaluation rules are themselves grouped into three rulesets that are executed sequentially. Rules in the first ruleset apply thresholds to several "red flag" quantities in the credit report, such as:

* number of times a payment was 60 days late
* debt-to-income ratio
* number of foreclosures or repossessions
* number of garnishments
* number of liens
* bankruptcy

A red flag above the threshold results in denial of credit.

Rules in the second ruleset increment a credit score variable. For example:

<pre width=130>
If applicant owns residence then add 40.
If applicant rents then add 30.
If applicant has lived at current address 2 to 4 years then add 20.
If applicant's income is under 20000 then add 10.
If applicant's income is between 40000 and 50000 then add 40.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;">Document(<br />
<br />
Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(prolog_func <nowiki>http:</nowiki>//example.org/2007/rif-prolog-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
ex:score(0)<br />
<br />
ex:score(?Applicant ?Score) :-<br />
ex:increment(?Applicant)<br />
ex:score(?Score)<br />
prolog_func:retract(ex:score(?Score))<br />
prolog_func:assert(ex:score(0)). <br />
<br />
ex:increment(?Applicant) :- <br />
ex:owns(?Applicant)<br />
ex:score(?Score)<br />
prolog_func:retract(ex:score(?Score))<br />
?NewScore = ?Score + 40<br />
prolog_func:assert(ex:score(?NewScore)).<br />
<br />
ex:increment(?Applicant):- <br />
ex:rents(?Applicant)<br />
ex:score(?Score)<br />
ex:retract(score(?Score))<br />
?NewScore = ?Score + 30<br />
prolog_func:assert(score(?NewScore)).<br />
<br />
ex:increment(?Applicant):-<br />
ex:lives(?Applicant ?Date),<br />
$sysTime(?CurrentDateTime)<br />
?CurrentYear = $fn:year-from-dateTime(?CurrentDateTime)<br />
?Year = $fn:year-from-dateTime(?Date)<br />
?Diff = ?CurrentYear - ?Year<br />
?Diff > 1<br />
?Diff < 5<br />
ex:score(?Score)<br />
prolog_func:retract(score(?Score))<br />
?NewScore = ?Score + 20<br />
prolog_func:assert(ex:score(?NewScore)).<br />
<br />
ex:increment(?Applicant):- <br />
ex:income(?Applicant ?Income)<br />
?Income < 20000<br />
ex:score(?Score)<br />
prolog_func:retract(score(?Score))<br />
?NewScore = ?Score + 10<br />
prolog_func:assert(ex:score(?NewScore)).<br />
<br />
ex:increment(?Applicant):-<br />
ex:income(?Applicant ?Income)<br />
?Income < 50000<br />
?Income > 40000<br />
ex:score(?Score)<br />
prolog_func:retract(ex:score(?Score))<br />
?NewScore = ?Score + 40<br />
prolog_func:assert(ex:score(?NewScore)).<br />
</code>
<br />A goal-driven solution which makes use of assert and retract (not supported by BLD) to update a global score value, which is stored in a fact.
</p>

The third and final ruleset compares the applicant's credit score and income to threshold values, and makes the final decision to approve or deny credit to the applicant.

The decision and supporting rationale is returned from the decision service as an XML document. This decision document is then used to construct the reply to the original credit approval request.

'''Supported by RIF PRD'''

This use case requires a goal-driven solution which makes use of assert and retract to update a global score value. Assert and retract are not supported by BLD; indeed, there is no such similar notion within BLD.

</div></div></div><div>

=== Publishing Rules for Interlinked Metadata ===

<div><div lang="en" dir="ltr">

The Semantic Web includes technologies (e.g., RDF) that allow metadata to be published in machine-readable form. Currently, this information is mostly enumerated as a set of facts. It is often desirable, however, to supplement such facts with rules that ''capture implicit knowledge''. To maximize the usefulness of such published rules, a standard rule format such as RIF is necessary.

One case involves extending current standards for metadata publication with rules in order to express implicit knowledge. Suppose that the International Movie Database (IMD) publishes its metadata and rules in a machine readable format at <nowiki>http://</nowiki>imd.example.org. Besides the ground facts, which can be expressed in RDF, the metadata might also have general rules like the following:

<pre width=130>
Every science fiction movie is a movie.
Every movie produced before 1930 is black and white.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD (Abridged) Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> ?Movie#ex:Movie :-<br />
?Movie#ex:ScienceFictionMovie.<br />
<br />
?Movie#ex:BlackWhiteMovie :-<br />
?Movie#ex:Movie[ex:date -> ?Date]<br />
?Date < "1930"^^xs:dateTime.<br />
</code>
<br />
</p>

Such rules allow data to be published more concisely by expressing knowledge that, without these rules, is implicit. This can greatly simplify the maintenance of data, guard against inadvertently introduced inconsistencies, and reduce storage requirements.

Published rules also allow combining data from different sources to exploit this knowledge. Consider an alternative database of movies published at <nowiki>http://</nowiki>altmd.example.org. In addition to metadata, it again publishes its own rules:

<pre width=130>
All movies listed at <nowiki>http://</nowiki>altmd.example.org but not listed at <nowiki>http://</nowiki>imd.example.org are independent movies.
All movies with budgets below 5 million USD are low-budget movies.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD (Abridged) Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> ?Movie#ex:IndependentMovie :-<br />
listed(?Movie#ex:Movie,<<nowiki>http:</nowiki>//altmd.example.org>)<br />
not(listed(?Movie#ex:Movie,<<nowiki>http:</nowiki>//imd.example.org>)). <br />
<br />
?Movie#ex:LowBudgetMovie :-<br />
?Movie#ex:Movie [date -> ?Date, budget -> ?Budget]<br />
?Budget < 5000000^^xs:long.<br />
</code>
<br />
</p>

Publication of rules with explicit references to other rulesets allows the definition of knowledge dependent on explicitly specified remote sources. Such explicitly specified ''scope'' is important in the Web environment, since it can reduce the danger of unintended interference from rules published at other remote sources, which may be exporting their own predicates.

Another example of such explicit referencing, which also illustrates implicit person-centric metadata, involves published rules being used to specify how to use other metadata, e.g. in the form of a widespread vocabulary such as FOAF or a standard exchange format like iCalendar. For example, FOAF user Charlie might choose to complement his normal FOAF profile with his preferences about which of his phone numbers should be used depending on his iCalendar schedule:

<pre width=130>
If Charlie is currently attending a public talk according to <nowiki>http://</nowiki>charlie.example.org/calender.ical
then leave him a voicemail message

If Charlie is currently in a meeting according to <nowiki>http://</nowiki>charlie.example.org/calender.ical
and the importance is high
then call his cell number

If Charlie currently has no appointments according to <nowiki>http://</nowiki>charlie.example.org/calender.ical
then call his office number
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD (Abridged) Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> contactInfo("Charlie" ?ContactInfo) :-<br />
sysTime(?Time)<br />
attending("Charlie" "talk" ?Time)<br />
contact("Charlie" "voicemail" ?ContactInfo).<br />
<br />
contactInfo("Charlie" ?ContactInfo) :-<br />
sysTime(?Time)<br />
attending("Charlie" "meeting" ?Time)<br />
contact("Charlie" "cell number" ?ContactInfo).<br />
<br />
contactInfo("Charlie", ?ContactInfo) :-<br />
sysTime(?Time),<br />
not(attending("Charlie",?Event, ?Time)),<br />
contact("Charlie", "office number", ?ContactInfo).<br />
<br />
<br />
sysTime(?Time) :-<br />
% get the actual system time e.g. via a built-in<br />
% or procedural attachment call to Java or C++.<br />
?Time = External(call(java.util.Calendar().getInstance())).<br />
<br />
<br />
attending("Charlie","talk", ?CurrentTime) :-<br />
% getEventData would implement the functionality to dynamically access and query<br />
% <nowiki>http:</nowiki>//charlie.example.org/calender.ical<br />
getEventData(<<nowiki>http:</nowiki>//charlie.example.org/calender.ical>,?EventTitle,?Type,?StartDate,?EndDate),<br />
?Type = "talk",<br />
External(op:dateTime-less-than(?CurrentTime,?EndDate),<br />
External(op:dateTime-greater-than(?CurrentTime,?StartDate).<br />
<br />
<br />
attending("Charlie","meeting", ?CurrentTime) :-<br />
getEventData(<<nowiki>http:</nowiki>//charlie.example.org/calender.ical>,?EventTitle,?Type,?StartDate,?EndDate),<br />
?Type = "meeting",<br />
External(op:dateTime-less-than(?CurrentTime,?EndDate),<br />
External(op:dateTime-greater-than(?CurrentTime,?StartDate).<br />
<br />
<br />
<br />
contact("Charlie", "voicemail", ?ContactInfo) :-<br />
% retrieve the Voice mail number, e.g. from<br />
% Charlie's vCard, <br />
% e.g. xmlns:vCard = "<nowiki>http://www.w3.org/2001/vcard-rdf/3.0#"</nowiki><br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard:FN> -> "Charlie"],<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard_TEL> -> ?Telephone],<br />
?Telephone[<rdf:type> -> <nowiki><http://www.w3.org/2001/vcard-rdf/3.0#voice></nowiki>],<br />
?Telephone[<rdf_value> -> ?ContactInfo].<br />
<br />
contact("Charlie", "cell number", ?ContactInfo) :-<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard:FN> -> "Charlie"],<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard_TEL> -> ?Telephone],<br />
?Telephone[<rdf:type> -> <nowiki><http://www.w3.org/2001/vcard-rdf/3.0#cell></nowiki>],<br />
?Telephone[<rdf_value> -> ?ContactInfo].<br />
<br />
contact("Charlie", "office number", ?ContactInfo) :-<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard:FN> -> "Charlie"],<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard_TEL> -> ?Telephone],<br />
?Telephone[<rdf:type> -> <nowiki><http://www.w3.org/2001/vcard-rdf/3.0#work></nowiki>],<br />
?Telephone[<rdf_value> -> ?ContactInfo]. <br />
</code>
<br />
</p>

RIF should allow extending current standards for metadata publication by enabling such implicit knowledge to be captured via rules and allowing metadata and rules distributed over different sources to be interlinked. In a manner similar to how HTML links human-readable Web pages, RIF should permit linking metadata on the Web to support new kinds of "intelligent" crawling and search.

'''Supported by RIF PRD'''

Since negation is not supported by RIF BLD it is not possible to express ''... but not listed at ...''.

</div></div></div></div><div>

== Conclusion ==

<div><div lang="en" dir="ltr">

The goal of the RIF working group is to provide representational interchange formats for processes based on the use of rules and rule-based systems. These formats act as "interlingua" to interchange rules and integrate with other languages, in particular (Semantic) Web mark-up languages.

As can be seen by studying the use-cases presented in this document, rules are used to perform a wide variety of tasks, and, therefore, rule-based systems are not monolithic. Rules have been used to perform or validate inference, perform calculations, direct the flow of information, enforce integrity constraints on databases, represent and enforce policies, control devices and processes in real-time, determine the need for human intervention, and so on.

In light of this diversity, rather than being a single all-encompassing format, RIF consists of several dialects, each dialect serving a particular set of related rule languages. The key idea is to attain the goal of interoperability (via interchange of RIF rules) ''within'' each dialect. This should allow the main benefits of RIF to be realized. For example, the invariant meaning of a set of integrity-constraint-enforcing rules would be represented within the appropriate RIF dialect and could then be translated into the native format of any of the formalisms capable of representing such rules.

RIF has been designed in such a way that it is possible to create new dialects (extensibility) according to the overall goals and the general requirements of RIF, as well as to update existing dialects (upwardly compatible). This is in keeping with the working group charter's call for an extensible format.

</div></div></div>

</div><div>

== References ==

<div><div lang="en" dir="ltr">

<span id="ref-Horty-deontic-logic" class="anchor"></span>

; [Horty2001]
: ''Agency and Deontic Logic'', John F. Horty, Oxford University Press, 2001.

<span id="event-calculus" class="anchor"></span>
; [KS86]
: Kowalski, R.A. and M.J. Sergot, ''A logic-based calculus of events.'' New Generation Computing, 1986. 4: p. 67-95.

<span id="moore" class="anchor"></span>
; [Moore80]
: Moore, R.C., ''Reasoning about Knowledge and Action,'' SRI TR-191, 1980.

</div></div></div>

<div>

== Appendix: Change Log (Informative) ==

<div><div lang="en" dir="ltr">

This appendix summarizes the main changes to this document since its publication as a Working Draft.

Changes since the [http://www.w3.org/TR/rif-ucr/ draft of December 18th, 2008]:
* [[#Structure_of_RIF|section describing the structure of RIF]] updated with the new RIF documents;
* all code examples are removed from the document
* each use cases has a new paragraph at the end which discusses the support of the use case by the current RIF dialects Core, BLD and PRD
* added an informative change log section
* flattened the list of requirements removing the distinction between general and basic requirements

</div></div></div></div>

</div>

UCR

Sandro — Tue, 11 Dec 2012 14:11:34 GMT

Sandro: fix link to rif primer

__NUMBEREDHEADINGS__
{{TR|title=RIF Use Cases and Requirements}}
<div id='editors'>
; Editors:
: Adrian Paschke, Freie Universitaet Berlin
: Leora Morgenstern, SAIC
: David Hirtle, National Research Council Canada
: Allen Ginsberg, Mitre
: Paula-Lavinia Patranjan, REWERSE
: Frank <nowiki>McCabe</nowiki>, Fujitsu
</div>
; Abstract
: <div id='abstract'><p></p> <p></p> <p></p> <p>This document, developed by the [http://www.w3.org/2005/rules/wg Rule Interchange Format (RIF) Working Group], specifies use cases and requirements for the W3C Rule Interchange Format, a family of rule interchange dialects that allows rules to be translated between rule languages and thus transferred between rule systems. </p> </div>
; Status of this Document
: 3rd revised version of the UCR document

[http://www.w3.org/Consortium/Legal/ipr-notice#Copyright Copyright] © 2010 [http://www.w3.org/ W3C]<sup>®</sup> ([http://www.csail.mit.edu/ MIT], [http://www.ercim.org/ ERCIM], [http://www.keio.ac.jp/ Keio]), All Rights Reserved. W3C [http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer liability], [http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks trademark] and [http://www.w3.org/Consortium/Legal/copyright-documents document use] rules apply.

<div id='docbody'>

<html>
<script type="text/javascript">/*<![CDATA[*/
/*
Written by Jonathan Snook, http://www.snook.ca/jonathan
Add-ons by Robert Nyman, http://www.robertnyman.com
Author says "The credit comment is all it takes, no license. Go crazy with it!:-)"
From http://www.robertnyman.com/2005/11/07/the-ultimate-getelementsbyclassname/
*/

var displayed = [];
displayed["bld"] = 1;
displayed["prd"] = 1;

function display(syntax,status) {
var howmany = 0;
if (status=='none') {
displayed[syntax] = 0;
} else {
displayed[syntax] = 1;
}
for ( i in displayed ) {
howmany = howmany + displayed[i];
}
set_display_by_class('p',syntax,status);
if ( howmany == 1 ) {
set_display_by_class('b','syntax-head','none');
} else {
set_display_by_class('b','syntax-head','');
}
}

function getElementsByClassName(oElm, strTagName, oClassNames){
var arrElements = (! (! (strTagName == "*") || ! (oElm.all)))? oElm.all : oElm.getElementsByTagName(strTagName);
var arrReturnElements = new Array();
var arrRegExpClassNames = new Array();
if(typeof oClassNames == "object"){
for(var i=0; !(i>=oClassNames.length); i++){ /*>*/
arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames[i].replace(/\-/g, "\\-") + "(\\s|$)"));
}
}
else{
arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames.replace(/\-/g, "\\-") + "(\\s|$)"));
}
var oElement;
var bMatchesAll;
for(var j=0; !(j>=arrElements.length); j++){ /*>*/
oElement = arrElements[j];
bMatchesAll = true;
for(var k=0; !(k>=arrRegExpClassNames.length); k++){ /*>*/
if(!arrRegExpClassNames[k].test(oElement.className)){
bMatchesAll = false;
break;
}
}
if(bMatchesAll){
arrReturnElements.push(oElement);
}
}
return (arrReturnElements)
}

function set_display_by_class(el, cls, newValue) {
var e = getElementsByClassName(document, el, cls);
if (e != null) {
for (var i=0; !(i>=e.length); i++) {
e[i].style.display = newValue;
}
}
}

function set_display_by_id(id, newValue) {
var e = document.getElementById(id);
if (e != null) {
e.style.display = newValue;
}
}
/*]]>*/
</script>

</html>

<div> 
== Introduction ==

<div><div lang="en" dir="ltr">

Rule-languages and rule-based systems have played seminal roles in the history of computer science and the evolution of information technology. From expert systems to deductive databases, the theory and practice of automating inference based on symbolic representations has had a rich history and continues to be a key technology driver.

Due to the innovations made possible by the Internet, the World Wide Web, and, most recently, the Semantic Web, there is now even greater opportunity for growth in this sector. While some of these opportunities may require advances in research, others can be addressed by enabling existing rule-based technologies to interoperate according to standards-based methodologies and processes. The basic goal of the Rule Interchange Format (RIF) Working Group is to devise such standards and make sure that they are not only useful in the current environment, but are easily extensible in order to deal with the evolution of rule technology and other enabling technologies. This mission of RIF is part of W3C's larger goal of enabling the sharing of information in forms suited to machine processing:

*# Rules themselves represent a valuable form of information for which there is not yet a standard interchange format, although significant progress has been made within the [http://www.ruleml.org/ RuleML Initiative] and elsewhere.
*# Rules provide a powerful business logic representation, as business rules, in many modern information systems.
*# Rules are often the technology of choice for creating maintainable adapters between information systems.
*# As part of the Semantic Web architecture, rules can extend or complement the OWL Web Ontology Language to more thoroughly cover a broader set of applications, with knowledge being encoded in OWL or rules or both.

The purpose of this RIF-UCR document is to describe the use cases that guided the design of RIF and to document the design requirements that were derived from both the use cases and from the basic goals of RIF. RIF-UCR also delivers a structured context for formulating future technical specifications of further RIF dialects. Each dialect targets at a cluster of similar rule languages and enables platform-independent interoperation between them (via interchange of RIF rules). The presented use cases illustrate some of the principal ways in which RIF can provide benefits. RIF can promote innovation and development by fostering collaborative work and providing new opportunities for third-party services. RIF can promote e-commerce by providing interoperability across vendor platforms. RIF can promote efficient process management through reuse, sharing, and the ability to provide unified views across disparate platforms. Last, but not least, RIF can promote the growth of knowledge by enabling reasoning with merged sets of rules originating from disparate knowledge sources.

The RIF-UCR document is structured as follows: Section 2 formulates the overall goals of RIF. Section 3 summarizes the released RIF dialects and the current structure of RIF. Section 4 discusses several important requirements for RIF dialects. Section 5 presents a set of use cases that are representative of the types of application scenarios that RIF is intended to support. The use cases illustrate the utilization of the current RIF dialects. More importantly, the functionality specified in the use cases, together with the requirements discussed in the previous section, serves as input for both the technical specification of future RIF dialects and for the implementation of various variants of these scenarios by RIF-compliant applications and systems.

Although in this document the discussion of requirements precedes the discussion of the use cases in this document, the development of the use cases preceded, and in fact motivated, the development of the requirements. In general, it is intended that for each requirement, there is at least one use case, or straightforward modification of a use case, from which that requirement was derived. There are some exceptions to this rule: some requirements were already defined as constraints in the working group charter, and were not necessarily derived from any specific use case. The fulfillment of such requirements is discussed with respect to the existing RIF dialects.

Note that in fact not all use cases can be represented in a straightforward manner within all RIF dialects. In particular, several use cases cannot be represented within the RIF dialect BLD. This is due first, to the fact that BLD is strictly less expressive than first-order logic (since negation is not expressible), and second, to the fact that some use cases are most naturally represented in languages more powerful than first-order logic, such as modal logics. Following the presentation of each use case in Section 5 is a note indicating in which of the current RIF dialects a use case can be represented naturally, sometimes accompanied by discussion.

It should be noted that even use cases which cannot be represented in a straightforward manner within some RIF dialect, such as BLD, there may be other approaches which will enable representation. For example, although epistemic operators such as <tt>Know</tt> and <tt>Believe</tt> are most straightforwardly represented within a modal logic, it is generally possible to represent such operators in a first-order logic using a possible-worlds semantics. For certain use cases which cannot be naturally represented within some dialect, the extent to which this can be done will be discussed.

</div></div></div><div>

== Goals ==

<div><div lang="en" dir="ltr">
The primary goal of RIF is to be an effective means of exchanging rules that has the potential to be widely adopted in industry and that is consistent with existing W3C technologies and specifications.

<span id="goal-exchange-of-rules" class="anchor"></span>
==== Exchange of Rules ====

The primary goal of RIF is to facilitate the exchange of rules.

<span id="goal-w3c-consistency" class="anchor"></span>
==== Consistency with W3C specifications ====

RIF is intended to be a W3C specification that builds on and develops the existing range of specifications that have been developed by the W3C. This implies that existing W3C technologies should fit well with RIF.

<span id="goal-widescale-adoption" class="anchor"></span>
==== Widescale Adoption ====

It is an explicit goal of the W3C that the Rules Interchange Format will have the maximum potential for widescale adoption. Rules interchange becomes more effective the wider adoption there is of the specification -- the so-called "network effect".

Along with the use cases in the next section, these goals motivate the requirements in Section 5.

</div></div></div><div>

== Structure of RIF ==

<div><div lang="en" dir="ltr">
RIF is described by a set of documents, each fulfilling a different purpose, and catering to a different audience. The three RIF dialects which can be used to represent RIF use cases are:

* [http://www.w3.org/TR/rif-core RIF Core Dialect], which provides a standard, base level of functionality for interchange
* [http://www.w3.org/TR/rif-bld RIF Basic Logic Dialect] and [http://www.w3.org/TR/2010/REC-rif-prd-20100622/ RIF Production Rule Dialect] provide extended functionality matching two common classes of rule engines, namely derivation rules and production rules.

Along with these three dialects, RIF consists of related documents: [http://www.w3.org/TR/rif-fld RIF Framework for Logic Dialects], [http://www.w3.org/TR/rif-dtb RIF Datatypes and Built-Ins 1.0], [http://www.w3.org/TR/rif-test RIF Test Cases], [http://www.w3.org/TR/rif-rdf-owl RIF RDF and OWL Compatibility], [http://www.w3.org/TR/rif-ucr/ RIF Use Cases and Requirements], [http://www.w3.org/TR/rif-owl-rl OWL 2 RL in RIF], [http://www.w3.org/2007/OWL/wiki/PlainLiteral rdf:PlainLiteral], [http://www.w3.org/TR/rif-xml-data RIF Combination with XML data], [http://www.w3.org/TR/rif-primer RIF Primer] and [http://www.w3.org/TR/rif-in-rdf/ RIF In RDF]. For an overview on RIF see the [http://www.w3.org/TR/rif-overview RIF Overview].

RIF is designed as a family of RIF dialects as shown in the following Venn diagram:

[[Image: RIF_DIALECTS_VENN.jpg | Venn Diagram of RIF Dialects]]

Each dialect is a collection of components that works together, forming an interlingua. New dialects are needed when no existing dialect provides the required rule-language features for interchange.

The RIF Framework for Logic-based Dialects ([http://www.w3.org/TR/rif-fld RIF-FLD]) describes mechanisms for specifying the syntax and semantics of logic-based RIF dialects through a number of generic concepts. Every logic-based RIF dialect should specialize these general mechanisms or justify why it does not. This specialization may include leaving out some elements of RIF-FLD, to produce its concrete syntax and model-theoretic semantics. Currently, the first two existing RIF dialects are the RIF Basic Logic Dialect (RIF-BLD) and the RIF Production Rules Dialect (RIF-PRD) which is a partial specialization of FLD.

[http://www.w3.org/TR/rif-bld RIF-BLD] (Basic Logic Dialect) is a specialization of RIF-FLD capable of representing definite Horn rules with equality enhanced with a number of syntactic extensions to support expressive features such as objects and frames, internationalized resource identifiers (IRIs) as identifiers for concepts, and XML Schema data types.

[http://www.w3.org/TR/rif-prd RIF-PRD] (Production Rules Dialect) specifies a production rules dialect to enable the interchange of production rules. The condition language of RIF PRD is defined in Core as a common subset of RIF BLD and RIF PRD.

[http://www.w3.org/TR/rif-core RIF-Core] (Core Dialect) specifies a common subset of RIF-BLD and RIF-PRD which includes RIF-DTB.

The normative syntax for RIF dialects is a concrete XML syntax. A non-normative presentation syntax is additionally specified for each dialect, to allow a more easily readable and compact presentation of language fragments (such as examples).

</div></div></div><div>

== Requirements ==

<span id="req-semantic-tagging" class="anchor"></span>

<div><div lang="en" dir="ltr">
The goals and use cases motivate a number of requirements for a Rule Interchange Format. The Working Group has approved the following requirements.

<span id="req-implementability" class="anchor"></span>

=== Implementability ===

''RIF must be implementable using well understood techniques, and should not require new research in, e.g., algorithms or semantics in order to implement translators.''

<span id="req-semantic-precision" class="anchor"></span>

=== Semantic precision ===

''RIF core must have a clear and precise syntax and semantics. Each standard RIF dialect must have a clear and precise syntax and semantics that extend RIF core.''

<span id="req-extensible" class="anchor"></span>

=== Extensible Format ===

''It must be possible to create new RIF dialects which extend existing dialects (thus providing backward compatibility) and are handled gracefully by systems which support existing dialects (thus providing forward compatibility).''

<span id="req-translators" class="anchor"></span>

=== Translators ===

''For every standard RIF dialect it must be possible to implement translators between rule languages covered by that dialect and RIF without changing the rule language.''

<span id="req-standard-components" class="anchor"></span>

=== Standard components ===

''RIF implementations must be able to use standard support technologies such as XML parsers and other parser generators, and should not require special purpose implementations when reuse is possible.''

<span id="req-coverage" class="anchor"></span>

=== Rule language coverage ===

''Because of the great diversity of rule languages, no single interchange language is likely to be able to bridge between all. Instead, RIF provides dialects each of which is targeted at a cluster of similar rule languages. RIF must allow intra-dialect interoperation, i.e. interoperability between semantically similar rule languages (via interchange of RIF rules) within one dialect, and should support inter-dialect interoperation, i.e. interoperation between dialects with maximum overlap.''

<span id="req-compliance-model" class="anchor"></span>

=== Compliance model ===

''The RIF specifications must provide clear conformance criteria that define what is or is not a conformant RIF implementation.''

<span id="req-default-behavior" class="anchor"></span>

=== Default behavior ===

''RIF must specify at the appropriate level of detail the default behavior that is expected from a RIF compliant application that does not have the capability to process all or part of the rules described in a RIF document, or it must provide a way to specify such default behavior.''

<span id="req-different-semantics" class="anchor"></span>

=== Different semantics ===

''RIF must cover rule languages having different semantics.''

<span id="req-dialects" class="anchor"></span>

=== Limited number of dialects ===

''RIF must have a standard core, and a limited number of standard dialects based upon that core.''

<span id="req-comments" class="anchor"></span>

=== Embedded comments ===

''RIF must be able to pass comments.''

<span id="req-metadata" class="anchor"></span>

=== Embedded metadata ===

''RIF must support metadata such as author and rule name.''

<span id="req-owl-data" class="anchor"></span>

=== OWL data ===

''RIF must cover OWL knowledge bases as data where compatible with RIF semantics.''

<span id="req-rdf-data" class="anchor"></span>

=== RDF data ===

''RIF must cover RDF triples as data where compatible with RIF semantics.''

<span id="req-dialect-identification" class="anchor"></span>

=== Dialect Identification ===

''The semantics of a RIF document must be uniquely determined by the content of the document, without out-of-band data.''

<span id="req-xml-syntax" class="anchor"></span>

=== XML syntax ===

''RIF must have an XML syntax as its primary normative syntax.''

<span id="req-xml-types" class="anchor"></span>

=== XML types ===

''RIF must support an appropriate set of scalar datatypes and associated operations as defined in XML Schema part 2 and associated specifications.'' See the charter on [http://www.w3.org/2005/rules/wg/charter#datatype0 Datatype support].

<span id="req-merge" class="anchor"></span>

=== Merge Rule Sets ===

''RIF must support the ability to merge rule sets.''

<span id="req-rulesets" class="anchor"></span>

=== Identify Rule Sets ===

''RIF must support the identification of rule sets.''

<span id="req-xml-data" class="anchor"></span>

=== XML data ===

''RIF should be able to accept XML elements as data.''

<span id="req-rif-text" class="anchor"></span>

=== Internationalized text ===

''RIF must support internationalized text — that is, text that additionally conveys information in terms of a language tag.''

</div></div></div><div>

== Use Cases ==

<div><div lang="en" dir="ltr">

A use case for RIF consists of a description of a problem together with a solution that either uses an existing RIF dialect or requires the specification of a new RIF dialect.

The set of use cases is intended to do the following:
<ul>
<li>motivate the need for a RIF in a broad range of application domains and industrial sectors;</li>
<li>provide scenarios that motivate the design of RIF and explain the benefits of a RIF in such scenarios;</li>
<li>guide users to RIF's specified dialects; and</li>
<li>motivate the working group's set of requirements for a RIF.</li>
</ul>

The set of use cases were developed over several years.
Nearly [http://www.w3.org/2005/rules/wg/wiki/Use_Cases fifty use cases] documenting the need for a RIF were originally submitted by the working group members. These were grouped into general categories and then synthesized as much as possible. The goal was to come up with a relatively small set of use cases that would cover a broad range of possible requirements. In addition, it was desired that the use cases refer to popular application domains and industrial sectors. For every use case we will briefly discuss the coverage of the use case by the existing three RIF dialects (Core, BLD, and PRD).



</div></div>

<div>

=== Negotiating eBusiness Contracts Across Rule Platforms ===

<div><div lang="en" dir="ltr">

This use case illustrates a fundamental use of RIF: to supply a vendor-neutral representation of rules, so that rule-system developers and stakeholders can do their work and make product investments without concern about vendor lock-in, and in particular without concern that a business partner does not have the same vendor technology. It also illustrates the fact that RIF can be used to foster collaborative work. Each developer and stakeholder can make a contribution to the joint effort without being forced to adopt the tools or platforms of the other contributors.

John is negotiating an electronic business contract regarding the supply of various types of items that Jane's company is manufacturing. Jane and John interchange the contract-related data and rules involved in the negotiation in electronic form so that they can run simulations. Both agree on a standard Business Object Model / data model (i.e., vocabulary / ontology) for the goods and services involved - in this case an XML schema and appropriate test XML documents are interchanged with their rules. Since John and Jane run applications based on different vendors' rule engines and rule languages, they interchange the rules using RIF; both vendors used can interpret the XML schema and data, and produce the results as an amended XML document. John's company defines its purchase orders in terms of an XML description of goods, packaging, delivery location and date with delivery and payment rules. A rule proposed by John might be the following:

<pre width=130>
If an item is perishable and it is delivered to John more than 10 days after the scheduled delivery date then the item will be rejected by him.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
This rule set can be adequately represented in RIF Core either using (ordered) relations as e.g. in standard Logic Programming, unordered relations using named arguments, or in a more object-oriented encoding using frames.<br />
<br />
''Ordered representation in RIF Core presentation syntax using relations:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
ex:reject("John" ?item) :-
ex:perishable(?item)
ex:delivered(?item ?deliverydate "John")
ex:scheduled(?item ?scheduledate)
?diffdays = External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
External(pred:numeric-greater-than(?diffdays 10))
)
)
)
</code>
<br />
Note, the nesting of external built-in functions and operations and the assignment/binding of (intermediate) result (sets) from functions to variables by equality in this example.<br />
<br />
''Unordered representation in RIF Core presentation syntax using namened arguments:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
ex:reject(ex:ware -> ?item ex:receiver -> "John") :-
ex:perishable(ex:ware -> ?item)
ex:delivered(ex:ware -> ?item ex:datetime -> ?deliverydate ex:receiver -> "John")
ex:scheduled(ex:datetime -> ?scheduledate ex:ware -> ?item)
?diffdays = External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
External(pred:numeric-greater-than(?diffdays 10))
)
)
)
</code>
<br />
Note, the arbitrarily unordered named argument arguments of the user-defined relations, in contrast to external built-in functions and operations, which must have a predefined order. <br />
<br />
''Object-Oriented Representation in RIF Core presentation syntax using frames:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
?item[ex:status -> "rejected"] :-
?item[ex:perishable -> true]
?item[ex:deliveredOn -> ?deliverydate ex:delivered -> "John"]
?item[ex:scheduledOn -> ?scheduledate ex:delivered -> "John"]
External(pred:numeric-greater-than(
External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
10
)
)
)
)
</code>
</p>

Jane replies with some suggested rule changes:

<pre width=130>
If an item is perishable and it is delivered to John more than 7 days after the scheduled delivery date but less than 14 days after the scheduled delivery date then a discount of 18.7% will be applied to the delivered item.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
''Representation in RIF Core presentation syntax using positional relations:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
ex:discount("John" ?item 18.7 ) :-
ex:perishable(?item)
ex:delivered(?item ?deliverydate "John")
ex:scheduled(?item ?scheduledate)
?diffdays = External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
External(pred:numeric-greater-than(?diffdays 7))
External(pred:numeric-less-than(?diffdays 14))
)
)
)
</code>
<br />

The binding of the intermeditate results to the variable "?diffdays" avoids repetition, as it used twice in the subsequent rule conditions. As demonstrated in the previous examples, similar representations for this rule can be given using slots or frames and as a production rule which asserts the conclusion as a new fact.
</p>

John considers this and agrees with Jane. Both organizations utilize these rules in their operational systems using disparate rule representations internally to compute prices for this order and determine contract compliance.

Future requests for the supply of items by John's company are defined on their purchasing web site, as the appropriate XML schema and a RIF ruleset (or rulesets). This allows Jane's company and its competitors to respond electronically with XML cost sheets. Suppliers respond with multiple cost sheets with different variations on the RIF rules proposed by John's company, allowing John's company to review the alternative rules with their associated costs to determine whether they, as a business, would benefit by relaxing or adding new rules as proposed by suppliers.

'''Supported by: RIF Core, RIF BLD, RIF PRD'''

The rules of this use case can be adequately represented in RIF Core (and BLD and PRD) either using (ordered) relations, as e.g. in standard Logic Programming, unordered relations, using named arguments, or in a more object-oriented encoding using frames.

</div></div></div><div>

=== Negotiating eCommerce Transactions Through Disclosure of Buyer and Seller Policies and Preferences ===

<div><div lang="en" dir="ltr">

This use case concerns the ability of parties involved in formal transactions or procedures, e.g., credit card authorization of a purchase, access of private medical records, etc., to express and protect their interests within a policy-governed framework. The goal is to formally encode the preferences, priorities, responses, etc., of the parties in such a way that the overall policy can work as intended while providing opportunity for automatic negotiation of terms when allowed by the policy. Utilization of RIF in this use case would extend the scope of this technology, affording a higher degree of interoperability, as well as enabling re-use and sharing of preferences, etc., through interchange. The detailed scenario below shows how this would work.

Alice wants to buy a device at an online site called "eShop." Alice employs software called "Emptor" that functions as automated negotiating agent for buyers. eShop employs software called "Venditor" as automated negotiating agent for sellers.

Alice's and eShop's policies describe who they trust and for what purposes. The negotiation is based on the policies, which are specified as rules, and credentials Emptor and Venditor have. These policies and credentials are disclosed (interchanged) so as to automatically establish trust with the goal of successfully completing the transaction.

Policies are themselves subject to access control. Thus, rule interchange is necessarily done during negotiation and (in general) depends on the current level of trust that the systems have on each other. Since Emptor and Venditor might use different rule languages and/or engines for evaluating (own and imported) rules, a (standard) rule interchange format (RIF) needs to be employed for enabling the rule interchange between the two systems.

When Alice clicks on a "buy it" button at the eShop's Web site, Emptor takes over and sends a request to eShop's site. Venditor receives the request and sends parts of its policy (i.e. a set of rules) back to Emptor. Among other things, the policy states that:

<pre width=130>
In order to grant access a buyer must provide valid credit card information together with delivery information (address, postal code, city, and country).
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF Core presentation syntax using relations and frames in combination: <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?buyer ?creditCard ?address (
ex:permit_access("eShop" ?buyer) :-
ex:provide("eShop" ?buyer)
?buyer[ex:card -> ?creditCard ex:deliveryAddr -> ?address]
ex:valid_payment_method(?creditCard)
ex:valid_delivery_address(?address)
)

Forall ?type ?person ?first ?last ?number ?code ?date ?month ?year (
ex:valid_payment_method(?card) :-
?card[type -> ?type
ex:holder -> ?person
ex:number -> ?number
ex:code -> ?code
ex:expiry -> ?date]
?person[ex:lastname -> ?last ex:firstname -> ?first]
?date[ex:month -> ?month ex:year -> ?year]
ex:credential(?type ?person ?number ?code ?date)
)

Forall ?address ?last ?first ?street ?strname ?number ?code ?city ?country (
ex:valid_delivery_address(?address) :-
?address[ex:name -> ?person ex:street -> ?street ex:postal_code -> ?code ex:city -> ?city ex:country -> ?country ]
?person[ex:lastname -> ?last ex:firstname -> ?first]
?street[name -> ?strname ex:number -> ?number]
ex:declaration(?person ?street ?number ?code ?city ?country)
)

)
)
</code>

Note that in this example relational representation is used in combination with frame representation. Such mixing of representation styles is supported by RIF.
</p>

Rules express compactly possible ways in which a resource can be accessed; by exchanging them negotiations are shorter and privacy protection is improved. In the example, Venditor reveals part of its policy in form of rules to enable Emptor to choose how to answer, i.e. to decide which credentials and required information to disclose.

For determining whether Venditor's request for information is consistent with Alice's policy, Emptor takes its rules into account, which state for example:

<pre width=130>
Disclose Alice's credit card information only to online shops belonging to the Better Business Bureau.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF Core presentation syntax:

<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?Shop ?card ?Credential ?Buyer (
ex:provide(?Shop ?Buyer ) :-
?Buyer[ex:card -> ?creditCard ex:deliveryAddr -> ?address]
ex:belongs_to(?Shop "Better Business Bureau")
)

Forall ?deliveryAddr ?card ?Date ?Person ?Street (
ex:Alice[ex:card -> ?card ex:deliveryAddr -> ?deliveryAddr] :-
?Date = ex:Date[ex:month -> 12 ex:year -> 2012]
?Person = ex:Person[ex:lastname -> "Sure" ex:firstname -> "Alice"]
?Street = ex:Street[name -> "North Street" number -> 111]
?card= ex:Card[ ex:type -> "Visa"
ex:holder -> ?Person
ex:number -> "123456789"
ex:code -> "123"
ex:expiry -> ?Date
]
?deliveryAddr = ex:DeliveryAddress[ ex:name -> ?Person
ex:street -> ?Street
ex:postal_code -> "NE3456"
ex:city -> "New York"
ex:country -> "USA"
]
)

)
)
</code>

</p>

By disclosing (interchanging) the above given rule, Emptor asks Venditor to provide credentials saying that it belongs to the Better Business Bureau, Alice's most trusted source of information on online shops. eShop has such a credential and its policy contains a rule stating to release it to any potential purchaser. Hence, Venditor passes the credential to Emptor. Emptor is now ready to disclose Alice's credit card information to Venditor but it still must check whether disclosing all the information does not break Alice's denial constraints. Alice has stated two constraints stating:

<pre width=130>
For anonymity reasons, never provide both her birth date and postal code.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
The current RIF dialects do not specify explicit constructs for integrity constraints.
</p>

For this purchase, Alice birthdate is no issue. Thus, Alice's constraints are respected. Emptor therefore provides Alice's credit card information to Venditor.

Companies that provide software such as Venditor and Emptor would make use of RIF in a number of ways. The rules expressing Alice's and/or eShop's policies could be expressed in different rule languages but still work with the software, using RIF-based interchanges. Secondly, assuming Venditor and Emptor are products of different companies using different internal rule languages, it would still be possible for them to work together in real-time. When these two systems need to exchange policy or preference information of their respective clients they would use RIF to enable the interchange in real-time. When Venditor sends its initial policy information to Emptor it uses RIF. Emptor takes that policy and translates it from RIF to its internal representation in order to determine what it needs to do.

'''Not supported by the current RIF dialects (Core, BLD, PRD) '''

Current RIF dialects do not specify explicit constructs for integrity constraints; thus, this use case is not adequately supported by any of these dialects.

</div></div></div><div>

=== Collaborative Policy Development for Dynamic Spectrum Access ===

<div><div lang="en" dir="ltr">

This use case demonstrates how RIF leads to increased flexibility in matching the goals of end-users of a service/device, with the goals of providers and regulators of such services/devices. RIF can do that because it enables deployment of third party systems that can generate various suitable interpretations and/or translations of the sanctioned rules governing a service/device.

This use case concerns ''Dynamic Spectrum Access for wireless communication devices''. Recent technological and regulatory trends are converging toward a more flexible architecture in which reconfigurable devices may operate legally in various regulatory and service environments. The ability of a device to absorb the rules defining the policies of a region, or the operational protocols required to dynamically access available spectrum, is contingent upon those rules being in a form that the device can use, as well as their being tailored to work with devices in the same class having different capabilities.

In this use-case we suppose a region adopts a policy that allows certain wireless devices to opportunistically use frequency bands that are normally reserved for certain high-priority users. ([http://europa.eu.int/eur-lex/lex/LexUriServ/site/en/oj/2005/l_187/l_18720050719en00220024.pdf The decision] by the European Union to allow "Dynamic Frequency Selection" (DFS) use of the 5 GHz frequency band by wireless systems, a band intermittently used by military and weather radar, is a recent example.)

Suppose the policy states:

<pre width=130>
A wireless device can transmit on a 5 GHz band if no priority user is currently using that band.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>

<br />Note, since default negation (not) such as negation as failure is not supported by RIF BLD there is no adequate way to represent that "no priority user is currently using the band".
</p>

How does a device know that no priority user is currently using a band it wants to use? The answer will depend on the specific capabilities of the device. One type of device may answer this question by sensing the amount of energy it is receiving on that band. That is, it might employ the rule:

<pre width=130>
If no energy is detected on a desired band then assume no other device is using the band.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
Forall ?device ?band ?level (<br />
ex:used(?device ?band) :- <br />
ex:detect(ex:energy(?level ?band))<br />
External(pred:numeric-greater-than(?level 0))<br />
)<br />
)<br />
)<br />
</code>
<br />Note, the engergy detection function would require an external call for sensing the level of energy. Such procedural attachments cannot be specified in BLD. Reaction rules provide event detection capabilities.
</p>

A second type of device, may get information from a control channel that lets it know whether the desired band is being used by a priority user. That is, it might employ the rule:

<pre width=130>
If no control signal indicating use of a desired band by a priority user is detected then assume the band is available.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
Forall ?device ?band ?user (<br />
ex:used(?device ?band) :- <br />
ex:detect(ex:signal(?user ?band))<br />
ex:priority(?user,"high").<br />
)<br />
)<br />
)<br />
</code>
<br />
</p>

So each type of device will need to employ different "interpretations" or "operational definitions" of the policy in question.

Now assume that there are 10 manufacturers of these 2 different types of wireless devices. Suppose that each of these manufacturers uses a distinct rule-based platform in designing its devices. Each manufacturer needs to write 2 interpretations of the policy (for each of the two types of device). That means that 20 different versions of the policy must be written, tested and maintained.

Enter RIF. The 10 manufacturers form a consortium. This is a third-party group that is responsible for translating regional policies into RIF. When it does so, however, it provides different versions corresponding to the possible interpretations (operational definitions) of the policy. So in this case, 2 RIF versions of the DFS policy are provided for the 2 types of device mentioned above. Each of these RIF specifications can be automatically translated into the appropriate rule-platform provided a RIF-Compiler for the target device architecture exists. Clearly it will be in the interest of each device manufacturer to develop such compilers. That is because the manufacturer only needs to develop such a compiler ''once'' for every architecture it owns. Contrast that investment with having to produce, test, and maintain different versions of various policies over the lifetime of a product.

This arrangement also allows the overall process to be organized in a fashion that maintains the natural division of labor in the corresponding division of artifacts produced by that labor: the policy and its various interpretations are written and maintained in platform-independent artifacts (RIF); knowledge about how to translate from RIF to a particular device architecture is maintained in the compilers. A change in policy is inserted at the top level in the policy artifact hierarchy where it should be; possible operational interpretations of that change are inserted at the next level down; the implementation implications for the various device architectures is generated automatically at the lowest level.

'''Partly supported by: RIF PRD'''

The energy detection function specified in this use case would require an external call to a device that would sense the level of energy. Such procedural attachments cannot be specified in the current RIF dialects. Reaction rules support (complex) event detection capabilities on, e.g., event streams over sensor data.

This use case is not supported at all by RIF BLD, and by extension, by RIF Core. These dialects do not support negation, and
the use case makes explicit mention of negation, e.g. for representing that "no priority user is currently using the band."<br />

</div></div></div><div>

=== Access to Business Rules of Supply Chain Partners ===

<div><div lang="en" dir="ltr">

A business process (BP) designer designs processes that can span multiple departments in the same business as well as other business partners. A classic example of this is the integration of supply chain business processes which typically involve multiple partners. Supply chain integration involves exposing a certain amount of business logic between partners as well as integrating processes across partners. In such activities it is therefore often necessary to access or invoke rules that originate in other ownership domains.

A key part of a business process is the logic used to make decisions within the process. Such logic is often coded in rules because rule languages are easier for BP designers to understand and manipulate than procedural code (as in Java) -- although both forms of business logic are prevalent. Where business logic is represented in different rule languages this presents a significant burden to the BP designer in designing an integrated process.

Two primary integration modalities are possible: importing the different rulesets into a single engine and processing them in a uniform manner, or accessing the rulesets by querying remote engines and processing the results. Each modality has its uses and contra-indications. Where there are strong ownership boundaries involved it may not be permitted to merge rule sets of partners.

For example, in an insurance adjustment process, the inspection of a damaged vehicle is often performed by independent inspectors. The critical decision in how an insurance claim will proceed is whether the damage results in a total loss or whether a repair is feasible:

<pre width=130>
If inspector believes vehicle is repairable then process as repair otherwise process as total loss.
</pre>

The question of whether a vehicle is repairable is one that is dependent on the processes executed by the inspector and cannot be directly integrated into the insurance companies own adjustment process. The insurance company effectively queries the inspector's logic. Within the adjustment process, the overall flow will be quite different for repairable claims and total loss claims.

Even in the case of a single company, which is nominally under a common ownership domain, information and business logic is often controlled by multiple stakeholders. For example, a large company will often be organized into semi-independent profit centers (business units). Each unit will be motivated differently, will have different ontologies and business logic and may use different rule languages to represent their logic (this is particularly the case where one company acquires another company).

RIF should be used to permit the BP designer a unified view of the different partners' business rules in designing the process, while at the same time permitting the partners to continue to leverage their own business rules without changing their own technologies.

How such a unified view of the business rules can be realized in a deployed BP will depend on both technical and non-technical factors. Even where all the parties are required to use a common rule language, there may be compelling ownership issues that mitigate against a simple merge of the rule sets. In the situation where merging of rulesets is not possible, then a query-style access to partners' business rules may be used. In this way, RIF permits a unified dynamic view of the business rule logic no matter what the original form of the rules.

For this to be viable from a business perspective it is critical that the semantics of the rules and query exchange be completely predictable and preferably loss-less.

'''Not supported, in a straightforward manner, by the current RIF dialects'''

<p>
BLD and PRD do not support modal operators or predicates on quoted sentences; therefore standard representations of knowledge, belief, and/or uncertainty cannot be specified in BLD and PRD. Even without such constructs, it can be possible to represent knowledge or belief using the semantics of possible worlds <nowiki>[</nowiki>[[#moore|Moore1980]]]. That is, one can get the effect of saying that an agent A believes proposition P by saying that P holds in all words that are belief-accessible to P. For example, to get the effect of saying
<pre width=130>Believe(john,overCreditLimit(bill,t))
</pre>
</p>

<p>
one says instead
<pre width=130>
holds(overCreditLimit(bill),t1) :- beliefAccessible(john,t,t1)
</pre>
</p>

The translation between sentences involve operators such as Know and Believe and sentences that make direct use of possible worlds relies on the possible-worlds semantics, which posits properties on the knowledge-accessibility or belief-accessibility relation. These relations correspond to axioms on the Know and Believe operators.

<p>
Such a strategy could work, to a certain extent, in RIF PRD, but would not work in RIF BLD. This is because expressing the standard axioms on belief or knowledge would require the use of negation, which is not supported by BLD.

For both PRD and BLD there is an additional consideration, which is that the notion of reification is in general not supported by the dialects of RIF.

</p>

</div></div></div><div>

=== Managing Inter-Organizational Business Policies and Practices ===

<div><div lang="en" dir="ltr">

This use case concerns organizations that acquire rule sets from external sources and that have to integrate these new rule sets into their existing rule bases. Such rule sets may be acquired in the following ways:

* An organization may buy rule sets from expert sources
* An organization may use rule sets from shared interest groups such as trade associations
* A component of a distributed organization may acquire rules when a rule set is distributed across a distributed organization. In such case, there may be different localization requirements in different regions and locations, entailing a variety of integration challenges in these various locations and component organizations.

The following scenario examines these different methods of acquisition and the various types of integration and management issues that may arise.

''This scenario uses the (fictitious) car rental company, EU-Rent, used as the case study in the [http://www.omg.org/spec/SBVR/1.0/ Semantics of Business Vocabulary and Business Rules Specification]. The EU legislation discussed is also fictitious, as are the consulting companies CarWise and AutoLaw.''

EU-Rent's corporate HQ deals with CarWise, a consulting company with expertise in managing fleets of vehicles. One service CarWise offers to its clients is negotiating with EU regulators to clarify regulations.

An EU regulator issues a directive dealing with insurance for vehicles owned by corporations. CarWise agrees with the regulator on an acceptable interpretation, and provides EU-Rent (and its other car rental clients) with two sets of rules:

* A business policy, stating that every car rental must be insured for damages to third parties.
* A supporting rule set, addressing levels of required coverage, tax calculation in different EU countries, liabilities in rentals that span multiple countries, and reporting of compliance with this business policy.

EU-Rent decides that it will maintain its compliance documentation electronically. CarWise then provides EU-Rent with an additional rule set for electronic compliance documentation, including such rules as:

<pre width=130>
Each tax schedule must have electronic signatures from two EU-Rent employees who are at least at the level of manager.
</pre>

Before it can use the two general rule sets, EU-Rent needs to connect them to the relevant data sets in its IT systems, e.g. relate the EU country-specific taxation rules to the relevant record types in its databases.

EU-Rent corporate HQ subsequently decides that the cost of third-party insurance will be built into the basic cost of each rental, and not shown as a separate item on the rental contract, to ensure that it can never be omitted from rentals or disputed by renters. It then sends three rule sets to its operating companies in the EU:

* The rule set for car rental insurance (from CarWise), including the basic policy and the supporting rule set.
* The rule set for electronic compliance documentation (also from CarWise).
* Its own rule set for building insurance into the basic rental cost.

The operating companies then have to localize the rule sets for their countries of operation. For example, in the UK, another consulting company, AutoLaw, advises EU-Rent of rules for placing aggregate insurance for large fleets with more than one insurer in order to spread the risk, for example:

<pre width=130>
For fleets of more than 200 vehicles, fleet insurance policies must be placed with at least 3 insurers, each of whom covers at least 25% of the risk.
</pre>

A timing issue makes it difficult for EU-Rent UK to strictly comply with this directive. EU-Rent UK has some existing insurance policies in place, which provide third-party insurance as an explicit item, and it cannot get refunds on early termination. It therefore asks corporate HQ for a temporary dispensation: that it can continue its existing insurance until it expires, and then switch to the new rules.

EU-Rent HQ permits this, not just for the UK, but for any of its operating companies that have similar insurance arrangements. To ensure that this dispensation is temporary, it adds a new rule:

<pre width=130>
Insurance policies that provide separate third-party coverage must not be renewed.
</pre>

EU-Rent HQ is also concerned about meeting deadlines for electronic filing. It introduces a new rule that it distributes to operating companies:

<pre width=130>
Each electronic compliance document must have its required electronic signatures 48 hours before its filing deadline.
</pre>

This rule is meant to be implemented as follows: If '48 hours before filing deadline' passes, and the electronic signatures are not present, then the operating company's rules system must report the out-of-compliance situation, and subsequently wait for the responsible managers to provide the signatures.

'''Partially supported by RIF PRD'''

The business rules in this use case express norms which requires the representation of deontic operators for obligations and permissions. Deontic operators are generally represented by modal operators, as in <nowiki>[</nowiki>[[#ref-Horty-deontic-logic|Horty2001]]]. As was discussed above, for Know and Belief, it is not possible to express modal operators directly within RIF dialects. However, one can use the technique discussed above, of reasoning directly within possible worlds. This is possible within PRD though not within BLD or Core.

Moreover, in a meta programming approach it is possible to express deontic reasoning rules with RIF PRD. Using this approach, too, one would not be able to use BLD or Core, since some business rules express negated deontic norms.

=== Ruleset Integration for Medical Decision Support ===

<div><div lang="en" dir="ltr">

Decision support systems aid in the process of human decision making, especially decision making that relies on expertise. Reasoning with rules is an important part of this expert decision making. For complex decision support systems, it is expected that rules will be furnished by a variety of different sources, including ontologies, knowledge bases, and other expert systems. This use case illustrates how RIF makes it possible to merge rulesets from diverse sources in diverse formats into one rule-based system, thereby enabling inferences that might otherwise have remained implicit.

Medical decision support systems, such as the ones discussed below, might use rules from pharmaceutical knowledge bases, laboratory knowledge bases, patient databases, and medical ontologies. For example, a large amount of information on therapeutic medications (drug taxonomies, indications, contraindications, and clearance times) and diseases (disease taxonomies, etiologies, and symptoms) is contained in existing ontologies such as [http://www.snomed.org SNOMED] Clinical Terms®. Rules can be used to express therapeutic recommendations, to formulate queries about relevant prescriptions for a patient, and to assess the effectiveness of a treatment.

The following scenario illustrates how rule-interchange would be used in various medical decision support systems to support the following functionalities:

* Improving situation assessment, e.g., determining when a patient needs to be put on medication, or have his medication switched.
* Prescribing a course of action, e.g., determining which drug is best for a patient in a particular circumstance.
* Improving event planning, e.g., determining whether a patient can be scheduled for a procedure given the medication that he is currently taking.

Bob, 62 years old and reasonably healthy, has been going to his internist, Dr. Rosen, for several years for control of his Type II diabetes. Dr. Rosen has been using the <tt>AutoDoc</tt> system to help him decide when to switch to medications and which drugs to prescribe. The <tt>AutoDoc</tt> system uses two sources when making its recommendations: a laboratory knowledge base giving particular results for patients and specifying when these results are out of normal range, and a pharmaceutical knowledge base giving guidelines for the use of medications. Automated reasoning with rules from these combined sources is possible if the rules are first mapped to RIF. Here are two specific examples of such synergistic effects.

''This scenario discusses the fictitious expert systems <tt>AutoDoc</tt> and MEDIC. In the interest of readability and brevity, the information and rules presented in the following scenario may not precisely capture the current state of medical knowledge and best practices in this field, but may be somewhat simplified.''

Originally Bob's diabetes was controlled through diet and moderate exercise. In time, however, Bob's blood glucose level began to rise, even under this regimen. Due to Bob's elevated <tt>HbA1c</tt> level (which indicates one's average blood sugar level over the last several months), Dr. Rosen prescribed oral medication for Bob. He was forced to change Bob's medication a number of times over the course of a year. He first prescribed Precose, an oral alpha-glucosidase inhibitor, but had to discontinue this medication due to undesired side effects. He then prescribed several sulfonylurea drugs, Micronase and Glucotrol, to no avail. Bob's lab results still indicated an elevated <tt>HbA1c</tt> level. The following rule from the ''laboratory knowledge base'' suggests that Bob's treatment at that time was not effective:

<pre width=130>
If a Type II diabetes patient's current level of HbA1c is high, then the patient's current treatment is considered to be ineffective.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations and an event calculus axiomatization:<br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
Forall ?Patient ?Treatment ?Level ?T (<br />
ex:holdsAt(ex:ineffective(?Patient ?Treatment) ?T) :-<br />
ex:holdsAt(ex:hasDisease(?Patient "diabetesTypeII") ?T)<br />
ex:holdsAt(ex:elevated(levelOf(?Patient "hbA1c" ?Level)) ?T)<br />
ex:holdsAt(ex:treatmentPlan(?Treatment ?Patient) ?T)<br />
)<br />
)<br />
)<br />
</code>
<br />Note, the example requires the formalization of changeable states which can be represented by an event calculus axiomatization. [[#event-calculus|KS86]]] The EC axioms can then be represented using RIF BLD.
</p>

To deal with this problem, Dr. Rosen was about to prescribe Glucophage (metformin, one of the biguanides) 850 mg, 3 times a day, when as usual, he double checked his prescription with the <tt>AutoDoc</tt> system. The system, based on the following guidelines from the ''pharmaceutical knowledge base'', informed Dr. Rosen that he should have prescribed an oral bitherapy (two medications, each of which controls blood sugar levels) instead of a monotherapy.

<pre width=130>
If an oral monotherapy at recommended doses of a sulfonylurea or biguanide, combined with lifestyle changes, is ineffective, then the monotherapy should be replaced by an oral bitherapy.
</pre>

Based on the recommendation from <tt>AutoDoc</tt>, Dr. Rosen switched Bob's prescription to Glucophage and Avandia (rosiglitazone, one of the thiazolidinediones).

Bob recently suffered a concussion and has become increasingly forgetful. He went to see a neurologist, Dr. Cervello, who prescribed a contrast MRI (Magnetic Resonance Imaging). When asked about current medication, Bob told Dr. Cervello that he was taking Glucotrol to control his diabetes, forgetting that he had been switched to Glucophage. This was potentially problematic, since Glucophage should not be taken close to the administration of a contrast injection.

Fortunately, when Bob went to the lab to schedule his MRI, the medical receptionist pulled up MEDIC (Medical Event and Drug Interaction Consultant), the hospital's new automated system, which checks for incompatible medical events and/or drugs (e.g., liposuction scheduled during pregnancy, blood thinners prescribed before surgery, etc.).

MEDIC uses a variety of sources in its reasoning, including:

* the pharmaceutical knowledge base, described above
* the patient databases, which gives the patient record, including the medications a patient is currently taking
* the hospital medical event protocol knowledge base, which details the protocol used for different medical procedures

In this case, MEDIC uses all three sources, and pulls up the following information:

* Metformin is contraindicated with contrast dye.
* Metformin is the generic form of Glucophage.
* Bob is taking Glucophage.
* The contrast MRI requires as one of its steps injecting the patient with contrast dye.

MEDIC therefore determines that Bob should not be taking the contrast MRI at this time.

For MEDIC to work, the rules from these different sources must be mapped to a unified interchange format.

'''Supported by RIF PRD'''

The use case requires the formalization of changeable states (fluents) which can be represented by e.g. an event calculus axiomatization <nowiki>[</nowiki>[[#event-calculus|KS86]]]. However, to formulate the classical event calculus as a set of Horn clause rules, so that it could be run as a Prolog program, negation as failure is needed, which is not supported by RIF BLD.
The use case can be represented in RIF PRD which supports changeable states (modifications) and assertions and retractions of knowledge.

</div></div></div><div>

=== Interchanging Rule Extensions to OWL ===

<div><div lang="en" dir="ltr">

Rules are often used in conjunction with other declarative knowledge representation formalisms, such as ontology languages (e.g. RDF and OWL), in order to provide greater expressive power than is provided by either formalism alone. Ontology languages, for example, typically provide a richer language for describing classes (unary predicates). Rules, on the other hand, typically provide a richer language for describing dependencies between properties (binary predicates), and may also support higher-arity predicates.

Rich domain models combining both rules and ontologies are often needed in domains such as medicine, biology, e-Science and Web services. In such domains, several actors and/or agents are involved that have to interchange the data, ontologies, and rules that they work with. An example is the use of such a domain model in an application that aims at assisting the labeling of brain cortex structures in MRI images. In this case, an OWL ontology is used to capture knowledge about the most important brain cortex anatomical structures, and a rule base is used to capture knowledge about mereological and spatial dependencies between properties.

For example, a rule is used to express the dependency between the ontology properties isMAEConnectedTo and isMAEBoundedBy, in particular (a simplified form of) the knowledge that two Material Anatomical Entities having a shared boundary are connected:

<pre width=130>
If MAE X is bounded by Z and MAE Y is also bounded by Z then X is connected to Y.
</pre>

Benefits of interchange via RIF include the ability to collaboratively develop and share valuable knowledge, the ability to integrate anatomical images, possibly from distributed image sources, and the ability to use large-scale federated systems for statistical analysis of brain images of major brain pathologies.

'''Supported by RIF Core, RIF BLD and RIF PRD'''

The use case uses RIF SWC to combine RIF Rules with OWL ontologies.
</div></div></div><div>

=== Vocabulary Mapping for Data Integration ===

<div><div lang="en" dir="ltr">

This use case concerns the integration of information from multiple data sources. The Semantic Web provides a common data representation and query language, which greatly simplifies access to diverse sources but does not directly address the problem that independent data sources may have rather divergent information models.

Rules are an effective way to express mappings between such information models. However, rules locked within local proprietary systems cannot be reused. With a common rule representation, such mappings can be published across the Semantic Web, enabling an enterprise or community to progressively build up a rich network of mappings unifying the information models.

Information mapping and integration problems like this arise in many diverse domains including health care, travel planning, IT management and customer information management. The following scenario comes from the world of IT systems management.

Vlad has been given the job of analyzing how exposed his division's business processes are to changes in their IT maintenance contracts. He has three sources of information to combine:

* a report on application services and associated servers, databases and networks (from the IT department)
* a maintenance contracts database (from the finance department)
* a registry indicating which business processes use which IT services (from the business planning group)

Each of these sources is in a different form but can be mapped into RDF to simplify access. However, they all have different information models. The IT report is too fine-grained: it talks about routers and interface cards whereas Vlad only needs to identify servers and pick out some generic dependency relations. On the other hand, the finance database models the world in terms of physical assets such as racks, which is too coarse-grained.

First, Vlad creates simple mapping rules to create a uniform, simplified view of the data in terms of a small number of concepts -- Server, Business<tt></tt>Process and Dependency. This involves rules such as:

<pre width=130>
If x is a ComputeNode in Rack r
and Rack r is in Cage c
and mc is a MaintenanceContract for Cage c
then x is a Server with MaintenanceContract mc

If x is a ComputeNode with a NetworkInterface with Port p
and app is an Application running on Port p
then x is a Server that hosts app

If bp is a BusinessProcess that uses Application app
then bp has a Dependency on app
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Forall ?X ?MC ?R ?C(
?X[rdf:type->ex:Server ex:maintenanceContract->?MC] :- And(
?X[rdf:type->ex:ComputeNode ex:location->?R] ?R#ex:Rack
?R[ex:location->?C] ?C#ex:Cage
?C[ex:maintenanceContract->?MC] ?MC#ex:MaintenanceContract ))

Forall ?X ?Ni ?P ?App (
?X[rdf:type->ex:Server ex:hosts->?App] :- And(
?X[rdf:type->ex:ComputeNode ex:networkInterface->?Ni]
?Ni[ex:port->?P] ?P#ex:Port
?App[rdf:type->ex:Application ex:onPort->?P]))

Forall ?App ?BP (
?BP[ex:dependsOn->?App] :-
?BP[rdf:type->ex:BusinessProcess ex:processUses->?App] ))
</code>
<br />
</p>

He then creates rules that combine the data across his now simplified data sources, e.g.

<pre width=130>
If bp is a BusinessProcess that has a Dependency on Application app
and x is a Server with MaintenanceContract mc that hosts Application app
then bp has a Dependency on mc
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Forall ?App ?BP ?App ?MC(
?BP[ex:dependsOn->?MC] :- <
?BP[rdf:type->ex:BusinessProcess ex:dependsOn->?App] ?App#ex:Application
?X[rdf:type->ex:Server ex:hosts->?App ex:maintenanceContract->?MC] ))
</code>
<br />
</p>

This gives him a uniform view that links from business processes through to the IT and finance data. Vlad publishes these rules so that other people across the company can reuse them to construct similar views.

'''Supported by RIF BLD and RID PRD'''

</div></div></div><div>

=== BPEL Orchestration of Rule-Based Web Services ===

<div><div lang="en" dir="ltr">

Rule-based Web services depend on the use of XML data for their request and response format. The involved rules must be able to access and compare XML data in their conditions and modify and generate XML data in their actions.

An existing commercial credit approval service deployed as a Web service takes an applicant credit request document as input and returns an approval or denial (with reason). It is implemented as a BPEL orchestration of two Web services -- a credit history providing service and a decision service containing a rules engine. BPEL first passes the credit request document to the decision service to determine, using rules, whether enough information (SSN, mother's maiden name, etc.) is available to request a credit history. If so, BPEL then requests a credit history from the history providing service and passes the credit history document to the decision service to be evaluated. Based on the evaluation, credit is approved or denied.

Because the rule engine is part of a Web service, existing BPEL diagramming and execution facilities can be used to integrate rules into this credit approval service. The credit evaluation model can be changed easily using GUI tools to customize rules. Use of RIF would improve the situation further. First, the credit history vendor could supply a default set of rules for evaluating its histories. Second, there would be several rule editing and customization tools from different RIF compatible vendors to tailor the rules to meet specific business objectives.

The credit evaluation rules are themselves grouped into three rulesets that are executed sequentially. Rules in the first ruleset apply thresholds to several "red flag" quantities in the credit report, such as:

* number of times a payment was 60 days late
* debt-to-income ratio
* number of foreclosures or repossessions
* number of garnishments
* number of liens
* bankruptcy

A red flag above the threshold results in denial of credit.

Rules in the second ruleset increment a credit score variable. For example:

<pre width=130>
If applicant owns residence then add 40.
If applicant rents then add 30.
If applicant has lived at current address 2 to 4 years then add 20.
If applicant's income is under 20000 then add 10.
If applicant's income is between 40000 and 50000 then add 40.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;">Document(<br />
<br />
Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(prolog_func <nowiki>http:</nowiki>//example.org/2007/rif-prolog-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
ex:score(0)<br />
<br />
ex:score(?Applicant ?Score) :-<br />
ex:increment(?Applicant)<br />
ex:score(?Score)<br />
prolog_func:retract(ex:score(?Score))<br />
prolog_func:assert(ex:score(0)). <br />
<br />
ex:increment(?Applicant) :- <br />
ex:owns(?Applicant)<br />
ex:score(?Score)<br />
prolog_func:retract(ex:score(?Score))<br />
?NewScore = ?Score + 40<br />
prolog_func:assert(ex:score(?NewScore)).<br />
<br />
ex:increment(?Applicant):- <br />
ex:rents(?Applicant)<br />
ex:score(?Score)<br />
ex:retract(score(?Score))<br />
?NewScore = ?Score + 30<br />
prolog_func:assert(score(?NewScore)).<br />
<br />
ex:increment(?Applicant):-<br />
ex:lives(?Applicant ?Date),<br />
$sysTime(?CurrentDateTime)<br />
?CurrentYear = $fn:year-from-dateTime(?CurrentDateTime)<br />
?Year = $fn:year-from-dateTime(?Date)<br />
?Diff = ?CurrentYear - ?Year<br />
?Diff > 1<br />
?Diff < 5<br />
ex:score(?Score)<br />
prolog_func:retract(score(?Score))<br />
?NewScore = ?Score + 20<br />
prolog_func:assert(ex:score(?NewScore)).<br />
<br />
ex:increment(?Applicant):- <br />
ex:income(?Applicant ?Income)<br />
?Income < 20000<br />
ex:score(?Score)<br />
prolog_func:retract(score(?Score))<br />
?NewScore = ?Score + 10<br />
prolog_func:assert(ex:score(?NewScore)).<br />
<br />
ex:increment(?Applicant):-<br />
ex:income(?Applicant ?Income)<br />
?Income < 50000<br />
?Income > 40000<br />
ex:score(?Score)<br />
prolog_func:retract(ex:score(?Score))<br />
?NewScore = ?Score + 40<br />
prolog_func:assert(ex:score(?NewScore)).<br />
</code>
<br />A goal-driven solution which makes use of assert and retract (not supported by BLD) to update a global score value, which is stored in a fact.
</p>

The third and final ruleset compares the applicant's credit score and income to threshold values, and makes the final decision to approve or deny credit to the applicant.

The decision and supporting rationale is returned from the decision service as an XML document. This decision document is then used to construct the reply to the original credit approval request.

'''Supported by RIF PRD'''

This use case requires a goal-driven solution which makes use of assert and retract to update a global score value. Assert and retract are not supported by BLD; indeed, there is no such similar notion within BLD.

</div></div></div><div>

=== Publishing Rules for Interlinked Metadata ===

<div><div lang="en" dir="ltr">

The Semantic Web includes technologies (e.g., RDF) that allow metadata to be published in machine-readable form. Currently, this information is mostly enumerated as a set of facts. It is often desirable, however, to supplement such facts with rules that ''capture implicit knowledge''. To maximize the usefulness of such published rules, a standard rule format such as RIF is necessary.

One case involves extending current standards for metadata publication with rules in order to express implicit knowledge. Suppose that the International Movie Database (IMD) publishes its metadata and rules in a machine readable format at <nowiki>http://</nowiki>imd.example.org. Besides the ground facts, which can be expressed in RDF, the metadata might also have general rules like the following:

<pre width=130>
Every science fiction movie is a movie.
Every movie produced before 1930 is black and white.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD (Abridged) Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> ?Movie#ex:Movie :-<br />
?Movie#ex:ScienceFictionMovie.<br />
<br />
?Movie#ex:BlackWhiteMovie :-<br />
?Movie#ex:Movie[ex:date -> ?Date]<br />
?Date < "1930"^^xs:dateTime.<br />
</code>
<br />
</p>

Such rules allow data to be published more concisely by expressing knowledge that, without these rules, is implicit. This can greatly simplify the maintenance of data, guard against inadvertently introduced inconsistencies, and reduce storage requirements.

Published rules also allow combining data from different sources to exploit this knowledge. Consider an alternative database of movies published at <nowiki>http://</nowiki>altmd.example.org. In addition to metadata, it again publishes its own rules:

<pre width=130>
All movies listed at <nowiki>http://</nowiki>altmd.example.org but not listed at <nowiki>http://</nowiki>imd.example.org are independent movies.
All movies with budgets below 5 million USD are low-budget movies.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD (Abridged) Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> ?Movie#ex:IndependentMovie :-<br />
listed(?Movie#ex:Movie,<<nowiki>http:</nowiki>//altmd.example.org>)<br />
not(listed(?Movie#ex:Movie,<<nowiki>http:</nowiki>//imd.example.org>)). <br />
<br />
?Movie#ex:LowBudgetMovie :-<br />
?Movie#ex:Movie [date -> ?Date, budget -> ?Budget]<br />
?Budget < 5000000^^xs:long.<br />
</code>
<br />
</p>

Publication of rules with explicit references to other rulesets allows the definition of knowledge dependent on explicitly specified remote sources. Such explicitly specified ''scope'' is important in the Web environment, since it can reduce the danger of unintended interference from rules published at other remote sources, which may be exporting their own predicates.

Another example of such explicit referencing, which also illustrates implicit person-centric metadata, involves published rules being used to specify how to use other metadata, e.g. in the form of a widespread vocabulary such as FOAF or a standard exchange format like iCalendar. For example, FOAF user Charlie might choose to complement his normal FOAF profile with his preferences about which of his phone numbers should be used depending on his iCalendar schedule:

<pre width=130>
If Charlie is currently attending a public talk according to <nowiki>http://</nowiki>charlie.example.org/calender.ical
then leave him a voicemail message

If Charlie is currently in a meeting according to <nowiki>http://</nowiki>charlie.example.org/calender.ical
and the importance is high
then call his cell number

If Charlie currently has no appointments according to <nowiki>http://</nowiki>charlie.example.org/calender.ical
then call his office number
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD (Abridged) Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> contactInfo("Charlie" ?ContactInfo) :-<br />
sysTime(?Time)<br />
attending("Charlie" "talk" ?Time)<br />
contact("Charlie" "voicemail" ?ContactInfo).<br />
<br />
contactInfo("Charlie" ?ContactInfo) :-<br />
sysTime(?Time)<br />
attending("Charlie" "meeting" ?Time)<br />
contact("Charlie" "cell number" ?ContactInfo).<br />
<br />
contactInfo("Charlie", ?ContactInfo) :-<br />
sysTime(?Time),<br />
not(attending("Charlie",?Event, ?Time)),<br />
contact("Charlie", "office number", ?ContactInfo).<br />
<br />
<br />
sysTime(?Time) :-<br />
% get the actual system time e.g. via a built-in<br />
% or procedural attachment call to Java or C++.<br />
?Time = External(call(java.util.Calendar().getInstance())).<br />
<br />
<br />
attending("Charlie","talk", ?CurrentTime) :-<br />
% getEventData would implement the functionality to dynamically access and query<br />
% <nowiki>http:</nowiki>//charlie.example.org/calender.ical<br />
getEventData(<<nowiki>http:</nowiki>//charlie.example.org/calender.ical>,?EventTitle,?Type,?StartDate,?EndDate),<br />
?Type = "talk",<br />
External(op:dateTime-less-than(?CurrentTime,?EndDate),<br />
External(op:dateTime-greater-than(?CurrentTime,?StartDate).<br />
<br />
<br />
attending("Charlie","meeting", ?CurrentTime) :-<br />
getEventData(<<nowiki>http:</nowiki>//charlie.example.org/calender.ical>,?EventTitle,?Type,?StartDate,?EndDate),<br />
?Type = "meeting",<br />
External(op:dateTime-less-than(?CurrentTime,?EndDate),<br />
External(op:dateTime-greater-than(?CurrentTime,?StartDate).<br />
<br />
<br />
<br />
contact("Charlie", "voicemail", ?ContactInfo) :-<br />
% retrieve the Voice mail number, e.g. from<br />
% Charlie's vCard, <br />
% e.g. xmlns:vCard = "<nowiki>http://www.w3.org/2001/vcard-rdf/3.0#"</nowiki><br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard:FN> -> "Charlie"],<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard_TEL> -> ?Telephone],<br />
?Telephone[<rdf:type> -> <nowiki><http://www.w3.org/2001/vcard-rdf/3.0#voice></nowiki>],<br />
?Telephone[<rdf_value> -> ?ContactInfo].<br />
<br />
contact("Charlie", "cell number", ?ContactInfo) :-<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard:FN> -> "Charlie"],<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard_TEL> -> ?Telephone],<br />
?Telephone[<rdf:type> -> <nowiki><http://www.w3.org/2001/vcard-rdf/3.0#cell></nowiki>],<br />
?Telephone[<rdf_value> -> ?ContactInfo].<br />
<br />
contact("Charlie", "office number", ?ContactInfo) :-<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard:FN> -> "Charlie"],<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard_TEL> -> ?Telephone],<br />
?Telephone[<rdf:type> -> <nowiki><http://www.w3.org/2001/vcard-rdf/3.0#work></nowiki>],<br />
?Telephone[<rdf_value> -> ?ContactInfo]. <br />
</code>
<br />
</p>

RIF should allow extending current standards for metadata publication by enabling such implicit knowledge to be captured via rules and allowing metadata and rules distributed over different sources to be interlinked. In a manner similar to how HTML links human-readable Web pages, RIF should permit linking metadata on the Web to support new kinds of "intelligent" crawling and search.

'''Supported by RIF PRD'''

Since negation is not supported by RIF BLD it is not possible to express ''... but not listed at ...''.

</div></div></div></div><div>

== Conclusion ==

<div><div lang="en" dir="ltr">

The goal of the RIF working group is to provide representational interchange formats for processes based on the use of rules and rule-based systems. These formats act as "interlingua" to interchange rules and integrate with other languages, in particular (Semantic) Web mark-up languages.

As can be seen by studying the use-cases presented in this document, rules are used to perform a wide variety of tasks, and, therefore, rule-based systems are not monolithic. Rules have been used to perform or validate inference, perform calculations, direct the flow of information, enforce integrity constraints on databases, represent and enforce policies, control devices and processes in real-time, determine the need for human intervention, and so on.

In light of this diversity, rather than being a single all-encompassing format, RIF consists of several dialects, each dialect serving a particular set of related rule languages. The key idea is to attain the goal of interoperability (via interchange of RIF rules) ''within'' each dialect. This should allow the main benefits of RIF to be realized. For example, the invariant meaning of a set of integrity-constraint-enforcing rules would be represented within the appropriate RIF dialect and could then be translated into the native format of any of the formalisms capable of representing such rules.

RIF has been designed in such a way that it is possible to create new dialects (extensibility) according to the overall goals and the general requirements of RIF, as well as to update existing dialects (upwardly compatible). This is in keeping with the working group charter's call for an extensible format.

</div></div></div>

</div><div>

== References ==

<div><div lang="en" dir="ltr">

<span id="ref-Horty-deontic-logic" class="anchor"></span>

; [Horty2001]
: ''Agency and Deontic Logic'', John F. Horty, Oxford University Press, 2001.

<span id="event-calculus" class="anchor"></span>
; [KS86]
: Kowalski, R.A. and M.J. Sergot, ''A logic-based calculus of events.'' New Generation Computing, 1986. 4: p. 67-95.

<span id="moore" class="anchor"></span>
; [Moore80]
: Moore, R.C., ''Reasoning about Knowledge and Action,'' SRI TR-191, 1980.

</div></div></div>

<div>

== Appendix: Change Log (Informative) ==

<div><div lang="en" dir="ltr">

This appendix summarizes the main changes to this document since its publication as a Working Draft.

Changes since the [http://www.w3.org/TR/rif-ucr/ draft of December 18th, 2008]:
* [[#Structure_of_RIF|section describing the structure of RIF]] updated with the new RIF documents;
* all code examples are removed from the document
* each use cases has a new paragraph at the end which discusses the support of the use case by the current RIF dialects Core, BLD and PRD
* added an informative change log section
* flattened the list of requirements removing the distinction between general and basic requirements

</div></div></div></div>

</div>

UCR

Sandro — Tue, 11 Dec 2012 14:03:13 GMT

Sandro: making example.org URLs not be links, fix SBVR link

__NUMBEREDHEADINGS__
{{TR|title=RIF Use Cases and Requirements}}
<div id='editors'>
; Editors:
: Adrian Paschke, Freie Universitaet Berlin
: Leora Morgenstern, SAIC
: David Hirtle, National Research Council Canada
: Allen Ginsberg, Mitre
: Paula-Lavinia Patranjan, REWERSE
: Frank <nowiki>McCabe</nowiki>, Fujitsu
</div>
; Abstract
: <div id='abstract'><p></p> <p></p> <p></p> <p>This document, developed by the [http://www.w3.org/2005/rules/wg Rule Interchange Format (RIF) Working Group], specifies use cases and requirements for the W3C Rule Interchange Format, a family of rule interchange dialects that allows rules to be translated between rule languages and thus transferred between rule systems. </p> </div>
; Status of this Document
: 3rd revised version of the UCR document

[http://www.w3.org/Consortium/Legal/ipr-notice#Copyright Copyright] © 2010 [http://www.w3.org/ W3C]<sup>®</sup> ([http://www.csail.mit.edu/ MIT], [http://www.ercim.org/ ERCIM], [http://www.keio.ac.jp/ Keio]), All Rights Reserved. W3C [http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer liability], [http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks trademark] and [http://www.w3.org/Consortium/Legal/copyright-documents document use] rules apply.

<div id='docbody'>

<html>
<script type="text/javascript">/*<![CDATA[*/
/*
Written by Jonathan Snook, http://www.snook.ca/jonathan
Add-ons by Robert Nyman, http://www.robertnyman.com
Author says "The credit comment is all it takes, no license. Go crazy with it!:-)"
From http://www.robertnyman.com/2005/11/07/the-ultimate-getelementsbyclassname/
*/

var displayed = [];
displayed["bld"] = 1;
displayed["prd"] = 1;

function display(syntax,status) {
var howmany = 0;
if (status=='none') {
displayed[syntax] = 0;
} else {
displayed[syntax] = 1;
}
for ( i in displayed ) {
howmany = howmany + displayed[i];
}
set_display_by_class('p',syntax,status);
if ( howmany == 1 ) {
set_display_by_class('b','syntax-head','none');
} else {
set_display_by_class('b','syntax-head','');
}
}

function getElementsByClassName(oElm, strTagName, oClassNames){
var arrElements = (! (! (strTagName == "*") || ! (oElm.all)))? oElm.all : oElm.getElementsByTagName(strTagName);
var arrReturnElements = new Array();
var arrRegExpClassNames = new Array();
if(typeof oClassNames == "object"){
for(var i=0; !(i>=oClassNames.length); i++){ /*>*/
arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames[i].replace(/\-/g, "\\-") + "(\\s|$)"));
}
}
else{
arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames.replace(/\-/g, "\\-") + "(\\s|$)"));
}
var oElement;
var bMatchesAll;
for(var j=0; !(j>=arrElements.length); j++){ /*>*/
oElement = arrElements[j];
bMatchesAll = true;
for(var k=0; !(k>=arrRegExpClassNames.length); k++){ /*>*/
if(!arrRegExpClassNames[k].test(oElement.className)){
bMatchesAll = false;
break;
}
}
if(bMatchesAll){
arrReturnElements.push(oElement);
}
}
return (arrReturnElements)
}

function set_display_by_class(el, cls, newValue) {
var e = getElementsByClassName(document, el, cls);
if (e != null) {
for (var i=0; !(i>=e.length); i++) {
e[i].style.display = newValue;
}
}
}

function set_display_by_id(id, newValue) {
var e = document.getElementById(id);
if (e != null) {
e.style.display = newValue;
}
}
/*]]>*/
</script>

</html>

<div> 
== Introduction ==

<div><div lang="en" dir="ltr">

Rule-languages and rule-based systems have played seminal roles in the history of computer science and the evolution of information technology. From expert systems to deductive databases, the theory and practice of automating inference based on symbolic representations has had a rich history and continues to be a key technology driver.

Due to the innovations made possible by the Internet, the World Wide Web, and, most recently, the Semantic Web, there is now even greater opportunity for growth in this sector. While some of these opportunities may require advances in research, others can be addressed by enabling existing rule-based technologies to interoperate according to standards-based methodologies and processes. The basic goal of the Rule Interchange Format (RIF) Working Group is to devise such standards and make sure that they are not only useful in the current environment, but are easily extensible in order to deal with the evolution of rule technology and other enabling technologies. This mission of RIF is part of W3C's larger goal of enabling the sharing of information in forms suited to machine processing:

*# Rules themselves represent a valuable form of information for which there is not yet a standard interchange format, although significant progress has been made within the [http://www.ruleml.org/ RuleML Initiative] and elsewhere.
*# Rules provide a powerful business logic representation, as business rules, in many modern information systems.
*# Rules are often the technology of choice for creating maintainable adapters between information systems.
*# As part of the Semantic Web architecture, rules can extend or complement the OWL Web Ontology Language to more thoroughly cover a broader set of applications, with knowledge being encoded in OWL or rules or both.

The purpose of this RIF-UCR document is to describe the use cases that guided the design of RIF and to document the design requirements that were derived from both the use cases and from the basic goals of RIF. RIF-UCR also delivers a structured context for formulating future technical specifications of further RIF dialects. Each dialect targets at a cluster of similar rule languages and enables platform-independent interoperation between them (via interchange of RIF rules). The presented use cases illustrate some of the principal ways in which RIF can provide benefits. RIF can promote innovation and development by fostering collaborative work and providing new opportunities for third-party services. RIF can promote e-commerce by providing interoperability across vendor platforms. RIF can promote efficient process management through reuse, sharing, and the ability to provide unified views across disparate platforms. Last, but not least, RIF can promote the growth of knowledge by enabling reasoning with merged sets of rules originating from disparate knowledge sources.

The RIF-UCR document is structured as follows: Section 2 formulates the overall goals of RIF. Section 3 summarizes the released RIF dialects and the current structure of RIF. Section 4 discusses several important requirements for RIF dialects. Section 5 presents a set of use cases that are representative of the types of application scenarios that RIF is intended to support. The use cases illustrate the utilization of the current RIF dialects. More importantly, the functionality specified in the use cases, together with the requirements discussed in the previous section, serves as input for both the technical specification of future RIF dialects and for the implementation of various variants of these scenarios by RIF-compliant applications and systems.

Although in this document the discussion of requirements precedes the discussion of the use cases in this document, the development of the use cases preceded, and in fact motivated, the development of the requirements. In general, it is intended that for each requirement, there is at least one use case, or straightforward modification of a use case, from which that requirement was derived. There are some exceptions to this rule: some requirements were already defined as constraints in the working group charter, and were not necessarily derived from any specific use case. The fulfillment of such requirements is discussed with respect to the existing RIF dialects.

Note that in fact not all use cases can be represented in a straightforward manner within all RIF dialects. In particular, several use cases cannot be represented within the RIF dialect BLD. This is due first, to the fact that BLD is strictly less expressive than first-order logic (since negation is not expressible), and second, to the fact that some use cases are most naturally represented in languages more powerful than first-order logic, such as modal logics. Following the presentation of each use case in Section 5 is a note indicating in which of the current RIF dialects a use case can be represented naturally, sometimes accompanied by discussion.

It should be noted that even use cases which cannot be represented in a straightforward manner within some RIF dialect, such as BLD, there may be other approaches which will enable representation. For example, although epistemic operators such as <tt>Know</tt> and <tt>Believe</tt> are most straightforwardly represented within a modal logic, it is generally possible to represent such operators in a first-order logic using a possible-worlds semantics. For certain use cases which cannot be naturally represented within some dialect, the extent to which this can be done will be discussed.

</div></div></div><div>

== Goals ==

<div><div lang="en" dir="ltr">
The primary goal of RIF is to be an effective means of exchanging rules that has the potential to be widely adopted in industry and that is consistent with existing W3C technologies and specifications.

<span id="goal-exchange-of-rules" class="anchor"></span>
==== Exchange of Rules ====

The primary goal of RIF is to facilitate the exchange of rules.

<span id="goal-w3c-consistency" class="anchor"></span>
==== Consistency with W3C specifications ====

RIF is intended to be a W3C specification that builds on and develops the existing range of specifications that have been developed by the W3C. This implies that existing W3C technologies should fit well with RIF.

<span id="goal-widescale-adoption" class="anchor"></span>
==== Widescale Adoption ====

It is an explicit goal of the W3C that the Rules Interchange Format will have the maximum potential for widescale adoption. Rules interchange becomes more effective the wider adoption there is of the specification -- the so-called "network effect".

Along with the use cases in the next section, these goals motivate the requirements in Section 5.

</div></div></div><div>

== Structure of RIF ==

<div><div lang="en" dir="ltr">
RIF is described by a set of documents, each fulfilling a different purpose, and catering to a different audience. The three RIF dialects which can be used to represent RIF use cases are:

* [http://www.w3.org/TR/rif-core RIF Core Dialect], which provides a standard, base level of functionality for interchange
* [http://www.w3.org/TR/rif-bld RIF Basic Logic Dialect] and [http://www.w3.org/TR/2010/REC-rif-prd-20100622/ RIF Production Rule Dialect] provide extended functionality matching two common classes of rule engines, namely derivation rules and production rules.

Along with these three dialects, RIF consists of related documents: [http://www.w3.org/TR/rif-fld RIF Framework for Logic Dialects], [http://www.w3.org/TR/rif-dtb RIF Datatypes and Built-Ins 1.0], [http://www.w3.org/TR/rif-test RIF Test Cases], [http://www.w3.org/TR/rif-rdf-owl RIF RDF and OWL Compatibility], [http://www.w3.org/TR/rif-ucr/ RIF Use Cases and Requirements], [http://www.w3.org/TR/rif-owl-rl OWL 2 RL in RIF], [http://www.w3.org/2007/OWL/wiki/PlainLiteral rdf:PlainLiteral], [http://www.w3.org/TR/rif-xml-data RIF Combination with XML data], [http://www.w3.org/TR/primer RIF Primer] and [http://www.w3.org/TR/rif-in-rdf/ RIF In RDF]. For an overview on RIF see the [http://www.w3.org/TR/rif-overview RIF Overview].

RIF is designed as a family of RIF dialects as shown in the following Venn diagram:

[[Image: RIF_DIALECTS_VENN.jpg | Venn Diagram of RIF Dialects]]

Each dialect is a collection of components that works together, forming an interlingua. New dialects are needed when no existing dialect provides the required rule-language features for interchange.

The RIF Framework for Logic-based Dialects ([http://www.w3.org/TR/rif-fld RIF-FLD]) describes mechanisms for specifying the syntax and semantics of logic-based RIF dialects through a number of generic concepts. Every logic-based RIF dialect should specialize these general mechanisms or justify why it does not. This specialization may include leaving out some elements of RIF-FLD, to produce its concrete syntax and model-theoretic semantics. Currently, the first two existing RIF dialects are the RIF Basic Logic Dialect (RIF-BLD) and the RIF Production Rules Dialect (RIF-PRD) which is a partial specialization of FLD.

[http://www.w3.org/TR/rif-bld RIF-BLD] (Basic Logic Dialect) is a specialization of RIF-FLD capable of representing definite Horn rules with equality enhanced with a number of syntactic extensions to support expressive features such as objects and frames, internationalized resource identifiers (IRIs) as identifiers for concepts, and XML Schema data types.

[http://www.w3.org/TR/rif-prd RIF-PRD] (Production Rules Dialect) specifies a production rules dialect to enable the interchange of production rules. The condition language of RIF PRD is defined in Core as a common subset of RIF BLD and RIF PRD.

[http://www.w3.org/TR/rif-core RIF-Core] (Core Dialect) specifies a common subset of RIF-BLD and RIF-PRD which includes RIF-DTB.

The normative syntax for RIF dialects is a concrete XML syntax. A non-normative presentation syntax is additionally specified for each dialect, to allow a more easily readable and compact presentation of language fragments (such as examples).

</div></div></div><div>

== Requirements ==

<span id="req-semantic-tagging" class="anchor"></span>

<div><div lang="en" dir="ltr">
The goals and use cases motivate a number of requirements for a Rule Interchange Format. The Working Group has approved the following requirements.

<span id="req-implementability" class="anchor"></span>

=== Implementability ===

''RIF must be implementable using well understood techniques, and should not require new research in, e.g., algorithms or semantics in order to implement translators.''

<span id="req-semantic-precision" class="anchor"></span>

=== Semantic precision ===

''RIF core must have a clear and precise syntax and semantics. Each standard RIF dialect must have a clear and precise syntax and semantics that extend RIF core.''

<span id="req-extensible" class="anchor"></span>

=== Extensible Format ===

''It must be possible to create new RIF dialects which extend existing dialects (thus providing backward compatibility) and are handled gracefully by systems which support existing dialects (thus providing forward compatibility).''

<span id="req-translators" class="anchor"></span>

=== Translators ===

''For every standard RIF dialect it must be possible to implement translators between rule languages covered by that dialect and RIF without changing the rule language.''

<span id="req-standard-components" class="anchor"></span>

=== Standard components ===

''RIF implementations must be able to use standard support technologies such as XML parsers and other parser generators, and should not require special purpose implementations when reuse is possible.''

<span id="req-coverage" class="anchor"></span>

=== Rule language coverage ===

''Because of the great diversity of rule languages, no single interchange language is likely to be able to bridge between all. Instead, RIF provides dialects each of which is targeted at a cluster of similar rule languages. RIF must allow intra-dialect interoperation, i.e. interoperability between semantically similar rule languages (via interchange of RIF rules) within one dialect, and should support inter-dialect interoperation, i.e. interoperation between dialects with maximum overlap.''

<span id="req-compliance-model" class="anchor"></span>

=== Compliance model ===

''The RIF specifications must provide clear conformance criteria that define what is or is not a conformant RIF implementation.''

<span id="req-default-behavior" class="anchor"></span>

=== Default behavior ===

''RIF must specify at the appropriate level of detail the default behavior that is expected from a RIF compliant application that does not have the capability to process all or part of the rules described in a RIF document, or it must provide a way to specify such default behavior.''

<span id="req-different-semantics" class="anchor"></span>

=== Different semantics ===

''RIF must cover rule languages having different semantics.''

<span id="req-dialects" class="anchor"></span>

=== Limited number of dialects ===

''RIF must have a standard core, and a limited number of standard dialects based upon that core.''

<span id="req-comments" class="anchor"></span>

=== Embedded comments ===

''RIF must be able to pass comments.''

<span id="req-metadata" class="anchor"></span>

=== Embedded metadata ===

''RIF must support metadata such as author and rule name.''

<span id="req-owl-data" class="anchor"></span>

=== OWL data ===

''RIF must cover OWL knowledge bases as data where compatible with RIF semantics.''

<span id="req-rdf-data" class="anchor"></span>

=== RDF data ===

''RIF must cover RDF triples as data where compatible with RIF semantics.''

<span id="req-dialect-identification" class="anchor"></span>

=== Dialect Identification ===

''The semantics of a RIF document must be uniquely determined by the content of the document, without out-of-band data.''

<span id="req-xml-syntax" class="anchor"></span>

=== XML syntax ===

''RIF must have an XML syntax as its primary normative syntax.''

<span id="req-xml-types" class="anchor"></span>

=== XML types ===

''RIF must support an appropriate set of scalar datatypes and associated operations as defined in XML Schema part 2 and associated specifications.'' See the charter on [http://www.w3.org/2005/rules/wg/charter#datatype0 Datatype support].

<span id="req-merge" class="anchor"></span>

=== Merge Rule Sets ===

''RIF must support the ability to merge rule sets.''

<span id="req-rulesets" class="anchor"></span>

=== Identify Rule Sets ===

''RIF must support the identification of rule sets.''

<span id="req-xml-data" class="anchor"></span>

=== XML data ===

''RIF should be able to accept XML elements as data.''

<span id="req-rif-text" class="anchor"></span>

=== Internationalized text ===

''RIF must support internationalized text — that is, text that additionally conveys information in terms of a language tag.''

</div></div></div><div>

== Use Cases ==

<div><div lang="en" dir="ltr">

A use case for RIF consists of a description of a problem together with a solution that either uses an existing RIF dialect or requires the specification of a new RIF dialect.

The set of use cases is intended to do the following:
<ul>
<li>motivate the need for a RIF in a broad range of application domains and industrial sectors;</li>
<li>provide scenarios that motivate the design of RIF and explain the benefits of a RIF in such scenarios;</li>
<li>guide users to RIF's specified dialects; and</li>
<li>motivate the working group's set of requirements for a RIF.</li>
</ul>

The set of use cases were developed over several years.
Nearly [http://www.w3.org/2005/rules/wg/wiki/Use_Cases fifty use cases] documenting the need for a RIF were originally submitted by the working group members. These were grouped into general categories and then synthesized as much as possible. The goal was to come up with a relatively small set of use cases that would cover a broad range of possible requirements. In addition, it was desired that the use cases refer to popular application domains and industrial sectors. For every use case we will briefly discuss the coverage of the use case by the existing three RIF dialects (Core, BLD, and PRD).



</div></div>

<div>

=== Negotiating eBusiness Contracts Across Rule Platforms ===

<div><div lang="en" dir="ltr">

This use case illustrates a fundamental use of RIF: to supply a vendor-neutral representation of rules, so that rule-system developers and stakeholders can do their work and make product investments without concern about vendor lock-in, and in particular without concern that a business partner does not have the same vendor technology. It also illustrates the fact that RIF can be used to foster collaborative work. Each developer and stakeholder can make a contribution to the joint effort without being forced to adopt the tools or platforms of the other contributors.

John is negotiating an electronic business contract regarding the supply of various types of items that Jane's company is manufacturing. Jane and John interchange the contract-related data and rules involved in the negotiation in electronic form so that they can run simulations. Both agree on a standard Business Object Model / data model (i.e., vocabulary / ontology) for the goods and services involved - in this case an XML schema and appropriate test XML documents are interchanged with their rules. Since John and Jane run applications based on different vendors' rule engines and rule languages, they interchange the rules using RIF; both vendors used can interpret the XML schema and data, and produce the results as an amended XML document. John's company defines its purchase orders in terms of an XML description of goods, packaging, delivery location and date with delivery and payment rules. A rule proposed by John might be the following:

<pre width=130>
If an item is perishable and it is delivered to John more than 10 days after the scheduled delivery date then the item will be rejected by him.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
This rule set can be adequately represented in RIF Core either using (ordered) relations as e.g. in standard Logic Programming, unordered relations using named arguments, or in a more object-oriented encoding using frames.<br />
<br />
''Ordered representation in RIF Core presentation syntax using relations:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
ex:reject("John" ?item) :-
ex:perishable(?item)
ex:delivered(?item ?deliverydate "John")
ex:scheduled(?item ?scheduledate)
?diffdays = External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
External(pred:numeric-greater-than(?diffdays 10))
)
)
)
</code>
<br />
Note, the nesting of external built-in functions and operations and the assignment/binding of (intermediate) result (sets) from functions to variables by equality in this example.<br />
<br />
''Unordered representation in RIF Core presentation syntax using namened arguments:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
ex:reject(ex:ware -> ?item ex:receiver -> "John") :-
ex:perishable(ex:ware -> ?item)
ex:delivered(ex:ware -> ?item ex:datetime -> ?deliverydate ex:receiver -> "John")
ex:scheduled(ex:datetime -> ?scheduledate ex:ware -> ?item)
?diffdays = External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
External(pred:numeric-greater-than(?diffdays 10))
)
)
)
</code>
<br />
Note, the arbitrarily unordered named argument arguments of the user-defined relations, in contrast to external built-in functions and operations, which must have a predefined order. <br />
<br />
''Object-Oriented Representation in RIF Core presentation syntax using frames:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
?item[ex:status -> "rejected"] :-
?item[ex:perishable -> true]
?item[ex:deliveredOn -> ?deliverydate ex:delivered -> "John"]
?item[ex:scheduledOn -> ?scheduledate ex:delivered -> "John"]
External(pred:numeric-greater-than(
External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
10
)
)
)
)
</code>
</p>

Jane replies with some suggested rule changes:

<pre width=130>
If an item is perishable and it is delivered to John more than 7 days after the scheduled delivery date but less than 14 days after the scheduled delivery date then a discount of 18.7% will be applied to the delivered item.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
''Representation in RIF Core presentation syntax using positional relations:'' <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?item ?deliverydate ?scheduledate ?diffdays (
ex:discount("John" ?item 18.7 ) :-
ex:perishable(?item)
ex:delivered(?item ?deliverydate "John")
ex:scheduled(?item ?scheduledate)
?diffdays = External(func:days-from-duration(
External(func:subtract-dateTimes(?deliverydate ?scheduledate))
))
External(pred:numeric-greater-than(?diffdays 7))
External(pred:numeric-less-than(?diffdays 14))
)
)
)
</code>
<br />

The binding of the intermeditate results to the variable "?diffdays" avoids repetition, as it used twice in the subsequent rule conditions. As demonstrated in the previous examples, similar representations for this rule can be given using slots or frames and as a production rule which asserts the conclusion as a new fact.
</p>

John considers this and agrees with Jane. Both organizations utilize these rules in their operational systems using disparate rule representations internally to compute prices for this order and determine contract compliance.

Future requests for the supply of items by John's company are defined on their purchasing web site, as the appropriate XML schema and a RIF ruleset (or rulesets). This allows Jane's company and its competitors to respond electronically with XML cost sheets. Suppliers respond with multiple cost sheets with different variations on the RIF rules proposed by John's company, allowing John's company to review the alternative rules with their associated costs to determine whether they, as a business, would benefit by relaxing or adding new rules as proposed by suppliers.

'''Supported by: RIF Core, RIF BLD, RIF PRD'''

The rules of this use case can be adequately represented in RIF Core (and BLD and PRD) either using (ordered) relations, as e.g. in standard Logic Programming, unordered relations, using named arguments, or in a more object-oriented encoding using frames.

</div></div></div><div>

=== Negotiating eCommerce Transactions Through Disclosure of Buyer and Seller Policies and Preferences ===

<div><div lang="en" dir="ltr">

This use case concerns the ability of parties involved in formal transactions or procedures, e.g., credit card authorization of a purchase, access of private medical records, etc., to express and protect their interests within a policy-governed framework. The goal is to formally encode the preferences, priorities, responses, etc., of the parties in such a way that the overall policy can work as intended while providing opportunity for automatic negotiation of terms when allowed by the policy. Utilization of RIF in this use case would extend the scope of this technology, affording a higher degree of interoperability, as well as enabling re-use and sharing of preferences, etc., through interchange. The detailed scenario below shows how this would work.

Alice wants to buy a device at an online site called "eShop." Alice employs software called "Emptor" that functions as automated negotiating agent for buyers. eShop employs software called "Venditor" as automated negotiating agent for sellers.

Alice's and eShop's policies describe who they trust and for what purposes. The negotiation is based on the policies, which are specified as rules, and credentials Emptor and Venditor have. These policies and credentials are disclosed (interchanged) so as to automatically establish trust with the goal of successfully completing the transaction.

Policies are themselves subject to access control. Thus, rule interchange is necessarily done during negotiation and (in general) depends on the current level of trust that the systems have on each other. Since Emptor and Venditor might use different rule languages and/or engines for evaluating (own and imported) rules, a (standard) rule interchange format (RIF) needs to be employed for enabling the rule interchange between the two systems.

When Alice clicks on a "buy it" button at the eShop's Web site, Emptor takes over and sends a request to eShop's site. Venditor receives the request and sends parts of its policy (i.e. a set of rules) back to Emptor. Among other things, the policy states that:

<pre width=130>
In order to grant access a buyer must provide valid credit card information together with delivery information (address, postal code, city, and country).
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF Core presentation syntax using relations and frames in combination: <br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?buyer ?creditCard ?address (
ex:permit_access("eShop" ?buyer) :-
ex:provide("eShop" ?buyer)
?buyer[ex:card -> ?creditCard ex:deliveryAddr -> ?address]
ex:valid_payment_method(?creditCard)
ex:valid_delivery_address(?address)
)

Forall ?type ?person ?first ?last ?number ?code ?date ?month ?year (
ex:valid_payment_method(?card) :-
?card[type -> ?type
ex:holder -> ?person
ex:number -> ?number
ex:code -> ?code
ex:expiry -> ?date]
?person[ex:lastname -> ?last ex:firstname -> ?first]
?date[ex:month -> ?month ex:year -> ?year]
ex:credential(?type ?person ?number ?code ?date)
)

Forall ?address ?last ?first ?street ?strname ?number ?code ?city ?country (
ex:valid_delivery_address(?address) :-
?address[ex:name -> ?person ex:street -> ?street ex:postal_code -> ?code ex:city -> ?city ex:country -> ?country ]
?person[ex:lastname -> ?last ex:firstname -> ?first]
?street[name -> ?strname ex:number -> ?number]
ex:declaration(?person ?street ?number ?code ?city ?country)
)

)
)
</code>

Note that in this example relational representation is used in combination with frame representation. Such mixing of representation styles is supported by RIF.
</p>

Rules express compactly possible ways in which a resource can be accessed; by exchanging them negotiations are shorter and privacy protection is improved. In the example, Venditor reveals part of its policy in form of rules to enable Emptor to choose how to answer, i.e. to decide which credentials and required information to disclose.

For determining whether Venditor's request for information is consistent with Alice's policy, Emptor takes its rules into account, which state for example:

<pre width=130>
Disclose Alice's credit card information only to online shops belonging to the Better Business Bureau.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF Core presentation syntax:

<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)

Group
(
Forall ?Shop ?card ?Credential ?Buyer (
ex:provide(?Shop ?Buyer ) :-
?Buyer[ex:card -> ?creditCard ex:deliveryAddr -> ?address]
ex:belongs_to(?Shop "Better Business Bureau")
)

Forall ?deliveryAddr ?card ?Date ?Person ?Street (
ex:Alice[ex:card -> ?card ex:deliveryAddr -> ?deliveryAddr] :-
?Date = ex:Date[ex:month -> 12 ex:year -> 2012]
?Person = ex:Person[ex:lastname -> "Sure" ex:firstname -> "Alice"]
?Street = ex:Street[name -> "North Street" number -> 111]
?card= ex:Card[ ex:type -> "Visa"
ex:holder -> ?Person
ex:number -> "123456789"
ex:code -> "123"
ex:expiry -> ?Date
]
?deliveryAddr = ex:DeliveryAddress[ ex:name -> ?Person
ex:street -> ?Street
ex:postal_code -> "NE3456"
ex:city -> "New York"
ex:country -> "USA"
]
)

)
)
</code>

</p>

By disclosing (interchanging) the above given rule, Emptor asks Venditor to provide credentials saying that it belongs to the Better Business Bureau, Alice's most trusted source of information on online shops. eShop has such a credential and its policy contains a rule stating to release it to any potential purchaser. Hence, Venditor passes the credential to Emptor. Emptor is now ready to disclose Alice's credit card information to Venditor but it still must check whether disclosing all the information does not break Alice's denial constraints. Alice has stated two constraints stating:

<pre width=130>
For anonymity reasons, never provide both her birth date and postal code.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
The current RIF dialects do not specify explicit constructs for integrity constraints.
</p>

For this purchase, Alice birthdate is no issue. Thus, Alice's constraints are respected. Emptor therefore provides Alice's credit card information to Venditor.

Companies that provide software such as Venditor and Emptor would make use of RIF in a number of ways. The rules expressing Alice's and/or eShop's policies could be expressed in different rule languages but still work with the software, using RIF-based interchanges. Secondly, assuming Venditor and Emptor are products of different companies using different internal rule languages, it would still be possible for them to work together in real-time. When these two systems need to exchange policy or preference information of their respective clients they would use RIF to enable the interchange in real-time. When Venditor sends its initial policy information to Emptor it uses RIF. Emptor takes that policy and translates it from RIF to its internal representation in order to determine what it needs to do.

'''Not supported by the current RIF dialects (Core, BLD, PRD) '''

Current RIF dialects do not specify explicit constructs for integrity constraints; thus, this use case is not adequately supported by any of these dialects.

</div></div></div><div>

=== Collaborative Policy Development for Dynamic Spectrum Access ===

<div><div lang="en" dir="ltr">

This use case demonstrates how RIF leads to increased flexibility in matching the goals of end-users of a service/device, with the goals of providers and regulators of such services/devices. RIF can do that because it enables deployment of third party systems that can generate various suitable interpretations and/or translations of the sanctioned rules governing a service/device.

This use case concerns ''Dynamic Spectrum Access for wireless communication devices''. Recent technological and regulatory trends are converging toward a more flexible architecture in which reconfigurable devices may operate legally in various regulatory and service environments. The ability of a device to absorb the rules defining the policies of a region, or the operational protocols required to dynamically access available spectrum, is contingent upon those rules being in a form that the device can use, as well as their being tailored to work with devices in the same class having different capabilities.

In this use-case we suppose a region adopts a policy that allows certain wireless devices to opportunistically use frequency bands that are normally reserved for certain high-priority users. ([http://europa.eu.int/eur-lex/lex/LexUriServ/site/en/oj/2005/l_187/l_18720050719en00220024.pdf The decision] by the European Union to allow "Dynamic Frequency Selection" (DFS) use of the 5 GHz frequency band by wireless systems, a band intermittently used by military and weather radar, is a recent example.)

Suppose the policy states:

<pre width=130>
A wireless device can transmit on a 5 GHz band if no priority user is currently using that band.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>

<br />Note, since default negation (not) such as negation as failure is not supported by RIF BLD there is no adequate way to represent that "no priority user is currently using the band".
</p>

How does a device know that no priority user is currently using a band it wants to use? The answer will depend on the specific capabilities of the device. One type of device may answer this question by sensing the amount of energy it is receiving on that band. That is, it might employ the rule:

<pre width=130>
If no energy is detected on a desired band then assume no other device is using the band.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
Forall ?device ?band ?level (<br />
ex:used(?device ?band) :- <br />
ex:detect(ex:energy(?level ?band))<br />
External(pred:numeric-greater-than(?level 0))<br />
)<br />
)<br />
)<br />
</code>
<br />Note, the engergy detection function would require an external call for sensing the level of energy. Such procedural attachments cannot be specified in BLD. Reaction rules provide event detection capabilities.
</p>

A second type of device, may get information from a control channel that lets it know whether the desired band is being used by a priority user. That is, it might employ the rule:

<pre width=130>
If no control signal indicating use of a desired band by a priority user is detected then assume the band is available.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
Forall ?device ?band ?user (<br />
ex:used(?device ?band) :- <br />
ex:detect(ex:signal(?user ?band))<br />
ex:priority(?user,"high").<br />
)<br />
)<br />
)<br />
</code>
<br />
</p>

So each type of device will need to employ different "interpretations" or "operational definitions" of the policy in question.

Now assume that there are 10 manufacturers of these 2 different types of wireless devices. Suppose that each of these manufacturers uses a distinct rule-based platform in designing its devices. Each manufacturer needs to write 2 interpretations of the policy (for each of the two types of device). That means that 20 different versions of the policy must be written, tested and maintained.

Enter RIF. The 10 manufacturers form a consortium. This is a third-party group that is responsible for translating regional policies into RIF. When it does so, however, it provides different versions corresponding to the possible interpretations (operational definitions) of the policy. So in this case, 2 RIF versions of the DFS policy are provided for the 2 types of device mentioned above. Each of these RIF specifications can be automatically translated into the appropriate rule-platform provided a RIF-Compiler for the target device architecture exists. Clearly it will be in the interest of each device manufacturer to develop such compilers. That is because the manufacturer only needs to develop such a compiler ''once'' for every architecture it owns. Contrast that investment with having to produce, test, and maintain different versions of various policies over the lifetime of a product.

This arrangement also allows the overall process to be organized in a fashion that maintains the natural division of labor in the corresponding division of artifacts produced by that labor: the policy and its various interpretations are written and maintained in platform-independent artifacts (RIF); knowledge about how to translate from RIF to a particular device architecture is maintained in the compilers. A change in policy is inserted at the top level in the policy artifact hierarchy where it should be; possible operational interpretations of that change are inserted at the next level down; the implementation implications for the various device architectures is generated automatically at the lowest level.

'''Partly supported by: RIF PRD'''

The energy detection function specified in this use case would require an external call to a device that would sense the level of energy. Such procedural attachments cannot be specified in the current RIF dialects. Reaction rules support (complex) event detection capabilities on, e.g., event streams over sensor data.

This use case is not supported at all by RIF BLD, and by extension, by RIF Core. These dialects do not support negation, and
the use case makes explicit mention of negation, e.g. for representing that "no priority user is currently using the band."<br />

</div></div></div><div>

=== Access to Business Rules of Supply Chain Partners ===

<div><div lang="en" dir="ltr">

A business process (BP) designer designs processes that can span multiple departments in the same business as well as other business partners. A classic example of this is the integration of supply chain business processes which typically involve multiple partners. Supply chain integration involves exposing a certain amount of business logic between partners as well as integrating processes across partners. In such activities it is therefore often necessary to access or invoke rules that originate in other ownership domains.

A key part of a business process is the logic used to make decisions within the process. Such logic is often coded in rules because rule languages are easier for BP designers to understand and manipulate than procedural code (as in Java) -- although both forms of business logic are prevalent. Where business logic is represented in different rule languages this presents a significant burden to the BP designer in designing an integrated process.

Two primary integration modalities are possible: importing the different rulesets into a single engine and processing them in a uniform manner, or accessing the rulesets by querying remote engines and processing the results. Each modality has its uses and contra-indications. Where there are strong ownership boundaries involved it may not be permitted to merge rule sets of partners.

For example, in an insurance adjustment process, the inspection of a damaged vehicle is often performed by independent inspectors. The critical decision in how an insurance claim will proceed is whether the damage results in a total loss or whether a repair is feasible:

<pre width=130>
If inspector believes vehicle is repairable then process as repair otherwise process as total loss.
</pre>

The question of whether a vehicle is repairable is one that is dependent on the processes executed by the inspector and cannot be directly integrated into the insurance companies own adjustment process. The insurance company effectively queries the inspector's logic. Within the adjustment process, the overall flow will be quite different for repairable claims and total loss claims.

Even in the case of a single company, which is nominally under a common ownership domain, information and business logic is often controlled by multiple stakeholders. For example, a large company will often be organized into semi-independent profit centers (business units). Each unit will be motivated differently, will have different ontologies and business logic and may use different rule languages to represent their logic (this is particularly the case where one company acquires another company).

RIF should be used to permit the BP designer a unified view of the different partners' business rules in designing the process, while at the same time permitting the partners to continue to leverage their own business rules without changing their own technologies.

How such a unified view of the business rules can be realized in a deployed BP will depend on both technical and non-technical factors. Even where all the parties are required to use a common rule language, there may be compelling ownership issues that mitigate against a simple merge of the rule sets. In the situation where merging of rulesets is not possible, then a query-style access to partners' business rules may be used. In this way, RIF permits a unified dynamic view of the business rule logic no matter what the original form of the rules.

For this to be viable from a business perspective it is critical that the semantics of the rules and query exchange be completely predictable and preferably loss-less.

'''Not supported, in a straightforward manner, by the current RIF dialects'''

<p>
BLD and PRD do not support modal operators or predicates on quoted sentences; therefore standard representations of knowledge, belief, and/or uncertainty cannot be specified in BLD and PRD. Even without such constructs, it can be possible to represent knowledge or belief using the semantics of possible worlds <nowiki>[</nowiki>[[#moore|Moore1980]]]. That is, one can get the effect of saying that an agent A believes proposition P by saying that P holds in all words that are belief-accessible to P. For example, to get the effect of saying
<pre width=130>Believe(john,overCreditLimit(bill,t))
</pre>
</p>

<p>
one says instead
<pre width=130>
holds(overCreditLimit(bill),t1) :- beliefAccessible(john,t,t1)
</pre>
</p>

The translation between sentences involve operators such as Know and Believe and sentences that make direct use of possible worlds relies on the possible-worlds semantics, which posits properties on the knowledge-accessibility or belief-accessibility relation. These relations correspond to axioms on the Know and Believe operators.

<p>
Such a strategy could work, to a certain extent, in RIF PRD, but would not work in RIF BLD. This is because expressing the standard axioms on belief or knowledge would require the use of negation, which is not supported by BLD.

For both PRD and BLD there is an additional consideration, which is that the notion of reification is in general not supported by the dialects of RIF.

</p>

</div></div></div><div>

=== Managing Inter-Organizational Business Policies and Practices ===

<div><div lang="en" dir="ltr">

This use case concerns organizations that acquire rule sets from external sources and that have to integrate these new rule sets into their existing rule bases. Such rule sets may be acquired in the following ways:

* An organization may buy rule sets from expert sources
* An organization may use rule sets from shared interest groups such as trade associations
* A component of a distributed organization may acquire rules when a rule set is distributed across a distributed organization. In such case, there may be different localization requirements in different regions and locations, entailing a variety of integration challenges in these various locations and component organizations.

The following scenario examines these different methods of acquisition and the various types of integration and management issues that may arise.

''This scenario uses the (fictitious) car rental company, EU-Rent, used as the case study in the [http://www.omg.org/spec/SBVR/1.0/ Semantics of Business Vocabulary and Business Rules Specification]. The EU legislation discussed is also fictitious, as are the consulting companies CarWise and AutoLaw.''

EU-Rent's corporate HQ deals with CarWise, a consulting company with expertise in managing fleets of vehicles. One service CarWise offers to its clients is negotiating with EU regulators to clarify regulations.

An EU regulator issues a directive dealing with insurance for vehicles owned by corporations. CarWise agrees with the regulator on an acceptable interpretation, and provides EU-Rent (and its other car rental clients) with two sets of rules:

* A business policy, stating that every car rental must be insured for damages to third parties.
* A supporting rule set, addressing levels of required coverage, tax calculation in different EU countries, liabilities in rentals that span multiple countries, and reporting of compliance with this business policy.

EU-Rent decides that it will maintain its compliance documentation electronically. CarWise then provides EU-Rent with an additional rule set for electronic compliance documentation, including such rules as:

<pre width=130>
Each tax schedule must have electronic signatures from two EU-Rent employees who are at least at the level of manager.
</pre>

Before it can use the two general rule sets, EU-Rent needs to connect them to the relevant data sets in its IT systems, e.g. relate the EU country-specific taxation rules to the relevant record types in its databases.

EU-Rent corporate HQ subsequently decides that the cost of third-party insurance will be built into the basic cost of each rental, and not shown as a separate item on the rental contract, to ensure that it can never be omitted from rentals or disputed by renters. It then sends three rule sets to its operating companies in the EU:

* The rule set for car rental insurance (from CarWise), including the basic policy and the supporting rule set.
* The rule set for electronic compliance documentation (also from CarWise).
* Its own rule set for building insurance into the basic rental cost.

The operating companies then have to localize the rule sets for their countries of operation. For example, in the UK, another consulting company, AutoLaw, advises EU-Rent of rules for placing aggregate insurance for large fleets with more than one insurer in order to spread the risk, for example:

<pre width=130>
For fleets of more than 200 vehicles, fleet insurance policies must be placed with at least 3 insurers, each of whom covers at least 25% of the risk.
</pre>

A timing issue makes it difficult for EU-Rent UK to strictly comply with this directive. EU-Rent UK has some existing insurance policies in place, which provide third-party insurance as an explicit item, and it cannot get refunds on early termination. It therefore asks corporate HQ for a temporary dispensation: that it can continue its existing insurance until it expires, and then switch to the new rules.

EU-Rent HQ permits this, not just for the UK, but for any of its operating companies that have similar insurance arrangements. To ensure that this dispensation is temporary, it adds a new rule:

<pre width=130>
Insurance policies that provide separate third-party coverage must not be renewed.
</pre>

EU-Rent HQ is also concerned about meeting deadlines for electronic filing. It introduces a new rule that it distributes to operating companies:

<pre width=130>
Each electronic compliance document must have its required electronic signatures 48 hours before its filing deadline.
</pre>

This rule is meant to be implemented as follows: If '48 hours before filing deadline' passes, and the electronic signatures are not present, then the operating company's rules system must report the out-of-compliance situation, and subsequently wait for the responsible managers to provide the signatures.

'''Partially supported by RIF PRD'''

The business rules in this use case express norms which requires the representation of deontic operators for obligations and permissions. Deontic operators are generally represented by modal operators, as in <nowiki>[</nowiki>[[#ref-Horty-deontic-logic|Horty2001]]]. As was discussed above, for Know and Belief, it is not possible to express modal operators directly within RIF dialects. However, one can use the technique discussed above, of reasoning directly within possible worlds. This is possible within PRD though not within BLD or Core.

Moreover, in a meta programming approach it is possible to express deontic reasoning rules with RIF PRD. Using this approach, too, one would not be able to use BLD or Core, since some business rules express negated deontic norms.

=== Ruleset Integration for Medical Decision Support ===

<div><div lang="en" dir="ltr">

Decision support systems aid in the process of human decision making, especially decision making that relies on expertise. Reasoning with rules is an important part of this expert decision making. For complex decision support systems, it is expected that rules will be furnished by a variety of different sources, including ontologies, knowledge bases, and other expert systems. This use case illustrates how RIF makes it possible to merge rulesets from diverse sources in diverse formats into one rule-based system, thereby enabling inferences that might otherwise have remained implicit.

Medical decision support systems, such as the ones discussed below, might use rules from pharmaceutical knowledge bases, laboratory knowledge bases, patient databases, and medical ontologies. For example, a large amount of information on therapeutic medications (drug taxonomies, indications, contraindications, and clearance times) and diseases (disease taxonomies, etiologies, and symptoms) is contained in existing ontologies such as [http://www.snomed.org SNOMED] Clinical Terms®. Rules can be used to express therapeutic recommendations, to formulate queries about relevant prescriptions for a patient, and to assess the effectiveness of a treatment.

The following scenario illustrates how rule-interchange would be used in various medical decision support systems to support the following functionalities:

* Improving situation assessment, e.g., determining when a patient needs to be put on medication, or have his medication switched.
* Prescribing a course of action, e.g., determining which drug is best for a patient in a particular circumstance.
* Improving event planning, e.g., determining whether a patient can be scheduled for a procedure given the medication that he is currently taking.

Bob, 62 years old and reasonably healthy, has been going to his internist, Dr. Rosen, for several years for control of his Type II diabetes. Dr. Rosen has been using the <tt>AutoDoc</tt> system to help him decide when to switch to medications and which drugs to prescribe. The <tt>AutoDoc</tt> system uses two sources when making its recommendations: a laboratory knowledge base giving particular results for patients and specifying when these results are out of normal range, and a pharmaceutical knowledge base giving guidelines for the use of medications. Automated reasoning with rules from these combined sources is possible if the rules are first mapped to RIF. Here are two specific examples of such synergistic effects.

''This scenario discusses the fictitious expert systems <tt>AutoDoc</tt> and MEDIC. In the interest of readability and brevity, the information and rules presented in the following scenario may not precisely capture the current state of medical knowledge and best practices in this field, but may be somewhat simplified.''

Originally Bob's diabetes was controlled through diet and moderate exercise. In time, however, Bob's blood glucose level began to rise, even under this regimen. Due to Bob's elevated <tt>HbA1c</tt> level (which indicates one's average blood sugar level over the last several months), Dr. Rosen prescribed oral medication for Bob. He was forced to change Bob's medication a number of times over the course of a year. He first prescribed Precose, an oral alpha-glucosidase inhibitor, but had to discontinue this medication due to undesired side effects. He then prescribed several sulfonylurea drugs, Micronase and Glucotrol, to no avail. Bob's lab results still indicated an elevated <tt>HbA1c</tt> level. The following rule from the ''laboratory knowledge base'' suggests that Bob's treatment at that time was not effective:

<pre width=130>
If a Type II diabetes patient's current level of HbA1c is high, then the patient's current treatment is considered to be ineffective.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations and an event calculus axiomatization:<br />
<br />
<code style="white-space: pre;"> Document(

Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
Forall ?Patient ?Treatment ?Level ?T (<br />
ex:holdsAt(ex:ineffective(?Patient ?Treatment) ?T) :-<br />
ex:holdsAt(ex:hasDisease(?Patient "diabetesTypeII") ?T)<br />
ex:holdsAt(ex:elevated(levelOf(?Patient "hbA1c" ?Level)) ?T)<br />
ex:holdsAt(ex:treatmentPlan(?Treatment ?Patient) ?T)<br />
)<br />
)<br />
)<br />
</code>
<br />Note, the example requires the formalization of changeable states which can be represented by an event calculus axiomatization. [[#event-calculus|KS86]]] The EC axioms can then be represented using RIF BLD.
</p>

To deal with this problem, Dr. Rosen was about to prescribe Glucophage (metformin, one of the biguanides) 850 mg, 3 times a day, when as usual, he double checked his prescription with the <tt>AutoDoc</tt> system. The system, based on the following guidelines from the ''pharmaceutical knowledge base'', informed Dr. Rosen that he should have prescribed an oral bitherapy (two medications, each of which controls blood sugar levels) instead of a monotherapy.

<pre width=130>
If an oral monotherapy at recommended doses of a sulfonylurea or biguanide, combined with lifestyle changes, is ineffective, then the monotherapy should be replaced by an oral bitherapy.
</pre>

Based on the recommendation from <tt>AutoDoc</tt>, Dr. Rosen switched Bob's prescription to Glucophage and Avandia (rosiglitazone, one of the thiazolidinediones).

Bob recently suffered a concussion and has become increasingly forgetful. He went to see a neurologist, Dr. Cervello, who prescribed a contrast MRI (Magnetic Resonance Imaging). When asked about current medication, Bob told Dr. Cervello that he was taking Glucotrol to control his diabetes, forgetting that he had been switched to Glucophage. This was potentially problematic, since Glucophage should not be taken close to the administration of a contrast injection.

Fortunately, when Bob went to the lab to schedule his MRI, the medical receptionist pulled up MEDIC (Medical Event and Drug Interaction Consultant), the hospital's new automated system, which checks for incompatible medical events and/or drugs (e.g., liposuction scheduled during pregnancy, blood thinners prescribed before surgery, etc.).

MEDIC uses a variety of sources in its reasoning, including:

* the pharmaceutical knowledge base, described above
* the patient databases, which gives the patient record, including the medications a patient is currently taking
* the hospital medical event protocol knowledge base, which details the protocol used for different medical procedures

In this case, MEDIC uses all three sources, and pulls up the following information:

* Metformin is contraindicated with contrast dye.
* Metformin is the generic form of Glucophage.
* Bob is taking Glucophage.
* The contrast MRI requires as one of its steps injecting the patient with contrast dye.

MEDIC therefore determines that Bob should not be taking the contrast MRI at this time.

For MEDIC to work, the rules from these different sources must be mapped to a unified interchange format.

'''Supported by RIF PRD'''

The use case requires the formalization of changeable states (fluents) which can be represented by e.g. an event calculus axiomatization <nowiki>[</nowiki>[[#event-calculus|KS86]]]. However, to formulate the classical event calculus as a set of Horn clause rules, so that it could be run as a Prolog program, negation as failure is needed, which is not supported by RIF BLD.
The use case can be represented in RIF PRD which supports changeable states (modifications) and assertions and retractions of knowledge.

</div></div></div><div>

=== Interchanging Rule Extensions to OWL ===

<div><div lang="en" dir="ltr">

Rules are often used in conjunction with other declarative knowledge representation formalisms, such as ontology languages (e.g. RDF and OWL), in order to provide greater expressive power than is provided by either formalism alone. Ontology languages, for example, typically provide a richer language for describing classes (unary predicates). Rules, on the other hand, typically provide a richer language for describing dependencies between properties (binary predicates), and may also support higher-arity predicates.

Rich domain models combining both rules and ontologies are often needed in domains such as medicine, biology, e-Science and Web services. In such domains, several actors and/or agents are involved that have to interchange the data, ontologies, and rules that they work with. An example is the use of such a domain model in an application that aims at assisting the labeling of brain cortex structures in MRI images. In this case, an OWL ontology is used to capture knowledge about the most important brain cortex anatomical structures, and a rule base is used to capture knowledge about mereological and spatial dependencies between properties.

For example, a rule is used to express the dependency between the ontology properties isMAEConnectedTo and isMAEBoundedBy, in particular (a simplified form of) the knowledge that two Material Anatomical Entities having a shared boundary are connected:

<pre width=130>
If MAE X is bounded by Z and MAE Y is also bounded by Z then X is connected to Y.
</pre>

Benefits of interchange via RIF include the ability to collaboratively develop and share valuable knowledge, the ability to integrate anatomical images, possibly from distributed image sources, and the ability to use large-scale federated systems for statistical analysis of brain images of major brain pathologies.

'''Supported by RIF Core, RIF BLD and RIF PRD'''

The use case uses RIF SWC to combine RIF Rules with OWL ontologies.
</div></div></div><div>

=== Vocabulary Mapping for Data Integration ===

<div><div lang="en" dir="ltr">

This use case concerns the integration of information from multiple data sources. The Semantic Web provides a common data representation and query language, which greatly simplifies access to diverse sources but does not directly address the problem that independent data sources may have rather divergent information models.

Rules are an effective way to express mappings between such information models. However, rules locked within local proprietary systems cannot be reused. With a common rule representation, such mappings can be published across the Semantic Web, enabling an enterprise or community to progressively build up a rich network of mappings unifying the information models.

Information mapping and integration problems like this arise in many diverse domains including health care, travel planning, IT management and customer information management. The following scenario comes from the world of IT systems management.

Vlad has been given the job of analyzing how exposed his division's business processes are to changes in their IT maintenance contracts. He has three sources of information to combine:

* a report on application services and associated servers, databases and networks (from the IT department)
* a maintenance contracts database (from the finance department)
* a registry indicating which business processes use which IT services (from the business planning group)

Each of these sources is in a different form but can be mapped into RDF to simplify access. However, they all have different information models. The IT report is too fine-grained: it talks about routers and interface cards whereas Vlad only needs to identify servers and pick out some generic dependency relations. On the other hand, the finance database models the world in terms of physical assets such as racks, which is too coarse-grained.

First, Vlad creates simple mapping rules to create a uniform, simplified view of the data in terms of a small number of concepts -- Server, Business<tt></tt>Process and Dependency. This involves rules such as:

<pre width=130>
If x is a ComputeNode in Rack r
and Rack r is in Cage c
and mc is a MaintenanceContract for Cage c
then x is a Server with MaintenanceContract mc

If x is a ComputeNode with a NetworkInterface with Port p
and app is an Application running on Port p
then x is a Server that hosts app

If bp is a BusinessProcess that uses Application app
then bp has a Dependency on app
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Forall ?X ?MC ?R ?C(
?X[rdf:type->ex:Server ex:maintenanceContract->?MC] :- And(
?X[rdf:type->ex:ComputeNode ex:location->?R] ?R#ex:Rack
?R[ex:location->?C] ?C#ex:Cage
?C[ex:maintenanceContract->?MC] ?MC#ex:MaintenanceContract ))

Forall ?X ?Ni ?P ?App (
?X[rdf:type->ex:Server ex:hosts->?App] :- And(
?X[rdf:type->ex:ComputeNode ex:networkInterface->?Ni]
?Ni[ex:port->?P] ?P#ex:Port
?App[rdf:type->ex:Application ex:onPort->?P]))

Forall ?App ?BP (
?BP[ex:dependsOn->?App] :-
?BP[rdf:type->ex:BusinessProcess ex:processUses->?App] ))
</code>
<br />
</p>

He then creates rules that combine the data across his now simplified data sources, e.g.

<pre width=130>
If bp is a BusinessProcess that has a Dependency on Application app
and x is a Server with MaintenanceContract mc that hosts Application app
then bp has a Dependency on mc
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> Forall ?App ?BP ?App ?MC(
?BP[ex:dependsOn->?MC] :- <
?BP[rdf:type->ex:BusinessProcess ex:dependsOn->?App] ?App#ex:Application
?X[rdf:type->ex:Server ex:hosts->?App ex:maintenanceContract->?MC] ))
</code>
<br />
</p>

This gives him a uniform view that links from business processes through to the IT and finance data. Vlad publishes these rules so that other people across the company can reuse them to construct similar views.

'''Supported by RIF BLD and RID PRD'''

</div></div></div><div>

=== BPEL Orchestration of Rule-Based Web Services ===

<div><div lang="en" dir="ltr">

Rule-based Web services depend on the use of XML data for their request and response format. The involved rules must be able to access and compare XML data in their conditions and modify and generate XML data in their actions.

An existing commercial credit approval service deployed as a Web service takes an applicant credit request document as input and returns an approval or denial (with reason). It is implemented as a BPEL orchestration of two Web services -- a credit history providing service and a decision service containing a rules engine. BPEL first passes the credit request document to the decision service to determine, using rules, whether enough information (SSN, mother's maiden name, etc.) is available to request a credit history. If so, BPEL then requests a credit history from the history providing service and passes the credit history document to the decision service to be evaluated. Based on the evaluation, credit is approved or denied.

Because the rule engine is part of a Web service, existing BPEL diagramming and execution facilities can be used to integrate rules into this credit approval service. The credit evaluation model can be changed easily using GUI tools to customize rules. Use of RIF would improve the situation further. First, the credit history vendor could supply a default set of rules for evaluating its histories. Second, there would be several rule editing and customization tools from different RIF compatible vendors to tailor the rules to meet specific business objectives.

The credit evaluation rules are themselves grouped into three rulesets that are executed sequentially. Rules in the first ruleset apply thresholds to several "red flag" quantities in the credit report, such as:

* number of times a payment was 60 days late
* debt-to-income ratio
* number of foreclosures or repossessions
* number of garnishments
* number of liens
* bankruptcy

A red flag above the threshold results in denial of credit.

Rules in the second ruleset increment a credit score variable. For example:

<pre width=130>
If applicant owns residence then add 40.
If applicant rents then add 30.
If applicant has lived at current address 2 to 4 years then add 20.
If applicant's income is under 20000 then add 10.
If applicant's income is between 40000 and 50000 then add 40.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;">Document(<br />
<br />
Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)<br />
Prefix(func http://www.w3.org/2007/rif-builtin-function#)<br />
Prefix(prolog_func <nowiki>http:</nowiki>//example.org/2007/rif-prolog-builtin-function#)
Prefix(ex <nowiki>http:</nowiki>//example.org/example#)<br />
<br />
Group<br />
(<br />
ex:score(0)<br />
<br />
ex:score(?Applicant ?Score) :-<br />
ex:increment(?Applicant)<br />
ex:score(?Score)<br />
prolog_func:retract(ex:score(?Score))<br />
prolog_func:assert(ex:score(0)). <br />
<br />
ex:increment(?Applicant) :- <br />
ex:owns(?Applicant)<br />
ex:score(?Score)<br />
prolog_func:retract(ex:score(?Score))<br />
?NewScore = ?Score + 40<br />
prolog_func:assert(ex:score(?NewScore)).<br />
<br />
ex:increment(?Applicant):- <br />
ex:rents(?Applicant)<br />
ex:score(?Score)<br />
ex:retract(score(?Score))<br />
?NewScore = ?Score + 30<br />
prolog_func:assert(score(?NewScore)).<br />
<br />
ex:increment(?Applicant):-<br />
ex:lives(?Applicant ?Date),<br />
$sysTime(?CurrentDateTime)<br />
?CurrentYear = $fn:year-from-dateTime(?CurrentDateTime)<br />
?Year = $fn:year-from-dateTime(?Date)<br />
?Diff = ?CurrentYear - ?Year<br />
?Diff > 1<br />
?Diff < 5<br />
ex:score(?Score)<br />
prolog_func:retract(score(?Score))<br />
?NewScore = ?Score + 20<br />
prolog_func:assert(ex:score(?NewScore)).<br />
<br />
ex:increment(?Applicant):- <br />
ex:income(?Applicant ?Income)<br />
?Income < 20000<br />
ex:score(?Score)<br />
prolog_func:retract(score(?Score))<br />
?NewScore = ?Score + 10<br />
prolog_func:assert(ex:score(?NewScore)).<br />
<br />
ex:increment(?Applicant):-<br />
ex:income(?Applicant ?Income)<br />
?Income < 50000<br />
?Income > 40000<br />
ex:score(?Score)<br />
prolog_func:retract(ex:score(?Score))<br />
?NewScore = ?Score + 40<br />
prolog_func:assert(ex:score(?NewScore)).<br />
</code>
<br />A goal-driven solution which makes use of assert and retract (not supported by BLD) to update a global score value, which is stored in a fact.
</p>

The third and final ruleset compares the applicant's credit score and income to threshold values, and makes the final decision to approve or deny credit to the applicant.

The decision and supporting rationale is returned from the decision service as an XML document. This decision document is then used to construct the reply to the original credit approval request.

'''Supported by RIF PRD'''

This use case requires a goal-driven solution which makes use of assert and retract to update a global score value. Assert and retract are not supported by BLD; indeed, there is no such similar notion within BLD.

</div></div></div><div>

=== Publishing Rules for Interlinked Metadata ===

<div><div lang="en" dir="ltr">

The Semantic Web includes technologies (e.g., RDF) that allow metadata to be published in machine-readable form. Currently, this information is mostly enumerated as a set of facts. It is often desirable, however, to supplement such facts with rules that ''capture implicit knowledge''. To maximize the usefulness of such published rules, a standard rule format such as RIF is necessary.

One case involves extending current standards for metadata publication with rules in order to express implicit knowledge. Suppose that the International Movie Database (IMD) publishes its metadata and rules in a machine readable format at <nowiki>http://</nowiki>imd.example.org. Besides the ground facts, which can be expressed in RDF, the metadata might also have general rules like the following:

<pre width=130>
Every science fiction movie is a movie.
Every movie produced before 1930 is black and white.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD (Abridged) Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> ?Movie#ex:Movie :-<br />
?Movie#ex:ScienceFictionMovie.<br />
<br />
?Movie#ex:BlackWhiteMovie :-<br />
?Movie#ex:Movie[ex:date -> ?Date]<br />
?Date < "1930"^^xs:dateTime.<br />
</code>
<br />
</p>

Such rules allow data to be published more concisely by expressing knowledge that, without these rules, is implicit. This can greatly simplify the maintenance of data, guard against inadvertently introduced inconsistencies, and reduce storage requirements.

Published rules also allow combining data from different sources to exploit this knowledge. Consider an alternative database of movies published at <nowiki>http://</nowiki>altmd.example.org. In addition to metadata, it again publishes its own rules:

<pre width=130>
All movies listed at <nowiki>http://</nowiki>altmd.example.org but not listed at <nowiki>http://</nowiki>imd.example.org are independent movies.
All movies with budgets below 5 million USD are low-budget movies.
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD (Abridged) Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> ?Movie#ex:IndependentMovie :-<br />
listed(?Movie#ex:Movie,<<nowiki>http:</nowiki>//altmd.example.org>)<br />
not(listed(?Movie#ex:Movie,<<nowiki>http:</nowiki>//imd.example.org>)). <br />
<br />
?Movie#ex:LowBudgetMovie :-<br />
?Movie#ex:Movie [date -> ?Date, budget -> ?Budget]<br />
?Budget < 5000000^^xs:long.<br />
</code>
<br />
</p>

Publication of rules with explicit references to other rulesets allows the definition of knowledge dependent on explicitly specified remote sources. Such explicitly specified ''scope'' is important in the Web environment, since it can reduce the danger of unintended interference from rules published at other remote sources, which may be exporting their own predicates.

Another example of such explicit referencing, which also illustrates implicit person-centric metadata, involves published rules being used to specify how to use other metadata, e.g. in the form of a widespread vocabulary such as FOAF or a standard exchange format like iCalendar. For example, FOAF user Charlie might choose to complement his normal FOAF profile with his preferences about which of his phone numbers should be used depending on his iCalendar schedule:

<pre width=130>
If Charlie is currently attending a public talk according to <nowiki>http://</nowiki>charlie.example.org/calender.ical
then leave him a voicemail message

If Charlie is currently in a meeting according to <nowiki>http://</nowiki>charlie.example.org/calender.ical
and the importance is high
then call his cell number

If Charlie currently has no appointments according to <nowiki>http://</nowiki>charlie.example.org/calender.ical
then call his office number
</pre>

<p class="rif" style="display:none">
<b class="syntax-head"></b>
Representation in RIF BLD (Abridged) Presentation Syntax using relations:<br />
<br />
<code style="white-space: pre;"> contactInfo("Charlie" ?ContactInfo) :-<br />
sysTime(?Time)<br />
attending("Charlie" "talk" ?Time)<br />
contact("Charlie" "voicemail" ?ContactInfo).<br />
<br />
contactInfo("Charlie" ?ContactInfo) :-<br />
sysTime(?Time)<br />
attending("Charlie" "meeting" ?Time)<br />
contact("Charlie" "cell number" ?ContactInfo).<br />
<br />
contactInfo("Charlie", ?ContactInfo) :-<br />
sysTime(?Time),<br />
not(attending("Charlie",?Event, ?Time)),<br />
contact("Charlie", "office number", ?ContactInfo).<br />
<br />
<br />
sysTime(?Time) :-<br />
% get the actual system time e.g. via a built-in<br />
% or procedural attachment call to Java or C++.<br />
?Time = External(call(java.util.Calendar().getInstance())).<br />
<br />
<br />
attending("Charlie","talk", ?CurrentTime) :-<br />
% getEventData would implement the functionality to dynamically access and query<br />
% <nowiki>http:</nowiki>//charlie.example.org/calender.ical<br />
getEventData(<<nowiki>http:</nowiki>//charlie.example.org/calender.ical>,?EventTitle,?Type,?StartDate,?EndDate),<br />
?Type = "talk",<br />
External(op:dateTime-less-than(?CurrentTime,?EndDate),<br />
External(op:dateTime-greater-than(?CurrentTime,?StartDate).<br />
<br />
<br />
attending("Charlie","meeting", ?CurrentTime) :-<br />
getEventData(<<nowiki>http:</nowiki>//charlie.example.org/calender.ical>,?EventTitle,?Type,?StartDate,?EndDate),<br />
?Type = "meeting",<br />
External(op:dateTime-less-than(?CurrentTime,?EndDate),<br />
External(op:dateTime-greater-than(?CurrentTime,?StartDate).<br />
<br />
<br />
<br />
contact("Charlie", "voicemail", ?ContactInfo) :-<br />
% retrieve the Voice mail number, e.g. from<br />
% Charlie's vCard, <br />
% e.g. xmlns:vCard = "<nowiki>http://www.w3.org/2001/vcard-rdf/3.0#"</nowiki><br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard:FN> -> "Charlie"],<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard_TEL> -> ?Telephone],<br />
?Telephone[<rdf:type> -> <nowiki><http://www.w3.org/2001/vcard-rdf/3.0#voice></nowiki>],<br />
?Telephone[<rdf_value> -> ?ContactInfo].<br />
<br />
contact("Charlie", "cell number", ?ContactInfo) :-<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard:FN> -> "Charlie"],<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard_TEL> -> ?Telephone],<br />
?Telephone[<rdf:type> -> <nowiki><http://www.w3.org/2001/vcard-rdf/3.0#cell></nowiki>],<br />
?Telephone[<rdf_value> -> ?ContactInfo].<br />
<br />
contact("Charlie", "office number", ?ContactInfo) :-<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard:FN> -> "Charlie"],<br />
<<nowiki>http:</nowiki>//charlie.example.org/vCard>[<vCard_TEL> -> ?Telephone],<br />
?Telephone[<rdf:type> -> <nowiki><http://www.w3.org/2001/vcard-rdf/3.0#work></nowiki>],<br />
?Telephone[<rdf_value> -> ?ContactInfo]. <br />
</code>
<br />
</p>

RIF should allow extending current standards for metadata publication by enabling such implicit knowledge to be captured via rules and allowing metadata and rules distributed over different sources to be interlinked. In a manner similar to how HTML links human-readable Web pages, RIF should permit linking metadata on the Web to support new kinds of "intelligent" crawling and search.

'''Supported by RIF PRD'''

Since negation is not supported by RIF BLD it is not possible to express ''... but not listed at ...''.

</div></div></div></div><div>

== Conclusion ==

<div><div lang="en" dir="ltr">

The goal of the RIF working group is to provide representational interchange formats for processes based on the use of rules and rule-based systems. These formats act as "interlingua" to interchange rules and integrate with other languages, in particular (Semantic) Web mark-up languages.

As can be seen by studying the use-cases presented in this document, rules are used to perform a wide variety of tasks, and, therefore, rule-based systems are not monolithic. Rules have been used to perform or validate inference, perform calculations, direct the flow of information, enforce integrity constraints on databases, represent and enforce policies, control devices and processes in real-time, determine the need for human intervention, and so on.

In light of this diversity, rather than being a single all-encompassing format, RIF consists of several dialects, each dialect serving a particular set of related rule languages. The key idea is to attain the goal of interoperability (via interchange of RIF rules) ''within'' each dialect. This should allow the main benefits of RIF to be realized. For example, the invariant meaning of a set of integrity-constraint-enforcing rules would be represented within the appropriate RIF dialect and could then be translated into the native format of any of the formalisms capable of representing such rules.

RIF has been designed in such a way that it is possible to create new dialects (extensibility) according to the overall goals and the general requirements of RIF, as well as to update existing dialects (upwardly compatible). This is in keeping with the working group charter's call for an extensible format.

</div></div></div>

</div><div>

== References ==

<div><div lang="en" dir="ltr">

<span id="ref-Horty-deontic-logic" class="anchor"></span>

; [Horty2001]
: ''Agency and Deontic Logic'', John F. Horty, Oxford University Press, 2001.

<span id="event-calculus" class="anchor"></span>
; [KS86]
: Kowalski, R.A. and M.J. Sergot, ''A logic-based calculus of events.'' New Generation Computing, 1986. 4: p. 67-95.

<span id="moore" class="anchor"></span>
; [Moore80]
: Moore, R.C., ''Reasoning about Knowledge and Action,'' SRI TR-191, 1980.

</div></div></div>

<div>

== Appendix: Change Log (Informative) ==

<div><div lang="en" dir="ltr">

This appendix summarizes the main changes to this document since its publication as a Working Draft.

Changes since the [http://www.w3.org/TR/rif-ucr/ draft of December 18th, 2008]:
* [[#Structure_of_RIF|section describing the structure of RIF]] updated with the new RIF documents;
* all code examples are removed from the document
* each use cases has a new paragraph at the end which discusses the support of the use case by the current RIF dialects Core, BLD and PRD
* added an informative change log section
* flattened the list of requirements removing the distinction between general and basic requirements

</div></div></div></div>

</div>