W3C


RIF Basic Logic Dialect

W3C Editor's Draft 23 July 2008

This version:
http://www.w3.org/2005/rules/wg/draft/ED-rif-bld-20080723/
Latest editor's draft:
http://www.w3.org/2005/rules/wg/draft/rif-bld/
Previous version:
http://www.w3.org/2005/rules/wg/draft/ED-rif-bld-20080717/ (color-coded diff)
Editors:
Harold Boley, National Research Council, Canada
Michael Kifer, State University of New York at Stony Brook, USA


Abstract

This document, developed by the Rule Interchange Format (RIF) Working Group, specifies the Basic Logic Dialect, RIF-BLD, a format that allows logic rules to be exchanged between rule systems. The RIF-BLD presentation syntax and semantics are specified both directly and as specializations of the RIF Framework for Logic-based Dialects. The XML serialization syntax of RIF-BLD, obtained via a mapping from the presentation syntax, is specified using XML Schema.

Status of this Document

May Be Superseded

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is being published as one of a set of 6 documents:

  1. RIF Use Cases and Requirements
  2. RIF Basic Logic Dialect (this document)
  3. RIF Framework for Logic Dialects
  4. RIF RDF and OWL Compatibility
  5. RIF Production Rule Dialect
  6. RIF Datatypes and Built-Ins 1.0

Please Comment By 2008-07-28

The Rule Interchange Format (RIF) Working Group seeks public feedback on these Working Drafts. Please send your comments to public-rif-comments@w3.org (public archive). If possible, please offer specific changes to the text that would address your concern. You may also wish to check the Wiki Version of this document for internal-review comments and changes being drafted which may address your concerns.

No Endorsement

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Patents

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.


Contents

1 Overview

This specification develops RIF-BLD (the Basic Logic Dialect of the Rule Interchange Format). From a theoretical perspective, RIF-BLD corresponds to the language of definite Horn rules with equality and a standard first-order semantics [CL73]. Syntactically, RIF-BLD has a number of 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-BLD/RDF and RIF-BLD/OWL languages. These features make RIF-BLD 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-BLD is defined in two different ways -- both normative:

  • As a direct specification, independently of the RIF Framework for Logic Dialects [RIF-FLD], for the benefit of those who desire a direct path to RIF-BLD, e.g., as prospective implementers, and are not interested in extensibility issues. This version of the RIF-BLD specification is given first.
  • As a specialization of the RIF Framework for Logic-based Dialects [RIF-FLD], which is part of the RIF extensibility framework. Building on RIF-FLD, this version of the RIF-BLD specification is comparatively short and is presented in Section RIF-BLD as a Specialization of the RIF Framework at the end of this document. This is intended for the reader who is already familiar with RIF-FLD and does not need to go through the much longer direct specification of RIF-BLD. This section is also useful for dialect designers, as it is a concrete example of how a non-trivial RIF dialect can be derived from the RIF framework for logic dialects.

Logic-based RIF dialects that specialize or extend RIF-BLD in accordance with the RIF Framework for Logic Dialects [RIF-FLD] will be developed in other specifications by the RIF working group.

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

Example 1 (An introductory RIF-BLD example).

A rule can be written in English to derive buy relationships (rather than store any of them) from sell relationships (e.g., stored as facts, as exemplified by the second line):

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-BLD 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-BLD XML Syntax is given in this specification. To formalize their meaning, a RIF-BLD Semantics is specified.

2 Direct Specification of RIF-BLD Presentation Syntax

This normative section specifies the syntax of RIF-BLD directly, without relying on [RIF-FLD]. We define both the presentation syntax (below) and an XML syntax in Section XML Serialization Syntax for RIF-BLD. The presentation syntax is normative, but is not intended to be a concrete syntax for RIF-BLD. It is defined in "mathematical English," a special form of English for communicating mathematical definitions, examples, etc. This 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 RIF-BLD conformance is described in terms of semantics-preserving transformations.

Note to the reader: this section depends on Section Constants, Symbol Spaces, and Datatypes of [RIF-DTB].


2.1 Alphabet of RIF-BLD

Definition (Alphabet). The alphabet of the presentation language of RIF-BLD consists of

  • a countably infinite set of constant symbols Const
  • a countably infinite set of variable symbols Var (disjoint from Const)
  • a countably infinite set of argument names, ArgNames (disjoint from Const and Var)
  • 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 ^^

The set of connective symbols, quantifiers, =, etc., is disjoint from Const and Var. The argument names in ArgNames are written as unicode strings that must not start with a question mark, "?". Variables are written as Unicode strings preceded with the symbol "?".

Constants are written as "literal"^^symspace, where literal is a sequence of Unicode characters and symspace is an identifier for a symbol space. Symbol spaces are defined in Section Constants and Symbol Spaces of [RIF-DTB].

The symbols =, #, and ## are used in formulas that define equality, class membership, and subclass relationships. The symbol -> is used in terms that have named arguments and in frame formulas. The symbol External indicates that an atomic formula or a function term is defined externally (e.g., a built-in) and the symbols Prefix and Base are used in abridged representations of IRIs.

The symbol Document is used to specify RIF-BLD documents, Import is an import directive, and the symbol Group is used to organize RIF-BLD formulas into collections.   ☐

The language of RIF-BLD is the set of formulas constructed using the above alphabet according to the rules given below.


2.2 Terms

RIF-BLD defines several kinds of terms: constants and variables, positional terms, terms with named arguments, plus equality, membership, subclass, frame, and external terms. The word "term" will be used to refer to any of these constructs.

To simplify the next definition, we will use base term to refer to simple, positional, or named-argument terms, or to terms of the form External(t), where t is a positional or a named-argument term.

Definition (Term).

  1. Constants and variables. If tConst or tVar then t is a simple term.
  2. Positional terms. If tConst and t1, ..., tn are base terms then t(t1 ... tn) is a positional term.
  3. Terms with named arguments. A term with named arguments is of the form t(s1->v1 ... sn->vn), where tConst and v1, ..., vn are base terms and s1, ..., sn are pairwise distinct symbols from the set ArgNames.

    The constant t here represents a predicate or a function; s1, ..., sn represent argument names; and v1, ..., vn represent argument values. The argument names, s1, ..., sn, are required to be pairwise distinct. Terms with named arguments are like positional terms except that the arguments are named and their order is immaterial. Note that a term of the form f() is, trivially, both a positional term and a term with named arguments.

  4. Equality terms. t = s is an equality term, if t and s are base terms.
  5. Class membership terms (or just membership terms). t#s is a membership term if t and s are base terms.
  6. Subclass terms. t##s is a subclass term if t and s are base terms.
  7. Frame terms. t[p1->v1 ... pn->vn] is a frame term (or simply a frame) if t, p1, ..., pn, v1, ..., vn, n ≥ 0, are base terms.

    Membership, subclass, and frame terms are used to describe objects and class hierarchies.

  8. Externally defined terms. If t is a positional, named-argument, or a frame term then External(t) is an externally defined term.
  9. Such terms are used for representing built-in functions and predicates as well as "procedurally attached" terms or predicates, which might exist in various rule-based systems, but are not specified by RIF.

    Note that frame terms are allowed to be externally defined. Therefore, externally defined objects can be accessed using the more natural frame-based interface. For instance, External("http://example.com/acme"^^rif:iri["http://example.com/mycompany/president"^^rif:iri(?Year) -> ?Pres]) could be an interface provided to access an externally defined method "http://example.com/mycompany/president"^^rif:iri of an external object "http://example.com/acme"^^rif:iri.   ☐

    Feature At Risk #1: External frames

    Note: This feature is "at risk" and may be removed from this specification based on feedback. Please send feedback to public-rif-comments@w3.org.

Observe that the argument names of frame terms, p1, ..., pn, are base terms and, as a special case, can be variables. In contrast, terms with named arguments can use only the symbols from ArgNames to represent their argument names. They cannot be constants from Const or variables from Var. (The reason for this restriction has to do with the complexity of unification, which is used by several inference mechanisms of first-order logic.)

2.3 Formulas

Any term (positional or with named arguments) of the form p(...), where p is a predicate symbol, is also an atomic formula. Equality, membership, subclass, and frame terms are also atomic formulas. An externally defined term of the form External(φ), where φ is an atomic formula, is also an atomic formula, called an externally defined atomic formula.

Note that simple terms (constants and variables) are not formulas.

More general formulas are constructed out of the atomic formulas with the help of logical connectives.

Definition (Formula). A formula is a statement that has one of the following forms:

  1. Atomic: If φ is an atomic formula then it is also a formula.
  2. Condition formula: A condition formula is either an atomic formula or a formula that has one of the following forms:
    • Conjunction: If φ1, ..., φn, n ≥ 0, are condition formulas then so is And(φ1 ... φn), called a conjunctive formula. As a special case, And() is allowed and is treated as a tautology, i.e., a formula that is always true.
    • Disjunction: If φ1, ..., φn, n ≥ 0, are condition formulas then so is Or(φ1 ... φn), called a disjunctive formula. As a special case, Or() is permitted and is treated as a contradiction, i.e., a formula that is always false.
    • Existentials: If φ is a condition formula and ?V1, ..., ?Vn are variables then Exists ?V1 ... ?Vn(φ) is an existential formula.

    Condition formulas are intended to be used inside the premises of rules. Next we define the notion of RIF-BLD rules, sets of rules, and RIF documents.

  3. Rule implication: φ :- ψ is a formula, called rule implication, if:
    • φ is an atomic formula or a conjunction of atomic formulas,
    • ψ is a condition formula, and
    • none of the atomic formulas in φ is an externally defined term (i.e., a term of the form External(...)).

    Feature At Risk #2: Equality in the rule conclusion (φ in the above)

    Note: This feature is "at risk" and may be removed from this specification based on feedback. Please send feedback to public-rif-comments@w3.org.

  4. Universal rule: If φ is a rule implication and ?V1, ..., ?Vn are variables then Forall ?V1 ... ?Vn(φ) is a formula, called a universal rule. It is required that all the free variables in φ occur among variables ?V1 ... ?Vn in the quantification part. A variable ?v is free in φ if it does not occur in a subformula of φ of the form Q ?v (ψ), where Q is a quantifier (Forall or Exists). Universal rules will also be referred to as RIF-BLD rules.
  5. Universal fact: If φ is an atomic formula then Forall ?V1 ... ?Vn(φ) is a formula, called a universal fact, provided that all the free variables in φ occur among the variables ?V1 ... ?Vn.

    Universal facts are often considered to be rules without premises (or having true as their premises).

  6. Group: If φ1, ..., φn are RIF-BLD rules, universal facts, variable-free rule implications, variable-free atomic formulas, or group formulas then Group(φ1 ... φn) is a group formula.

    Group formulas are used to represent sets of rules and facts. Note that some of the φi's can be group formulas themselves, which means that groups can be nested.

  7. Document: An expression of the form Document(directive1 ... directiven Γ) is a RIF-BLD document formula (or simply a document formula), if
    • Γ is an optional group formula that encompasses the logical content of the document.
    • directive1, ..., directiven is an optional sequence of directives. A directive can be an import directive, a base directive, or a prefix directive.
      • A base directive has the form Base(iri), where iri is a unicode string in the form of an IRI.

        The Base directive does not affect the semantics. It defines a syntactic shortcut for expanding relative IRIs into full IRIs, as described in Section Constants and Symbol Spaces of [RIF-DTB].

      • A prefix directive has the form Prefix(p v), where p is an alphanumeric string that serves as the prefix name and v is a macro-expansion for p -- a string that forms an IRI.

        Like the Base directive, the Prefix directives do not affect the semantics of RIF documents. Instead, they define shorthands to allow more concise representation of IRI constants. This mechanism is explained in [RIF-DTB], Section Constants and Symbol Spaces.

      • An import directive can have one of these two forms: Import(t) or Import(t p). Here t is an IRI constant and p is a term. The constant t indicates the location of another document to be imported and p is called the profile of import.

        Section Direct Specification of RIF-BLD Semantics of this document defines the semantics for the directive Import(t) only. The semantics of the directive Import(t p) is given in [RIF-RDF+OWL]. It is used for importing non-RIF-BLD logical entities, such as RDF data and OWL ontologies. The profile specifies what kind of entity is being imported and under what semantics (for instance, the various RDF entailment regimes).

      A document formula can contain at most one Base directive. The Base directive, if present, must be first, followed by any number of Prefix directives, followed by any number of Import directives.

In this definition, the component formulas φ, φi, ψi, and Γ are said to be subformulas of the respective formulas (condition, rule, group, etc.) that are built using these components.   ☐


The above definitions endow RIF-BLD with a wide variety of syntactic forms for terms and formulas, which creates infrastructure for exchanging syntactically diverse rule languages. Systems that do not support some of the syntax directly can still support it through syntactic transformations. For instance, disjunctions in the rule body can be eliminated through a standard transformation, such as replacing p :- Or(q r) with a pair of rules p :- q,   p :- r. Terms with named arguments can be reduced to positional terms by ordering the arguments by their names and incorporating the ordered argument names into the predicate name. For instance, p(bb->1 aa->2) can be represented as p_aa_bb(2,1).


2.4 RIF-BLD Annotations in the Presentation Syntax

RIF-BLD allows every term and formula (including terms and formulas that occur inside other terms and formulas) to 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. Both items inside the annotation are optional. The id part represents the identifier of the term/formula to which the annotation is attached and φ is the metadata part of the annotation. RIF-BLD does not impose any restrictions on φ apart from what is stated above. In particular, it may include variables, function symbols, rif:local constants, and so on.

Document formulas with and without annotations will be referred to as RIF-BLD documents.

A convention is used to avoid a syntactic ambiguity in the above definition. For instance, in (* id φ *) t[w -> v] the metadata annotation could be attributed to the term t or to the entire frame t[w -> v]. The convention in RIF-BLD is that the above annotation is considered to be syntactically attached to the entire frame. Yet, since φ can be a conjunction, some conjuncts can be used to provide metadata targeted to the object part, t, of the frame. Generally, the convention associates each annotation to the largest term or formula it precedes.

We suggest to use Dublin Core, RDFS, and OWL properties for metadata, along the lines of Section 7.1 of [OWL-Reference]-- specifically owl:versionInfo, rdfs:label, rdfs:comment, rdfs:seeAlso, rdfs:isDefinedBy, dc:creator, dc:description, dc:date, and foaf:maker.

2.5 Well-formed Formulas

Not all formulas and thus not all documents are well-formed in RIF-BLD: it is required that no constant appear in more than one context. What this means precisely is explained below.

The set of all constant symbols, Const, is partitioned into several subsets as follows:

  • A subset of individuals.

    The symbols in Const that belong to the primitive datatypes are required to be individuals.

  • A number of subsets for predicate symbols such that:
    • There is one subset per symbol arity (defined below). Positional predicate symbols and the symbols with named arguments are in separate subsets.
    • The symbols for externally defined predicates are in subsets separate from the other predicate symbols.
  • Subsets of function symbols:

    As with predicate symbols, there is one subset per symbol arity. Symbols with named arguments and externally defined functions are in their own subsets.

Each predicate and function symbol has precisely one arity. For positional symbols, an arity is a non-negative integer that tells how many arguments the symbol can take. For symbols that take named arguments, an arity is a set {s1 ... sk} of argument names (siArgNames) that are allowed for that symbol.

An important point is that neither the above partitioning of constant symbols nor the arity are specified explicitly. Instead, the arity of a symbol and its type is determined by the context in which the symbol is used.

Definition (Context of a symbol). The context of an occurrence of a symbol, s∈Const, in a formula, φ, is determined as follows:

  • If s occurs as an atomic subformula of the form s(...) with arity α then s occurs in the context of a predicate symbol with arity α.
  • If s occurs as a term (not subformula) of the form s(...) with arity α then s occurs in the context of a function symbol with arity α.
  • If s occurs as an atomic subformula External(s(...)) with arity α then s occurs in the context of an external predicate symbol with arity α.
  • If s occurs as a term (not subformula) External(s(...)) with arity α then s occurs in the context of an external function symbol with arity α.   ☐

Definition (Imported document). Let Δ be a document formula and Import(t) be one of its import directives, where t is an IRI constant that identifies another document formula, Δ'. We say that Δ' is directly imported into Δ.

A document formula Δ' is said to be imported into Δ if it is either directly imported into Δ or it is imported (directly or not) into some other formula that is directly imported into Δ.     ☐


Definition (Well-formed formula). A formula φ is well-formed iff:

  • every constant symbol (whether rif:local or not) mentioned in φ occurs in exactly one context.
  • if φ is a document formula and Δ'1, ..., Δ'k are all of its imported 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-BLD.   ☐
  • 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.


Definition (Language of RIF-BLD). The language of RIF-BLD consists of the set of all well-formed 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-BLD

Until now, we have been using mathematical English to specify the syntax of RIF-BLD. Tool developers, however, may prefer EBNF notation, which provides a more succinct overview of the syntax. Several points should be kept in mind regarding this notation.

  • The syntax of first-order logic is not context-free, so EBNF cannot capture the syntax of RIF-BLD precisely. For instance, it cannot capture the section on well-formedness conditions, i.e., the requirement that each symbol in RIF-BLD can occur in at most one context. As a result, the EBNF grammar defines a strict superset of RIF-BLD (not all formulas that are derivable using the EBNF grammar are well-formed formulas in RIF-BLD).
  • The EBNF grammar does not address all details of how constants (defined in [RIF-DTB]) and variables are represented, and it is not sufficiently precise about the delimiters and escape symbols. White space is informally used as a delimiter, and is implied in productions that use Kleene star. For instance, TERM* is to be understood as TERM TERM ... TERM, where each ' ' abstracts from one or more blanks, tabs, newlines, etc. This is so because RIF's presentation syntax is a tool for specifying the semantics and for illustration of the main RIF concepts through examples. It is not intended as a concrete syntax for a rule language. RIF defines a concrete syntax only for exchanging rules, and that syntax is XML-based, obtained as a refinement and serialization of the presentation syntax.
  • For all the above reasons, the EBNF grammar is not normative. Recall, however, that the RIF-BLD presentation syntax, as specified in mathematical English, is normative.


2.6.1 EBNF for the Condition Language

The Condition Language represents formulas that can be used in the body of RIF-BLD rules. The EBNF grammar for a superset of the RIF-BLD condition language is as follows.

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

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. Exists introduces existentially quantified variables. Here Var+ stands for the list of variables that are free in FORMULA. RIF-BLD conditions permit only existential variables. A RIF-BLD FORMULA can also be an ATOMIC term, i.e. an Atom, External Atom, Equal, Member, Subclass, or Frame. A TERM can be a constant, variable, Expr, or External Expr.

The RIF-BLD presentation syntax does not commit to any particular vocabulary and permits arbitrary Unicode strings in constant symbols, argument names, and variables. Constant symbols can have this form: "UNICODESTRING"^^SYMSPACE, where SYMSPACE is a ANGLEBRACKIRI or CURIE that represents an 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.

Equality, membership, and subclass terms are self-explanatory. An Atom and Expr (expression) can either be positional or with named arguments. 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. Likewise, External(Expr) is a call to an externally defined function.

As explained in Section RIF-BLD Annotations in the Presentation Syntax, RIF-BLD 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-BLD conditions).

This example shows conditions that are composed of atoms, expressions, frames, and existentials. 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))

Terms with named arguments:

  cpt:book(cpt:author->auth:rifwg  cpt:title->bks:LeRif)
  Exists ?X (cpt:book(cpt:author->?X cpt:title->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-BLD rules extends the syntax in Section EBNF for RIF-BLD 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 | 'And' '(' ATOMIC* ')') ':-' FORMULA
 PROFILE   ::= TERM

For convenience, we reproduce the condition language part of the EBNF below.

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

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

A RIF-BLD 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-BLD 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-BLD Condition Language. In the CLAUSE production, an ATOMIC is what is usually called a fact. An Implies rule can have an ATOMIC or a conjunction of 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-BLD 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-BLD document containing an annotated group).

This example shows a complete document containing a group formula that consists of two RIF-BLD 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 Direct Specification of RIF-BLD Semantics

This normative section specifies the semantics of RIF-BLD directly, without relying on [RIF-FLD].

Recall that the presentation syntax of RIF-BLD allows the use of macros, which are specified via the Prefix and Base directives, and various shortcuts for integers, strings, and rif:local symbols. The semantics, below, is described using the full syntax, i.e., we assume that all shortcuts and macros have already been expanded as defined in [RIF-DTB], Section Constants and Symbol Spaces.

3.1 Truth Values

The set TV of truth values in RIF-BLD consists of just two values, t and f.

3.2 Semantic Structures

The key concept in a model-theoretic semantics of a logic language is the notion of a semantic structure. The definition, below, is a little bit more general than necessary. This is done in order to better see the connection with the semantics of the RIF framework described in [RIF-FLD].

Definition (Semantic structure). A semantic structure, I, is a tuple of the form <TV, DTS, D, Dind, Dfunc, IC, IV, IF, Iframe, INF, Isub, Iisa, I=, Iexternal, Itruth>. Here D is a non-empty set of elements called the domain of I, and Dind, Dfunc are nonempty subsets of D. Dind is used to interpret the elements of Const that are individuals and Dfunc is used to interpret the elements of Const that are function symbols. As before, Const denotes the set of all constant symbols and Var the set of all variable symbols. TV denotes the set of truth values that the semantic structure uses and DTS is a set of identifiers for primitive datatypes (please refer to Section Datatypes of [RIF-DTB] for the semantics of datatypes).

The other components of I are total mappings defined as follows:

  1. IC maps Const to D.

    This mapping interprets constant symbols. In addition:

    • If a constant, c ∈ Const, is an individual then it is required that IC(c) ∈ Dind.
    • If c ∈ Const, is a function symbol (positional or with named arguments) then it is required that IC(c) ∈ Dfunc.
  2. IV maps Var to Dind.

    This mapping interprets variable symbols.

  3. IF maps D to functions D*indD (here D*ind is a set of all sequences of any finite length over the domain Dind).

    This mapping interprets positional terms. In addition:

    • If dDfunc then IF(d) must be a function D*indDind.
    • This means that when a function symbol is applied to arguments that are individual objects then the result is also an individual object.
  4. INF maps D to the set of total functions of the form SetOfFiniteSets(ArgNames × Dind) → D.

    This mapping interprets function symbols with named arguments. In addition:

    • If dDfunc then INF(d) must be a function SetOfFiniteSets(ArgNames × Dind) → Dind.
    • This is analogous to the interpretation of positional terms with two differences:
      • Each pair <s,v> ∈ ArgNames × Dind represents an argument/value pair instead of just a value in the case of a positional term.
      • The arguments of a term with named arguments constitute a finite set of argument/value pairs rather than a finite ordered sequence of simple elements. So, the order of the arguments does not matter.
  5. Iframe maps Dind to total functions of the form SetOfFiniteBags(Dind × Dind) → D.

    This mapping interprets frame terms. An argument, dDind, to Iframe represents an object and the finite bag {<a1,v1>, ..., <ak,vk>} represents a bag of attribute-value pairs for d. We will see shortly how Iframe is used to determine the truth valuation of frame terms.

    Bags (multi-sets) are used here because the order of the attribute/value pairs in a frame is immaterial and pairs may repeat: o[a->b a->b]. Such repetitions arise naturally when variables are instantiated with constants. For instance, o[?A->?B ?C->?D] becomes o[a->b a->b] if variables ?A and ?C are instantiated with the symbol a and ?B, ?D with b.

  6. Isub gives meaning to the subclass relationship. It is a mapping of the form Dind × DindD.

    The operator ## is required to be transitive, i.e., c1 ## c2 and c2 ## c3 must imply c1 ## c3. This is ensured by a restriction in Section Interpretation of Formulas.

  7. Iisa gives meaning to class membership. It is a mapping of the form Dind × DindD.

    The relationships # and ## are required to have the usual property that all members of a subclass are also members of the superclass, i.e., o # cl and cl ## scl must imply o # scl. This is ensured by a restriction in Section Interpretation of Formulas.

  8. I= is a mapping of the form Dind × DindD.

    It gives meaning to the equality operator.

  9. Itruth is a mapping of the form DTV.

    It is used to define truth valuation for formulas.

  10. Iexternal is a mapping from the coherent set of schemas for externally defined functions to total functions D* → D. For each external schema σ = (?X1 ... ?Xn; τ) in the coherent set of external schemas associated with the language, Iexternal(σ) is a function of the form DnD.

    For every external schema, σ, associated with the language, Iexternal(σ) is assumed to be specified externally in some document (hence the name external schema). In particular, if σ is a schema of a RIF built-in predicate or function, Iexternal(σ) is specified in [RIF-DTB] so that:

    • If σ is a schema of a built-in function then Iexternal(σ) must be the function defined in the aforesaid document.
    • If σ is a schema of a built-in predicate then Itruth ο (Iexternal(σ)) (the composition of Itruth and Iexternal(σ), a truth-valued function) must be as specified in [RIF-DTB].

For convenience, we also define the following mapping I from terms to D:

  • I(k) = IC(k), if k is a symbol in Const
  • I(?v) = IV(?v), if ?v is a variable in Var
  • I(f(t1 ... tn)) = IF(I(f))(I(t1),...,I(tn))
  • I(f(s1->v1 ... sn->vn)) = INF(I(f))({<s1,I(v1)>,...,<sn,I(vn)>})
  • Here we use {...} to denote a set of argument/value pairs.

  • I(o[a1->v1 ... ak->vk]) = Iframe(I(o))({<I(a1),I(v1)>, ..., <I(an),I(vn)>})
  • Here {...} denotes a bag of attribute/value pairs.

  • I(c1##c2) = Isub(I(c1), I(c2))
  • I(o#c) = Iisa(I(o), I(c))
  • I(x=y) = I=(I(x), I(y))
  • I(External(t)) = Iexternal(σ)(I(s1), ..., I(sn)), if t is an instance of the external schema σ = (?X1 ... ?Xn; τ) by substitution ?X1/s1 ... ?Xn/s1.

    Note that, by definition, External(t) is well formed only if t is an instance of an external schema. Furthermore, by the definition of coherent sets of external schemas, t can be an instance of at most one such schema, so I(External(t)) is well-defined.

The effect of datatypes. The set DTS must include the datatypes described in Section Primitive Datatypes of [RIF-DTB].


The datatype identifiers in DTS impose the following restrictions. Given dtDTS, let LSdt denote the lexical space of dt, VSdt denote its value space, and Ldt: LSdtVSdt the lexical-to-value-space mapping (for the definitions of these concepts, see Section Primitive Datatypes of [RIF-DTB]. Then the following must hold:

  • VSdtDind; and
  • For each constant "lit"^^dt such that litLSdt, IC("lit"^^dt) = Ldt(lit).

That is, IC must map the constants of a datatype dt in accordance with Ldt.

RIF-BLD does not impose restrictions on IC for constants in symbol spaces that are not datatypes mentioned in DTS.   ☐


3.3 RIF-BLD Annotations in the Semantics

RIF-BLD annotations are stripped before the mappings that constitute RIF-BLD semantic structures are applied. Likewise, they are stripped before applying the truth valuation, TValI, in the next section. Thus, identifiers and metadata have no effect on the formal semantics.

Note that although identifiers and metadata associated with RIF-BLD formulas are ignored by the semantics, they can be extracted by XML tools. The frame terms used to represent RIF-BLD metadata can then be fed into other RIF-BLD rules, thus enabling reasoning about metadata.


3.4 Interpretation of Non-document Formulas

This section defines how a semantic structure, I, determines the truth value TValI(φ) of a RIF-BLD formula, φ, where φ is any formula other than a document formula. Truth valuation of document formulas is defined in the next section.

We define a mapping, TValI, from the set of all non-document formulas to TV. Note that the definition implies that TValI(φ) is defined only if the set DTS of the datatypes of I includes all the datatypes mentioned in φ and Iexternal is defined on all externally defined functions and predicates in φ.


Definition (Truth valuation). Truth valuation for well-formed formulas in RIF-BLD is determined using the following function, denoted TValI:

  1. Positional atomic formulas: TValI(r(t1 ... tn)) = Itruth(I(r(t1 ... tn)))
  2. Atomic formulas with named arguments: TValI(p(s1->v1 ... sk->vk)) = Itruth(I(p(s1->v1 ... sk->vk))).
  3. Equality: TValI(x = y) = Itruth(I(x = y)).
    • To ensure that equality has precisely the expected properties, it is required that:
      Itruth(I(x = y)) = t if and only if I(x) = I(y) and that Itruth(I(x = y)) = f otherwise.
    • This is tantamount to saying that TValI(x = y) = t if I(x) = I(y).
  4. Subclass: TValI(sc ## cl) = Itruth(I(sc ## cl)).

    To ensure that the operator ## is transitive, i.e., c1 ## c2 and c2 ## c3 imply c1 ## c3, the following is required:

    For all c1, c2, c3D,   if TValI(c1 ## c2) = TValI(c2 ## c3) = t   then TValI(c1 ## c3) = t.
  5. Membership: TValI(o # cl) = Itruth(I(o # cl)).

    To ensure that all members of a subclass are also members of the superclass, i.e., o # cl and cl ## scl implies o # scl, the following is required:

    For all o, cl, sclD,   if TValI(o # cl) = TValI(cl ## scl) = t   then   TValI(o # scl) = t.
  6. Frame: TValI(o[a1->v1 ... ak->vk]) = Itruth(I(o[a1->v1 ... ak->vk])).

    Since the bag of attribute/value pairs represents the conjunctions of all the pairs, the following is required, if k > 0:

    TValI(o[a1->v1 ... ak->vk]) = t if and only if TValI(o[a1->v1]) = ... = TValI(o[ak->vk]) = t.
  7. Externally defined atomic formula: TValI(External(t)) = Itruth(Iexternal(σ)(I(s1), ..., I(sn))), if t is an atomic formula that is an instance of the external schema σ = (?X1 ... ?Xn; τ) by substitution ?X1/s1 ... ?Xn/s1.

    Note that, by definition, External(t) is well-formed only if t is an instance of an external schema. Furthermore, by the definition of coherent sets of external schemas, t can be an instance of at most one such schema, so I(External(t)) is well-defined.

  8. Conjunction: TValI(And(c1 ... cn)) = t if and only if TValI(c1) = ... = TValI(cn) = t. Otherwise, TValI(And(c1 ... cn)) = f.
  9. The empty conjunction is treated as a tautology, so TValI(And()) = t.

  10. Disjunction: TValI(Or(c1 ... cn)) = f if and only if TValI(c1) = ... = TValI(cn) = f. Otherwise, TValI(Or(c1 ... cn)) = t.
  11. The empty disjunction is treated as a contradiction, so TValI(Or()) = f.

  12. Quantification:
    • TValI(Exists ?v1 ... ?vn (φ)) = t if and only if for some I*, described below, TValI*(φ) = t.
    • TValI(Forall ?v1 ... ?vn (φ)) = t if and only if for every I*, described below, TValI*(φ) = t.

    Here I* is a semantic structure of the form <TV, DTS, D, Dind, Dfunc, IC, I*V, IF, Iframe, INF, Isub, Iisa, I=, Iexternal, Itruth>, which is exactly like I, except that the mapping I*V, is used instead of IV.   I*V is defined to coincide with IV on all variables except, possibly, on ?v1,...,?vn.

  13. Rule implication:
    • TValI(conclusion :- condition) = t, if either TValI(conclusion)=t or TValI(condition)=f.
    • TValI(conclusion :- condition) = f   otherwise.
  14. Groups of rules:

    If Γ is a group formula of the form Group(φ1 ... φn) then

    • TValI(Γ) = t if and only if TValI(φ1) = t, ..., TValI(φn) = t.
    • TValI(Γ) = f   otherwise.

    This means that a group of rules is treated as a conjunction.   ☐


3.5 Interpretation of Documents

Document formulas are interpreted using semantic multi-structures.

Definition (Semantic multi-structure). A semantic multi-structure is a set {IΔ1, ..., IΔn}, n>0, where IΔ1, ..., IΔn are semantic structures adorned with document formulas. These structures must be identical in all respects except that the mappings ICΔ1, ..., ICΔn might differ on the constants in Const that belong to the rif:local symbol space. The above set is allowed to have at most one semantic structure with the same adornment.     ☐

With the help of semantic multi-structures we can now explain the semantics of RIF documents.

Definition (Truth valuation of a document formula). Let Δ be a document formula and let Δ1, ..., Δk be all the RIF-BLD document formulas that are imported (directly or indirectly, according to Definition Imported document) into Δ. Let Γ, Γ1, ..., Γk denote the respective group formulas associated with these documents. If any of these Γi is missing (which is a possibility, since every part of a document is optional), assume that it is a tautology, such as a = a, so that every TVal function maps such a Γi to the truth value t. Let I = {IΔ, IΔ1, ..., IΔk, ...} be a semantic multi-structure that contains semantic structures adorned with at least the documents Δ, Δ1, ..., Δk. Then we define:

TValI(Δ) = t if and only if TValIΔ(Γ) = TValIΔ1(Γ1) = ... = TValIΔk(Γk) = t.

Note that this definition considers only those document formulas that are reachable via the one-argument import directives. Two argument import directives are not covered here. Their semantics is defined by the document RIF RDF and OWL Compatibility [RIF-RDF+OWL].         ☐


The above definitions make the intent behind the rif:local constants clear: occurrences of such constants in different documents can be interpreted differently even if they have the same name. Therefore, each document can choose the names for the rif:local constants freely and without regard to the names of such constants used in the imported documents.


3.6 Logical Entailment

We now define what it means for a set of RIF-BLD rules (such as a group or a document formula) to entail another RIF-BLD formula. In RIF-BLD we are mostly interested in entailment of RIF condition formulas, which can be viewed as queries to RIF-BLD documents. Therefore, entailment of condition formulas provides formal underpinning to RIF-BLD queries.


From now on, every formula is assumed to be part of some document. If it is not physically part of any document, it will be said to belong to a special query document. If I is a semantic multi-structure, Δ is the document of φ, and IΔ is the component structure in I that corresponds to Δ, then TValI(φ) is defined as TValIΔ(φ). Otherwise, TValI(φ) is undefined.

Definition (Models). A multi-structure I is a model of a formula, φ, written as I |= φ, iff TValI(φ) is defined and equals t.   ☐

Definition (Logical entailment). Let Γ and φ be RIF-BLD formulas. We say that Γ entails φ, written as Γ |= φ, if and only if for every multi-structure, I, for which both TValI(Γ) and TValI(φ) are defined, I |= Γ implies I |= φ.   ☐


Note that one consequence of the multi-document semantics of RIF-BLD is that local constants specified in one document cannot be queried from another document. In particular, they cannot be returned as query answers. For instance, if one document, Δ', has the fact "http://example.com/ppp"^^rif:iri("abc"^^rif:local) while another document formula, Δ, imports Δ' and has the rule "http://example.com/qqq"^^rif:iri(?X) :- "http://example.com/ppp"^^rif:iri(?X) , then Δ |= "http://example.com/qqq"^^rif:iri("abc"^^rif:local) does not hold. This is because "abc"^^rif:local in Δ' and "abc"^^rif:local in the query on the right-hand side of |= are treated as different constants by semantic multi-structures.


4 XML Serialization Syntax for RIF-BLD

The RIF-BLD XML serialization defines

Recall that the syntax of RIF-BLD is not context-free and thus cannot be fully captured by EBNF and 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 BLD document in XML syntax). A valid BLD document in the XML syntax is an XML document that is valid with respect to the XML schema in Appendix XML Schema for BLD.   ☐

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

The XML serialization for RIF-BLD 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 BLD. 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-BLD uses [XML1.0] for its XML syntax.


4.1 XML for the Condition Language

XML serialization of RIF-BLD in Section EBNF for RIF-BLD 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, for predicates, or Expr, for functions)
- Member    (member formula)
- Subclass  (subclass formula)
- Frame     (Frame formula)
- object    (Member/Frame role, containing a TERM or an object description)
- op        (Atom/Expr role for predicates/functions as operations)
- args      (Atom/Expr positional arguments role, with fixed 'ordered' attribute, containing n TERMs)
- instance  (Member instance role)
- class     (Member class role)
- sub       (Subclass sub-class role)
- super     (Subclass super-class role)
- slot      (Atom/Expr or Frame slot role, with fixed 'ordered' attribute, containing a Name or TERM followed by a TERM)
- Equal     (prefix version of term equation '=')
- Expr      (expression formula, positional or with named arguments)
- left      (Equal left-hand side role)
- right     (Equal right-hand side role)
- Const     (individual, function, or predicate symbol, with optional 'type' attribute)
- Name      (name of named argument)
- 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-BLD condition language see Appendix XML Schema for BLD.

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-BLD 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(curr   http://example.com/currencies#)
Prefix(rif    http://www.w3.org/2007/rif#)
Prefix(xs     http://www.w3.org/2001/XMLSchema#)
RIF condition

   And (Exists ?Buyer (cpt:purchase(?Buyer ?Seller
                                    cpt:book(?Author bks:LeRif)
                                    curr:USD(49)))
        ?Seller=?Author )

XML serialization

   <And>
     <formula>
       <Exists>
         <declare><Var>Buyer</Var></declare>
         <formula>
           <Atom>
             <op><Const type="&rif;iri">&cpt;purchase</Const></op>
             <args ordered="yes">
               <Var>Buyer</Var>
               <Var>Seller</Var>
               <Expr>
                 <op><Const type="&rif;iri">&cpt;book</Const></op>
                 <args ordered="yes">
                   <Var>Author</Var>
                   <Const type="&rif;iri">&bks;LeRif</Const>
                 </args>
               </Expr>
               <Expr>
                 <op><Const type="&rif;iri">&curr;USD</Const></op>
                 <args ordered="yes"><Const type="&xs;integer">49</Const></args>
               </Expr>
             </args>
           </Atom>
         </formula>
       </Exists>
     </formula>
     <formula>
       <Equal>
         <left><Var>Seller</Var></left>
         <right><Var>Author</Var></right>
       </Equal>
     </formula>
   </And>


Example 6 (A RIF condition with named arguments and its XML serialization).

This example illustrates XML serialization of RIF conditions that involve terms with named arguments. As in Example 5, we assume the following prefix directives:

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

   And (Exists ?Buyer ?P (
                 And (?P#cpt:purchase
                      ?P[cpt:buyer->?Buyer
                         cpt:seller->?Seller
                         cpt:item->cpt:book(cpt:author->?Author cpt:title->bks:LeRif)
                         cpt:price->49
                         cpt:currency->curr:USD]))
        ?Seller=?Author)


XML serialization:

   <And>
     <formula>
       <Exists>
         <declare><Var>Buyer</Var></declare>
         <declare><Var>P</Var></declare>
         <formula>
           <And>
             <formula>
               <Member>
                 <instance><Var>P</Var></instance>
                 <class><Const type="&rif;iri">&cpt;purchase</Const></class>
               </Member>
             </formula>
             <formula>
               <Frame>
                 <object>
                   <Var>P</Var>
                 </object>
                 <slot ordered="yes">
                   <Const type="&rif;iri">&cpt;buyer</Const>
                   <Var>Buyer</Var>
                 </slot>
                 <slot ordered="yes">
                   <Const type="&rif;iri">&cpt;seller</Const>
                   <Var>Seller</Var>
                 </slot>
                 <slot ordered="yes">
                   <Const type="&rif;iri">&cpt;item</Const>
                   <Expr>
                     <op><Const type="&rif;iri">&cpt;book</Const></op>
                     <slot ordered="yes">
                       <Name>&cpt;author</Name>
                       <Var>Author</Var>
                     </slot>
                     <slot ordered="yes">
                       <Name>&cpt;title</Name>
                       <Const type="&rif;iri">&bks;LeRif</Const>
                     </slot>
                   </Expr>
                 </slot>
                 <slot ordered="yes">
                   <Const type="&rif;iri">&cpt;price</Const>
                   <Const type="&xs;integer">49</Const>
                 </slot>
                 <slot ordered="yes">
                   <Const type="&rif;iri">&cpt;currency</Const>
                   <Const type="&rif;iri">&curr;USD</Const>
                 </slot>
               </Frame>
             </formula>
           </And>
         </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-BLD serialization elements from Section XML for RIF-BLD Condition Language by including rules, along with their enclosing groups and documents, as described in Section EBNF for RIF-BLD Rule Language. The extended set includes the tags listed below. While there is a RIF-BLD 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-BLD 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-BLD is given in Appendix XML Schema for BLD.


Example 7 (Serializing a RIF-BLD 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(rif  http://www.w3.org/2007/rif#)
  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, χbld, from the presentation syntax to the XML syntax of RIF-BLD. 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 χbld to these metavariables. When an expression χbld(metavar) occurs in an XML pattern in the right column of a translation table, it should be understood as a recursive application of χbld to the presentation syntax represented by the metavariable. The XML syntax result of such an application is substituted for the expression χbld(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 χbld mapping from the presentation syntax to the XML syntax of the RIF-BLD Condition Language is specified by the table below. Each row indicates a translation χbld(Presentation) = XML. Since the presentation syntax of RIF-BLD 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 argumenti is assumed to be instantiated to values unequal to the instantiations of named arguments unicodestringj -> fillerj. 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 (
  conjunct1
  . . .
  conjunctn
    )
<And>
  <formula>χbld(conjunct1)</formula>
   . . .
  <formula>χbld(conjunctn)</formula>
</And>
Or (
  disjunct1
  . . .
  disjunctn
   )
<Or>
  <formula>χbld(disjunct1)</formula>
   . . .
  <formula>χbld(disjunctn)</formula>
</Or>
Exists
  variable1
  . . .
  variablen (
             body
            )
<Exists>
  <declare>χbld(variable1)</declare>
   . . .
  <declare>χbld(variablen)</declare>
  <formula>χbld(body)</formula>
</Exists>
External (
  atomframexpr
         )
<External>
  <content>χbld(atomframexpr)</content>
</External>
pred (
  argument1
  . . .
  argumentn
     )
<Atom>
  <op>χbld(pred)</op>
  <args ordered="yes">
    χbld(argument1)
    . . .
    χbld(argumentn)
  </args>
</Atom>
func (
  argument1
  . . .
  argumentn
     )
<Expr>
  <op>χbld(func)</op>
  <args ordered="yes">
    χbld(argument1)
    . . .
    χbld(argumentn)
  </args>
</Expr>
pred (
  unicodestring1 -> filler1
  . . .
  unicodestringn -> fillern
     )
<Atom>
  <op>χbld(pred)</op>
  <slot ordered="yes">
    <Name>unicodestring1</Name>
    χbld(filler1)
  </slot>
   . . .
  <slot ordered="yes">
    <Name>unicodestringn</Name>
    χbld(fillern)
  </slot>
</Atom>
func (
  unicodestring1 -> filler1
  . . .
  unicodestringn -> fillern
     )
<Expr>
  <op>χbld(func)</op>
  <slot ordered="yes">
    <Name>unicodestring1</Name>
    χbld(filler1)
  </slot>
   . . .
  <slot ordered="yes">
    <Name>unicodestringn</Name>
    χbld(fillern)
  </slot>
</Expr>
inst [
  key1 -> filler1
  . . .
  keyn -> fillern
     ]
<Frame>
  <object>χbld(inst)</object>
  <slot ordered="yes">
    χbld(key1)
    χbld(filler1)
  </slot>
   . . .
  <slot ordered="yes">
    χbld(keyn)
    χbld(fillern)
  </slot>
</Frame>
inst # class
<Member>
  <instance>χbld(inst)</instance>
  <class>χbld(class)</class>
</Member>
sub ## super
<Subclass>
  <sub>χbld(sub)</sub>
  <super>χbld(super)</super>
</Subclass>
left = right
<Equal>
  <left>χbld(left)</left>
  <right>χbld(right)</right>
</Equal>
"unicodestring"^^symspace
<Const type="symspace">unicodestring</Const>
?unicodestring
<Var>unicodestring</Var>


4.3.2 Mapping of the Rule Language

The χbld mapping from the presentation syntax to the XML syntax of the RIF-BLD Rule Language is specified by the table below. It extends the translation table of Section Translation of RIF-BLD 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 dealt with 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 χbld applies only to such macro-expanded documents. RIF-BLD 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-BLD 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(loc1 prfl1?)
   . . .
  Import(locn prfln?)
  group
        )
<Document>
  <directive>
    <Import>
      <location>χbld(loc1)</location>
      <profile>χbld(prfl1)</profile>?
    </Import>
  </directive>
   . . .
  <directive>
    <Import>
      <location>χbld(locn)</location>
      <profile>χbld(prfln)</profile>?
    </Import>
  </directive>
  <payload>χbld(group)</payload>
</Document>
Group(
  clause1
   . . .
  clausen
     )
<Group>
  <sentence>χbld(clause1)</sentence>
   . . .
  <sentence>χbld(clausen)</sentence>
</Group>
Forall
  variable1
   . . .
  variablen (
             rule
            )
<Forall>
  <declare>χbld(variable1)</declare>
   . . .
  <declare>χbld(variablen)</declare>
  <formula>χbld(rule)</formula>
</Forall>
conclusion :- condition
<Implies>
  <if>χbld(condition)</if>
  <then>χbld(conclusion)</then>
</Implies>

4.3.3 Mapping of Annotations

The χbld mapping from RIF-BLD 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-BLD Condition Language and Translation of RIF-BLD 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 argumenti is assumed to be instantiated to values unequal to the instantiations of named arguments unicodestringj -> fillerj.

Presentation Syntax XML Syntax
(* iriconst? frameconj? *)
Typetag ( e1 . . . en )
<Typetag>
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  e1' . . . en'
</Typetag>

where e1', . . ., en' are defined by the equation
χbld(Typetag(e1 . . . en)) = <Typetag>e1' . . . en'</Typetag>
(* iriconst? frameconj? *)
Quantifier variable1 . . . variablen ( body )
<Quantifier>
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  <declare>χbld(variable1)</declare>
  . . .
  <declare>χbld(variablen)</declare>
  <formula>χbld(body)</formula>
</Quantifier>
(* iriconst? frameconj? *)
pred (
  argument1
  . . .
  argumentn
     )
<Atom>
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  <op>χbld(pred)</op>
  <args ordered="yes">
    χbld(argument1)
    . . .
    χbld(argumentn)
  </args>
</Atom>
(* iriconst? frameconj? *)
func (
  argument1
  . . .
  argumentn
     )
<Expr>
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  <op>χbld(func)</op>
  <args ordered="yes">
    χbld(argument1)
    . . .
    χbld(argumentn)
  </args>
</Expr>
(* iriconst? frameconj? *)
pred (
  unicodestring1 -> filler1
  . . .
  unicodestringn -> fillern
     )
<Atom>
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  <op>χbld(pred)</op>
  <slot ordered="yes">
    <Name>unicodestring1</Name>
    χbld(filler1)
  </slot>
   . . .
  <slot ordered="yes">
    <Name>unicodestringn</Name>
    χbld(fillern)
  </slot>
</Atom>
(* iriconst? frameconj? *)
func (
  unicodestring1 -> filler1
  . . .
  unicodestringn -> fillern
     )
<Expr>
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  <op>χbld(func)</op>
  <slot ordered="yes">
    <Name>unicodestring1</Name>
    χbld(filler1)
  </slot>
   . . .
  <slot ordered="yes">
    <Name>unicodestringn</Name>
    χbld(fillern)
  </slot>
</Expr>
(* iriconst? frameconj? *)
inst [
  key1 -> filler1
  . . .
  keyn -> fillern
     ]
<Frame>
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  <object>χbld(inst)</object>
  <slot ordered="yes">
    χbld(key1)
    χbld(filler1)
  </slot>
   . . .
  <slot ordered="yes">
    χbld(keyn)
    χbld(fillern)
  </slot>
</Frame>
(* iriconst? frameconj? *)
e1 $ e2
<Binop>
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  e1' e2'
</Binop>

where Binop, e1', e2' are defined by the equation
χbld(e1 $ e2) = <Binop>e1' e2'</Binop>
(* iriconst? frameconj? *)
unicodestring^^symspace
<Const type="symspace">
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  unicodestring
</Const>
(* iriconst? frameconj? *)
?unicodestring
<Var>
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  unicodestring
</Var>


5 Conformance Clauses

RIF-BLD does not require or expect conformant systems to implement the RIF-BLD 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 BLDΤ,Ε formula iff

  • it is a well-formed BLD 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 BLDΤ,Ε consumer iff it implements a semantics-preserving mapping, μ, from the set of all BLDΤ,Ε formulas to the language L of the processor.

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

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

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


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


RIF-BLD specific clauses

  • Conformant BLD producers and consumers are required to support only the entailments of the form φ |=BLD ψ, 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.
  • A conformant RIF-BLD consumer is a conformant BLDΤ,Ε consumer if Τ consists only of the datatypes and Ε consists only of the externally defined terms that are required by RIF-BLD. These datatypes and externally defined terms (called built-ins) are specified in the [RIF-DTB]. A conformant RIF-BLD consumer must reject all inputs that do not match the syntax of BLD. If it implements extensions, it may do so under user control -- having a "strict BLD" mode and a "run-with-extensions" mode.
  • A conformant BLD producer produces documents that include only the datatypes and externals required by BLD.

Feature At Risk #3: Strictness Requirement

Note: This feature is "at risk" and may be removed from this specification based on feedback. Please send feedback to public-rif-comments@w3.org.

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

  • A round-tripping of a conformant BLD 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 BLD document. While semantically equivalent, the original and the round-tripped BLD documents need not be identical. Metadata SHOULD survive BLD round-tripping.


6 RIF-BLD as a Specialization of the RIF Framework [RIF-FLD]

This normative section describes RIF-BLD by specializing RIF-FLD. The reader is assumed to be familiar with RIF-FLD as described in RIF Framework for Logic-Based Dialects [RIF-FLD]. The reader who is not interested in how RIF-BLD is derived from the framework can skip this section.


6.1 The Presentation Syntax of RIF-BLD as a Specialization of RIF-FLD

This section defines the precise relationship between the presentation syntax of RIF-BLD and the syntactic framework of RIF-FLD.

The presentation syntax of the RIF Basic Logic Dialect is defined by specialization from the presentation syntax of the RIF Syntactic Framework for Logic Dialects described in [RIF-FLD]. Section Syntax of a RIF Dialect as a Specialization of the RIF Framework in [RIF-FLD] lists the parameters of the syntactic framework in mathematical English, which we will now specialize for RIF-BLD.


  1. Alphabet.
    The alphabet of the RIF-BLD presentation syntax is the alphabet of RIF-FLD with the symbols Dialect, Neg, and Naf excluded.
  2. Assignment of signatures to each constant and variable symbol.
  3. The signature set of RIF-BLD contains the following signatures:

    1. Basic.
      • individual{ }
      • atomic{ }

      The signature individual{ } represents the context in which individual objects (but not atomic formulas) can appear.
      The signature atomic{ } represents the context where atomic formulas can occur.

    2. For every integer n ≥ 0, there are signatures
      • fn{(individual ... individual) ⇒ individual} -- for n-ary function symbols,
      • pn{(individual ... individual) ⇒ atomic} -- for n-ary predicates.

      These represent function and predicate symbols of arity n (each of the above cases has n individuals as arguments inside the parentheses).

    3. For every set of symbols s1,...,skArgNames, there are signatures fs1...sk{(s1->individual ... sk->individual) ⇒ individual} and ps1...sk{(s1->individual ... sk->individual) ⇒ atomic}. These are signatures for terms and predicates with arguments named s1, ..., sk, respectively. In this specialization of RIF-FLD, the argument names s1, ..., sk must be pairwise distinct.
    4. A symbol in Const can have exactly one signature, individual, fn, or pn, where n ≥ 0, or fs1...sk{(s1->individual ... sk->individual) ⇒ individual}, ps1...sk{(s1->individual ... sk->individual) ⇒ atomic}, for some s1,...,skArgNames. It cannot have the signature atomic, since only complex terms can have such signatures. Thus, by itself a symbol cannot be a proposition in RIF-BLD, but a term of the form p() can be.

      Accordingly, in RIF-BLD each constant symbol can be either an individual, a function of one particular arity or with certain argument names, a predicate of one particular arity or with certain argument names, an externally defined function of one particular arity, or an externally defined predicate symbol of one particular arity -- it is not possible for the same symbol to play more than one role.

    5. The constant symbols that belong to the primitive RIF datatypes (XML Schema datatypes, rdf:XMLLiteral, rif:text, etc.) all have the signature individual in RIF-BLD.
    6. The symbols of type rif:iri and rif:local can have the following signatures in RIF-BLD: individual, fn, or pn, for n = 0,1,....; or fs1...sk, ps1...sk, for some argument names s1,...,skArgNames.
    7. All variables are associated with signature individual{ }, so they can range only over individuals.
    8. The signature for equality is ={(individual individual)atomic}.

      This means that equality can compare only those terms whose signature is individual; it cannot compare predicate names or function symbols. Equality terms are also not allowed to occur inside other terms, since the above signature implies that any term of the form t = s has signature atomic and not individual.

    9. The frame signature, ->, is ->{(individual individual individual)atomic}.

      Note that this precludes the possibility that a frame term might occur as an argument to a predicate, a function, or inside some other term.

    10. The membership signature, #, is #{(individual individual) ⇒ atomic}.

      Note that this precludes the possibility that a membership term might occur as an argument to a predicate, a function, or inside some other term.

    11. The signature for the subclass relationship is ##{(individual individual)atomic}.

      As with frames and membership terms, this precludes the possibility that a subclass term might occur inside some other term.

    RIF-BLD uses no special syntax for declaring signatures. Instead, the rule author specifies signatures contextually. That is, since RIF-BLD requires that each symbol is associated with a unique signature, the signature is determined from the context in which the symbol is used. If a symbol is used in more than one context, the parser must treat this as a syntax error. If no errors are found, all terms and atomic formulas are guaranteed to be well-formed. Thus, signatures are not part of the RIF-BLD language, and individual and atomic are not reserved keywords.

  4. Supported types of terms.
    • RIF-BLD supports the following types of terms defined by the syntactic framework (see the Section Terms of [RIF-FLD]):
      1. constants
      2. variables
      3. positional
      4. with named arguments
      5. equality
      6. frame
      7. membership
      8. subclass
      9. external
    • Compared to RIF-FLD, terms (both positional and with named arguments) have significant restrictions in order to keep BLD relatively compact.
      • The signature for the variable symbols does not permit them to occur in the context of predicates, functions, or formulas. In particular, in the RIF-BLD specialization of RIF-FLD, a variable is not an atomic formula.
      • Likewise, a symbol cannot be an atomic formula by itself. That is, if pConst then p is not a well-formed atomic formula. However, p() can be an atomic formula.
      • Signatures permit only constant symbols to occur in the context of function or predicate names. Indeed, RIF-BLD signatures ensure that all variables have the signature individual{ } and all other terms, except for the constants from Const, can have either the signature individual{ } or atomic{ }. Therefore, if t is a (non-Const) term then t(...) is not a well-formed term.
      • In an externally defined term, External(t), t can be only a positional, named-argument, or a frame term. Compared to RIF-FLD, this restricts t so that it cannot be a constant.
      • Combined with the fact that in a well-formed term of the form External(t) the subterm t must be an instance of an external schema (by the definition of well-formed external terms in RIF-FLD), it follows that a predicate or a function symbol, p, that occurs in an external term External(p(...)) cannot also occur as a non-external symbol.

      • If a term, t, is an instance of an externally defined schema from 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.
  5. Required symbol spaces.
  6. RIF-BLD requires the following symbol spaces defined in Section Constants and Symbol Spaces of [RIF-DTB].

  7. Supported formulas.
  8. RIF-BLD supports the following types of formulas (see Well-formed Terms and Formulas in [RIF-FLD] for the definitions):

    • RIF-BLD condition
    • A RIF-BLD condition is an atomic formula, a conjunctive or disjunctive combination of atomic formulas with optional existential quantification of variables, or an external atomic formula.

    • RIF-BLD rule
    • A RIF-BLD rule is a universally quantified RIF-FLD rule with the following restrictions:

      • The head (or conclusion) of the rule is an atomic formula or a conjunction of atomic formulas.

        Note: This feature (Equality in the rule conclusion) is "at risk". See feature at risk #2

      • None of the atomic formulas mentioned in the rule head is externally defined (i.e., cannot have the form External(...)).
      • The body (or premise) of the rule is a RIF-BLD condition.
      • All free (non-quantified) variables in the rule must be quantified with Forall outside of the rule (i.e., Forall ?vars (head :- body)).
    • Universal fact

      A universal fact is a universally quantified atomic formula with no free variables.

    • RIF-BLD group

      A RIF-BLD group is a RIF-FLD group that contains only RIF-BLD rules, universal facts, variable-free rule implications, variable-free atomic formulas, and RIF-BLD groups.

    • RIF-BLD document

      A RIF-BLD document is a RIF-FLD document that consists of directives and a RIF-BLD group formula. There is no Dialect directive and the Import(loc) directive (with one argument) can import RIF-BLD documents only. There are no BLD-specific restrictions on the two-argument directive Import.

Recall that negation (classical or default) is not supported by RIF-BLD in either the rule head or the body.


6.2 The Semantics of RIF-BLD as a Specialization of RIF-FLD

This normative section defines the precise relationship between the semantics of RIF-BLD and the semantic framework of RIF-FLD. Specification of the semantics that does not rely on RIF-FLD is given in Section Direct Specification of RIF-BLD Semantics.

The semantics of the RIF Basic Logic Dialect is defined by specialization from the semantics of the Semantic Framework for Logic Dialects of RIF. Section Semantics of a RIF Dialect as a Specialization of the RIF Framework in [RIF-FLD] lists the parameters of the semantic framework, which one need to specialize. Thus, for RIF-BLD, we need to look at the following parameters:

  • The effect of the syntax.
  • RIF-BLD does not support negation. This is the only obvious simplification with respect to RIF-FLD as far as the semantics is concerned. The restrictions on the signatures of symbols in RIF-BLD do not affect the semantics in a significant way.

  • Truth values.
  • The set TV of truth values in RIF-BLD consists of just two values, t and f such that f <t t. The order <t is total.

  • Datatypes.
  • RIF-BLD supports the datatypes listed in Section Datatypes of [RIF-DTB].

  • Logical entailment.
  • Recall that logical entailment in RIF-FLD is defined with respect to an unspecified set of intended semantic structures and that dialects of RIF must make this notion concrete. For RIF-BLD, this set is defined in one of the two following equivalent ways:

    • as a set of all models; or
    • as the unique minimal model, if it exists. (Note that such a model might not exist because of equality and built-in predicates associated with the RIF-BLD required datatypes).

    These two definitions are equivalent for entailment of existentially closed RIF-BLD conditions by RIF-BLD documents (i.e., formulas where every variable, ?V, occurs in a subformula of the form Exists ...?V...(ψ)), since all rules in RIF-BLD are Horn -- it is a classical result of Van Emden and Kowalski [vEK76].

  • Import directive.
  • The semantics of the two-argument Import directive is given in [RIF-RDF+OWL]. The semantics of the one-argument directive is the same as in RIF-FLD.

6.3 The XML Serialization of RIF-BLD as a Specialization of RIF-FLD

Section Mapping from the RIF-FLD Presentation Syntax to the XML Syntax of [RIF-FLD] defines a mapping, χfld, from the presentation syntax of RIF-FLD to its XML serialization. When restricted to well-formed RIF-BLD formulas, χfld coincides with the BLD-to-XML mapping χbld. In this way, the XML serialization of RIF-BLD is a specialization of the RIF-FLD XML Serialization Framework defined in [RIF-FLD].

6.4 RIF-BLD Conformance as a Specialization of RIF-FLD

If T is a set of datatypes and E a set of externally defined terms, then the general definition of conformance in RIF-FLD yields the notion of conformant BLDT,E producers and consumers.

BLD further requires strictness, i.e., that a conformant producer produces only the documents where T and E are precisely those datatypes and externals, which are specified in [RIF-DTB], and that a conformant consumer consumes only such documents.

Note: This feature (Strictness requirement) is "at risk". See feature at risk #3

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. Special thanks to: Jos de Bruijn, David Hirtle, Stella Mitchell, Leora Morgenstern, Igor Mozetic, Axel Polleres, and Dave Reynolds, for their thorough reviews and insightful discussions. The working group chairs, Chris Welty and Christian de Sainte-Marie, provided invaluable technical help and inspirational leadership throughout the long and difficult trials leading to this draft. Last, but not least, our W3C team contact, Sandro Hawke, was 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 (REWERSE), Axel Polleres (DERI), Chris Welty (IBM), Christian de Sainte Marie (ILOG), Dave Reynolds (HP), Gary Hallmark (ORACLE), Harold Boley (NRC), Hassan Aït-Kaci (ILOG), Igor Mozetic (JFI), John Hall (OMG), 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 two past members of the working group, Allen Ginsberg and Paula-Lavinia Patranjan.

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-DTB]
RIF Datatypes and Built-Ins 1.0 Axel Polleres, Harold Boley, Michael Kifer, eds. W3C Editor's Draft, 23 July 2008, http://www.w3.org/2005/rules/wg/draft/ED-rif-dtb-20080723/. Latest version available at http://www.w3.org/2005/rules/wg/draft/rif-dtb/.

[RIF-FLD]
RIF Framework for Logic Dialects Harold Boley, Michael Kifer, eds. W3C Editor's Draft, 23 July 2008, http://www.w3.org/2005/rules/wg/draft/ED-rif-fld-20080723/. Latest version available at http://www.w3.org/2005/rules/wg/draft/rif-fld/.

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

[KLW95]
Logical foundations of object-oriented and frame-based languages, M. Kifer, G. Lausen, J. Wu. Journal of ACM, July 1995, pp. 741--843.
[OWL-Reference]
OWL Web Ontology Language Reference, M. Dean, G. Schreiber, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-ref-20040210/. 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-RDF+OWL]
RIF RDF and OWL Compatibility Jos de Bruijn, eds. W3C Editor's Draft, 23 July 2008, http://www.w3.org/2005/rules/wg/draft/ED-rif-rdf-owl-20080723/. Latest version available at http://www.w3.org/2005/rules/wg/draft/rif-rdf-owl/.

[RIF-UCR]
RIF Use Cases and Requirements Adrian Paschke, David Hirtle, Allen Ginsberg, Paula-Lavinia Patranjan, Frank McCabe, eds. W3C Editor's Draft, 23 July 2008, http://www.w3.org/2005/rules/wg/draft/ED-rif-ucr-20080723/. Latest version available at http://www.w3.org/2005/rules/wg/draft/rif-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.


9 Appendix: XML Schema for RIF-BLD

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

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


9.1 Condition Language

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

<xs:schema 
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 xmlns="http://www.w3.org/2007/rif#"
 targetNamespace="http://www.w3.org/2007/rif#"
 elementFormDefault="qualified"
 version="Id: BLDCond.xsd, v. 1.0, 2008-07-20, dhirtle/hboley">

 <xs:annotation>
   <xs:documentation>
   This is the XML schema for the Condition Language as defined by
   the Last Call Draft of the RIF Basic Logic Dialect.
   
   The schema is based on the following EBNF for the RIF-BLD Condition Language:

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

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

   </xs:documentation>
 </xs:annotation>
 
 <xs:group name="FORMULA">  
   <xs:choice>
     <xs:element ref="And"/>
     <xs:element ref="Or"/>
     <xs:element ref="Exists"/>
     <xs:group ref="ATOMIC"/>
     <xs:element name="External" type="External-FORMULA.type"/>
   </xs:choice>
 </xs:group>
 
 <xs:complexType name="External-FORMULA.type">
   <xs:sequence>
     <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
     <xs:element name="content" type="content-FORMULA.type"/>
   </xs:sequence>
 </xs:complexType>
 
 <xs:complexType name="content-FORMULA.type">
   <xs:sequence>
     <xs:choice>
       <xs:element ref="Atom"/>
       <xs:element ref="Frame"/>
     </xs:choice>
   </xs:sequence>
 </xs:complexType>

 <xs:element name="And">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
       <xs:element ref="formula" minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>
 
 <xs:element name="Or">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
       <xs:element ref="formula" minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>
 
 <xs:element name="Exists">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
       <xs:element ref="declare" minOccurs="1" maxOccurs="unbounded"/>
       <xs:element ref="formula"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>
 
 <xs:element name="formula">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="FORMULA"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>
 
 <xs:element name="declare">
   <xs:complexType>
     <xs:sequence>
       <xs:element ref="Var"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:group name="ATOMIC">
   <xs:choice>
     <xs:element ref="Atom"/>
     <xs:element ref="Equal"/>
     <xs:element ref="Member"/>
     <xs:element ref="Subclass"/>
     <xs:element ref="Frame"/>
   </xs:choice>
 </xs:group>
 
 <xs:element name="Atom">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="UNITERM"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>  
 
 <xs:group name="UNITERM">
   <xs:sequence>
     <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
     <xs:element ref="op"/>
     <xs:choice>
       <xs:element ref="args" minOccurs="0" maxOccurs="1"/>
       <xs:element name="slot" type="slot-UNITERM.type" minOccurs="0" maxOccurs="unbounded"/>
     </xs:choice>
   </xs:sequence>
 </xs:group>

 <xs:element name="op">
   <xs:complexType>
     <xs:sequence>
       <xs:element ref="Const"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>
 
 <xs:element name="args">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="TERM" minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="ordered" type="xs:string" fixed="yes"/>
   </xs:complexType>
 </xs:element>

 <xs:complexType name="slot-UNITERM.type">
   <xs:sequence>
     <xs:element ref="Name"/>
     <xs:group ref="TERM"/>
   </xs:sequence>
   <xs:attribute name="ordered" type="xs:string" fixed="yes"/>
 </xs:complexType>

 <xs:element name="Equal">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
       <xs:element ref="left"/>
       <xs:element ref="right"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:element name="left">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="TERM"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:element name="right">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="TERM"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:element name="Member">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
       <xs:element ref="instance"/>
       <xs:element ref="class"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:element name="Subclass">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
       <xs:element ref="sub"/>
       <xs:element ref="super"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>
 
 <xs:element name="instance">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="TERM"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>
 
 <xs:element name="class">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="TERM"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>
 
 <xs:element name="sub">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="TERM"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>
 
 <xs:element name="super">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="TERM"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>
   
 <xs:element name="Frame">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
       <xs:element ref="object"/>
       <xs:element name="slot" type="slot-Frame.type" minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:element name="object">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="TERM"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:complexType name="slot-Frame.type">
   <xs:sequence>
     <xs:group ref="TERM"/>
     <xs:group ref="TERM"/>
   </xs:sequence>
   <xs:attribute name="ordered" type="xs:string" fixed="yes"/>
 </xs:complexType>

 <xs:group name="TERM">  
     <xs:choice>
        <xs:element ref="Const"/>
        <xs:element ref="Var"/>
        <xs:element ref="Expr"/>
        <xs:element name="External" type="External-TERM.type"/>
     </xs:choice>
 </xs:group>
 
 <xs:complexType name="External-TERM.type">
   <xs:sequence>
     <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
     <xs:element name="content" type="content-TERM.type"/>
   </xs:sequence>
 </xs:complexType>
 
 <xs:complexType name="content-TERM.type">
   <xs:sequence>
     <xs:element ref="Expr"/>
   </xs:sequence>
 </xs:complexType>

 <xs:element name="Expr">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="UNITERM"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:element name="Const">
   <xs:complexType mixed="true">
     <xs:sequence>
       <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
     </xs:sequence>
     <xs:attribute name="type" type="xs:anyURI" use="required"/>
   </xs:complexType>
 </xs:element>
 
 <xs:element name="Name" type="xs:string">
 </xs:element>

 <xs:element name="Var">
   <xs:complexType mixed="true">
     <xs:sequence>
       <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:group name="IRIMETA">
   <xs:sequence>
     <xs:element ref="id" minOccurs="0" maxOccurs="1"/>
     <xs:element ref="meta" minOccurs="0" maxOccurs="1"/>
   </xs:sequence>
 </xs:group>

 <xs:element name="id">
   <xs:complexType>
     <xs:sequence>
       <xs:element name="Const" type="IRICONST.type"/>   
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:element name="meta">
   <xs:complexType>
    <xs:choice>
      <xs:element ref="Frame"/>
      <xs:element name="And" type="And-meta.type"/>
    </xs:choice>
   </xs:complexType>
 </xs:element>
 
 <xs:complexType name="And-meta.type">
   <xs:sequence>
     <xs:element name="formula" type="formula-meta.type" minOccurs="0" maxOccurs="unbounded"/>
   </xs:sequence>
 </xs:complexType>

 <xs:complexType name="formula-meta.type">
   <xs:sequence>
     <xs:element ref="Frame"/>
   </xs:sequence>
 </xs:complexType>
 
 <xs:complexType name="IRICONST.type" mixed="true">
   <xs:sequence/>
   <xs:attribute name="type" type="xs:anyURI" use="required" fixed="http://www.w3.org/2007/rif#iri"/>
 </xs:complexType>
 
</xs:schema>

9.2 Rule Language

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

<xs:schema 
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 xmlns="http://www.w3.org/2007/rif#"
 targetNamespace="http://www.w3.org/2007/rif#"
 elementFormDefault="qualified"
 version="Id: BLDRule.xsd, v. 1.0, 2008-07-16, dhirtle/hboley">

 <xs:annotation>
   <xs:documentation>
   This is the XML schema for the Rule Language as defined by
   the Last Call Draft of the RIF Basic Logic Dialect.
   
   The schema is based on the following EBNF for the RIF-BLD 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 | 'And' '(' ATOMIC* ')') ':-' FORMULA
 PROFILE   ::= TERM
     
   Note that this is an extension of the syntax for the RIF-BLD Condition Language (BLDCond.xsd).
   </xs:documentation>
 </xs:annotation>

 <xs:include schemaLocation="BLDCond.xsd"/>

 <xs:element name="Document">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
       <xs:element ref="directive" minOccurs="0" maxOccurs="unbounded"/>
       <xs:element ref="payload" minOccurs="0" maxOccurs="1"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:element name="directive">
   <xs:complexType>
     <xs:sequence>
       <xs:element ref="Import"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:element name="payload">
   <xs:complexType>
     <xs:sequence>
       <xs:element ref="Group"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>
 
 <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">
   <xs:complexType>
     <xs:sequence>
       <xs:element name="Const" type="IRICONST.type"/>   
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:element name="profile">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="TERM"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>
 
 <xs:element name="Group">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
       <xs:element ref="sentence" minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:element name="sentence">
  <xs:complexType>
    <xs:choice>
      <xs:group ref="RULE"/>
      <xs:element ref="Group"/>
    </xs:choice>
  </xs:complexType>
</xs:element>
 
 <xs:group name="RULE">
   <xs:choice>
     <xs:element ref="Forall"/>
     <xs:group ref="CLAUSE"/>
   </xs:choice>
 </xs:group>

 <xs:element name="Forall">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
       <xs:element ref="declare" minOccurs="1" maxOccurs="unbounded"/>
       <xs:element name="formula">
         <xs:complexType>
           <xs:group ref="CLAUSE"/>
         </xs:complexType>
       </xs:element>
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:group name="CLAUSE">  
   <xs:choice>
     <xs:element ref="Implies"/>
     <xs:group ref="ATOMIC"/>
   </xs:choice>
 </xs:group>
 
 <xs:element name="Implies">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>
       <xs:element ref="if"/>
       <xs:element ref="then"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>

 <xs:element name="if">
   <xs:complexType>
     <xs:sequence>
       <xs:group ref="FORMULA"/>
     </xs:sequence>
   </xs:complexType>
 </xs:element>
 
 <xs:element name="then">
   <xs:complexType>
    <xs:choice>
      <xs:group ref="ATOMIC"/>
      <xs:element name="And" type="And-then.type"/>
    </xs:choice>
   </xs:complexType>
 </xs:element>

 <xs:complexType name="And-then.type">
   <xs:sequence>
     <xs:element name="formula" type="formula-then.type" minOccurs="0" maxOccurs="unbounded"/>
   </xs:sequence>
 </xs:complexType>

 <xs:complexType name="formula-then.type">
   <xs:sequence>
     <xs:group ref="ATOMIC"/>
   </xs:sequence>
 </xs:complexType>
  
</xs:schema>

10 Appendix: RIF Media Type Registration

The anticipated RIF media type is "application/rif+xml". The draft registration for this media type (pending IETF discussion and approval by the IESG) follows.

   Type name: application

   Subtype name: rif+xml

   Required parameters: none

   Optional parameters: charset, as per RFC 3023 (XML Media Types)

   Encoding considerations: same as RFC 3023 (XML Media Types)

   Security considerations: 

       Systems which consume RIF documents are potentially vulnerable
       to attack by malicious producers of RIF documents.  The
       vulnerabilities and forms of attack are similar to those of
       other Web-based formats with programming or scripting
       capabilities, such as HTML with embedded Javascript.

       Excessive Resource Use / Denial of Service Attacks

          Full and complete processing of a RIF document, even one
          conforming to the RIF-BLD dialect, may require unlimited CPU
          and memory resources.  Through the use of "import", it may
          also require arbitrary URI dereferencing, which may consume
          all available network resources on the consuming system or
          other systems.  RIF consuming systems SHOULD implement
          reasonable defenses against these attacks.

       Exploiting Implementation Flaws

          RIF is a relatively complex format, and rule engines can be
          extremely sophisticated, so it is likely that some RIF
          consuming systems will have bugs which allow specially
          constructed RIF documents to perform inappropriate
          operations. We urge RIF implementors to make systems which
          carefully anticipate and handle all possible inputs,
          including those which present syntactic or semantic errors.

       External (Application) Functions

          Because RIF may be extended with local, application defined
          datatypes and functions, arbitrary vulnerabilities may be
          introduced.  Before being installed on systems which consume
          untrusted RIF documents, these external functions should be
          closely reviewed for their own vulnerabilities and for the
          vulnerabilities that may occur when they are used in
          unexpected combinations, like "cross-site scripting"
          attacks.
       
       In addition, as this media type uses the "+xml" convention, it
       shares the same security considerations as other XML formats;
       see RFC 3023 (XML Media Types).


   Interoperability considerations: 

       This media type is intended to be shared with other RIF
       dialects, to be specified in the future.  Interoperation
       between the dialects is governed by the RIF specifications.

   Published specification: 

       RIF Basic Logic Dialect
       W3C Working Draft (Recommendation Track)
       http://www.w3.org/TR/rif-bld/

       This media type is intended to be shared with other RIF
       dialects, to be specified in the future.

   Applications that use this media type: 

       Unknown at the time of this draft.  Multiple applications are
       expected, however, before the specification reaches W3C
       Proposed Recommendation status.

   Additional information:

     Magic number(s): 

           As with XML in general (See RFC 3023 (XML Media Types)),
           there is no magic number for this format.

           However, the XML namespace "http://www.w3.org/ns/rif" will
           normally be present in the document.  It may theoretically
           be missing if the document uses XML entities in an
           obfuscatory manner.

           The hex form of that namespace will depend on the charset.
           For utf-8, the hex is: 68 74 74 70 3a 2f 2f 77 77 77 2e 77
           33 2e 6f 72.
           
     File extension(s): 

           .rif (or .xml)

     Macintosh file type code(s): 

           "TEXT" (like other XML)

   Person & email address to contact for further information:

       Sandro Hawke, sandro@w3.org.  Please send technical comments
       and questions about RIF to public-rif-comments@w3.org, a
       mailing list a public archive at
       http://lists.w3.org/Archives/Public/public-rif-comments/ 

   Intended usage: 

       COMMON

   Restrictions on usage: 

       None

   Author:

       The editor and contact for this media type registration is
       Sandro Hawke, sandro@w3.org.

   Change controller: 

       RIF is a product of the Rule Interchange Format (RIF) Working
       Group of the World Wide Web Consortium (W3C).  See
       http://www.w3.org/2005/rules/wg for information on the group.
       The W3C (currently acting through this working group) has
       change control over the RIF specification.



   (Any other information that the author deems interesting may be added
   below this line.)