RIF Basic Logic Dialect

This documentspecification 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 (see Horn Logic) with equality and with a standard first-order semantics. 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 data types. In addition, the document RIF RDF and OWL Compatibility 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 specialization of the RIF Framework for Logic-based Dialects (RIF-FLD), which is part of the RIF extensibility framework.

  This version of the RIF-BLD specification is very short and is presented at the end of this document, in Section RIF-BLD as a Specialization of the RIF Framework. It is intended for the reader who is familiar with RIF-FLD and, therefore, does not need to go through the much longer direct specification of RIF-BLD. This version of the specification 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.

• Independently of the RIF framework for logic dialects, for the benefit of those who desire a quicker path to RIF-BLD, e.g. as prospective implementers, and are not interested in the extensibility issues. This version of the RIF-BLD specification is given first.

Logic-based RIF dialects that extend RIF-BLD in accordance with the RIF Framework for Logic Dialects will be specifieddeveloped in other documentsspecifications by this 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).

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

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.

This normative section specifies the syntax of RIF-BLD directly, without relying on RIF-FLD. We define both the presentation syntax and an XML syntax. The presentation syntax is normative, but not intended to be a concrete syntax for RIF-BLD. It is defined in mathematical English and is meant to be used in the definitions and examples. 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. Note to the reader: this sectionsyntax 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 Data Types of the document Data Types and BuiltinsBuilt-Ins, Version 1.0.

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 the document Data Types and BuiltinsBuilt-Ins, Version 1.0.

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 builtin) and the symbols Prefix and Base are used in abridged representations of IRIs.

The symbol Document is used to definespecify 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.

1. Constants and variables. If t ∈ Const or t ∈ Var then t is a simple term.
2. Positional terms. If t ∈ Const and t₁, ..., t_n are base terms then t(t₁ ... t_n) is a positional term.
3. Terms with named arguments. A term with named arguments is of the form t(s₁->v₁ ... s_n->v_n), where t ∈ Const and v₁, ..., v_n are base terms and s₁, ..., s_n are pairwise distinct symbols from the set ArgNames.

   The constant t here represents a predicate or a function; s₁, ..., s_n represent argument names; and v₁, ..., v_n represent argument values. The argument names, s₁, ..., s_n, 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 both positional and with named arguments.

4. Equality terms. If t and s are base terms then t = s is an equality term.
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[p₁->v₁ ... p_n->v_n] is a frame term (or simply a frame) if t, p₁, ..., p_n, v₁, ..., v_n, 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 builtin 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/acme/president"^^rif:iri(?Year)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 inof 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, p₁, ..., p_n, 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 integral part of many inference rules underlying first-order logic.

For a term of the form External(t) to be well-formed, t must be an instance of an external schema, i.e., a schema of an externally specified term, as defined in Section Schemas for Externally Defined Terms of the document Data Types and BuiltinsBuilt-Ins, Version 1.0.

Also, if a term of the form External(p(...)) occurs as an atomic formula then p is considered a predicate symbol.

A well-formed term is one that occurs in a well-formed set of fomulas.

Simple terms (constants and variables) are not formulas. Not all atomic formulas are well-formed. A well-formed atomic formula is an atomic formula that is also a well-formed term (see Section Well-formedness of Terms). More general formulas are constructed out of the atomic formulas with the help of logical connectives.

Definition (Well-formed formula). A well-formed formula is a statement that has one of the following forms:

• Atomic: If φ is a well-formed atomic formula then it is also a well-formed formula.
• Condition formula: A condition formula is either an atomic formula or a formula that has one of the following forms:
  • Conjunction: If φ₁, ..., φ_n, n ≥ 0, are well-formed condition formulas then so is And(φ₁ ... φ_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 φ₁, ..., φ_n, n ≥ 0, are well-formed condition formulas then so is Or(φ₁ ... φ_n), called a disjunctive formula. When n=0, we get Or() as a special case; it is treated as a contradiction, i.e., a formula that is always false.
  • Existentials: If φ is a well-formed condition formula and ?V₁, ..., ?V_n are variables then Exists ?V₁ ... ?V_n(φ) is an existential formula.

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

• Rule implication: φ :- ψ is a well-formed formula, called rule implication, if:
  • φ is a well-formed atomic formula or a conjunction of well-formed 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.

• Quantified rule: If φ is a rule implication and ?V₁, ..., ?V_n are variables then Forall ?V₁ ... ?V_n(φ) is a well-formed formula, called quantified rule. It is required that all the free (i.e., non-quantified) variables in φ occur in the prefix Forall ?V₁ ... ?V_n. Quantified rules will also be referred to as RIF-BLD rules.
• Group: If ρ₁, ..., ρ_n are RIF-BLD rules or well-formed group formulas (they can be mixed) then Group(ρ₁ ... ρ_n) is a well-formed group formula.

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

• Document: An expression of the form Document(directive₁ ... directive_n Γ) is a well-formed RIF-BLD document formula ,(or simply a document formula), if
  • Γ is a well-formed group formula that makes the actual logical content of the document.
  • directive₁, ..., directive_n are directives. A directive can be an import directive, a prefix directive, or a base directive.
  • • 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 the document RIF RDF and OWL Compatibility. 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 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.

      Prefix directives do not affect the semantics of RIF documents. Instead, they are used as shorthands to allow more concise representation of IRI constants. This mechanism is explained in the document Data Types and BuiltinsBuilt-Ins, Version 1.0, Section Constants and Symbol Spaces.

    • A base directive has the form Base(iri), where iri is a unicode string in the form of an IRI.

      Like prefix directives, base directives do not affect the semantics. They are used as syntactic shortcuts for expanding relative IRIs into full IRIs, as described in Section Constants and Symbol Spaces of the document Data Types and BuiltinsBuilt-Ins, Version 1.0.

  • All parts of a document formula -- the directives and the group formula -- are optional and can be omitted.   ☐

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 them into the predicate name. For instance, p(bb->1 aa->2) can be represented as p_aa_bb(2,1).

It is suggested to use Dublin Core, RDFS, and OWL properties for metadata, along the lines of http://www.w3.org/TR/owl-ref/#Annotations -- specifically owl:versionInfo, rdfs:label, rdfs:comment, rdfs:seeAlso, rdfs:isDefinedBy, dc:creator, dc:description, dc:date, and foaf:maker.

• 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 rules that are derivable using the EBNF grammar are well-formed rules in RIF-BLD).
• The EBNF grammar 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 the 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 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. (The non-normative status of the EBNF grammer should not be confused with the normative status of the RIF-BLD presentation syntax.)

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

The optional annotations, IRIMETA, for identification and metadata, will be further explained in Section EBNF for RIF-BLD Rule Language. 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 have the form: "UNICODESTRING"^^SYMSPACE, where SYMSPACE is a Unicode string that represents an identifier or an alias of the symbol space of the constant, and UNICODESTRING is a Unicode string from the lexical space of that symbol space. Shortcuts for constants are defined in Section Shortcuts for Constants in RIF's Presentation Syntax of the document Data Types and Built-Ins, Version 1.0. Names are denoted by Unicode character sequences. Variables are denoted by a UNICODESTRING 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.

Example 12 (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 shortcut notation prefix:suffix, which should beis 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 the document Data Types and BuiltinsBuilt-Ins, Version 1.0. 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]))

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' '(' DIRECTIVE* Group? ')'
  DIRECTIVE ::= Import | Prefix | Base
  Import    ::= IRIMETA? 'Import' '('  IRIIRICONST Profile? ')'
  Prefix    ::= 'Prefix' '(' Name IRI ')'
  Base      ::= 'Base' '(' IRI ')'
  Group     ::= IRIMETA? 'Group' '(' (RULE | Group)* ')'
  RULE      ::=  IRIMETA?(IRIMETA? 'Forall' Var+ '(' CLAUSE  ')'')') | CLAUSE
  CLAUSE    ::= Implies | ATOMIC
  Implies   ::= IRIMETA?  ATOMIC(ATOMIC | 'And' '(' ATOMIC* ')') ':-' FORMULA
  IRICONST  ::= '"' IRI '"^^' 'rif:iri'
  Profile   ::= UNICODESTRING

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

IRI ::= UNICODESTRING PROFILE ::= UNICODESTRINGFor convenient reference,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' '('  ATOMICAtom | Frame ')'
  ATOMIC         ::=  AtomIRIMETA? (Atom | Equal | Member | Subclass |  FrameFrame)
  Atom           ::= UNITERM
  UNITERM        ::= Const '(' (TERM* | (Name '->' TERM)*) ')'
  Equal          ::= TERM '=' TERM
  Member         ::= TERM '#' TERM
  Subclass       ::= TERM '##' TERM
  Frame          ::= TERM '[' (TERM '->' TERM)* ']'
  TERM           ::=  ConstIRIMETA? (Const | Var | Expr | 'External' '(' Expr  ')'')')
  Expr           ::= UNITERM
  Const          ::= '"' UNICODESTRING '"^^' SYMSPACE
  Name           ::= UNICODESTRING
  Var            ::= '?' UNICODESTRING
  SYMSPACE       ::= UNICODESTRING

AAs explained in Section RIF-BLD Document , GroupAnnotations in the Presentation Syntax, etc.RIF-BLD formulas and terms can be prefixed with optional identifier-metadataannotations, IRIMETA ., for identification and metadata. IRIMETA is represented using (*...*)-brackets that contain an optional ConstIRI constant as identifier followed by an optional Frame or conjunction of Frames as metadata. An IRI has the form of an internationalized resource identifier as defined by [RFC-3987].

A RIF-BLD Document consists of an optional DIRECTIVE preamble and an optional Group main part. A DIRECTIVE can be any number of Imports, Prefixes, or Base s.s, the latter two just serving as shortcut mechanisms for (long) IRIs. A RIF-BLD Group is a nested collection of any number of RULEs along with any number of nested Groups.

Rules are generated by CLAUSE, which can be in the scope of a Forall quantifier. If a CLAUSE in the RULE production has a free (non-quantified) variable, it must occur in the Var+ sequence. 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 productionproduction, an ATOMIC is treated as a rule with an empty condition part -- in which case itwhat is usually called a fact. An Implies rule can have an ATOMIC or a conjunction of ATOMICs as conclusion; it has a FORMULA as 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 23 (RIF-BLD rules).

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

As before, for better readability we use the compact URI notation defined in [[DTB|DataData Types and Builtins,Built-Ins, Version 1.0, 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(opPrefix(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)
                 External(fn:subtract-dateTimes-yielding-dayTimeDuration(?deliverydate ?scheduledate ?diffduration)) External(fn:get-days-from-dayTimeDuration(?diffduration ?diffdays)) External(op:numeric-greater-than(?diffdays?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)
                      External(fn:subtract-dateTimes-yielding-dayTimeDuration(?deliverydate ?scheduledate ?diffduration)) External(fn:get-days-from-dayTimeDuration(?diffduration ?diffdays)) External(op:numeric-greater-than(?diffdays?diffduration = External(func:subtract-dateTimes(?deliverydate ?scheduledate))
                     ?diffdays = External(func:days-from-duration(?diffduration))
                     External(pred:numeric-greater-than(?diffdays 10)))
            )
   )

Example 34 (A RIF-BLD document containing a groupan annotated with metadata).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 2a.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(w3 http://www.w3.org/) Prefix(opPrefix(func http://www.w3.org/2007/rif-builtin-function#)
  Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
   Prefix(xsdPrefix(xs   http://www.w3.org/2001/XMLSchema#)
  
  (*  <http://sample.org>"http://sample.org"^^rif:iri pd[dc:publisher ->  w3:W3Chttp://www.w3.org/
                                     dc:date ->  "2008-04-04"^^xsd: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)
                 External(fn:subtract-dateTimes-yielding-dayTimeDuration(?deliverydate ?scheduledate ?diffduration)) External(fn:get-days-from-dayTimeDuration(?diffduration ?diffdays)) External(op:numeric-greater-than(?diffdays?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)
    )
  )
)

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. The semantics, below, is described using the full syntax, i.e., the description assumes that all macros have already been expanded as explained in Data Types and BuiltinsBuilt-Ins, Version 1.0, Section Constants and Symbol Spaces.

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.

Definition (Semantic structure). A semantic structure, I, is a tuple of the form <TV, DTS, D, D_ind, D_func, I_C, I_V, I_F, I_frame, I_SF, I_sub, I_isa, I₌, I_external, I_truth>. Here D is a non-empty set of elements called the domain of I, and D_ind, D_func are nonempty subsets of D. D_ind is used to interpret the elements of Const, which denote individuals and D_func is used to interpret the elements of Const, which denote 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 data types (please refer to Section Data Types of the document Data Types and BuiltinsBuilt-Ins, Version 1.0 for the semantics of data types).

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

1. I_C maps Const to D.

   This mapping interprets constant symbols. In addition:

2. • If a constant, c ∈ Const, denotes an individual then it is required that I_C(c) ∈ D_ind.
   • If c ∈ Const, denotes a function symbol (positional or with named arguments) then it is required that I_C(c) ∈ D_func.
3. I_V maps Var to D_ind.

   This mapping interprets variable symbols.

4. I_F maps D to functions D*_ind → D (here D*_ind is a set of all sequences of any finite length over the domain D_ind)

   This mapping interprets positional terms. In addition:

5. • If d ∈ D_func then I_F(d) must be a function D*_ind → D_ind.
   • This means that when a function symbol is applied to arguments that are individual objects then the result is also an individual object.
6. I_SF maps D to the set of total functions of the form SetOfFiniteSets(ArgNames × D_ind) → D.

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

7. • If d ∈ D_func then I_SF(d) must be a function SetOfFiniteSets(ArgNames × D_ind) → D_ind.
   • This is analogous to the interpretation of positional terms with two differences:
   • • Each pair <s,v> ∈ ArgNames × D_ind 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.
8. I_frame maps D_ind to total functions of the form SetOfFiniteBags(D_ind × D_ind) → D.

   This mapping interprets frame terms. An argument, d ∈ D_ind, to I_frame represent an object and the finite bag {<a1,v1>, ..., <ak,vk>} represents a bag of attribute-value pairs for d. We will see shortly how I_frame 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.

9. I_sub gives meaning to the subclass relationship. It is a mapping of the form D_ind × D_ind → D.

   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.

10. I_isa gives meaning to class membership. It is a mapping of the form D_ind × D_ind → D.

    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.

11. I₌ is a mapping of the form D_ind × D_ind → D.

    It gives meaning to the equality operator.

12. I_truth is a mapping of the form D → TV.

    It is used to define truth valuation for formulas.

13. I_external is a mapping from the coherent set of schemas for externally defined functions to total functions D* → D. For each external schema σ = (?X₁ ... ?X_n; τ) in the coherent set of such schemas associated with the language, I_external(σ) is a function of the form Dⁿ → D.

    For every external schema, σ, associated with the language, I_external(σ) is assumed to be specified externally in some document (hence the name external schema). In particular, if σ is a schema of a RIF builtin predicate or function, I_external(σ) is specified in the document Data Types and BuiltinsBuilt-Ins, Version 1.0 so that:

    • If σ is a schema of a builtin function then I_external(σ) must be the function defined in the aforesaid document.
    • If σ is a schema of a builtin predicate then I_truth ο (I_external(σ)) (the composition of I_truth and I_external(σ), a truth-valued function) must be as specified in Data Types and BuiltinsBuilt-Ins, Version 1.0.

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

• I(k) = I_C(k), if k is a symbol in Const
• I(?v) = I_V(?v), if ?v is a variable in Var
• I(f(t₁ ... t_n)) = I_F(I(f))(I(t₁),...,I(t_n))
• I(f(s₁->v₁ ... s_n->v_n)) = I_SF(I(f))({<s₁,I(v₁)>,...,<s_n,I(v_n)>})

• Here we use {...} to denote a set of argument/value pairs.

• I(o[a₁->v₁ ... a_k->v_k]) = I_frame(I(o))({<I(a₁),I(v₁)>, ..., <I(a_n),I(v_n)>})

• Here {...} denotes a bag of attribute/value pairs.

• I(c1##c2) = I_sub(I(c1), I(c2))
• I(o#c) = I_isa(I(o), I(c))
• I(x=y) = I₌(I(x), I(y))
• I(External(t)) = I_externsl(σ)(I(s₁), ..., I(s_n)), if t is an instance of the external schema σ = (?X₁ ... ?X_n; τ) by substitution ?X₁/s₁ ... ?X_n/s₁.

  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 data types. The set DTS must include the data types described in DTS imposeSection Primitive Data Types of the following restrictions. If dt ∈document Data Types and Built-Ins, Version 1.0.

The data types in DTS impose the following restrictions. If dt ∈ DTS is a symbol space identifier of a data type, let LS_dt denote the lexical space of dt, VS_dt denote its value space, and L_dt: LS_dt → VS_dt the lexical-to-value-space mapping (for the definitions of these concepts, see Section Primitive Data Types of the document Data Types and BuiltinsBuilt-Ins, Version 1.0). Then the following must hold:

• VS_dt ⊆ D_ind; and
• For each constant "lit"^^dt such that lit ∈ LS_dt, I_C("lit"^^dt) = L_dt(lit).

That is, I_C must map the constants of a data type dt in accordance with L_dt.

RIF-BLD does not impose restrictions on I_C for constants in the lexical spaces that do not correspond to primitive datatypes in DTS.   ☐

1. Positional atomic formulas: TVal_I(r(t₁ ... t_n)) = I_truth(I(r(t₁ ... t_n)))
2. Atomic formulas with named arguments: TVal_I(p(s₁->v₁ ... s_k->v_k)) = I_truth(I(p(s₁->v₁ ... s_k->v_k))).
3. Equality: TVal_I(x = y) = I_truth(I(x = y)).
   • To ensure that equality has precisely the expected properties, it is required that:
     I_truth(I(x = y)) = t if and only if I(x) = I(y) and that I_truth(I(x = y)) = f otherwise.
   • This is tantamount to saying that TVal_I(x = y) = t if I(x) = I(y).
4. Subclass: TVal_I(sc ## cl) = I_truth(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, c3 ∈ D,   if TVal_I(c1 ## c2) = TVal_I(c2 ## c3) = t   then TVal_I(c1 ## c3) = t.
5. Membership: TVal_I(o # cl) = I_truth(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, scl ∈ D,   if TVal_I(o # cl) = TVal_I(cl ## scl) = t   then   TVal_I(o # scl) = t.
6. Frame: TVal_I(o[a₁->v₁ ... a_k->v_k]) = I_truth(I(o[a₁->v₁ ... a_k->v_k])).

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

   TVal_I(o[a₁->v₁ ... a_k->v_k]) = t if and only if TVal_I(o[a₁->v₁]) = ... = TVal_I(o[a_k->v_k]) = t.
7. Externally defined atomic formula: TVal_I(External(t)) = I_truth(I_external(σ)(I(s₁), ..., I(s_n))), if t is an atomic formula that is an instance of the external schema σ = (?X₁ ... ?X_n; τ) by substitution ?X₁/s₁ ... ?X_n/s₁.

   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: TVal_I(And(c₁ ... c_n)) = t if and only if TVal_I(c₁) = ... = TVal_I(c_n) = t. Otherwise, TVal_I(And(c₁ ... c_n)) = f.

9. The empty conjunction is treated as a tautology, so TVal_I(And()) = t.

10. Disjunction: TVal_I(Or(c₁ ... c_n)) = f if and only if TVal_I(c₁) = ... = TVal_I(c_n) = f. Otherwise, TVal_I(Or(c₁ ... c_n)) = t.

11. The empty disjunction is treated as a contradiction, so TVal_I(Or()) = f.

12. Quantification:
    • TVal_I(Exists ?v₁ ... ?v_n (φ)) = t if and only if for some I*, described below, TVal_I*(φ) = t.
    • TVal_I(Forall ?v₁ ... ?v_n (φ)) = t if and only if for every I*, described below, TVal_I*(φ) = t.

    Here I* is a semantic structure of the form <TV, DTS, D, D_ind, D_func, I_C, I*_V, I_F, I_frame, I_SF, I_sub, I_isa, I₌, I_externsl, I_truth>, which is exactly like I, except that the mapping I*_V, is used instead of I_V.   I*_V is defined to coincide with I_V on all variables except, possibly, on ?v₁,...,?v_n.

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

    If Γ is a group formula of the form Group(ρ₁ ... ρ_n) then

    • TVal_I(Γ) = t if and only if TVal_I(ρ₁) = t, ..., TVal_I(ρ_n) = t.
    • TVal_I(Γ) = f   otherwise.

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

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

The above definitions make the intent behind the rif:local constants clear: rif:local constants that occur 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.

• a normative mapping from the RIF-BLD presentation syntax to XML syntax.(Section Translation Between the RIF-BLD Presentation and XML serializationSyntaxes), and
• a normative XML Schema for the XML syntax (Appendix XML Schema for BLD).

Recall that the syntax of RIF-BLD is alternating or fully striped [ ANF01 ]. Anot context-free and thus cannot be fully striped serialization views XML documents as objectscaptured by EBNF and divides allXML tags into class descriptors, called type tags , and property descriptors, called role tags .Schema. Validity with respect to XML Schema can be a useful test. To reflect this state of affairs, we use capitalized names for type tags and lowercase names for role tags.define two notions of syntactic correctness. The all-uppercase classesweaker 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 presentation syntax, such as FORMULA , becomeXML syntax is an XML document that is valid w.r.t. the XML schema groupsin Appendix XML Schema for BLD. They act like macros and are not visible  ☐

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 Translation Between the RIF-BLD Presentation and XML Syntaxes.   ☐

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.

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, 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, containing a Name or TERM followed by a TERM)
- Equal     (prefix version of term equation '=')
- Expr      (expression formula, positional or with named arguments)
-  sideleft      (Equal left-hand side  androle)
- right     (Equal right-hand side role)
- Const     (individual, function, or predicate symbol, with optional 'type' attribute)
- Name      (name of named argument)
- Var       (logic variable)

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

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:dateTimexs:dateTime data type can be represented as <Const type="&xsd;dateTime">2007-11-23T03:55:44-02:30</Const><Const type="&xs;dateTime">2007-11-23T03:55:44-02:30</Const>. RIF-BLD also utilizes the ordered attribute to indicate the orderedness of children of the elements args and slot it is associated with.

Example 45 (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(xsdPrefix(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  rif:ordered="yes">ordered="yes">
               <Var>Buyer</Var>
               <Var>Seller</Var>
               <Expr>
                 <op><Const type="&rif;iri">&cpt;book</Const></op>
                 <args  rif:ordered="yes">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  rif:ordered="yes"><Const type="&xsd;integer">49</Const></args>ordered="yes"><Const type="&xs;integer">49</Const></args>
               </Expr>
             </args>
           </Atom>
         </formula>
       </Exists>
     </formula>
     <formula>
       <Equal>
          <side><Var>Seller</Var></side> <side><Var>Author</Var></side><left><Var>Seller</Var></left>
         <right><Var>Author</Var></right>
       </Equal>
     </formula>
   </And>

Example 56 (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 4,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(xsdPrefix(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  rif:ordered="yes">ordered="yes">
                   <Const type="&rif;iri">&cpt;buyer</Const>
                   <Var>Buyer</Var>
                 </slot>
                 <slot  rif:ordered="yes">ordered="yes">
                   <Const type="&rif;iri">&cpt;seller</Const>
                   <Var>Seller</Var>
                 </slot>
                 <slot  rif:ordered="yes">ordered="yes">
                   <Const type="&rif;iri">&cpt;item</Const>
                   <Expr>
                     <op><Const type="&rif;iri">&cpt;book</Const></op>
                     <slot  rif:ordered="yes">ordered="yes">
                       <Name>&cpt;author</Name>
                       <Var>Author</Var>
                     </slot>
                     <slot  rif:ordered="yes">ordered="yes">
                       <Name>&cpt;title</Name>
                       <Const type="&rif;iri">&bks;LeRif</Const>
                     </slot>
                   </Expr>
                 </slot>
                 <slot  rif:ordered="yes">ordered="yes">
                   <Const type="&rif;iri">&cpt;price</Const>
                   <Const  type="&xsd;integer">49</Const>type="&xs;integer">49</Const>
                 </slot>
                 <slot  rif:ordered="yes">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>
          <side><Var>Seller</Var></side> <side><Var>Author</Var></side><left><Var>Seller</Var></left>
         <right><Var>Author</Var></right>
       </Equal>
     </formula>
   </And>

We now extend the RIF-BLD serialization 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 serialization uses the following additional tags. While there is a RIF-BLD element tag for the Import directive, there are none for the Prefix and Base directives (they can be represented as discussed in Section Mapping of the RIF-BLD Rule Language).

- Document  (document, containing optional directives and payload)
- directive (directive role, containing Import, Prefix, or Base)
- payload   (payload role, containing Group)
- Import    (importation, containing location and optional profile)
- location  (location role, containing  Const of type iri)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)ATOMIC or conjunction of ATOMICs)

- id        (identifier role, containing  Const)IRICONST)
- meta      (meta role, containing metadata as a Frame or Frame conjunction)

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

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

Example 67 (Serializing a RIF-BLD document containing a groupan annotated with metadata).group).

This example shows a serialization for the document from Example 3.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(w3 http://www.w3.org/)Prefix(rif  http://www.w3.org/2007/rif#)
   Prefix(opPrefix(func http://www.w3.org/2007/rif-builtin-function#)
  Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#)
   Prefix(xsdPrefix(xs   http://www.w3.org/2001/XMLSchema#)
  
  (*  <http://sample.org>"http://sample.org"^^rif:iri pd[dc:publisher ->  w3:W3Chttp://www.w3.org/
                                     dc:date ->  "2008-04-04"^^xsd: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)
                 External(fn:subtract-dateTimes-yielding-dayTimeDuration(?deliverydate ?scheduledate ?diffduration)) External(fn:get-days-from-dayTimeDuration(?diffduration ?diffdays)) External(op:numeric-greater-than(?diffdays?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  w3 "http://www.w3.org/"> <!ENTITYrif  "http://www.w3.org/2007/rif#">
  <!ENTITY  opfunc "http://www.w3.org/2007/rif-builtin-function#">
  <!ENTITY pred "http://www.w3.org/2007/rif-builtin-predicate#">
  <!ENTITY  xsdxs   "http://www.w3.org/2001/XMLSchema#">
]>

 <Document><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>type="&rif;local">pd</Const>
        </object>
        <slot  rif:ordered="yes">ordered="yes">
          <Const type="&rif;iri">&dc;publisher</Const>
          <Const  type="&rif;iri">&w3;W3C</Const>type="&rif;iri">http://www.w3.org/</Const>
        </slot>
        <slot  rif:ordered="yes">ordered="yes">
          <Const type="&rif;iri">&dc;date</Const>
          <Const  type="&xsd;date">2008-04-04</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  rif:ordered="yes"><Var>item</Var></args>ordered="yes"><Var>item</Var></args>
                 </Atom>
               </formula>
               <formula>
                 <Atom>
                   <op><Const type="&rif;iri">&cpt;delivered</Const></op>
                   <args  rif:ordered="yes">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  rif:ordered="yes">ordered="yes">
                     <Var>item</Var>
                     <Var>scheduledate</Var>
                   </args>
                 </Atom>
               </formula>
               <formula>
                 <Equal>
                   <left><Var>diffduration</Var></left>
                   <right>
                     <External>
                       <content>
                         <Atom>
                           <op><Const  type="&rif;iri">&fn;subtract-dateTimes-yielding-dayTimeDuration</Const></op>type="&rif;iri">&func;subtract-dateTimes</Const></op>
                           <args  rif:ordered="yes">ordered="yes">
                             <Var>deliverydate</Var>
                             <Var>scheduledate</Var>
                            <Var>diffduration</Var></args>
                         </Atom>
                       </content>
                     </External>
                   </right>
                 </Equal>
               </formula>
               <formula>
                 <Equal>
                   <left><Var>diffdays</Var></left>
                   <right>
                     <External>
                       <content>
                         <Atom>
                           <op><Const  type="&rif;iri">&fn;get-days-from-dayTimeDuration</Const></op>type="&rif;iri">&func;days-from-duration</Const></op>
                           <args  rif:ordered="yes">ordered="yes">
                             <Var>diffduration</Var>
                            <Var>diffdays</Var></args>
                         </Atom>
                       </content>
                     </External>
                   </right>
                 </Equal>
               </formula>
               <formula>
                 <External>
                   <content>
                     <Atom>
                       <op><Const  type="&rif;iri">&op;numeric-greater-than</Const></op>type="&rif;iri">&pred;numeric-greater-than</Const></op>
                       <args  rif:ordered="yes">ordered="yes">
                         <Var>diffdays</Var>
                         <Const  type="&xsd;long">10</Const>type="&xs;integer">10</Const>
                       </args>
                     </Atom>
                   </content>
                 </External>
               </formula>
             </And>
           </if>
           <then>
             <Atom>
               <op><Const  type="&xsd;long">reject</Const></op>type="&rif;iri">&cpt;reject</Const></op>
               <args  rif:ordered="yes">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  rif:ordered="yes"><Var>item</Var></args>ordered="yes"><Var>item</Var></args>
             </Atom>
           </if>
           <then>
             <Atom>
               <op><Const type="&rif;iri">&cpt;reject</Const></op>
               <args  rif:ordered="yes">ordered="yes">
                 <Const type="&rif;iri">&ppl;Fred</Const>
                 <Var>item</Var>
               </args>
             </Atom>
           </then>
         </Implies>
       </formula>
     </Forall>
    </sentence>
   </Group>
  </payload>
 </Document>

And (
  conjunct1
  . . .
  conjunctn
    )

<And>
  <formula>χbld(conjunct1 ' </formula>)</formula>
   . . .
  <formula>χbld(conjunctn ' </formula>)</formula>
</And>

Or (
  disjunct1
  . . .
  disjunctn
   )

<Or>
  <formula>χbld(disjunct1 ' </formula>)</formula>
   . . .
  <formula>χbld(disjunctn ' </formula>)</formula>
</Or>

Exists
  variable1
  . . .
  variablen (
             body
            )

<Exists>
  <declare>χbld(variable1 ' </declare>)</declare>
   . . .
  <declare>χbld(variablen ' </declare>)</declare>
  <formula> body' </formula>χbld(body)</formula>
</Exists>

External (
  atomframexpr
         )

<External>
  <content>χbld(atomframexpr)</content>
</External>

pred (
  argument1
  . . .
  argumentn
     )

<Atom>
  <op> pred' </op>χbld(pred)</op>
  <args  rif:ordered="yes">ordered="yes">
    χbld(argument1 ')
    . . .
    χbld(argumentn ')
  </args>
</Atom>

 External ( atomicexpr ) <External> <content> atomicexpr' </content> </External>func (
  argument1
  . . .
  argumentn
     )

<Expr>
  <op> func' </op>χbld(func)</op>
  <args  rif:ordered="yes">ordered="yes">
    χbld(argument1 ')
    . . .
    χbld(argumentn ')
  </args>
</Expr>

pred (
  unicodestring1 -> filler1
  . . .
  unicodestringn -> fillern
     )

<Atom>
  <op> pred' </op>χbld(pred)</op>
  <slot  rif:ordered="yes">ordered="yes">
    <Name>unicodestring1</Name>
    χbld(filler1 ')
  </slot>
   . . .
  <slot  rif:ordered="yes">ordered="yes">
    <Name>unicodestringn</Name>
    χbld(fillern ')
  </slot>
</Atom>

func (
  unicodestring1 -> filler1
  . . .
  unicodestringn -> fillern
     )

<Expr>
  <op> func' </op>χbld(func)</op>
  <slot  rif:ordered="yes">ordered="yes">
    <Name>unicodestring1</Name>
    χbld(filler1 ')
  </slot>
   . . .
  <slot  rif:ordered="yes">ordered="yes">
    <Name>unicodestringn</Name>
    χbld(fillern ')
  </slot>
</Expr>

inst [
  key1 -> filler1
  . . .
  keyn -> fillern
     ]

<Frame>
  <object> inst' </object>χbld(inst)</object>
  <slot  rif:ordered="yes">ordered="yes">
    χbld(key1 ')
    χbld(filler1 ')
  </slot>
   . . .
  <slot  rif:ordered="yes">ordered="yes">
    χbld(keyn ')
    χbld(fillern ')
  </slot>
</Frame>

inst # class

<Member>
  <instance> inst' </instance>χbld(inst)</instance>
  <class> class' </class>χbld(class)</class>
</Member>

sub ## super

<Subclass>
  <sub> sub' </sub>χbld(sub)</sub>
  <super> super' </super>χbld(super)</super>
</Subclass>

left = right

<Equal>
   <side> left' </side> <side> right' </side><left>χbld(left)</left>
  <right>χbld(right)</right>
</Equal>

unicodestring^^space

<Const type="space">unicodestring</Const>

?unicodestring

<Var>unicodestring</Var>

The translation betweenχ_bld mapping from the presentation syntax andto the XML syntax of the RIF-BLD Rule Language is given by the table below, whichbelow; it extends the translation table of Section Translation of RIF-BLD Condition Language. PresentationWhile the Import directive is handled by the presentation-to-XML syntax mapping, the Prefix and Base directives are not. Instead, Prefix and Base directives should be dealt with by macro-expanding these shortcuts declared in the presentation syntax. 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 Syntax Document( Import( loc 1 ) . . . Import( loc n ) group ) <Document> <directive> <Import> <location> loc 1 ' </location> </Import> </directive> .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.

Document(
  Import(loc1  prounicodestring1?)
   . . .
  Import(locn  prounicodestringn?)
  group
        )

<Document>
  <directive>
    <Import>
      <location>χbld(loc1 ' </location> <profile> pro)</location>
      <profile><Profile>unicodestring1 ' </profile></Profile></profile>?
    </Import>
  </directive>
   . . .
  <directive>
    <Import>
      <location>χbld(locn ' </location> <profile> pro)</location>
      <profile><Profile>unicodestringn ' </profile></Profile></profile>?
    </Import>
  </directive>
  <payload> group' </payload>χbld(group)</payload>
</Document>

Group(
  clause1
   . . .
  clausen
     )

<Group>
  <sentence>χbld(clause1 ' </sentence>)</sentence>
   . . .
  <sentence>χbld(clausen ' </sentence>)</sentence>
</Group>

Forall
  variable1
   . . .
  variablen (
             rule
            )

<Forall>
  <declare>χbld(variable1 ' </declare>)</declare>
   . . .
  <declare>χbld(variablen ' </declare>)</declare>
  <formula> rule' </formula> </Forall>χbld(rule)</formula>
</Forall>

conclusion :- condition

<Implies>
  <if> condition' </if>χbld(condition)</if>
  <then> conclusion' </then>χbld(conclusion)</then>
</Implies>

Typetag ( e1 . . . en )

<Typetag>
  χbld document. While semantically equivalent, the original and the round-tripped(e1) . . . χbld documents need not be identical. Metadata SHOULD survive BLD round-tripping. 6 RIF-BLD as a Specialization of the RIF Framework 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 . 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 the Presentation Syntax 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(en)
</Typetag>

(* iriconst? frameconj? *)
Typetag ( e1 .  Section Syntax of a RIF Dialect as a Specialization of the RIF Framework in that document lists the parameters of the syntactic framework in mathematical English, which we will now specialize for RIF-BLD. Alphabet.  The alphabet of the RIF-BLD presentation syntax is the alphabet of RIF-FLD with the negation symbols Neg and Naf excluded. Assignment of signatures to each constant and variable symbol.  The signature set of RIF-BLD contains the following signatures: 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. For every integeren  ≥ 0 , there are signatures f)

<Typetag>
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  χbld(e1) . . . χbld(en {(individual ... individual) ⇒ individual} -- for n-ary function symbols, p n {(individual ... individual) ⇒ atomic} -- for n-ary predicates. These represent function and predicate symbols of arity)
</Typetag>

Typetag v1 . . . vm ( e1 . . . en  (each of the above cases has)

<Typetag>
  χbld(v1) . . . χbld(vm) χbld(e1) . . . χbld(en individual s as arguments inside the parentheses). For every set of symbols s1 ,..., sk ∈ ArgNames , there are signatures f s1...sk {(s1->individual ... sk->individual) ⇒ individual} and p s1...sk {(s1->individual ... sk->individual) ⇒ atomic})
</Typetag>

(* iriconst? frameconj? *)
Typetag v1 .  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. A symbol in Const can have exactly one signature, individual , f. . vm ( e1 . . . en  , or p)

<Typetag>
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  χbld(v1) . . . χbld(vm) χbld(e1) . . . χbld(en , where)
</Typetag>

predfunc (
  e1 . . . en 
          ≥ 0 , or f s1...sk {(s1->individual ... sk->individual) ⇒ individual} , p s1...sk {(s1->individual ... sk->individual) ⇒ atomic} , for some s1 ,..., sk ∈ ArgNames)

<Typetag>
  <op>χbld(predfunc)</op>
  χbld(e1) .  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. Thus, 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. The constant symbols that belong to the supported RIF data types (XML Schema data types, rdf:XMLLiteral , rif:text. . χbld(en)
 all have the signature individual in RIF-BLD. The symbols of type rif:iri and rif:local can have the following signatures in RIF-BLD: individual , f</Typetag>

(* iriconst? frameconj? *)
predfunc (
  e1 . . . en 
          , or p)

<Typetag>
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  <op>χbld(predfunc)</op>
  χbld(e1) . . . χbld(en , for)
</Typetag>

inst [
  e1 . . . en 
      = 0,1,.... ; or f s1...sk , p s1...sk , for some argument names s1 ,..., sk ∈ ArgNames]

<Frame>
  <object>χbld(inst)</object>
  χbld(e1) .  All variables are associated with signature individual{ } , so they can range only over individuals. 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. χbld(en)
</Frame>

(* iriconst? frameconj? *)
inst [
  e1 . . . en 
     ]

<Frame>
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  <object>χbld(inst)</object>
  χbld(e1) . . . χbld(en)
</Frame>

e1 $ e2

<Typetag>
  χbld(e1) χbld(e2)
</Typetag>

(* iriconst? frameconj? *)
e1 $ e2

<Typetag>
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  χbld(e1) χbld(e2)
</Typetag>

unicodestring^^space

<Const type="space">unicodestring</Const>

(* iriconst? frameconj? *)
unicodestring^^space

<Const type="space">
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  unicodestring
</Const>

?unicodestring

<Var>unicodestring</Var>

(* iriconst? frameconj? *)
?unicodestring

<Var>
  <id>χbld(iriconst)</id>?
  <meta>χbld(frameconj)</meta>?
  unicodestring
</Var>

Let Τ be a set of data types, which includes the form t = s has signature atomic and not individual .data types specified in the frame signature, ->RIF-DTB document, and suppose Ε is ->{(individual individual individual) ⇒ atomic} . Note that this precludesa set of external predicates and functions, which includes the possibility thatbuilt-ins listed in the RIF-DTB document. Let D be a frame term might occur as an argument toRIF dialect (e.g., RIF-BLD). We say that a predicate,formula φ is a function, or inside some other term.D_Τ,Ε formula iff

• it is a formula in the membership signature, #dialect D,
• is #{(individual individual) ⇒ atomic} . Note that this precludesall the possibility thatdata types used in φ are in Τ, and
• all the externally defined functions and predicates used in φ are in Ε.

A membership term might occur as an argument toRIF processor is a predicate,conformant D_Τ,Ε consumer iff it implements a function, or inside some other term.semantics-preserving mapping, μ, from the signature forset of all D_Τ,Ε formulas to the subclass relationship is ##{(individual individual) ⇒ atomic} . As with frames and membership terms, this precludeslanguage L of the possibilityprocessor.

Formally, this means that a subclass term might occur inside some other term. RIF-BLD uses no special syntaxfor declaring signatures. Instead, the author specifies signatures contextually . That is, since RIF-BLD requires that each symbol is associated with a unique signature, the signatureany pair φ, ψ of D_Τ,Ε formulas for which φ |=_D ψ is determined fromdefined, φ |=_D ψ iff μ(φ) |=_L μ(ψ). Here |=_D denotes the contextlogical entailment in whichthe symbol is used. If a symbolRIF dialect D and |=_L is usedthe logical entailment 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 partlanguage L of the RIF-BLD language, and individual and atomic are not reserved keywordsRIF processor. In RIF-BLD. Supported typesaddition, a D_Τ,Ε conformant consumer must reject any document that contains a non-D_Τ,Ε formula.

A RIF processor is a conformant D_Τ,Ε producer iff it implements a semantics-preserving mapping, μ, from a subset of terms . RIF-BLD supports all the term types defined by the syntactic framework (seethe Section Termslanguage L of RIF-FLD): constants variables positional with named arguments equality frame membership subclass external Comparedthe processor to RIF-FLD, terms (both positional and with named arguments) have significant restrictions.a set of D_Τ,Ε formulas.