Warning:
This wiki has been archived and is now read-only.

Core-alternative

From RIF

Jump to: navigation, search

Document title:: RIF Core (Second Edition)

Editors: Harold Boley, National Research Council Canada; Gary Hallmark, Oracle Corporation; Michael Kifer, State University of New York at Stony Brook, USA; Adrian Paschke, Free University Berlin; Axel Polleres, DERI; Dave Reynolds, Hewlett-Packard Laboratories, Bristol UK

Abstract: This document, developed by the Rule Interchange Format (RIF) Working Group, specifies RIF-Core, a common subset of RIF-BLD and RIF-PRD based on RIF-DTB 1.0. The RIF-Core presentation syntax and semantics are specified as restrictions on RIF-BLD. The XML serialization syntax of RIF-Core is specified via a mapping from the presentation syntax. A normative XML schema is also provided.
Status of this Document: @@initial draft.

1 Overview
2 RIF-Core Presentation Syntax
3 RIF-Core Semantics
4 XML Serialization Syntax for RIF-Core
5 Conformance and Safety
- 5.1 Safeness
- 5.2 Conformance Clauses
6 RIF-Core as a Specialization of RIF-PRD
- 6.1 Intersection of RIF-PRD and RIF-BLD
7 Acknowledgements
8 References
- 8.1 Normative References
- 8.2 Informational References
9 Appendix: XML Schema for RIF-Core
- 9.1 Condition Language
- 9.2 Rule Language

1 Overview

This specification develops RIF-Core (the Core of the Rule Interchange Format). From a theoretical perspective, RIF-Core corresponds to the language of definite Horn rules without function symbols ('Datalog') and a standard first-order semantics. RIF-Core thus is a subset of RIF-BLD [RIF-BLD]. At the same time, RIF-Core is a language of production rules permitting only assert actions. RIF-Core thus also is a subset of RIF-PRD [RIF-PRD]. Moreover, RIF-Core is based on the built-ins of RIF-DTB 1.0 [RIF-DTB]. The common subset of RIF-BLD and RIF-PRD is specified based on RIF-DTB 1.0.

Syntactically, RIF-Core has a number of Datalog extensions to support features such as objects and frames as in F-logic [KLW95], internationalized resource identifiers (or IRIs, defined by [RFC-3987]) as identifiers for concepts, and XML Schema datatypes [XML-SCHEMA2]. In addition, RIF RDF and OWL Compatibility [RIF-RDF+OWL] defines the syntax and semantics of integrated RIF-Core/RDF and RIF-Core/OWL languages. These features make RIF-Core a Web-aware language. However, it should be kept in mind that RIF is designed to enable interoperability among rule languages in general, and its uses are not limited to the Web.

RIF-Core is defined as a specialization of RIF-BLD (hence of [RIF-FLD] which is part of the RIF extensibility framework). It is a syntactic subset of RIF-BLD, so that a well-formed RIF-Core formula (including documents and condition formula) is also a well-formed RIF-BLD formula. The semantics of RIF-Core is defined to be identical to that of RIF-BLD.

RIF-Core is also a syntactic subset of RIF-PRD. It is intended that a RIF-PRD consumer can treat a RIF-Core ruleset as if it were a RIF-PRD rule set and it would conform to the normative RIF-Core first order semantics. However, due to the presence of builtin functions and predicates there are RIF-Core rulesets which are unsafe and do not reach a stable fixed-point under RIF-PRD semantics. We define the conformance to RIF-Core so as to only require conformance over a safe subset of rules, in this way we permit RIF-PRD processors to be minimally conformant while allowing RIF-Core documents to contain unsafe rules. Producers of RIF-Core who require maximum interchange are advised to restrict themselves to safe rules. These notions of safeness and strict conformance are defined formally in section 5 Conformance and Safety.

To give a preview, here is a simple complete RIF-Core example deriving a ternary relation from its inverse.

Example 1 (An introductory RIF-Core example).

A rule can be written in English to derive the buy relationships (rather than store them) from the sell relationships that are stored as facts (e.g., as exemplified by the English statement below):

A buyer buys an item from a seller if the seller sells the item to the buyer.
John sells LeRif to Mary.

The fact Mary buys LeRif from John can be logically derived by a modus ponens argument. Assuming Web IRIs for the predicates buy and sell, as well as for the individuals John, Mary, and LeRif, the above English text can be represented in RIF-Core Presentation Syntax as follows.

Document(
  Prefix(cpt http://example.com/concepts#)
  Prefix(ppl http://example.com/people#)
  Prefix(bks http://example.com/books#)

  Group
  (
    Forall ?Buyer ?Item ?Seller (
        cpt:buy(?Buyer ?Item ?Seller) :- cpt:sell(?Seller ?Item ?Buyer)
    )
 
    cpt:sell(ppl:John bks:LeRif ppl:Mary)
  )
)

For the interchange of such rule (and fact) documents, an equivalent RIF-Core XML Syntax is given in this specification. To formalize their meaning, a RIF-Core Semantics is specified.

2 RIF-Core Presentation Syntax

RIF-BLD [RIF-BLD] specifies a presentation syntax and an XML syntax. The presentation syntax is normative, but is not intended to be a concrete syntax. Since RIF is an interchange format, it uses XML as its concrete syntax.

RIF-Core is a syntactic subset of RIF-BLD and in this section we define a corresponding presentation syntax for RIF-Core, we do this as a restriction on the RIF-BLD syntax and so this specification depends upon that of RIF-BLD.

2.1 Alphabet of RIF-Core

The alphabet of the presentation language of RIF-Core is the alphabet of the RIF-BLD presentation language with the exclusion of the symbol ## and the set of symbols ArgNames.

That is it consists of:

a countably infinite set of constant symbols Const
a countably infinite set of variable symbols Var (disjoint from Const)
connective symbols And, Or, and :-
quantifiers Exists and Forall
the symbols =, #, ->, External, Import, Prefix, and Base
the symbols Group and Document
the auxiliary symbols (, ), [, ], <, >, and ^^

Where the sets Const and Var are disjoint from each other and from all other symbols listed above.

2.2 Terms of RIF-Core

The Terms of RIF-Core are the terms of RIF-BLD with the exclusion of terms with named arguments and Subclass terms.

That is RIF-Core terms are one of:

Simple terms: constants and variables.
Positional terms: t(t₁ ... t_n)
Equality terms: t = s
Class membership terms - t#s
Frame terms: t[p₁->v₁ ... p_n->v_n], or
Externally defined terms: External(pt) where pt is a positional term.

Editor's Note: This presumes that the At Risk #1 feature External frames is dropped from RIF-BLD, if that is not the case the above will need updating.

A base term is a simple, positional or externally defined term, each of the t, p, v and s above are base terms.

2.3 Formulas of RIF-Core

The Formulas of the RIF-Core are the formulas of RIF-BLD with the following modifications.

Atomic formula: any RIF-Core term, including base terms, equality terms, class membership terms and frame terms.
Restricted atomic formula: a RIF-Core simple, positional or frame term (i.e. excluding equality, class membership and externally defined terms).
Conditional formula: either an atomic formula, a conjunction, disjunction or existential over RIF-Core conditional formula.
Rule implication: φ :- ψ is a formula, called rule implication, if:
- φ is an restricted atomic formula,
- ψ is a condition formula, and
- none of the atomic formulas in φ is an externally defined term (i.e., a term of the form External(...)). (Note: external terms can occur in the arguments of atomic formulas in the rule conclusion.)
Universal rule: as RIF-BLD restricted to RIF-Core rule implications. If φ is a RIF-Core rule implication and ?V₁, ..., ?V_n, n>0, are variables then Forall ?V₁ ... ?V_n(φ) is a RIF-Core universal rule formula also referred to as a RIF-Core Rule. It is required that all the free variables in φ occur among the variables ?V₁ ... ?V_n in the quantification part.
Universal fact: as RIF-BLD restricted to RIF-Core restricted atomic formula. If φ is a RIF-Core atomic formula then Forall ?V₁ ... ?V_n(φ) is a formula, called a universal fact, provided that all the free variables in φ occur among the variables ?V₁ ... ?V_n.
Group: If φ₁, ..., φ_n are RIF-Core rules, universal facts, variable-free rule implications, variable-free atomic formulas, or group formulas then Group(φ₁ ... φ_n) is a RIF-Core group formula.
Document: An expression of the form Document(directive₁ ... directive_n Γ) is a RIF-Core document formula, if Γ is an optional RIF-Core group formula and directive₁, ..., directive_n is an optional sequence of directives as defined in RIF-BLD.

2.4 Annotations and documents

RIF-Core allows every term and formula to be optionally annotated in the same way as RIF-BLD. Every term and formula (including terms and formulas that occur inside other terms and formulas) may be optionally preceded by an annotation of the form (* id φ *), where id is a rif:iri constant and φ is a frame formula or a conjunction of frame formulas.

RIF-Core document formulas with and without annotations will be referred to as RIF-Core documents.

2.5 Well-formed formulas

Definition (Well-formed formula). A RIF-Core formula φ is well-formed iff it is a well-formed RIF-BLD formula. That is iff:

every constant symbol (whether coming from the symbol space rif:local or not) mentioned in φ occurs in exactly one context.
if φ is a RIF-Core document formula and Δ'₁, ..., Δ'_k are all of its imported RIF-Core documents, then every non-rif:local constant symbol mentioned in φ or any of the imported Δ'_is must occur in exactly one context (in all of the Δ'_is).
Whenever a formula contains a term or a subformula of the form External(t), t must be an instance of the coherent set of external schemas (Section Schemas for Externally Defined Terms of [RIF-DTB]) associated with the language of RIF-Core.
If t is an instance of the coherent set of external schemas associated with the language then t can occur only as External(t), i.e., as an external term or atomic formula.

Where the definition of context is given in [RIF-BLD].

Definition (Language of RIF-Core). The language of RIF-Core consists of the set of all well-formed RIF-Core formulas and is determined by:

the alphabet of the language and
a set of coherent external schemas, which determine the available built-ins and other externally defined predicates and functions.

2.6 EBNF Grammar for the Presentation Syntax of RIF-Core (Informative)

Until now, we have used mathematical English to specify the syntax of RIF-Core. Tool developers, however, may prefer EBNF notation, which provides a more succinct overview of the syntax. However, note that EBNF is unable to express all of the above well-formedness conditions, in particular the requirement that each symbol appear in only one context. For this reason this section is not Normative.

The EBNF for the RIF-BLD presentation syntax is given as follows, showing the entire (top-down) context of its three parts for rules, conditions, and annotations.

Rule Language:

  Document       ::= IRIMETA? 'Document' '(' Base? Prefix* Import* Group? ')'
  Base           ::= 'Base' '(' IRI ')'
  Prefix         ::= 'Prefix' '(' Name IRI ')'
  Import         ::= IRIMETA? 'Import' '(' IRICONST PROFILE? ')'
  Group          ::= IRIMETA? 'Group' '(' (RULE | Group)* ')'
  RULE           ::= (IRIMETA? 'Forall' Var+ '(' CLAUSE ')') | CLAUSE
  CLAUSE         ::= Implies | ATOMIC
  Implies        ::= IRIMETA? ATOMIC  ':-' FORMULA
  PROFILE        ::= TERM

Condition Language:

  FORMULA        ::= IRIMETA? 'And' '(' FORMULA* ')' |
                     IRIMETA? 'Or' '(' FORMULA* ')' |
                     IRIMETA? 'Exists' Var+ '(' FORMULA ')' |
                     ATOMIC |
                     IRIMETA? Equal |
                     IRIMETA? Member |
                     IRIMETA? 'External' '(' Atom | Frame ')'
  ATOMIC         ::= IRIMETA? (Atom | Frame)
  Atom           ::= UNITERM
  UNITERM        ::= Const '(' (TERM* ')'
  Equal          ::= TERM '=' TERM
  Member         ::= TERM '#' TERM
  Frame          ::= TERM '[' (TERM '->' TERM)* ']'
  TERM           ::= IRIMETA? (Const | Var )
  Const          ::= '"' UNICODESTRING '"^^' SYMSPACE | CONSTSHORT
  Name           ::= UNICODESTRING
  Var            ::= '?' UNICODESTRING
  SYMSPACE       ::= ANGLEBRACKIRI | CURIE

Annotations:

  IRIMETA        ::= '(*' IRICONST? (Frame | 'And' '(' Frame* ')')? '*)'

The following subsections explain and exemplify these parts, starting with the basic language of positive conditions.

2.6.1 EBNF for the Condition Language

The Condition Language represents formulas that can be used in the premises of RIF-Core rules (also called rule bodies). The EBNF grammar for a superset of the RIF-Core condition language is as follows.

  FORMULA        ::= IRIMETA? 'And' '(' FORMULA* ')' |
                     IRIMETA? 'Or' '(' FORMULA* ')' |
                     IRIMETA? 'Exists' Var+ '(' FORMULA ')' |
                     ATOMIC |
                     IRIMETA? Equal |
                     IRIMETA? Member |
                     IRIMETA? 'External' '(' Atom | Frame ')'
  ATOMIC         ::= IRIMETA? (Atom | Frame)
  Atom           ::= UNITERM
  UNITERM        ::= Const '(' (TERM* ')'
  Equal          ::= TERM '=' TERM
  Member         ::= TERM '#' TERM
  Frame          ::= TERM '[' (TERM '->' TERM)* ']'
  TERM           ::= IRIMETA? (Const | Var )
  Const          ::= '"' UNICODESTRING '"^^' SYMSPACE | CONSTSHORT
  Name           ::= UNICODESTRING
  Var            ::= '?' UNICODESTRING
  SYMSPACE       ::= ANGLEBRACKIRI | CURIE

The production rule for the non-terminal FORMULA represents RIF condition formulas (defined earlier). The connectives And and Or define conjunctions and disjunctions of conditions, respectively. ATOMIC terms represent those terms that can be used in the conclusion part of a rule, whereas FORMULA also include Equal, Member and External terms. A TERM can be a constant or variable.

The RIF-Core presentation syntax does not commit to any particular vocabulary and permits arbitrary Unicode strings in constant symbols and variables. Constant symbols can have this form: "UNICODESTRING"^^SYMSPACE, where SYMSPACE is a ANGLEBRACKIRI or CURIE that represents the identifier of the symbol space of the constant, and UNICODESTRING is a Unicode string from the lexical space of that symbol space. ANGLEBRACKIRI and CURIE are defined in Section Shortcuts for Constants in RIF's Presentation Syntax of [RIF-DTB]. Constant symbols can also have several shortcut forms, which are represented by the non-terminal CONSTSHORT. These shortcuts are also defined in the same section of [RIF-DTB]. One of them is the CURIE shortcut, which is extensively used in the examples in this document. Names are Unicode character sequences. Variables are composed of UNICODESTRING symbols prefixed with a ?-sign.

A frame term is a term composed of an object Id and a collection of attribute-value pairs. An External(Atom) is a call to an externally defined predicate; External(Frame) is a call to an externally defined frame.

As noted in Section 2.4, RIF-Core formulas and terms can be prefixed with optional annotations, IRIMETA, for identification and metadata. IRIMETA is represented using (*...*)-brackets that contain an optional IRI constant, IRICONST, as identifier followed by an optional Frame or conjunction of Frames as metadata. An IRICONST is the special case of a Const with the symbol space rif:iri, again permitting the shortcut forms defined in [RIF-DTB]. One such specialization is '"' IRI '"^^' 'rif:iri' from the Const production, where IRI is a sequence of Unicode characters that forms an internationalized resource identifier as defined by [RFC-3987].

Example 2 (RIF-Core conditions).

This example shows conditions that are composed of atoms, expressions and frames. In frame formulas variables are shown in the positions of object Ids, object properties, and property values. For brevity, we use the CURIE shortcut notation prefix:suffix for constant symbols, which is understood as a macro that expands into an IRI obtained by concatenation of the prefix definition and suffix. Thus, if bks is a prefix that expands into http://example.com/books# then bks:LeRif is an abbreviation for "http://example.com/books#LeRif"^^rif:iri. This and other shortcuts are defined in [RIF-DTB]. Assume that the following prefix directives appear in the preamble to the document:

Prefix(bks  http://example.com/books#)
Prefix(auth http://example.com/authors#)
Prefix(cpt  http://example.com/concepts#)

Positional terms:
  
  cpt:book(auth:rifwg bks:LeRif)
  Exists ?X (cpt:book(?X bks:LeRif))

Frames:

  bks:wd1[cpt:author->auth:rifwg cpt:title->bks:LeRif]
  Exists ?X (bks:wd2[cpt:author->?X  cpt:title->bks:LeRif])
  Exists ?X (And (bks:wd2#cpt:book  bks:wd2[cpt:author->?X  cpt:title->bks:LeRif]))
  Exists ?I ?X (?I[cpt:author->?X  cpt:title->bks:LeRif])
  Exists ?I ?X (And (?I#cpt:book ?I[cpt:author->?X  cpt:title->bks:LeRif]))
  Exists ?S (bks:wd2[cpt:author->auth:rifwg ?S->bks:LeRif])
  Exists ?X ?S (bks:wd2[cpt:author->?X ?S->bks:LeRif])
  Exists ?I ?X ?S (And (?I#cpt:book  ?I[author->?X ?S->bks:LeRif]))

2.6.2 EBNF for the Rule Language

The presentation syntax for RIF-Core rules extends the syntax in Section EBNF for RIF-Core Condition Language with the following productions.

 Document  ::= IRIMETA? 'Document' '(' Base? Prefix* Import* Group? ')'
 Base      ::= 'Base' '(' IRI ')'
 Prefix    ::= 'Prefix' '(' Name IRI ')'
 Import    ::= IRIMETA? 'Import' '(' IRICONST PROFILE? ')'
 Group     ::= IRIMETA? 'Group' '(' (RULE | Group)* ')'
 RULE      ::= (IRIMETA? 'Forall' Var+ '(' CLAUSE ')') | CLAUSE
 CLAUSE    ::= Implies | ATOMIC
 Implies        ::= IRIMETA? ATOMIC  ':-' FORMULA
 PROFILE   ::= TERM

Recall that an IRI has the form of an internationalized resource identifier as defined by [RFC-3987].

A RIF-Core Document consists of an optional Base, followed by any number of Prefixes, followed by any number of Imports, followed by an optional Group. Base and Prefix serve as shortcut mechanisms for IRIs. An Import indicates the location of a document to be imported and an optional profile. A RIF-Core Group is a collection of any number of RULE elements along with any number of nested Groups.

Rules are generated using CLAUSE elements. The RULE production has two alternatives:

In the first, a CLAUSE is in the scope of the Forall quantifier. In that case, all variables mentioned in CLAUSE are required to also appear among the variables in the Var+ sequence.
In the second alternative, CLAUSE appears on its own. In that case, CLAUSE cannot have variables.

Frame, Var, ATOMIC, and FORMULA were defined as part of the syntax for positive conditions in Section EBNF for RIF-Core Condition Language. In the CLAUSE production, an ATOMIC is what is usually called a fact. An Implies rule can have an ATOMIC elements as its conclusion; it has a FORMULA as its premise. Note that, by a definition in Section Formulas, formulas that query externally defined atoms (i.e., formulas of the form External(Atom(...))) are not allowed in the conclusion part of a rule (ATOMIC does not expand to External).

Example 3 (RIF-Core rules).

This example shows a business rule borrowed from the document RIF Use Cases and Requirements:

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.

As before, for better readability we use the compact URI notation defined in [RIF-DTB], Section Constants and Symbol Spaces. Again, prefix directives are assumed in the preamble to the document. Then, two versions of the main part of the document are given.

Prefix(ppl  http://example.com/people#)
Prefix(cpt  http://example.com/concepts#)
Prefix(func http://www.w3.org/2007/rif-builtin-function#)
Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)

a. Universal form:

   Forall ?item ?deliverydate ?scheduledate ?diffduration ?diffdays (
        cpt:reject(ppl:John ?item) :-
            And(cpt:perishable(?item)
                cpt:delivered(?item ?deliverydate ppl:John)
                cpt:scheduled(?item ?scheduledate)
                ?diffduration = External(func:subtract-dateTimes(?deliverydate ?scheduledate))
                ?diffdays = External(func:days-from-duration(?diffduration))
                External(pred:numeric-greater-than(?diffdays 10)))
   )

b. Universal-existential form:

   Forall ?item (
        cpt:reject(ppl:John ?item ) :-
            Exists ?deliverydate ?scheduledate ?diffduration ?diffdays (
                 And(cpt:perishable(?item)
                     cpt:delivered(?item ?deliverydate ppl:John)
                     cpt:scheduled(?item ?scheduledate)
                     ?diffduration = External(func:subtract-dateTimes(?deliverydate ?scheduledate))
                     ?diffdays = External(func:days-from-duration(?diffduration))
                     External(pred:numeric-greater-than(?diffdays 10)))
            )
   )

Example 4 (A RIF-Core document containing an annotated group).

This example shows a complete document containing a group formula that consists of two RIF-Core rules. The first of these rules is copied from Example 3a. The group is annotated with an IRI identifier and frame-represented Dublin Core metadata.

Document(
  Prefix(ppl  http://example.com/people#)
  Prefix(cpt  http://example.com/concepts#)
  Prefix(dc   http://purl.org/dc/terms/)
  Prefix(func http://www.w3.org/2007/rif-builtin-function#)
  Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
  Prefix(xs   http://www.w3.org/2001/XMLSchema#)
  
  (* "http://sample.org"^^rif:iri pd[dc:publisher -> http://www.w3.org/
                                     dc:date -> "2008-04-04"^^xs:date] *)
  Group
  (
    Forall ?item ?deliverydate ?scheduledate ?diffduration ?diffdays (
        cpt:reject(ppl:John ?item) :-
            And(cpt:perishable(?item)
                cpt:delivered(?item ?deliverydate ppl:John)
                cpt:scheduled(?item ?scheduledate)
                ?diffduration = External(func:subtract-dateTimes(?deliverydate ?scheduledate))
                ?diffdays = External(func:days-from-duration(?diffduration))
                External(pred:numeric-greater-than(?diffdays 10)))
    )
 
    Forall ?item (
        cpt:reject(ppl:Fred ?item) :- cpt:unsolicited(?item)
    )
  )
)

3 RIF-Core Semantics

RIF-Core is a syntactic subset of RIF-BLD and the semantics of RIF-Core is identical that of RIF-BLD.

We use the same semantic structures I as defined in RIF-BLD [RIF-BLD] section 3.2 and the same truth value mapping TVal_I as defined in [RIF-BLD] section 3.4 to give the interpretation of RIF-Core non-Document formulas.

Then we define the interpretation of RIF-Core Documents analogously to RIF-BLD documents:

Let Δ be a RIF-Core document formula and let Δ₁, ..., Δ_k be all the RIF-Core document formulas that are imported (directly or indirectly, according to Definition Imported document in [RIF-BLD] section 2.5) into Δ. Let Γ, Γ₁, ..., Γ_k denote the respective RIF-Core group formulas associated with these documents. Let I = {I^Δ, I^Δ₁, ..., I^Δ_k, ...} be a semantic multi-structure that contains semantic structures adorned with at least the documents Δ, Δ₁, ..., Δ_k. Then we define:

TVal_I(Δ) = t if and only if TVal_I^Δ(Γ) = TVal_I^Δ₁(Γ₁) = ... = TVal_{I^Δ_k}(Γ_k) = t. ☐

We then define the same notion of logical entailment for RIF-Core as for RIF-BLD:

Definition (Models). A multi-structure I is a model of a formula, φ, written as I |= φ, iff TVal_I(φ) = t. Here φ can be a RIF-Core document or a non-document formula. ☐

Definition (Logical entailment). Let φ and ψ be RIF-Core (document or non-document) formulas. We say that φ entails ψ, written as φ |= ψ, if and only if for every multi-structure, I, for which both TVal_I(φ) and TVal_I(ψ) are defined, I |= φ implies I |= ψ. ☐

4 XML Serialization Syntax for RIF-Core

The RIF-Core XML serialization defines

a normative mapping from the RIF-Core presentation syntax to XML (Section Mapping from the Presentation Syntax to the XML Syntax), and
a normative XML Schema for the XML syntax (Appendix XML Schema for Core).

Recall that the syntax of RIF-Core is not context-free and thus cannot be fully captured by EBNF or XML Schema. Still, validity with respect to XML Schema can be a useful test. To reflect this state of affairs, we define two notions of syntactic correctness. The weaker notion checks correctness only with respect to XML Schema, while the stricter notion represents "true" syntactic correctness.

Definition (Valid Core document in XML syntax). A valid Core document in the XML syntax is an XML document that is valid with respect to the XML schema in Appendix XML Schema for Core. ☐

Definition (Conformant Core document in XML syntax). A conformant Core document in the XML syntax is a valid Core document in the XML syntax that is the image of a well-formed RIF-Core document in the presentation syntax (see Definition Well-formed formula in Section Formulas) under the presentation-to-XML syntax mapping χ_core defined in Section Mapping from the Presentation Syntax to the XML Syntax. ☐

The XML serialization for RIF-Core is alternating or fully striped [ANF01]. A fully striped serialization views XML documents as objects and divides all XML tags into class descriptors, called type tags, and property descriptors, called role tags [TRT03]. We follow the tradition of using capitalized names for type tags and lowercase names for role tags.

The all-uppercase classes in the presentation syntax, such as FORMULA, become XML Schema groups in Appendix XML Schema for Core. They act like macros and are not visible in instance markup. The other classes as well as non-terminals and symbols (such as Exists or =) become XML elements with optional attributes, as shown below.

RIF-Core uses [XML1.0] for its XML syntax.

4.1 XML for the Condition Language

XML serialization of RIF-Core in Section EBNF for RIF-Core Condition Language uses the following elements.

- And       (conjunction)
- Or        (disjunction)
- Exists    (quantified formula for 'Exists', containing declare and formula roles)
- declare   (declare role, containing a Var)
- formula   (formula role, containing a FORMULA)
- Atom      (atom formula, positional or with named arguments)
- External  (external call, containing a content role)
- content   (content role, containing an Atom)
- Member    (member formula)
- Frame     (Frame formula)
- object    (Member/Frame role, containing a TERM or an object description)
- op        (Atom role for predicates/functions as operations)
- args      (Atom positional arguments role, with fixed 'ordered' attribute, containing n TERMs)
- instance  (Member instance role)
- class     (Member class role)
- sub       (Subclass sub-class role)
- slot      (Atom or Frame slot role, with fixed 'ordered' attribute, containing a Name or TERM followed by a TERM)
- Const     (individual, function, or predicate symbol, with optional 'type' attribute)
- Var       (logic variable)
   
- id        (identifier role, containing IRICONST)
- meta      (meta role, containing metadata as a Frame or Frame conjunction)

The id and meta elements, which are expansions of the IRIMETA element, can occur optionally as the initial children of any Class element.

For the XML Schema definition of the RIF-Core condition language see Appendix XML Schema for Core.

The XML syntax for symbol spaces uses the type attribute associated with the XML element Const. For instance, a literal in the xs:dateTime datatype is represented as <Const type="&xs;dateTime">2007-11-23T03:55:44-02:30</Const>. RIF-Core also uses the ordered attribute to indicate that the children of args and slot elements are ordered.

Example 5 (A RIF condition and its XML serialization).

This example illustrates XML serialization for RIF conditions. As before, the compact URI notation is used for better readability. Assume that the following prefix directives are found in the preamble to the document:

Prefix(bks    http://example.com/books#)
Prefix(cpt    http://example.com/concepts#)
Prefix(rif    http://www.w3.org/2007/rif#)
Prefix(xs     http://www.w3.org/2001/XMLSchema#)

RIF condition

   And (Exists ?Buyer cpt:purchaseBook(?Buyer, ?Seller, bks:LeRif, ?Author) ?Seller = ?Author

    <And>
     <formula>
       <Exists>
         <declare><Var>Buyer</Var></declare>
         <formula>
           <Atom>
             <op><Const type="&rif;iri">&cpt;purchaseBook</Const></op>
             <args ordered="yes">
               <Var>Buyer</Var>
               <Var>Seller</Var>
               <Const type="&rif;iri">&bks;LeRif</Const>
               <Var>Author</Var>
             </args>
           </Atom>
         </formula>
       </Exists>
     </formula>
     <formula>
       <Equal>
         <left><Var>Seller</Var></left>
         <right><Var>Author</Var></right>
       </Equal>
     </formula>
   </And>

4.2 XML for the Rule Language

We now extend the set of RIF-Core serialization elements from Section XML for RIF-Core Condition Language by including rules, along with their enclosing groups and documents, as described in Section EBNF for RIF-Core Rule Language. The extended set includes the tags listed below. While there is a RIF-Core element tag for the Import directive, there are none for the Prefix and Base directives: they are handled as discussed in Section Mapping of the RIF-Core Rule Language.

- Document  (document, containing optional directive and payload roles)
- directive (directive role, containing Import)
- payload   (payload role, containing Group)
- Import    (importation, containing location and optional profile)
- location  (location role, containing IRICONST)
- profile   (profile role, containing PROFILE)
- Group     (nested collection of sentences)
- sentence  (sentence role, containing RULE or Group)
- Forall    (quantified formula for 'Forall', containing declare and formula roles)
- Implies   (implication, containing if and then roles)
- if        (antecedent role, containing FORMULA)
- then      (consequent role, containing ATOMIC or conjunction of ATOMICs)

The XML Schema Definition of RIF-Core is given in Appendix XML Schema for Core.

Example 7 (Serializing a RIF-Core document containing an annotated group).

This example shows a serialization for the document from Example 4. For convenience, the document is reproduced at the top and then is followed by its serialization.

Presentation syntax:

Document(
  Prefix(ppl  http://example.com/people#)
  Prefix(cpt  http://example.com/concepts#)
  Prefix(dc   http://purl.org/dc/terms/)
  Prefix(func http://www.w3.org/2007/rif-builtin-function#)
  Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
  Prefix(xs   http://www.w3.org/2001/XMLSchema#)
  
  (* "http://sample.org"^^rif:iri pd[dc:publisher -> http://www.w3.org/
                                     dc:date -> "2008-04-04"^^xs:date] *)
  Group
  (
    Forall ?item ?deliverydate ?scheduledate ?diffduration ?diffdays (
        cpt:reject(ppl:John ?item) :-
            And(cpt:perishable(?item)
                cpt:delivered(?item ?deliverydate ppl:John)
                cpt:scheduled(?item ?scheduledate)
                ?diffduration = External(func:subtract-dateTimes(?deliverydate ?scheduledate))
                ?diffdays = External(func:days-from-duration(?diffduration))
                External(pred:numeric-greater-than(?diffdays 10)))
    )
 
    Forall ?item (
        cpt:reject(ppl:Fred ?item) :- cpt:unsolicited(?item)
    )
  )
)

XML syntax: 

<!DOCTYPE Document [
  <!ENTITY ppl  "http://example.com/people#">
  <!ENTITY cpt  "http://example.com/concepts#">
  <!ENTITY dc   "http://purl.org/dc/terms/">
  <!ENTITY rif  "http://www.w3.org/2007/rif#">
  <!ENTITY func "http://www.w3.org/2007/rif-builtin-function#">
  <!ENTITY pred "http://www.w3.org/2007/rif-builtin-predicate#">
  <!ENTITY xs   "http://www.w3.org/2001/XMLSchema#">
]>

<Document 
    xmlns="http://www.w3.org/2007/rif#"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xs="http://www.w3.org/2001/XMLSchema#">
  <payload>
   <Group>
    <id>
      <Const type="&rif;iri">http://sample.org</Const>
    </id>
    <meta>
      <Frame>
        <object>
          <Const type="&rif;local">pd</Const>
        </object>
        <slot ordered="yes">
          <Const type="&rif;iri">&dc;publisher</Const>
          <Const type="&rif;iri">http://www.w3.org/</Const>
        </slot>
        <slot ordered="yes">
          <Const type="&rif;iri">&dc;date</Const>
          <Const type="&xs;date">2008-04-04</Const>
        </slot>
      </Frame>
    </meta>
    <sentence>
     <Forall>
       <declare><Var>item</Var></declare>
       <declare><Var>deliverydate</Var></declare>
       <declare><Var>scheduledate</Var></declare>
       <declare><Var>diffduration</Var></declare>
       <declare><Var>diffdays</Var></declare>
       <formula>
         <Implies>
           <if>
             <And>
               <formula>
                 <Atom>
                   <op><Const type="&rif;iri">&cpt;perishable</Const></op>
                   <args ordered="yes"><Var>item</Var></args>
                 </Atom>
               </formula>
               <formula>
                 <Atom>
                   <op><Const type="&rif;iri">&cpt;delivered</Const></op>
                   <args ordered="yes">
                     <Var>item</Var>
                     <Var>deliverydate</Var>
                     <Const type="&rif;iri">&ppl;John</Const>
                   </args>
                 </Atom>
               </formula>
               <formula>
                 <Atom>
                   <op><Const type="&rif;iri">&cpt;scheduled</Const></op>
                   <args ordered="yes">
                     <Var>item</Var>
                     <Var>scheduledate</Var>
                   </args>
                 </Atom>
               </formula>
               <formula>
                 <Equal>
                   <left><Var>diffduration</Var></left>
                   <right>
                     <External>
                       <content>
                         <Expr>
                           <op><Const type="&rif;iri">&func;subtract-dateTimes</Const></op>
                           <args ordered="yes">
                             <Var>deliverydate</Var>
                             <Var>scheduledate</Var>
                           </args>
                         </Expr>
                       </content>
                     </External>
                   </right>
                 </Equal>
               </formula>
               <formula>
                 <Equal>
                   <left><Var>diffdays</Var></left>
                   <right>
                     <External>
                       <content>
                         <Expr>
                           <op><Const type="&rif;iri">&func;days-from-duration</Const></op>
                           <args ordered="yes">
                             <Var>diffduration</Var>
                           </args>
                         </Expr>
                       </content>
                     </External>
                   </right>
                 </Equal>
               </formula>
               <formula>
                 <External>
                   <content>
                     <Atom>
                       <op><Const type="&rif;iri">&pred;numeric-greater-than</Const></op>
                       <args ordered="yes">
                         <Var>diffdays</Var>
                         <Const type="&xs;integer">10</Const>
                       </args>
                     </Atom>
                   </content>
                 </External>
               </formula>
             </And>
           </if>
           <then>
             <Atom>
               <op><Const type="&rif;iri">&cpt;reject</Const></op>
               <args ordered="yes">
                 <Const type="&rif;iri">&ppl;John</Const>
                 <Var>item</Var>
               </args>
             </Atom>
           </then>
         </Implies>
       </formula>
     </Forall>
    </sentence>
    <sentence>
     <Forall>
       <declare><Var>item</Var></declare>
       <formula>
         <Implies>
           <if>
             <Atom>
               <op><Const type="&rif;iri">&cpt;unsolicited</Const></op>
               <args ordered="yes"><Var>item</Var></args>
             </Atom>
           </if>
           <then>
             <Atom>
               <op><Const type="&rif;iri">&cpt;reject</Const></op>
               <args ordered="yes">
                 <Const type="&rif;iri">&ppl;Fred</Const>
                 <Var>item</Var>
               </args>
             </Atom>
           </then>
         </Implies>
       </formula>
     </Forall>
    </sentence>
   </Group>
  </payload>
 </Document>

4.3 Mapping from the Presentation Syntax to the XML Syntax

This section defines a normative mapping, χ_core, from the presentation syntax to the XML syntax of RIF-Core. The mapping is given via tables where each row specifies the mapping of a particular syntactic pattern in the presentation syntax. These patterns appear in the first column of the tables and the bold-italic symbols represent metavariables. The second column represents the corresponding XML patterns, which may contain applications of the mapping χ_core to these metavariables. When an expression χ_core(metavar) occurs in an XML pattern in the right column of a translation table, it should be understood as a recursive application of χ_core to the presentation syntax represented by the metavariable. The XML syntax result of such an application is substituted for the expression χ_core(metavar). A sequence of terms containing metavariables with subscripts is indicated by an ellipsis. A metavariable or a well-formed XML subelement is marked as optional by appending a bold-italic question mark, ?, on its right.

4.3.1 Mapping of the Condition Language

The χ_core mapping from the presentation syntax to the XML syntax of the RIF-Core Condition Language is specified by the table below. Each row indicates a translation χ_core(Presentation) = XML. Since the presentation syntax of RIF-Core is context sensitive, the mapping must differentiate between the terms that occur in the position of the individuals and the terms that occur as atomic formulas. To this end, in the translation table, the positional and named argument terms that occur in the context of atomic formulas are denoted by the expressions of the form pred(...) and the terms that occur as individuals are denoted by expressions of the form func(...). In the table, each metavariable for an (unnamed) positional argument_i is assumed to be instantiated to values unequal to the instantiations of named arguments unicodestring_j -> filler_j. Regarding the last but first row, we assume that shortcuts for constants [RIF-DTB] have already been expanded to their full form ("..."^^symspace).

Presentation Syntax	XML Syntax
And ( conjunct₁ . . . conjunct_n )	<And> <formula>`χ_core`(conjunct₁)</formula> . . . <formula>`χ_core`(conjunct_n)</formula> </And>
Or ( disjunct₁ . . . disjunct_n )	<Or> <formula>`χ_core`(disjunct₁)</formula> . . . <formula>`χ_core`(disjunct_n)</formula> </Or>
Exists variable₁ . . . variable_n ( body )	<Exists> <declare>`χ_core`(variable₁)</declare> . . . <declare>`χ_core`(variable_n)</declare> <formula>`χ_core`(body)</formula> </Exists>
External ( atomframexpr )	<External> <content>`χ_core`(atomframexpr)</content> </External>
pred ( argument₁ . . . argument_n )	<Atom> <op>`χ_core`(pred)</op> <args ordered="yes"> `χ_core`(argument₁) . . . `χ_core`(argument_n) </args> </Atom>
inst [ key₁ -> filler₁ . . . key_n -> filler_n ]	<Frame> <object>`χ_core`(inst)</object> <slot ordered="yes"> `χ_core`(key₁) `χ_core`(filler₁) </slot> . . . <slot ordered="yes"> `χ_core`(key_n) `χ_core`(filler_n) </slot> </Frame>
inst # class	<Member> <instance>`χ_core`(inst)</instance> <class>`χ_core`(class)</class> </Member>
"unicodestring"^^symspace	<Const type="symspace">unicodestring</Const>
?unicodestring	<Var>unicodestring</Var>

4.3.2 Mapping of the Rule Language

The χ_core mapping from the presentation syntax to the XML syntax of the RIF-Core Rule Language is specified by the table below. It extends the translation table of Section Translation of RIF-Core Condition Language. While the Import directive is handled by the presentation-to-XML syntax mapping, the Prefix and Base directives are not. Instead, these directives should be handled by macro-expanding the associated shortcuts (compact URIs). Namely, a prefix name declared in a Prefix directive is expanded into the associated IRI, while relative IRIs are completed using the IRI declared in the Base directive. The mapping χ_core applies only to such macro-expanded documents. RIF-Core also allows other treatments of Prefix and Base provided that they produce equivalent XML documents. One such treatment is employed in the examples in this document, especially Example 7. It replaces prefix names with definitions of XML entities as follows. Each Prefix declaration becomes an ENTITY declaration [XML1.0] within a DOCTYPE DTD attached to the RIF-Core Document. The Base directive is mapped to the xml:base attribute [XML-Base] in the XML Document tag. Compact URIs of the form prefix:suffix are then mapped to &prefix;suffix.

Presentation Syntax	XML Syntax
Document( Import(loc₁ prfl₁?) . . . Import(loc_n prfl_n?) group )	<Document> <directive> <Import> <location>`χ_core`(loc₁)</location> <profile>`χ_core`(prfl₁)</profile>? </Import> </directive> . . . <directive> <Import> <location>`χ_core`(loc_n)</location> <profile>`χ_core`(prfl_n)</profile>? </Import> </directive> <payload>`χ_core`(group)</payload> </Document>
Group( clause₁ . . . clause_n )	<Group> <sentence>`χ_core`(clause₁)</sentence> . . . <sentence>`χ_core`(clause_n)</sentence> </Group>
Forall variable₁ . . . variable_n ( rule )	<Forall> <declare>`χ_core`(variable₁)</declare> . . . <declare>`χ_core`(variable_n)</declare> <formula>`χ_core`(rule)</formula> </Forall>
conclusion :- condition	<Implies> <if>`χ_core`(condition)</if> <then>`χ_core`(conclusion)</then> </Implies>

4.3.3 Mapping of Annotations

The χ_core mapping from RIF-Core annotations in the presentation syntax to the XML syntax is specified by the table below. It extends the translation tables of Sections Translation of RIF-Core Condition Language and Translation of RIF-Core Rule Language. The metavariable Typetag in the presentation and XML syntaxes stands for any of the class names And, Or, External, Document, or Group, and Quantifier for Exists or Forall. The dollar sign, $, stands for any of the binary infix operator names #, ##, =, or :-, while Binop stands for their respective class names Member, Subclass, Equal, or Implies. Again, each metavariable for an (unnamed) positional argument_i is assumed to be instantiated to values unequal to the instantiations of named arguments unicodestring_j -> filler_j.

Presentation Syntax	XML Syntax
(* iriconst? frameconj? ) Typetag* ( e₁ . . . e_n )	<Typetag> <id>`χ_core`(iriconst)</id>? <meta>`χ_core`(frameconj)</meta>? e₁' . . . e_n' </Typetag> `where e₁', . . ., e_n' are defined by the equation` `χ_core(Typetag(e₁ . . . e_n)) = <Typetag>e₁' . . . e_n'</Typetag>`
(* iriconst? frameconj? ) Quantifier* variable₁ . . . variable_n ( body )	<Quantifier> <id>`χ_core`(iriconst)</id>? <meta>`χ_core`(frameconj)</meta>? <declare>`χ_core`(variable₁)</declare> . . . <declare>`χ_core`(variable_n)</declare> <formula>`χ_core`(body)</formula> </Quantifier>
(* iriconst? frameconj? ) pred* ( argument₁ . . . argument_n )	<Atom> <id>`χ_core`(iriconst)</id>? <meta>`χ_core`(frameconj)</meta>? <op>`χ_core`(pred)</op> <args ordered="yes"> `χ_core`(argument₁) . . . `χ_core`(argument_n) </args> </Atom>
(* iriconst? frameconj? ) pred* ( unicodestring₁ -> filler₁ . . . unicodestring_n -> filler_n )	<Atom> <id>`χ_core`(iriconst)</id>? <meta>`χ_core`(frameconj)</meta>? <op>`χ_core`(pred)</op> <slot ordered="yes"> <Name>unicodestring₁</Name> `χ_core`(filler₁) </slot> . . . <slot ordered="yes"> <Name>unicodestring_n</Name> `χ_core`(filler_n) </slot> </Atom>
(* iriconst? frameconj? ) inst* [ key₁ -> filler₁ . . . key_n -> filler_n ]	<Frame> <id>`χ_core`(iriconst)</id>? <meta>`χ_core`(frameconj)</meta>? <object>`χ_core`(inst)</object> <slot ordered="yes"> `χ_core`(key₁) `χ_core`(filler₁) </slot> . . . <slot ordered="yes"> `χ_core`(key_n) `χ_core`(filler_n) </slot> </Frame>
(* iriconst? frameconj? *) e₁ $ e₂	<Binop> <id>`χ_core`(iriconst)</id>? <meta>`χ_core`(frameconj)</meta>? e₁' e₂' </Binop> `where Binop, e₁', e₂' are defined by the equation` `χ_core(e₁ $ e₂) = <Binop>e₁' e₂'</Binop>`
(* iriconst? frameconj? ) unicodestring^^symspace*	<Const type="symspace"> <id>`χ_core`(iriconst)</id>? <meta>`χ_core`(frameconj)</meta>? unicodestring </Const>
(* iriconst? frameconj? ) ?unicodestring*	<Var> <id>`χ_core`(iriconst)</id>? <meta>`χ_core`(frameconj)</meta>? unicodestring </Var>

5 Conformance and Safety

RIF-Core is a syntactic subset of both RIF-BLD and RIF-PRD. The semantics of any RIF-Core formula is well defined via the semantic structures, truth valuation function and definition of logical entailment given in section 3.

All RIF-Core documents are syntactically also RIF-PRD documents. However, some formula are unsafe and do not lead to a stable fixed-point if executed under the RIF-PRD operational semantics. Without datatypes and builtins then RIF-Core would correspond to pure Datalog for which the logical semantics and operational fixed-point semantics do coincide [Vianu97].

In order to allow production rule systems and logic programming systems to interchange rulesets via RIF-Core we define a safe subset of RIF-Core and only require minimally conformant RIF-Core consumers to correctly translate this safe subset. A minimally conformant RIF-Core consumer when presented with a well-formed but not safe RIF-Core document is free to reject that document or translate it (with or without a warning) with the risk that the translated ruleset when executed may not terminate. We allow any well-formed RIF-Core document to be regarded as a Conformant RIF-Core document even if not safe, thus allowing RIF-Core producers and consumers to produce and consume unsafe rulesets when appropriate.

5.1 Safeness

A subformula of a RIF-Core condition formula is called an external subformula if it appears within an Externally defined term. A subformula of a condition formula is called disjunctive subformula if it appears within a Disjunction.

Definition (Safeness).

A variable ?v is called safe with respect to a RIF formula φ if it appears in at least one non-external, non-disjunctive atomic subformula of φ such that ?v is not in the scope of an existential quantifier within ψ.

A RIF condition formula φ is called safe if all its variables are safe with respect to φ and for all its existential subformulas Exists ?V₁ ... ?V_n ( ψ ) each ?V₁ ... ?V_n is safe with respect to ψ

A RIF rule φ :- ψ is called safe if all its variables are safe with respect to ψ.

A RIF rule implication φ :- ψ is called safe if all its variables are safe with respect to ψ.

A RIF Universal rule implication Forall ?V1 ... ?Vn (&phi) is called safe if φ is safe.

A RIF Universal fact Forall ?V1 ... ?Vn (φ) is called safe if φ is ground.

5.2 Conformance Clauses

RIF-Core does not require or expect conformant systems to implement the RIF-Core presentation syntax. Instead, conformance is described in terms of semantics-preserving transformations.

Let Τ be a set of datatypes that includes the datatypes specified in [RIF-DTB], and suppose Ε is a set of external predicates and functions that includes the built-ins listed in [RIF-DTB]. We say that a formula φ is a Core_Τ,Ε formula iff

it is a well-formed Core formula,
all the datatypes used in φ are in Τ, and
all the externally defined functions and predicates used in φ are in Ε.

A RIF processor is a conformant Core_Τ,Ε consumer iff it implements a semantics-preserving mapping, μ, from the set of all Core_Τ,Ε formulas to the language L of the processor.

Formally, this means that for any pair φ, ψ of Core_Τ,Ε formulas for which φ |=_Core ψ is defined, φ |=_Core ψ iff μ(φ) |=_L μ(ψ). Here |=_Core denotes the logical entailment in RIF-Core and |=_L is the logical entailment in the language L of the RIF processor.

A RIF processor is a conformant Core_Τ,Ε producer iff it implements a semantics-preserving mapping, ν, from a subset of the language L of the processor to a set of Core_Τ,Ε formulas.

Formally, this means that for any pair φ, ψ of formulas in the aforesaid subset of L for which φ |=_L ψ is defined, φ |=_L ψ iff ν(φ) |=_Core ν(ψ).

A conformant document is one which conforms to all the syntactic constraints of RIF-Core, including ones that cannot be checked by an XML Schema validator (cf. Definition Conformant Core document in XML syntax).

A round-tripping of a conformant Core document is its semantics-preserving mapping to a document in any language L followed by a semantics-preserving mapping from the L document back to a conformant Coredocument. While semantically equivalent, the original and the round-tripped Core documents need not be identical. Metadata should survive Core round-tripping.

The above definitions are specializations to Core of the general conformance clauses defined in the RIF framework for logic dialects [RIF-FLD]. The following clauses are further restrictions that are specific to RIF-Core.

RIF-Core specific clauses

Conformant Core producers and consumers are required to support only the entailments of the form φ |=_Core ψ, where ψ is a closed RIF condition formula, i.e., an existentially quantified RIF condition in which every variable, ?V, is in the scope of a quantifier of the form Exists ?V.

Safely conformant Core producers and consumers are required to support only entailments of the form φ |=_Core ψ, where ψ is a closed RIF condition formula and φ is a safe formula.

A conformant RIF-Core consumer is a conformant Core_Τ,Ε consumer in which Τ consists only of the datatypes and Ε consists only of the externally defined functions and predicates that are required by RIF-Core. These datatypes and externally defined terms (called built-ins) are specified in [RIF-DTB]. A conformant RIF-Core consumer must reject all inputs that do not match the syntax of Core. If it implements extensions, it may do so under user control -- having a "strict Core" mode and a "run-with-extensions" mode.

A conformant Core producer is a conformant Core_Τ,Ε producer, which produces documents that include only the datatypes and externals that are required by Core.

Feature At Risk #3: Strictness Requirement

Note: This feature is "at risk" and may be altered or removed from this specification based on feedback. If you have concerns about this or information which may be useful in our eventual decision, please tell us at public-rif-comments@w3.org. See the full list of features "at risk" in RIF.

The two preceding clauses are features AT RISK. In particular, the "strictness" requirement is under discussion.

6 RIF-Core as a Specialization of RIF-PRD

This normative section describes RIF-Core by specializing RIF-PRD . The reader is assumed to be familiar with RIF-PRD as described in [RIF-PRD]. The reader who is not interested in how RIF-Core is derived from PRD can skip this section.

6.1 Intersection of RIF-PRD and RIF-BLD

RIF-PRD and RIF-BLD share essentially the same presentation syntax and XML syntax.

The differences between the two dialects are summarized below:

RIF-BLD allows logic and externally specified, fixed-interpretation functions as TERM, whereas RIF-PRD accepts only externally specified functions;
RIF-BLD allows ATOMIC or And(ATOMIC*) in rule conclusions, whereas RIF-PRD allows ACTION or Do(ACTION*). In RIF-PRD it is not possible to conclude equality or class membership.
RIF-PRD allows Not(FORMULA), which RIF-BLD does not accept;
RIF-PRD defines ASSERT and Retract actions that are not allowed in RIF-BLD.
RIF-PRD introduces a pattern matching constraint in Forall

For context, the table below lists the constructs which are in the maximal common subset (intersection) of BLD and PRD, marks certain rows as not being in Core, or annotates them w.r.t. restrictions making them part of Core.

	Presentation syntax	XML syntax
	TERM ::=
Core	[Const \| Var \| External]
	Const ::=
Core	'"' UNICODESTRING '"^^' SYMSPACE	<Const type=xsd:anyURI [xml:lang=xsd:language]? > Any Unicode string </Const>
	Var ::=
Core	'?' Any Unicode string	<Var> Any Unicode string </Var>
	External (as TERM) ::=	Remark: only used for external built-in calls; no logical functions
Core	'External' '(' Expr ')'	<External> <content> Expr </content> </External>
	ATOMIC ::=
Core	[Atom \| Frame]
	Atom ::=
Core	Const '(' (TERM* ')'	<Atom> <op> Const </op> <args rif:ordered="yes"> TERM* </args>? </Atom>
	Equal ::=
Core	TERM = TERM	<Equal> <left> TERM </left> <right> TERM </right> </Equal>
	Member ::=	Remark: under discussion; might be not part of Core
Core	TERM # TERM	<Member> <instance> TERM </instance> <class> TERM </class> </Member>
	Frame ::=
Core	TERM ' [ ' (TERM ' -> ' TERM)* ' ] '	<Frame> <object> TERM </object> <slot rif:ordered="yes"> TERM TERM </slot>* </Frame>
	FORMULA ::=
Core	[ATOMIC \| External \| And \| Or \| Exists]
	External (as FORMULA) ::=
Core	'External '(' [Atom \| Frame] ')'	<External> <content> [ Atom \| Frame ] </content> </External>
	And ::=
Core	'And' '(' FORMULA* ')'	<And> <formula> FORMULA </formula>* </And>
	Or ::=
Core	'Or' '(' FORMULA* ')'	<Or> <formula> FORMULA </formula>* </Or>
	Exists ::=
Core	'Exists' Var+ '(' FORMULA ')'	<Exists> <declare> Var </declare>+ <formula> FORMULA </formula> </Exists>
	RULE ::=	Remark: There is an implicit assert assumption for production rules
Core	[ Forall \| Implies \| ATOMIC ]
	Forall ::=	Remark: There is an implicit assert assumption for production rules
Core	' Forall ' Var+ ' ( ' [Implies \| ATOMIC] ' ) '	<Forall> <declare> Var </declare>+ <formula> [Implies \| ATOMIC ] </formula> </Forall>
	Implies ::=	Remark: There is an implicit assert assumption for production rules;
Core	ATOMIC '=>' FORMULA	<Implies> <if> FORMULA </if> <then> ATOMIC </then> </Implies>
	Group ::=
Core	METADATA? 'Group' '(' ([RULE \| Group])* ')'	<Group> <sentence> [ RULE \| Group ] </sentence>* </Group>
Core	METADATA? 'Document' '(' Group? ')'	<Document> <payload> Group </payload>? </Document>
	METADATA ::=
Core	'(' Const? (Frame \| 'And' '(' Frame ')')? '*)'	<AnyClassTag> <id> Const </declare>? <meta> [ Frame \| <And> <formula> Frame </formula> </And> ] </meta>? other content of AnyClassTag </AnyClassTag>

7 Acknowledgements

This document is the product of the Rules Interchange Format (RIF) Working Group (see below) whose members deserve recognition for their time and commitment. The editors extend special thanks to: ***, for their thorough reviews and insightful discussions; the working group chairs, Chris Welty and Christian de Sainte-Marie, for their invaluable technical help and inspirational leadership; and W3C staff contact Sandro Hawke, a constant source of ideas, help, and feedback.

The regular attendees at meetings of the Rule Interchange Format (RIF) Working Group at the time of the publication were: Adrian Paschke (Freie Universitaet Berlin), Axel Polleres (DERI), Chris Welty (IBM), Christian de Sainte Marie (IBM), Dave Reynolds (HP), Gary Hallmark (ORACLE), Harold Boley (NRC), Jos de Bruijn (FUB), Leora Morgenstern (IBM), Michael Kifer (Stony Brook), Mike Dean (BBN), Sandro Hawke (W3C/MIT), and Stella Mitchell (IBM). We would also like to thank *** past members of the working group, ***.

8 References

8.1 Normative References

[RDF-CONCEPTS]: Resource Description Framework (RDF): Concepts and Abstract Syntax, Klyne G., Carroll J. (Editors), W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/. Latest version available at http://www.w3.org/TR/rdf-concepts/.

[RFC-3066]: RFC 3066 - Tags for the Identification of Languages, H. Alvestrand, IETF, January 2001. This document is http://www.isi.edu/in-notes/rfc3066.txt.

[RFC-3987]: RFC 3987 - Internationalized Resource Identifiers (IRIs), M. Duerst and M. Suignard, IETF, January 2005. This document is http://www.ietf.org/rfc/rfc3987.txt.

[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.

[RIF-DTB]: RIF Datatypes and Built-Ins 1.0, Polleres A., Boley H. and Kifer M. (Editors), W3C Rule Interchange Format Working Group Draft. Latest Version available at http://www.w3.org/2005/rules/wiki/DTB.

[RIF-FLD]: RIF Framework for Logic Dialects, Boley H. and Kifer M. (Editors), W3C Rule Interchange Format Working Group Draft. Latest Version available at http://www.w3.org/2005/rules/wiki/FLD.

[RIF-RDF+OWL]: RIF RDF and OWL Compatibility, de Bruijn, J. (Editor), W3C Rule Interchange Format Working Group Draft. Latest Version available at http://www.w3.org/2005/rules/wiki/SWC.

[RIF-PRD]: RIF Production Rule Dialect, de Sainte Marie C., Paschke A., Hallmark G. (Editors), W3C Rule Interchange Format Working Group Draft. Latest Version available at http://www.w3.org/2005/rules/wiki/PRD.

[XML1.0]: Extensible Markup Language (XML) 1.0 (Fourth Edition), W3C Recommendation, World Wide Web Consortium, 16 August 2006, edited in place 29 September 2006. This version is http://www.w3.org/TR/2006/REC-xml-20060816/.

[XML-Base]: XML Base, W3C Recommendation, World Wide Web Consortium, 27 June 2001. This version is http://www.w3.org/TR/2001/REC-xmlbase-20010627/. The latest version is available at http://www.w3.org/TR/xmlbase/.

[XML-SCHEMA2]: XML Schema Part 2: Datatypes, W3C Recommendation, World Wide Web Consortium, 2 May 2001. This version is http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/. The latest version is available at http://www.w3.org/TR/xmlschema-2/.

8.2 Informational References

[ANF01]: Normal Form Conventions for XML Representations of Structured Data, Henry S. Thompson. October 2001. Available at http://www.ltg.ed.ac.uk/~ht/normalForms.html.

[CL73]: Symbolic Logic and Mechanical Theorem Proving, C.L. Chang and R.C.T. Lee. Academic Press, 1973.

[CURIE]: CURIE Syntax 1.0: A syntax for expressing Compact URIs, Mark Birbeck, Shane McCarron. W3C Working Draft 2 April 2008. Available at http://www.w3.org/TR/curie/.

[Enderton01]: A Mathematical Introduction to Logic, Second Edition, H. B. Enderton. Academic Press, 2001.

[KLW95]: Logical foundations of object-oriented and frame-based languages, M. Kifer, G. Lausen, J. Wu. Journal of ACM, July 1995, pp. 741--843.

[Mendelson97]: Introduction to Mathematical Logic, Fourth Edition, E. Mendelson. Chapman & Hall, 1997.

[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/.

[RDFSYN04]: RDF/XML Syntax Specification (Revised), Dave Beckett, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/. Latest version available at http://www.w3.org/TR/rdf-syntax-grammar/.

[RIF-UCR]: RIF Use Cases and Requirements, Paschke A., Hirtle D., Ginsberg A., Patranjan P-L., McCabe F. (Editors), W3C Rule Interchange Format Working Group Draft. Latest Version available at http://www.w3.org/2005/rules/wiki/UCR.

[TRT03]: Object-Oriented RuleML: User-Level Roles, URI-Grounded Clauses, and Order-Sorted Terms, H. Boley. Springer LNCS 2876, Oct. 2003, pp. 1-16. Preprint at http://iit-iti.nrc-cnrc.gc.ca/publications/nrc-46502_e.html.

[vEK76]: The semantics of predicate logic as a programming language, M. van Emden and R. Kowalski. Journal of the ACM 23 (1976), pp. 733-742.

[Vianu97]: Rule-Based Languages, Vianu V.. Annals of Mathematics and Artificial Intelligence 19 (1997), pp. 215-259.

9 Appendix: XML Schema for RIF-Core

The namespace of RIF is http://www.w3.org/2007/rif#.

XML schemas for the RIF-Core sublanguages are defined below and are also available here with additional examples.

9.1 Condition Language

 <?xml version="1.0" encoding="UTF-8"?>

9.2 Rule Language

 <?xml version="1.0" encoding="UTF-8"?>

Retrieved from "https://www.w3.org/2005/rules/wiki/index.php?title=Core-alternative&oldid=6280"