### The Syntax of RIF-BLD as a Specialization of RIF-FLD

This section defines the precise relationship between the syntax of RIF-BLD and the syntactic framework of RIF-FLD. The other sections describe RIF-BLD largely independently of RIF-FLD.

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

*Alphabet*.The alphabet of RIF-BLD is the alphabet of RIF-FLD with the negation symbols

`neg`and`naf`excluded

*Assignment of signatures to each constant symbol*.- The signature set of RIF-BLD contains the following signatures:
`term{ }`,`atomic{ }`,`bi_atomic{ }`, where`bi_atomic`<`atomic`.The signature

`term{ }`represents the context in which individual objects (but not atomic formulas) can appear. The signature`bi_atomic{ }`represents atomic formulas for builtin predicates (such as`fn:substring`). Since`bi_atomic`<`atomic`, builtin atomic formulas are also atomic formulas, but normally most atomic formulas are user-defined and they will have the signature`atomic`rather than`bi_atomic`.

For every integer n ≥ 0, there are signatures

`f`_{n}{(`term`...`term`) ⇒`term`},`p`_{n}{(`term`...`term`) ⇒`atomic`}, and`bi`_{n}{(`term`...`term`) ⇒`bi_atomic`} (in each case there are`n``term`s inside the parentheses). These represent function symbols of arity`n`, user-defined predicate symbols of arity`n`, and`n`-ary builtin predicates, respectively.For every set of symbols

`s1`,...,`sk`∈`SigNames`, there are signatures`f`_{s1...sk}{(`s1->term`...`sk->term`) ⇒`term`} and`p`_{s1...sk}{(`s1->term`...`sk->term`) ⇒`atomic`}. These are signatures for terms with named arguments and predicates with arguments named`s1`, ...,`sk`, respectively.A symbol in

`Const`can have exactly one signature,`term`,`f`_{n},`p`_{n}, or`bi`_{n}, where`n`≥ 0, or`f`_{s1...sk}{(`s1->term`...`sk->term`) ⇒`term`},`p`_{s1...sk}{(`s1->term`...`sk->term`) ⇒`atomic`}, for some`s1`,...,`sk`∈`SigNames`. It cannot have the signature`atomic`or`bi_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.- Thus, in RIF-BLD each constant symbol can be either an individual, a predicate of one particular arity or with certain argument names, a builtin of one particular arity, or a function symbol of one particular arity -- it is not possible for the same symbol to play more than one role.

The constant symbols that correspond to XML Schema data types all have the signature

`term`in RIF-BLD. The symbols of type`rif:iri`and`rif:local`can have the following signatures in RIF-BLD:`term`,`f`_{n},`p`_{n}, or`bi`_{n}, for n = 0,1,....; or`f`_{s1...sk},`p`_{s1...sk}, for some argument names`s1`,...,`sk`∈`SigNames`.All variables are associated with signature

`term{ }`, so they can range only over individuals.The signature for equality is

`={(term term)`⇒`atomic`,`(term term)`⇒`term}`. This means that equality can compare only those terms whose signature is`term`; it cannot compare predicate names or function symbols.The frame signature,

`->`, is`->{(term term term)`⇒`atomic`,`(term term term)`⇒`term}`.The membership signature,

`#`, is`#{(term term)`⇒`atomic`,`(term term)`⇒`term}`.The signature for the subclass relationship is

`##{(term term)`⇒`atomic`,`(term term)`⇒`term}`.

RIF-BLD uses no extra syntax for declaring signatures. Instead, signatures are

*inferred*. Since RIF-BLD requires that each symbol is associated with a unique signature, the signature can be determined from the context in which the symbol is used. If a symbol is used in more than one context, the parser should treat it as a syntax error. If no errors are found, all terms and atomic formulas are guaranteed to be well-formed. As a consequence, signatures are*not*part of the RIF-BLD language and`term`,`atomic`, and`bi_atomic`are not reserved keywords in RIF-BLD.

- The signature set of RIF-BLD contains the following signatures:
*Supported types of terms*.RIF-BLD supports all the term types defined by the syntactic framework (see Well-formed Terms and Formulas):

- constants
- variables
- positional
- with named arguments
- equality
- frame
- membership
- subclass

- The signature for the variable symbols does not permit them to occur in the context of predicates, functions, or formulas. In particular, unlike in RIF-FLD, a variable is not an atomic formula in RIF-BLD.
Likewise, a symbol cannot be an atomic formula by itself. That is, if

`p`∈`Const`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

`term{ }`and all other terms, except for the constants from`Const`, can have either the signature`term{ }`or`atomic{ }`. Therefore, if`t`is a (non-`Const`) term then`t(...)`is not a well-formed term.

*Supported symbol spaces*.RIF-BLD supports all the symbol spaces defined in Section Symbol Spaces of the syntactic framework:

`xsd:string``xsd:decimal``xsd:time``xsd:date``xsd:dateTime``rdf:XMLLiteral``rif:text``rif:iri``rif:local`

*Supported formulas*.RIF-BLD supports the following types of formulas (see Well-formed Terms and Formulas for the definitions):

**RIF-BLD condition**- A RIF-BLD condition is a conjunctive and disjunctive combination of atomic formulas with optional existential quantification of variables.

**RIF-BLD rule**- A RIF-BLD rule is a RIF-FLD rule with the following restrictions:
The head (or conclusion) of the rule is an atomic formula, which is not a builtin predicate (i.e., its signature is

`atomic`, but not`bi_atomic`).- The body (or premise) of the rule is a RIF-BLD condition.
The free variables in the rule can be optionally quantified with

`Forall`outside of the rule (i.e.,`Forall ?vars (head :- body)`).

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

In order to make this document self-contained, we will now define the syntax of RIF-BLD with no references to RIF-FLD -- except for Symbol Spaces whose definition we do not duplicate here.

### Alphabet of RIF-BLD

The * alphabet* 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`and

`Or`, quantifiers

`Exists`and

`Forall`, the symbols

`=`,

`#`,

`##`,

`->`,

`:-`, and auxiliary symbols, such as "(" and ")". The set of connective symbols, quantifiers,

`=`, etc., is disjoint from

`Const`and

`Var`. Variables are written as Unicode strings preceded with the symbol "?". The syntax for constant symbols is given in Section Symbol Spaces of RIF-FLD.

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

### Terms

RIF-BLD supports several kinds of terms: *constants* and *variables*, *positional* terms, terms with *named arguments*, *equality*, *membership*, and *subclass* terms, and *frames*. The word "*term*" will be used to refer to any kind of terms. Formally, terms are defined as follows:

*Constants and variables*. If`t`∈`Const`or`t`∈`Var`then`t`is a.**simple term***Positional terms*. If`t`∈`Const`and`t`_{1}, ...,`t`_{n}are terms then`t(t`_{1}...`t`_{n}`)`is a.**positional term***Terms with named arguments*. A(a term with named arguments) is of the form**term with named arguments**`t(s`_{1}`->v`_{1}...`s`_{n}`->v`_{n}`)`, where`t`∈`Const`,`v`_{1}, ...,`v`_{n}are terms (positional, with named arguments, frame, etc.), and`s`_{1}, ...,`s`_{n}are (not necessarily distinct) symbols from the set`ArgNames`. The term`t`here represents a predicate or a function;`s`_{1}, ...,`s`_{n}represent argument names; and`v`_{1}, ...,`v`_{n}represent argument values. Terms with named arguments are like positional terms except that the arguments are named and their order is immaterial. Note that a term like f() is both positional and with named arguments.*Equality terms*. If`t`and`s`are terms then`t = s`is an.**equality term***Class membership terms*(or just*membership terms*).`t#s`is aif**membership term**`t`and`s`are arbitrary terms.*Subclass terms*.`t##s`is aif**subclass term**`t`and`s`are arbitrary terms.*Frame terms*.`t[p`_{1}`->v`_{1}...`p`_{n}`->v`_{n}`]`is a(or simply a**frame term**) if**frame**`t`,`p`_{1}, ...,`p`_{n},`v`_{1}, ...,`v`_{n}, n ≥ 0, are arbitrary terms.Membership, subclass, and frame terms are used to describe objects in object-based logics like F-logic [KLW95]. These terms can be readily mixed both with positional terms and terms with named arguments:

`p(?X q#r[v(1,2)->s] t(d->e f->g))`.

### Well-formedness

The set of all symbols, `Const`, is partitioned into positional predicate symbols, predicate symbols with named arguments, positional function symbols, function symbols with named arguments, and individuals. Each positional predicate and function symbol has precisely one * arity*, which is a non-negative integer that tells how many arguments the symbol can take. An

*(of a symbol with named arguments) is a bag*

**arity for terms with named arguments**`{s`

_{1}...

`s`

_{k}

`}`of argument names (

`s`

_{i}∈

`ArgNames`). Each predicate or function symbol with named arguments has precisely one arity (for terms with named arguments).

The arity of a symbol (or whether it is a predicate, a function, or an individual) is not specified explicitly in RIF-BLD. Instead, it is inferred as follows. Each constant symbol in a RIF-BLD formula (or a set of formulas) is expected to occur in at most one context: as an individual, a function symbol of a particular arity, a predicate symbol of a particular arity, or an individual. The arity of the symbol and its type is then determined by its context. If a symbol from `Const` occurs in more than one context, the formula (or a set of formulas) is not considered to be well-formed in RIF-BLD.

### 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 formula. Simple terms (constants and variables) are

*not*formulas. Not all atomic formulas are well-formed -- see Section Well-formedness. A

*is an atomic formula that is also a well-formed term.*

**well-formed atomic formula**More general formulas are constructed out of the atomic formulas with the help of logical connectives. A * formula* is a statement that can have one of the following forms:

*Atomic*: If φ is a well-formed atomic formula then it is also a formula.*Conjunction*: If φ_{1}, ..., φ_{n},`n`≥ 0, are formulas then so is`And(`φ_{1}... φ_{n}`)`. 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 formulas then so is`Or(`φ_{1}... φ_{n}`)`. When`n=0`, we get`Or()`as a special case; it is treated as a formula that is always false.*Existentials*: If φ is a formula and`?V`_{1}, ...,`?V`_{n}are variables then`Exists``?V`_{1}...`?V`_{n}`(`φ`)`is a formula.

Formulas constructed using the above definitions are called * RIF-BLD conditions*.

*are defined as follows:*

**RIF-BLD rules***Rule*: If φ is an atomic formula and ψ is a RIF-BLD condition then φ`:-`ψ is a formula, provided that φ*does not*have the signature`bi_atomic`(i.e., is not a builtin predicate).*Universals*: If φ is a rule and`?V`_{1}, ...,`?V`_{n}are variables then`Forall``?V`_{1}...`?V`_{n}`(`φ`)`is a formula, called an.**explicitly quantified rule**

### EBNF Grammar for the Presentation Syntax of RIF-BLD

So far, the syntax of RIF-BLD was specified in Mathematical English. Tool developers, however, prefer the more formal EBNF notation, which we will give next. 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 well-formedness conditions, i.e., the requirement that each symbol in RIF-BLD can occur in at most one context. As a result, the grammar, below, defines only a superset of RIF-BLD.

The EBNF syntax is

*not a concrete*syntax: it does not address the details of how constants and variables are represented, and it is not sufficiently precise about the delimiters and escape symbols. Instead, white space is informally used as a delimiter, and white space 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 done on purpose, since RIF's presentation syntax is intended as 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 EBNF syntax.

#### EBNF for RIF-BLD Condition Language

The Condition Language represents formulas that can be used in the body of the RIF-BLD rules. It is supposed to be a common part of a number of RIF dialects, including RIF PRD. The EBNF grammar for a superset of the RIF-BLD condition language is as follows.

CONDITION ::= 'And' '(' CONDITION* ')' | 'Or' '(' CONDITION* ')' | 'Exists' Var+ '(' CONDITION ')' | COMPOUND COMPOUND ::= Uniterm | Equal | Member | Subclass | Frame Uniterm ::= Const '(' (TERM* | (Const '->' TERM)*) ')' Equal ::= TERM '=' TERM Member ::= TERM '#' TERM Subclass ::= TERM '##' TERM Frame ::= TERM '[' (TERM '->' TERM)* ']' TERM ::= Const | Var | COMPOUND Const ::= LITERAL '^^' SYMSPACE Var ::= '?' VARNAME

The production rule for the non-terminal `CONDITION` 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 `CONDITION`. RIF-BLD conditions permit only existential variables, but RIF-FLD syntax allows arbitrary quantification, which can be used in some dialects. A `CONDITION` can also be a `COMPOUND` term, i.e. a `Uniterm`, `Equal`, `Member`, `Subclass`, or `Frame`. The production for the non-terminal `TERM` defines RIF-BLD terms -- constants, variables, or `COMPOUND` terms.

The RIF-BLD presentation syntax does not commit to any particular vocabulary for the names of variables or for the literals used in constant symbols. In the examples, variables are denoted by Unicode character sequences beginning with a ?-sign. Constant symbols have the form: `LITERAL^^SYMSPACE`, where `SYMSPACE` is an IRI string that identifies the symbol space of the constant and `LITERAL` is a Unicode string from the lexical space of that symbol space. Equality, membership, and subclass terms are self-explanatory. Uniterms (*Universal terms*) are terms that can be either positional or with named arguments. A frame term is a term composed of an object Id and a collection of attribute-value pairs.

Example 1 shows conditions that are composed of uniterms, frames, and existentials. The examples of the frames show that variables can occur in the syntactic positions of object Ids, object properties, or property values.

Example 1 (RIF-BLD conditions) We use the prefix bks to abbreviate http://example.com/books# and the prefix auth for http://example.com/authors#. Positional terms: book^^rif:local(auth:rifwg^^rif:iri bks:LeRif^^rif:iri) Exists ?X (book^^rif:local(?X LeRif^^rif:local)) Terms with named arguments: book^^rif:local(author^^rif:local->auth:rifwg^^rif:iri title^^rif:local->bks:LeRif^^rif:iri) Exists ?X (book^^rif:local(author^^rif:local->?X title^^rif:local->bks:LeRif^^rif:iri)) Frames: wd1^^rif:local[author^^rif:local->auth:rifwg^^rif:iri title^^rif:local->bks:LeRif^^rif:iri ] Exists ?X (wd2^^rif:local[author^^rif:local->?X title^^rif:local->bks:LeRif^^rif:iri ]) Exists ?X (wd2^^rif:local#book^^rif:local[author^^rif:local->?X title^^rif:local->bks:LeRif^^rif:iri]) Exists ?I ?X (?I[author^^rif:local->?X title^^rif:local->bks:LeRif^^rif:iri]) Exists ?I ?X (?I#book^^rif:local[author^^rif:local->?X title^^rif:local->bks:LeRif^^rif:iri]) Exists ?S (wd2^^rif:local[author^^rif:local->auth:rifwg^^rif:iri ?S->bks:LeRif^^rif:iri]) Exists ?X ?S (wd2^^rif:local[author^^rif:local->?X ?S->bks:LeRif^^rif:iri]) Exists ?I ?X ?S (?I#book^^rif:local[author->?X ?S->bks:LeRif^^rif:iri])

#### EBNF for RIF-BLD Rule Language

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

Ruleset ::= RULE* RULE ::= 'Forall' Var+ '(' RULE ')' | Implies | COMPOUND Implies ::= COMPOUND ':-' CONDITION

A `Ruleset` is a set of RIF rules. Rules are generated by the `Implies` production, with optional `Forall`-quantification. `Var`, `COMPOUND`, and `CONDITION` were defined as part of the syntax for positive conditions in Section EBNF for RIF-BLD Condition Language. Note that `COMPOUND` terms are treated as rules with an empty condition part -- they are usually called *facts*. Note that, by a definition in Section Formulas, atomic formulas that correspond to builtin predicates (i.e., formulas with signature `bi_atomic`) are not allowed in the conclusion part of a rule. This restriction is not reflected in the EBNF syntax.

The document RIF Use Cases and Requirements includes a use case "Negotiating eBusiness Contracts Across Rule Platforms", which discusses a business rule slightly modified here:

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.

In the Presentation EBNF Syntax used throughout this document, this rule can be written in one of these two equivalent ways:

Example 2 (RIF-BLD rules) Here we use the prefix ppl as an abbreviation for http://example.com/people#. The prefix op is used for a yet-to-be-determined IRI, which will be used for RIF builtin predicates. a. Universal form: Forall ?item ?deliverydate ?scheduledate ?diffduration ?diffdays ( reject^^rif:local(ppl:John^^rif:iri ?item) :- And(perishable^^rif:local(?item) delivered^^rif:local(?item ?deliverydate ppl:John^^rif:iri) scheduled^^rif:local(?item ?scheduledate) fn:subtract-dateTimes-yielding-dayTimeDuration(?deliverydate ?scheduledate ?diffduration) fn:get-days-from-dayTimeDuration(?diffduration ?diffdays) op:numeric-greater-than(?diffdays 10)) ) b. Universal-existential form: Forall ?item ( reject^^rif:local(ppl#John^^rif:iri ?item ) :- Exists ?deliverydate ?scheduledate ?diffduration ?diffdays ( And(perishable^^rif:local(?item) delivered^^rif:local(?item ?deliverydate ppl:John^^rif:iri) scheduled^^rif:local(?item ?scheduledate) fn:subtract-dateTimes-yielding-dayTimeDuration(?deliverydate ?scheduledate ?diffduration) fn:get-days-from-dayTimeDuration(?diffduration ?diffdays) op:numeric-greater-than(?diffdays 10)) ) )

### XML Serialization for the Interchange of RIF-BLD

The XML serialization for RIF-BLD presentation syntax given in this section is *alternating* or *fully striped* (e.g., Alternating Normal Form). Positional information is optionally exploited only for the `arg` role elements. For example, role elements (`declare` and `formula`) are explicit within the `Exists` element. Following the examples of Java and RDF, we use capitalized names for class elements and names that start with lowercase for role elements.

The all-uppercase classes in the presentation syntax, such as `CONDITION`, become XML entities. 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.

#### XML for RIF-BLD Condition Language

We now serialize the syntax of Section EBNF for RIF-BLD Condition Language in XML.

Classes, roles and their intended meaning - 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 CONDITION formula) - Uniterm (term or atomic formula, positional or with named arguments) - Member (member formula) - Subclass (subclass formula) - Frame (Frame formula) - object (Member/Frame role containing a TERM or an object description) - op (Uniterm role for predicates/functions as operations) - arg (argument role) - upper (Member/Subclass upper class role) - lower (Member/Subclass lower instance/class role) - slot (Uniterm/Frame slot role, prefix version of slot infix ' -> ') - Equal (prefix version of term equation '=') - side (Equal left-hand side and right-hand side role) - Const (slot, individual, function, or predicate symbol, with optional 'type' attribute) - Var (logic variable)

For the XML Schema Definition (XSD) of the RIF-BLD condition language see Appendix Specification.

The XML syntax for symbol spaces utilizes the `type` attribute associated with XML term elements such as `Const`. For instance, a literal in the `xsd:dateTime` data type can be represented as `<Const type="xsd:dateTime">2007-11-23T03:55:44-02:30</Const>`.

The following example illustrates XML serialization of RIF conditions.

Example 3 (A RIF condition and its XML serialization): We use the prefix bks as an abbreviation for http://example.com/books# and curr for http://example.com/currencies# a. RIF condition And ( Exists ?Buyer ( purchase^^rif:local ( ?Buyer ?Seller book^^rif:local ( ?Author bks:LeRif^^rif:iri ) curr:USD^^rif:iri ( 49^^xsd:integer ) ) ?Seller=?Author ) b. XML serialization <And> <formula> <Exists> <declare><Var>Buyer</Var></declare> <formula> <Uniterm> <op><Const type="rif:local">purchase</Const></op> <arg><Var>Buyer</Var></arg> <arg><Var>Seller</Var></arg> <arg> <Uniterm> <op><Const type="rif:local">book</Const></op> <arg><Var>Author</Var></arg> <arg><Const type="rif:iri">bks:LeRif</Const></arg> </Uniterm> </arg> <arg> <Uniterm> <op><Const type="rif:iri">curr:USD</Const></op> <arg><Const type="xsd:integer">49</Const></arg> </Uniterm> </arg> </Uniterm> </formula> </Exists> </formula> <formula> <Equal> <side><Var>Seller</Var></side> <side><Var>Author</Var></side> </Equal> </formula> </And>

The following example illustrates XML serialization of RIF conditions that involve terms with named arguments.

Example 4 (A RIF condition and its XML serialization): We use the prefix bks to abbreviate http://example.com/books#, the prefix auth for http://example.com/authors#, and curr for http://example.com/currencies#, a. RIF condition: And ( Exists ?Buyer ?P ( ?P # purchase^^rif:local [ buyer^^rif:local -> ?Buyer seller^^rif:local -> ?Seller item^^rif:local -> book^^rif:local ( author^^rif:local -> ?Author title^^rif:local -> bks:LeRif^^rif:iri ) price^^rif:local -> 49^^xsd:integer currency^^rif:local -> curr:USD^^rif:iri ] ) ?Seller=?Author ) b. XML serialization: <And> <formula> <Exists> <declare><Var>Buyer</Var></declare> <declare><Var>P</Var></declare> <formula> <Frame> <object> <Member> <lower><Var>P</Var></lower> <upper><Const type="rif:local">purchase</Const></upper> </Member> </object> <slot><Const type="rif:local">buyer</Const><Var>Buyer</Var></slot> <slot><Const type="rif:local">seller</Const><Var>Seller</Var></slot> <slot> <Const type="rif:local">item</Const> <Uniterm> <op><Const type="rif:local">book</Const></op> <slot><Const type="rif:local">author</Const><Var>Author</Var></slot> <slot><Const type="rif:local">title</Const><Const type="rif:iri">bks:LeRif</Const></slot> </Uniterm> </slot> <slot><Const type="rif:local">price</Const><Const type="xsd:integer">49</Const></slot> <slot><Const type="rif:local">currency</Const><Const type="rif:iri">curr:USD</Const></slot> </Frame> </formula> </Exists> </formula> <formula> <Equal> <side><Var>Seller</Var></side> <side><Var>Author</Var></side> </Equal> </formula> </And>

#### XML for RIF-BLD Rule Language

The following extends the XML syntax in Section XML for RIF-BLD Condition Language, by serializing the syntax of Section EBNF for RIF-BLD Rule Language in XML. The `Forall` element contains the role elements `declare` and `formula`, which were earlier used within the `Exists` element in Section XML for RIF-BLD Condition Language. The `Implies` element contains the role elements `if` and `then` to designate these two parts of a rule.

Classes, roles and their intended meaning - Ruleset (rule collection, containing rule roles) - Forall (quantified formula for 'Forall', containing declare and formula roles) - Implies (implication, containing if and then roles) - if (antecedent role, containing CONDITION) - then (consequent role, containing a Uniterm, Equal, or Frame)

For the XML Schema Definition (XSD) of the RIF-BLD Horn rule language see Appendix Specification.

For instance, the rule in Example 5a can be serialized in XML as shown below as the first element of a rule set whose second element is a business rule for Fred.

Example 5 (A RIF rule set in XML syntax) <Ruleset> <rule> <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> <Uniterm> <op><Const type="rif:local">perishable</Const></op> <arg><Var>item</Var></arg> </Uniterm> </formula> <formula> <Uniterm> <op><Const type="rif:local">delivered</Const></op> <arg><Var>item</Var></arg> <arg><Var>deliverydate</Var></arg> <arg><Const type="rif:iri">ppl:John</Const></arg> </Uniterm> </formula> <formula> <Uniterm> <op><Const type="rif:local">scheduled</Const></op> <arg><Var>item</Var></arg> <arg><Var>scheduledate</Var></arg> </Uniterm> </formula> <formula> <Uniterm> <op><Const type="rif:local">fn:subtract-dateTimes-yielding-dayTimeDuration</Const></op> <arg><Var>deliverydate</Var></arg> <arg><Var>scheduledate</Var></arg> <arg><Var>diffduration</Var></arg> </Uniterm> </formula> <formula> <Uniterm> <op><Const type="rif:local">fn:get-days-from-dayTimeDuration</Const></op> <arg><Var>diffduration</Var></arg> <arg><Var>diffdays</Var></arg> </Uniterm> </formula> <formula> <Uniterm> <op><Const type="rif:iri">op:numeric-greater-than</Const></op> <arg><Var>diffdays</Var></arg> <arg><Const type="xsd:long">10</Const></arg> </Uniterm> </formula> </And> </if> <then> <Uniterm> <op><Const type="xsd:long">reject</Const></op> <arg><Const type="rif:iri">ppl:John</Const></arg> <arg><Var>item</Var></arg> </Uniterm> </then> </Implies> </formula> </Forall> </rule> <rule> <Forall> <declare><Var>item</Var></declare> <formula> <Implies> <if> <Uniterm> <op><Const type="rif:local">unsolicited</Const></op> <arg><Var>item</Var></arg> </Uniterm> </if> <then> <Uniterm> <op><Const type="rif:local">reject</Const></op> <arg><Const type="rif:iri">ppl:Fred</Const></arg> <arg><Var>item</Var></arg> </Uniterm> </then> </Implies> </formula> </Forall> </rule> </Ruleset>

### Translation Between the RIF-BLD Presentation and XML Syntaxes

We now show how to translate between the presentation and XML syntaxes of RIF-BLD.

#### Translation of RIF-BLD Condition Language

The translation between the presentation syntax and the XML syntax of the RIF-BLD Condition Language is given by a table as follows.

Presentation Syntax | XML Syntax |
---|---|

And ( | <And> <formula> |

Or ( | <Or> <formula> |

Exists | <Exists> <declare> |

| <Uniterm> <op> |

| <Uniterm> <op> |

| <Frame> <object> |

| <Frame> <object> <Member> <lower> |

| <Frame> <object> <Subclass> <lower> |

| <Member> <lower> |

| <Subclass> <lower> |

| <Equal> <side> |

| <Const type=" |

? | <Var> |

#### Translation of RIF-BLD Rule Language

The translation between the presentation syntax and the XML syntax of the RIF-BLD Rule Language is given by a table that extends the translation table of Section Translation of RIF-BLD Condition Language as follows.

Presentation Syntax | XML Syntax |
---|---|

Ruleset ( | <Ruleset> <rule> |

Forall | <Forall> <declare> |

| <Implies> <if> |

### Subdialects of RIF-BLD

*** This is a proposal to specify RIF-CORE etc. by just removing syntactic constructs from RIF-BLD (hence, through The effect of the syntax, restricting the semantics). The point is that it makes more sense for most engines to support only some subdialects of BLD, and that subdialects and fragments of BLD are reused in the definition of other RIF dialects. *** |

The syntactic structure of RIF-BLD suggests several useful subdialects:

**RIF-CORE**. This subdialect is obtained from RIF-BLD by removing support for:- equality formulas in the rule conclusions (while still allowing them in conditions)
- terms with named arguments
- ??? membership, subclass, and frame terms ???

**RIF-CORE+equality**.- This subdialect extends RIF-CORE by adding support for equality formulas in the rule conclusions.

**RIF-CORE+named arguments**.- This subdialect extends RIF-CORE by adding syntactic support for terms with named arguments.

*** If frames are not included in RIF-CORE / RIF-CORECOND then extensions of RIF-CORE / RIF-CORECOND with frames are added here. |