Core
__NUMBEREDHEADINGS__
 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, HewlettPackard Laboratories, Bristol UK
 Abstract

This document, developed by the Rule Interchange Format (RIF) Working Group, specifies RIFCore, a common subset of RIFBLD and RIFPRD based on RIFDTB 1.0. The RIFCore presentation syntax and semantics are specified as restrictions on RIFBLD. The XML serialization syntax of RIFCore is specified via a mapping from the presentation syntax. A normative XML schema is also provided.
 Status of this Document
 @@initial draft.
Copyright © 2008 W3C^{®} (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Contents
1 Overview
This specification develops RIFCore (the Core of the Rule Interchange Format). From a theoretical perspective, RIFCore corresponds to the language of definite Horn rules without function symbols ('Datalog') and a standard firstorder semantics. RIFCore thus is a subset of RIFBLD [RIFBLD]. At the same time, RIFCore is a language of production rules permitting only assert actions. RIFCore thus also is a subset of RIFPRD [RIFPRD]. Moreover, RIFCore is based on the builtins of RIFDTB 1.0 [RIFDTB]. The common subset of RIFBLD and RIFPRD is specified based on RIFDTB 1.0.
Syntactically, RIFCore has a number of Datalog extensions to support features such as objects and frames as in Flogic [KLW95], internationalized resource identifiers (or IRIs, defined by [RFC3987]) as identifiers for concepts, and XML Schema datatypes [XMLSCHEMA2]. In addition, RIF RDF and OWL Compatibility [RIFRDF+OWL] defines the syntax and semantics of integrated RIFCore/RDF and RIFCore/OWL languages. These features make RIFCore a Webaware 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.
RIFCore is defined as a specialization of RIFBLD (hence of [RIFFLD] which is part of the RIF extensibility framework). It is a syntactic subset of RIFBLD, so that a wellformed RIFCore formula (including documents and condition formula) is also a wellformed RIFBLD formula.
RIFCore is also a syntactic subset of [RIFPRD]. It is intended that a RIFPRD consumer can treat a RIFCore ruleset as if it were a RIFPRD rule set and it would conform to the normative RIFCore first order semantics. However, due to the presence of builtin functions and predicates there are RIFCore rulesets which are unsafe and do not reach a stable fixedpoint under RIFPRD semantics. We define the conformance to RIFCore so as to only require conformance over a safe subset of rules; in this way we permit RIFPRD processors to be safely conformant while allowing RIFCore documents to contain unsafe rules. Producers of RIFCore who require maximum interchange are advised to restrict themselves to safe rules. These notions of safeness and safe conformance are defined formally in section 5 Conformance and Safeness.
RIFCore is not the maximal common subset of RIFBLD and RIFPRD. It omits some features from the intersection which do not significantly add to the expressiveness of the language and are perceived to be not widely supported by rule languages. For example, named argument uniterms are omitted from RIFCore on such grounds.
To give a preview, here is a simple complete RIFCore example deriving a ternary relation from its inverse.
Example 1 (An introductory RIFCore 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 RIFCore 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 RIFCore XML Syntax is given in this specification. To formalize their meaning, a RIFCore Semantics is specified.
This document assumes familiarity with [RIFBLD] and [RIFPRD], as RIFCore is derived from these documents via syntactic restrictions.
2 RIFCore Presentation Syntax
Like RIFBLD and RIFPRD, RIFCore has both a presentation syntax and an XML syntax. The presentation syntax is normative, but is not intended to be a concrete syntax for RIFCore. It is defined in "mathematical English," a special form of English for communicating mathematical definitions, examples, etc. The presentation syntax deliberately leaves out details such as the delimiters of the various syntactic components, escape symbols, parenthesizing, precedence of operators, and the like. Since RIF is an interchange format, it uses XML as its concrete syntax and RIFCore conformance is described in terms of semanticspreserving transformations.
RIFCore is a syntactic subset of RIFBLD, and this section defines the presentation syntax of RIFCore as a restriction on the presentation syntax of RIFBLD.
2.1 Alphabet of RIFCore
The alphabet of the presentation language of RIFCore is the alphabet of the RIFBLD presentation language with the exclusion of the symbol ## and the set of symbols ArgNames.
Editor's Note: The status of membership (#) and subclass (##) formulas within Core is under debate in the working group. While there is a notion of membership within PRD it is restricted compared to that in BLD. This current draft for Core includes membership (#) but restricts its use to solely within the RIF Core Condition Formulas. Future drafts may extend its use, also include ## or may omit both entirely.
2.2 Terms of RIFCore
The Terms of RIFCore are the terms of RIFBLD with the exclusion of terms with named arguments and subclass terms.
2.3 Formulas of RIFCore
The Formulas of the RIFCore are the formulas of RIFBLD with the following modifications.
 Subterms that occur inside positional atomic formulas can be either variables or constants. This implies that RIFCore does not allow function applications in positional formulas.
 Subterms that occur in an equality term can be variables, constants, or external positional terms. Thus, while function applications are not allowed as arguments to predicates, builtin and externally defined functions are permitted inside equalities.
 Equality terms cannot occur in rule conclusions  they are allowed only in rule premises.
Editor's Note: Builtin functions and predicates present problems for many bottomup and topdown reasoners, which lack constraintsolving capabilities. This is because these reasoners can typically make use of a builtin only if certain arguments are bound. For instance, a bottomup reasoner might have trouble with evaluating a condition formula And(p(?X) External(foo(?Y,?X))), where p is a database predicate and foo a builtin predicate, if the reasoner can invoke foo only when the first argument ?Y is bound. The working group is currently discussing the implications of all this for RIFCore compliance.
2.4 Annotations and Documents
RIFCore allows every term and formula to be optionally annotated in the same way as in RIFBLD. The frame formulas that are allowed as part of an annotation must be syntactically correct for RIFCore. In particular, no function symbols are allowed in such a formula.
2.5 Wellformed Formulas
A syntactically correct RIFCore formula that passes the wellformedness test for RIFBLD is also a wellformed RIFCore formula. In this case, it simply means that
 each symbol in Const can be either an individual, a (nonexternal) predicate symbol, an external function, or an external predicate
 if a symbol occurs in a position of a predicate or (external) function of some arity then it cannot occur elsewhere in the formula with some other arity
 for every occurrence of External(t), t must be an instance of the coherent set of external schemas (Section Schemas for Externally Defined Terms of [RIFDTB]) associated with the language of RIFCore.
For rif:local symbols, the above clauses 1. and 2. apply only within the scope of a single document. That is, two different occurrences of the same rif:local symbol in different documents may have different arities, may occur both as predicates and individuals, etc. For other symbols, the above restrictions apply not only to the document that contains the particular occurrence of the symbol, but also to all documents that are imported by that document.
2.6 EBNF Grammar for the Presentation Syntax of RIFCore
Until now, we have used mathematical English to specify the syntax of RIFCore as a restriction on RIFBLD. Tool developers, however, may prefer EBNF notation, which provides a more succinct overview of the syntax. However, EBNF is unable to express all of the wellformedness conditions. For instance, the requirement that each symbol appear in only one context cannot be so expressed. As a result, the EBNF grammar defines a strict superset of RIFCore. For that reason this section is not normative.
The EBNF for the RIFCore presentation syntax is given as follows. For convenience of reading we show the entire EBNF in its three parts (rules, conditions, and annotations); these are derived from the ENBF for RIFBLD by applying the restrictions described above.
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 ')' ATOMIC ::= IRIMETA? (Atom  Frame ) Atom ::= UNITERM UNITERM ::= Const '(' (TERM* ')' Equal ::= TERM '=' ( TERM  'External' '(' FUNC ')' ) FUNC ::= Const '(' (GENERAL_TERM* ')' GENERAL_TERM ::= IRIMETA? (Const  Var  FUNC) 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 the Condition Language and Rule Language parts; the Annotations part is unchanged from RIFBLD.
2.6.1 EBNF for the RIFCore Condition Language
The RIFCore Condition Language represents formulas that can be used in the premises of RIFCore rules (also called rule bodies). The EBNF grammar for a superset of the RIFCore condition language is shown in the above conditions part.
This is a subset of the EBNF for the RIFBLD condition language specified in RIFBLD conditions part reflecting the syntax restrictions on RIFCore described normatively in sections 2.1 through 2.5 above.
Example 2 from the RIFBLD document also illustrates a RIFCore condition.
2.6.2 EBNF for the RIFCore Rule Language
The presentation syntax for RIFCore rules is based on the syntax in Section EBNF for the RIFCore Condition Language with the productions shown in the above rules part.
Again, this is a subset of the EBNF for the RIFBLD rule language specified in RIFBLD rules part reflecting the syntax restrictions on RIFCore described normatively in sections 2.1 through 2.5 above.
Example 3 from the RIFBLD document also illustrates a set of RIFCore rules and Example 4 a RIFCore document that contains an annotated group formula. In contrast, Example 6 from the RIFBLD document shows a formula that is not in RIFCore because it includes terms with named arguments, which are not allowed in this dialect.
3 RIFCore Semantics
RIFCore is a syntactic subset of RIFBLD, and the semantics of RIFCore is identical to the one of RIFBLD for that subset.
4 XML Serialization Syntax for RIFCore
The XML syntax of RIFCore is a subset of the XML syntax of RIFBLD. All XML tags of RIFBLD (except Subclass, sub and super) are supported, but the XML schema of RIFCore restricts their context with respect to what is allowed by the XML schema of RIFBLD. The semantics of the XML syntax for RIFCore is defined through the same RIFBLD XMLtopresentation syntax mapping.
Editor's Note: As noted earlier the status of membership (#) and subclass (##) formulas are under discussion in the working group. Depending on the resolution of this issue the tags relating to subclass may be reinstated or those relating to membership may be removed.
Example 5, "A RIF condition and its XML serialization," in the RIFBLD document also illustrates XML serialization for a RIFCore condition formula. XML serialization of a complete RIFCore document appears in the RIFBLD document as Example 7.
5 Conformance and Safeness
RIFCore is a syntactic subset of both RIFBLD and RIFPRD. The semantics of a RIFCore formula is the same as the semantics given to it by RIFBLD.
All RIFCore documents are syntactically also RIFPRD documents. However, some formulas may be unsafe and cannot be executed under the RIFPRD operational semantics. Thus, in order to allow production rule systems and logic programming systems to interchange rulesets via RIFCore, we define a safe subset of RIFCore and the notion of safely conformant RIFCore consumers or producers. A safely conformant RIFCore consumer can reject nonsafe RIFCore documents even if they are otherwise wellformed. The notion of (general) conformance allows RIFCore producers and consumers to produce and consume unsafe rulesets. For safe Core documents, the logical semantics of RIFBLD and the operational fixedpoint semantics of RIFPRD coincide. In the absence of datatypes and builtins, this follows from the equivalence of operational and declarative semantics for Datalog, as discussed in [Vianu97].
Editor's Note: Since Vianu97 does not prove the equivalence of declarative/fixedpoint semantics for Datalog, just discusses it, the rewritten PRD section should add a more appropriate reference.
Editor's Note: A complete specification of Core as a specialization of RIFPRD will be included in a future draft.
5.1 Safeness
Intuitively, safeness of rules guarantees that when performing reasoning in a forwardchaining manner, it is possible to find bindings for all the variables in the rule so that the condition can be evaluated.
To define safeness in the face of external predicates and functions, we define the notion of binding patterns, which are lists of the form (p_{1}, ..., p_{n}), such that p_{i}=b or p_{i}=u, for 1 ≤ i ≤ n. Intuitively, b stands for a "bound" and u stands for an "unbound" argument.
Each external function or predicate has an associated list of valid binding patterns. We define here the binding patterns valid for the functions and predicates defined in [DTB].
Every function or predicate f defined in [DTB] has a valid binding pattern for each of its schemas with only the symbol b such that its length is the number of arguments in the schema. In addition,
 the external predicates pred:iristring, pred:stringequal, pred:dateequal, pred:dateTimeequal, pred:durationequal, pred:dateequal, pred:timeequal, pred:XMLLiteralequal, pred:matcheslanguagerange, pred:textequal have the valid binding patterns (b, u) and (u, b).
The functions and predicates defined in [DTB] have no other valid binding patterns.
Definition (Safeness). Let ψ be a condition formula, referred to here as the context. A variable ?V is safe (resp., strongly safe) in a formula
 And(φ_{1} ... φ_{n}), in the context of ψ, iff n > 0 and ?V is safe (resp., strongly safe) in φ_{1} or ... or φ_{n}, in the context of ψ;
 Or(φ_{1} ... φ_{n}), in the context of ψ, iff n > 0 and ?V is safe (resp., strongly safe) in φ_{1} and ... and φ_{n}, in the respective contexts of φ_{1}, ..., φ_{n};
 Exists ?V_{1} ... ?V_{n}(φ), in the context of ψ, iff φ is a formula, ?V is not in {?V_{1}, ..., ?V_{n}}, and ?V is safe (resp., strongly safe) in φ, in the context of ψ;
 ?V=t, in the context of ψ, iff all variables appearing in t are safe (resp., strongly safe) in ψ', which is obtained from ψ by replacing every occurrence of ?V=t with And(), in the context of ψ';
 t=?V, in the context of ψ, iff all variables appearing in t are safe (resp., strongly safe) in ψ', which is obtained from ψ by replacing every occurrence of ?V=t with And(), in the context of ψ'.
Furthermore, ?V is safe in a nonequality term φ, in the context of ψ, iff φ=?V or φ is a term with arguments t_{1}, ..., t_{n}, n > 0, and ?V is safe in t_{1} or ... or t_{n}, in the context of ψ.
Finally, ?V is strongly safe in a nonequality and nonexternal term φ, in the context of ψ, iff φ=?V or φ is a term with arguments t_{1}, ..., t_{n}, n > 0, and ?V is strongly safe in t_{1} or ... or t_{n}, in the context of ψ.
Every variablefree atomic formula is safe.
A universal fact Forall ?V1 ... ?Vn (φ) is safe iff φ is a variablefree atomic formula.
A universal rule Forall ?V1 ... ?Vn (φ : ψ) is safe iff φ : ψ is safe.
A rule implication φ : ψ is safe iff all variables appearing in φ are safe in ψ, in the context of ψ, and there is a replacement θ of variable occurrences in φ : ψ with the symbols b and u such that
 for every variable symbol ?V and each occurrence of ?V in an atomic formula α, let χ be the largest subformula of ψ such that α is a subformula of χ and ?V is strongly safe in χ, then all occurrences of ?V in χ must be replaced with the symbol b; and with u otherwise,
 every occurrence of a variable symbol ?V in φ is replaced with b if ?V is strongly safe in ψ; and with u otherwise,
 for every occurrence of any external term External(f(t_{1}, ..., t_{n})) in ψ or φ, the binding pattern obtained from (t_{1}, ..., t_{n}) by replacing every constant and every external term with b and replacing every variable according to θ is a valid binding pattern for f. ☐
Consider the following formula:
Forall ?x ?y ?z ?u (ex:p(?x) : Or( And( ex:q(?z) pred:iristring(?x ?z))) And( ?x=?y ?y=?u ex:q(?u)))
One can verify that this formula is safe, in the following way: the only variable appearing in the conclusion of the rule is ?x; ?x is safe in the first component of the disjunction, because it appears in the atomic formula pred:iristring(?x,?z). We then have that ?x is also safe in the second component, because ?u is safe in And( And() And() ex:q(?u)), and so ?y is safe in And( And() ?y=?u ex:q(?u)) and ?x is safe in And( ?x=?y ?y=?u ex:q(?u)). Finally, consider the replacement θ that replaces the occurrences of ?x in the consequent and the second disjunct with u, and all other variables occurrences with b. The following expression is obtained.
Forall ?x ?y ?z ?u (ex:p(u) : Or( And( ex:q(b) pred:iristring(u,b))) And( b=b b=b ex:q(b)))
One can verify that this is the only replacement that satisfies the first two conditions in the definition: ?x is not strongly safe in any formula of the condition, and so must be replaced with u; all other variables are strongly safe. Finally, we have that (u,b) is a valid binding pattern for pred:iristring.
Old Definition (To be deleted).
 A variable ?v is said to be safe with respect to a RIF condition formula φ if it appears in at least one plain atomic subformula of φ and is not in the scope of an existential quantifier within φ. A subformula of a RIF condition formula is plain if it is not an atom of the form External(...) and not within a disjunction.
 A RIF condition formula φ is called safe if all its variables are safe with respect to φ and for all its existential subformulas of the form Exists ?V_{1} ... ?V_{n} (ψ) each ?V_{1}, ..., ?V_{n} is 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 (φ) is called safe if the implication φ is safe.
 A RIF universal fact Forall ?V1 ... ?Vn (φ) is safe if φ contains no variables.
Editor's Note: In a future draft, there will be further discussion on the intuitions underlying this section's development of safeness conditions. Both positive and negative examples of various clauses in the definition of safeness will also be provided.
5.2 Conformance Clauses
RIFCore conformance is described in terms of semanticspreserving transformations.
Let Τ be a set of datatypes that includes the datatypes specified in [RIFDTB], and suppose Ε is a set of external predicates and functions that includes the builtins listed in [RIFDTB]. We say that a formula φ is a Core_{Τ,Ε} formula iff
 φ is a wellformed 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 semanticspreserving mapping from the set of all Core_{Τ,Ε} formulas to the language L of the processor.
A RIF processor is a conformant Core_{Τ,Ε} producer iff it implements a semanticspreserving mapping from a subset of the language L of the processor to a set of Core_{Τ,Ε} formulas.
A conformant document is an XML document that conforms to all the syntactic constraints of RIFCore, including ones that cannot be checked by an XML Schema validator. Note that the concrete presentation syntax given in Section 2.6 is purely informative (to help implementers see the set of language structures supported by RIFCore); the only normative concrete syntax for RIFCore is the XML syntax.
In addition:
 Conformant Core producers and consumers are required to support only the entailments of closed RIF condition formulas.
 A conformant 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 RIFCore. These datatypes and externally defined terms (called builtins) are specified in [RIFDTB]. A conformant RIFCore 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 "runwithextensions" 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 publicrifcomments@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.
 Safely conformant. A Core consumer or producer is safely conformant if it supports only entailments of the form φ =_{Core} ψ, where ψ is a closed RIF condition formula and φ is a safe formula. Since such a consumer/producer might not preserve entailment over unsafe formulas, it might not be Coreconformant in the more general sense defined earlier. Thus, safe conformance is a weaker requirement than (general) conformance.
6 RIFCore as a Specialization of RIFPRD
RIFCore is a syntactic subset of RIFPRD, and this section defines the presentation syntax of RIFCore as a restriction on the presentation syntax of RIFPRD.
6.1 Alphabet of RIFCore
The alphabet of the presentation language of RIFCore is the alphabet of the RIFPRD presentation language with the exclusion of the symbols ##, not, Do, Assert, Retract, and New.
Editor's Note: The status of membership (#) and subclass (##) formulas within Core is under debate in the working group. While there is a notion of membership within PRD it is restricted compared to that in BLD. This current draft for Core includes membership (#) but restricts its use to solely within the RIF Core Condition Formulas. Future drafts may extend its use, also include ## or may omit both entirely.
6.2 Terms of RIFCore
The Terms of RIFCore are the terms and atomic formulas of RIFPRD with the exclusion of subclass terms.
6.3 Formulas of RIFCore
The Formulas of RIFCore are the formulas of RIFPRD excluding negation.
6.4 Annotations and Documents
RIFCore allows every term and formula to be optionally annotated in the same way as in RIFPRD.
6.5 Wellformed Formulas
A syntactically correct RIFCore formula that passes the wellformedness test for RIFPRD is also a wellformed RIFCore formula.
6.6 Rules and Groups
A safe RIFCore rule is a wellformed RIFPRD rule with one of the following forms of abstract syntax:
 φ (where φ is a frame or an atom), or
 φ : condition, or
 Forall ?v_{1}...?v_{n} φ : condition
Some unsafe RIFCore rules are not RIFPRD rules. For example, ***example to be provided***
A RIFCore group is a RIFPRD group without strategy and without priority.
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 Jos de Bruijn for his safeness definition and to: ***, for their thorough reviews and insightful discussions; the working group chairs, Chris Welty and Christian de SainteMarie, 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).
8 References
8.1 Normative References
 [RDFCONCEPTS]
 Resource Description Framework (RDF): Concepts and Abstract Syntax, Klyne G., Carroll J. (Editors), W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/RECrdfconcepts20040210/. Latest version available at http://www.w3.org/TR/rdfconcepts/.
 [RFC3066]
 RFC 3066  Tags for the Identification of Languages, H. Alvestrand, IETF, January 2001. This document is http://www.isi.edu/innotes/rfc3066.txt.
 [RFC3987]
 RFC 3987  Internationalized Resource Identifiers (IRIs), M. Duerst and M. Suignard, IETF, January 2005. This document is http://www.ietf.org/rfc/rfc3987.txt.
 [RIFBLD]
 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.
 [RIFDTB]
 RIF Datatypes and BuiltIns 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.
 [RIFFLD]
 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.
 [RIFRDF+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.
 [RIFPRD]
 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/RECxml20060816/.
 [XMLBase]
 XML Base, W3C Recommendation, World Wide Web Consortium, 27 June 2001. This version is http://www.w3.org/TR/2001/RECxmlbase20010627/. The latest version is available at http://www.w3.org/TR/xmlbase/.
 [XMLSCHEMA2]
 XML Schema Part 2: Datatypes, W3C Recommendation, World Wide Web Consortium, 2 May 2001. This version is http://www.w3.org/TR/2001/RECxmlschema220010502/. The latest version is available at http://www.w3.org/TR/xmlschema2/.
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 objectoriented and framebased languages, M. Kifer, G. Lausen, J. Wu. Journal of ACM, July 1995, pp. 741843.
 [Mendelson97]
 Introduction to Mathematical Logic, Fourth Edition, E. Mendelson. Chapman & Hall, 1997.
 [OWLReference]
 OWL Web Ontology Language Reference, M. Dean, G. Schreiber, Editors, W3C Recommendation, 10 February 2004. Latest version available at http://www.w3.org/TR/owlref/.
 [RDFSYN04]
 RDF/XML Syntax Specification (Revised), Dave Beckett, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/RECrdfsyntaxgrammar20040210/. Latest version available at http://www.w3.org/TR/rdfsyntaxgrammar/.
 [RIFUCR]
 RIF Use Cases and Requirements, Paschke A., Hirtle D., Ginsberg A., Patranjan PL., McCabe F. (Editors), W3C Rule Interchange Format Working Group Draft. Latest Version available at http://www.w3.org/2005/rules/wiki/UCR.
 [TRT03]
 ObjectOriented RuleML: UserLevel Roles, URIGrounded Clauses, and OrderSorted Terms, H. Boley. Springer LNCS 2876, Oct. 2003, pp. 116. Preprint at http://iititi.nrccnrc.gc.ca/publications/nrc46502_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. 733742.
 [Vianu97]
 RuleBased Languages, Vianu V.. Annals of Mathematics and Artificial Intelligence 19 (1997), pp. 215259.
9 Appendix: XML Schema for RIFCore
The namespace of RIF is http://www.w3.org/2007/rif#.
XML schemas for the RIFCore sublanguages are defined below.
Editor's Note: The schemas will be made available on line in a future working draft.
9.1 Condition Language
<?xml version="1.0" encoding="UTF8"?>
9.2 Rule Language
<?xml version="1.0" encoding="UTF8"?>