Movatterモバイル変換

[0]ホーム

RIF Basic Logic Dialect (Second Edition)

W3C Recommendation 5 February 2013

This version:: http://www.w3.org/TR/2013/REC-rif-bld-20130205/
Latest version:: http://www.w3.org/TR/rif-bld/
Previous version:: http://www.w3.org/TR/2012/PER-rif-bld-20121211/

Editors:: Harold Boley, National Research Council Canada; Michael Kifer, State University of New York at Stony Brook, USA

Please refer to theerrata for this document, which may include some normative corrections.

Acolor-coded version of this document showing changes made since the previous version is also available.

This document is also available in these non-normative formats:PDF version.

Abstract

This document, developed by theRule Interchange Format (RIF) Working Group, specifies the Basic Logic Dialect, RIF-BLD, a format that allows logic rules to be exchanged between rule systems. The RIF-BLD presentation syntax and semantics are specified both directly and as specializations of theRIF Framework for Logic Dialects, or RIF-FLD. The XML serialization syntax of RIF-BLD is specified via a mapping from the presentation syntax. A normative XML schema is also provided.

Status of this Document

May Be Superseded

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

Set of Documents

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

Document Unchanged

There have been no changes to the body of this document since theprevious version. For details on earlier changes, see thechange log.

Please Send Comments

Please send any comments topublic-rif-comments@w3.org (public archive). Although work on this document by theRule Interchange Format (RIF) Working Group is complete, comments may be addressed in theerrata or in future revisions. Open discussion among developers is welcome atpublic-rif-dev@w3.org (public archive).

Endorsed By W3C

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

Patents

This document was produced by a group operating under the5 February 2004 W3C Patent Policy. W3C maintains apublic list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent.

1 Overview

This specification developsRIF-BLD (theBasicLogicDialect of theRuleInterchangeFormat). From a theoretical perspective, RIF-BLD corresponds to the language of definite Horn rules with equality and a standard first-order semantics [CL73]. Syntactically, RIF-BLD has a number of extensions to support features such as objects and frames as in F-logic [KLW95], internationalized resource identifiers (or IRIs, defined by [RFC-3987]) as identifiers for concepts, and XML Schema datatypes [XML-SCHEMA2]. In addition, RIF RDF and OWL Compatibility [RIF-RDF+OWL] defines semantics for the 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.

While rule interchange (and not, e.g., execution) is the principle design goal for RIF-BLD, the design clearly indicates a decision to avoid solving the (probably impossible) problem of rule interchange in general. Instead, the design of RIF reflects the rationale of identifying specific kinds of rules within existing rule systems, calledRIF dialects, that can be translated into other rule systems without changing their meaning. RIF-BLD is just the first in a series of such dialects. In particular, RIF-BLD has the RIF-Core dialect [RIF-Core] as a subset. It isnot expected that most rule systems will be able to translate all their rules into RIF-BLD, rather it is expected that only certain kinds of rules will be translatable. Since there are many existing rule languages with useful features that are not supported in RIF-BLD, it is expected that RIF-BLD translators will not translate rules that use such features. This could drive the design of "BLD-specific" rule sets in which rules are specifically written by the implementor to be within the BLD dialect and thus be portable between many rule system implementations.

Among its many influences, RIF shares certain characteristics with ISO Common Logic (CL) [ISO-CL], itself an evolution of KIF [KIF] and Conceptual Graphs [CG]. Like CL, RIF employs XML as its primary normative syntax, uses IRIs as identifiers, specifies integrated RIF-BLD/RDF and RIF-BLD/OWL languages for Semantic Web Compatibility [RIF-RDF+OWL], and provides a rich set of datatypes and built-ins that are designed to be well aligned with Web-aware rule system implementations [RIF-DTB]. Unlike CL, RIF-BLD was designed to be asimple dialect with limited expressiveness that lies within the intersection of first-order and logic-programming systems. This is why RIF-BLD does not support negation. More generally, RIF-BLD is part of a coherent array of RIF rule dialects, which encompasses both logic rules -- through the RIF framework for logic dialects [RIF-FLD] also including a variety of rule languages based on non-monotonic theories -- and production rules, as defined in [RIF-PRD]. CL, on the other hand, is strictly first-order; it does not account for non-monotonic semantics (e.g. negation as failure, defaults, priorities, etc.). For rule interchange between CL and RIF dialects, it is expected that partial RIF-CL mappings will be defined.

RIF-BLD also bears some similarity to SPARQL, in particular with respect to RDF Compatibility [RIF-RDF+OWL]. As with the well-known correspondence between a fragment of SQL and Datalog, SPARQL can be partially mapped to Datalog (and thus to the RIF-Core subset of RIF-BLD), see [AP07] and [AG08] for details. A full mapping of SPARQL would need constructs beyond RIF-BLD, such as non-monotonic negation. Likewise, not all of SPARQL's FILTER functions are expressible in RIF-DTB built-in predicates. Not all of RIF-BLD is expressible in SPARQL either, for instance recursive rules over RDF Data are not expressible as SPARQL CONSTRUCT statements.

RIF-BLD is defined in two different ways --both normative:

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

Logic-based RIF dialects that specialize or extend RIF-BLD in accordance with the RIF framework for logic dialects [RIF-FLD] include RIF-Core as a specialization of RIF-BLD. It is expected that other specifications will develop further logic dialects based on RIF-BLD such as a RIF-BLD extension capturing uncertainty [URD08].

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

Example 1 (An introductory RIF-BLD example).

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

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

Intuitively, the factMary buys LeRif from John should be logically derivable from the above premises.Assuming Web IRIs for the predicatesbuy andsell, as well as for the individualsJohn,Mary, andLeRif, the above English text can be represented in theRIF-BLD Presentation Syntax as follows.

Document(  Base(<http://example.com/people#>)  Prefix(cpt <http://example.com/concepts#>)  Prefix(bks <http://example.com/books#>)  Group  (    Forall ?Buyer ?Item ?Seller (        cpt:buy(?Buyer ?Item ?Seller) :- cpt:sell(?Seller ?Item ?Buyer)    )     cpt:sell(<John> bks:LeRif "Mary"^^rif:iri)  ))

Note that IRIs are represented in several different ways in this example. First,the [CURIE] notationprefix:suffix is used to shorten IRI representation. For instance,cpt:buy via aPrefix directive represents therif:iri constant"http://example.com/concepts#buy"^^rif:iri.Another way to shorten this IRI constant is to use the angle-bracketed notation<http://example.com/concepts#buy>. TheBase directive provides yet another shortcut: it applies to all relative IRIs, such as"Mary"^^rif:iri and<John>. TheBase directive expands these relative IRIs to"http://example.com/people#Mary"^^rif:iri and"http://example.com/people#John"^^rif:iri, respectively.

Whenever a RIF-BLD document falls into the Core subset or can be translated to it, the document should be produced in RIF-Core to allow its interchange with a maximum number of RIF consumers.For instance, the Datalog-like RIF document in Example 1 is also a RIF-Core example.

For the interchange of documents containing RIF-BLD rules (and facts), a concreteRIF-BLD XML Syntax is given in this specification. To formalize their meaning, a model-theoreticRIF-BLD Semantics is specified.

2 Direct Specification of RIF-BLD Presentation Syntax

This section specifies thepresentation syntax of RIF-BLD directly, without relying on [RIF-FLD]. In the first five (normative) subsections, the presentation syntax isdefined using "mathematical English," a special form of English for communicating mathematical definitions, examples, etc.In the non-normative subsectionEBNF Grammar for the Presentation Syntax of RIF-BLD, a grammar for a superset of the presentation syntax is given using Extended Backus–Naur Form (EBNF).Neither the mathematical English nor the EBNF is intended to be a concrete syntax for RIF-BLD. The mathematical English deliberately leaves out details such as the delimiters of the various syntactic components, escape symbols, parenthesizing, precedence of operators, and the like. The EBNF does not specify context-sensitive syntactic constraints.Since RIF is an interchange format, it usesXML as the only concrete syntax,which will be defined inXML Serialization Syntax for RIF-BLD. HenceRIF-BLD conformance is described in terms ofsemantics-preserving transformations.

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

2.1 Alphabet of RIF-BLD

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

a countably infinite set ofconstant symbolsConst
a countably infinite set ofvariable symbolsVar (disjoint fromConst)
a countably infinite set of argument names,ArgNames (disjoint fromConst andVar)
connective symbolsAnd,Or, and:-
quantifiersExists andForall
the symbols=,#,##,->,External,Import,Prefix, andBase
the symbolsGroup andDocument
the symbols for representing lists:List andOpenList.
the auxiliary symbols(,),[,],<,>, and^^

The set of connective symbols, quantifiers,=, etc., is disjoint fromConst andVar. The argument names inArgNames are written as Unicode strings that must not start with a question mark, "?". Variables are written as Unicode strings preceded with the symbol "?".

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

The symbols=,#, and## are used in formulas that define equality, class membership, and subclass relationships. The symbol-> is used in terms that have named arguments and in frame formulas. The symbolExternal indicates that an atomic formula or a function term is defined externally (e.g., a built-in) and the symbolsPrefix andBase enable compact representations of IRIs [RFC-3987].

The symbolDocument is used to specify RIF-BLD documents, the symbolImport is an import directive, and the symbolGroup is used to organize RIF-BLD formulas into collections. ☐

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

2.2 Terms

RIF-BLD defines several kinds of terms:constants andvariables,positional terms, terms withnamed arguments, plusequality,membership,subclass,frame, andexternal terms. The word "term" will be used to refer to any of these constructs.

To simplify the next definition, we will use the phrasebase term to refer to simple, positional, or named-argument terms, or to terms of the formExternal(t), wheret is a positional or a named-argument term.

Definition (Term).

Constants and variables. Ift ∈Const ort ∈Var thent is asimple term.
Positional terms. Ift ∈Const andt₁, ...,t_n,n≥0, are base terms thent(t₁ ... t_n) is apositional term.
Positional terms correspond to the usual terms and atomic formulas ofclassical first-order logic [Enderton01,Mendelson97].
Terms with named arguments. Aterm with named arguments is of the formt(s₁->v₁ ... s_n->v_n), wheren≥0,t ∈Const andv₁, ...,v_n are base terms ands₁, ...,s_n are pairwise distinct symbols from the setArgNames.
The constantt here represents a predicate or a function;s₁, ...,s_n represent argument names; andv₁, ...,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 formf() is, trivially, both a positional term and a term with named arguments.
Terms with named arguments are introduced to support exchange of languagesthat permit argument positions of predicates and functions to be named(in which case the order of the arguments does not matter).
List terms. There are two kinds of list terms:open andclosed.
- Aclosed list has the formList(t₁ ...t_m), wherem≥0 andt₁, ...,t_m are terms.
- Anopen list (or a list with a tail) has the formOpenList(t₁ ...t_mt), wherem>0 andt₁, ...,t_m,t are terms. Open lists are usually written using the following:List(t₁ ...t_m|t).
  The last argument,t, represents the tail of the list and so it is normally a list as well. However, the syntax does not restrictt in any way: it could be an integer, a variable, another list, or, in fact, any term. An example isList(1 2 | 3). This is not an ordinary list, where the last argument,3, would represent the tail of a list (and thus would also be a list, which3 is not). Such general open lists correspond to Lisp's dotted lists [Steele90]. Note that they can be the result of instantiating an open list with a variable in the tail, hence are hard to avoid. For instance,List(1 2 | 3) isList(1 2 | ?X), where the variable?X is replaced with3.
A closed list of the formList() (i.e., a list in whichm=0, corresponding to Lisp'snil) is called theempty list.
Equality terms.t = s is anequality term, ift ands are base terms.
Class membership terms (or justmembership terms).t#s is amembership term ift ands are base terms.
Subclass terms.t##s is asubclass term ift ands are base terms.
Frame terms.t[p₁->v₁ ... p_n->v_n] is aframe term (or simply aframe) ift,p₁, ...,p_n,v₁, ...,v_n,n ≥ 0, are base terms.
Membership, subclass, and frame terms are used to describe objects and class hierarchies.
Externally defined terms. Ift is a positional or a named-argument term thenExternal(t) is anexternally defined term.
External terms are used for representing built-in functions and predicates as well as "procedurally attached" terms or predicates, which might exist in various rule-based systems, but are not specified by RIF. ☐

Observe that the argument names of frame terms,p₁, ...,p_n, are base terms and so, as a special case, can be variables. In contrast, terms with named arguments can use only the symbols fromArgNames to represent their argument names. They cannot be constants fromConst or variables fromVar. The reason for not allowing variables for those is to control the complexity of unification, which is used by several inference mechanisms of first-order logic.

Example 2 (Terms)

a. Positional term:"http://example.com/ex1"^^rif:iri(1 "http://example.com/ex2"^^rif:iri(?X 5) "abc")

b. Term with named arguments:"http://example.com/Person"^^rif:iri(id->"http://example.com/John"^^rif:iri "age"^^rif:local->?X "spouse"^^rif:local->?Y)

c. Frame term:"http://example.com/John"^^rif:iri["age"^^rif:local->?X "spouse"^^rif:local->?Y]

d. Lists

- Empty list:List()

- Closed list with variable inside:List("a"^^xs:string ?Y "c"^^xs:string)

- Open list with variables:List("a"^^xs:string ?Y "c"^^xs:string | ?Z)

- Equality term with lists inside:List(Head | Tail) = List("a"^^xs:string ?Y "c"^^xs:string)

- Nested list:List("a"^^xs:string List(?X "b"^^xs:string) "c"^^xs:string)

e. Classification terms

- Membership:?X # ?Y

- Subclass:?X ## "http://example.com/ex1"^^rif:iri(?Y)

- Membership:"http://example.com/John"^^rif:iri # "http://example.com/Person"^^rif:iri

- Subclass:"http://example.com/Student"^^rif:iri ## "http://example.com/Person"^^rif:iri

f. External term:External(pred:numeric-greater-than(?diffdays 10)))

2.3 Formulas

RIF-BLD distinguishes certain subsets of the setConst of symbols, including subsets ofpredicate symbols andfunction symbols. SectionWell-formed Formulas gives more details, but we do not need those details yet.

Definition (Atomic Formula).Any term (positional or with named arguments) of the formp(...), wherep is a predicate symbol, is also anatomic formula. Equality, membership, subclass, and frame terms are also atomic formulas. An externally defined term of the formExternal(φ), whereφ is an atomic formula, is also an atomic formula, called anexternally defined atomic formula. ☐

Note that simple terms (constants and variables) arenot formulas.

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

Definition (Formula).Aformula can have several different forms and is defined as follows:

Atomic: Ifφ is an atomic formula then it is also a formula.
Condition formula: Acondition formula is either an atomic formula or a formula that has one of the following forms:
- Conjunction: Ifφ₁, ...,φ_n,n ≥ 0, are condition formulas then so isAnd(φ₁ ... φ_n), called aconjunctive 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 condition formulas then so isOr(φ₁ ... φ_n), called adisjunctive formula. As a special case,Or() is permitted and is treated as a contradiction, i.e., a formula that is always false.
- Existentials: Ifφ is a condition formula and?V₁, ...,?V_n,n>0, are distinct variables thenExists ?V₁ ... ?V_n(φ) is anexistential formula.
Condition formulas are intended to be used inside the premises of rules. Next we define the notions of rule implications, universal rules, universal facts, groups (i.e., sets of rules and facts), and documents.
Rule implication:φ :- ψ is a formula, calledrule implication, if:
- φ is an atomic formula or aconjunction of atomic formulas,
- ψ is a condition formula, and
- none of the atomic formulas inφ is an externally defined term (i.e., a term of the formExternal(...)). Note: external termscan occur in thearguments of atomic formulas in the rule conclusion. For instance,p(func:numeric-add(?X "2"^^xs:integer)) :- q(?X).
Universal rule: Ifφ is a rule implication and?V₁, ...,?V_n,n>0, are distinct variables thenForall ?V₁ ... ?V_n(φ) is a formula, called auniversal rule. It is required that all thefree variables inφ occur among the variables?V₁ ... ?V_n in the quantification part. An occurrence of a variable?v isfree inφ if it is not inside a subformula ofφ of the formExists ?v (ψ) andψ is a formula. Universal rules will also be referred to asRIF-BLD rules.
Universal fact: Ifφ is an atomic formula and?V₁, ...,?V_n,n>0, are distinct variables thenForall ?V₁ ... ?V_n(φ) is a formula, called auniversal fact, provided that all the free variables inφ occur among the variables?V₁ ... ?V_n.
Universal facts are often considered to be rules without premises.
Group: Ifφ₁, ...,φ_n are RIF-BLD rules, universal facts, variable-free rule implications, variable-free atomic formulas,or group formulas thenGroup(φ₁ ... φ_n) is agroup formula. As a special case, the empty group formula,Group(), is allowed and is treated as a tautology, i.e., a formula that is always true.
Non-empty group formulas are used to represent sets of rules and facts. Note that some of theφ_i's can be group formulas themselves, which means that groups can be nested.
Document: An expression of the formDocument(directive₁ ...directive_n Γ) is aRIF-BLD document formula (or simply adocument formula), if
- Γ is an optional group formula; it is called the group formulaassociated with the document.
- directive₁, ...,directive_n is an optional sequence ofdirectives. A directive can be abase directive, aprefix directive or animport directive.
  - Abase directive has the formBase(<iri>), whereiri is a Unicode string in the form of an absolute IRI [RFC-3987].
    TheBase directive defines a syntactic shortcut for expanding relative IRIs into full IRIs, as described in SectionConstants, Symbol Spaces, and Datatypes of [RIF-DTB]. This applies to relative IRIs that appear anywhere, including as constants, symbol spaces, locators, and profiles.
  - Aprefix directive has the formPrefix(p <v>), wherep is an alphanumeric string that serves as the prefix name andv is an expansion forp -- a Unicode sequence of characters that forms an IRI. (An alphanumeric string is a sequence of ASCII characters, where each character is a letter, a digit, or an underscore "_", and the first character is a letter.)
    Like theBase directive, thePrefix directives can be used to define shorthands to allow more concise representation of constants that come from the symbol spacerif:iri (we will call such constantsrif:iriconstants). This mechanism is explained in [RIF-DTB], SectionConstants, Symbol Spaces, and Datatypes.
  - Animport directive can have one of these two forms:Import(<loc>) orImport(<loc> <p>). Hereloc is a Unicode sequence of characters that forms an IRI andp is another Unicode sequence of characters. The constantloc represents the location of another document to be imported; it is called thelocator of the imported document. The argumentp is called theprofile of import; it has the form of a Unicode character sequence in the form of an IRI -- see [RIF-RDF+OWL].
    SectionDirect Specification of RIF-BLD Semantics of this document defines the semantics for the directiveImport(<loc>) only. The two-argument directive,Import(<loc> <p>), is intended for importing non-RIF-BLD documents, such as rules from other RIF dialects, RDF data, or OWL ontologies. The profile,p, indicates what kind of entity is being imported and under what semantics (for instance, the various RDF entailment regimes have different profiles). The semantics ofImport(<loc> <p>) (for variousp) are expected to be given by other specifications on a case-by-case basis. For instance, [RIF-RDF+OWL] defines the semantics for the profiles that are recommended for importing RDF and OWL.
  Note that althoughBase,Prefix, andImport all use symbols of the form <iri> to indicate the connection of these symbols to IRIs, these symbols arenotrif:iri constants, as semantically they are interpreted in a way that is quite different from constants.
  A document formula can contain at most oneBase directive. TheBase directive, if present, must be first, followed by any number ofPrefix directives, followed by any number ofImport directives.

In the definition of a formula, the component formulasφ,φ_i,ψ_i, andΓ are said to besubformulas of the respective formulas (condition, rule, group, etc.) that are built using these components. ☐

2.4 RIF-BLD Annotations in the Presentation Syntax

RIF-BLD allows every term and formula (including terms and formulas that occur inside other terms and formulas) to be optionally preceded byoneannotation of the form(* id φ *), whereid is arif:iri constant andφ is a frame formula or a conjunction of frame formulas. Both items inside the annotation are optional. Theid part represents the identifier of the term or formula to which the annotation is attached andφ is the metadata part of the annotation. RIF-BLD does not impose any restrictions onφ apart from what is stated above. This means that it may include variables, function symbols, constants from the symbol spacerif:local (often referred to aslocal orrif:localconstants), and so on.

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

The following convention is used to avoid a syntactic ambiguity with respect to annotations. The annotation scoping convention associates each annotation to the largest term or formula it precedes. For instance, in(* id φ *) t[w -> v] the metadata annotation could be attributed to the termt or to the entire framet[w -> v]. The convention specifies that the above annotation is considered to be syntactically attached to the entire frame. Yet, sinceφ can be a conjunction, some conjuncts can be used to provide metadata targeted to the object part,t, of the frame. For instance,(* And(_foo[meta_for_frame->"this is an annotation for the entire frame"] _bar[meta_for_object->"this is an annotation for t" meta_for_property->"this is an annotation for w"]) *) t[w -> v].

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

2.5 Well-formed Formulas

Not all formulas and thus not all documents are well-formed in RIF-BLD:it is required that no constant appear in more than one context. What this means precisely is explained below. Informally, this means that each constant symbol in RIF-BLD can be either an individual, a plain function, a plain predicate, an externally defined function, or an externally defined predicate. However, symbols can bepolyadic: the same function or predicate symbol (normal or external) can occur with different numbers of arguments in different places. Note that polyadic symbols could be replaced by non-polyadic symbols with the arity information encoded in the function or predicate names. For instance, the polyadic termsp(?X) andp(?X,?Y) could be represented asp_1(?X) andp_2(?X,?Y), respectively.

The set of all constant symbols,Const, is partitioned into the following subsets:

A subset of individuals.
The symbols inConst that belong to the symbol spaces ofDatatypes are required to be individuals.
A subset of plain (i.e., non-external) function symbols.
A subset for external function symbols.
A subset of plain predicate symbols.
A subset for external predicate symbols.

The above subsets do not differentiate between positional and named argument symbols. Also, as seen from the following definitions, these subsets are not specified explicitly but, rather, are inferred from the occurrences of the symbols.

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

Ifs occurs as a predicate of the forms(...) (positional or named-argument) in an atomicsubformula ofφ thens occurs in thecontext of a (plain) predicate symbol.
Ifs occurs as a function symbol in a non-subformula term of the forms(...) thens occurs in thecontext of a (plain) function symbol.
Ifs occurs as a predicate in an atomic subformulaExternal(s(...)) thens occurs in thecontext of an external predicate symbol.
Ifs occurs as a function in a non-subformula termExternal(s(...)) thens occurs in thecontext of an external function symbol.
Ifs occurs in any other context (in a frame:s[...],...[s->...], or...[...->s]; or in a positional/named-argument term:p(...s...),q(...->s...)), it is said to occur as anindividual. ☐

Definition (Imported document).LetΔ be a document formula andImport(loc) be one of its import directives, whereloc is alocator of another document formula,Δ'. We say thatΔ' isdirectly imported intoΔ.

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

The above definition deals only with one-argument import directives, since only such directives can be used to import other RIF-BLD documents.Two-argument import directives are provided to enable import of other types of documents, and their semantics are supposed to be covered by other specifications, such as [RIF-RDF+OWL].

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

every constant symbol (whether coming from the symbol spacerif:local or not) mentioned inφ occurs in exactly onecontext.
ifφ is a document formula andΔ'₁, ...,Δ'_k are all of its imported documents, then every non-rif:local constant symbol mentioned inφ or any of the importedΔ'_is must occur in exactly one context (in all of theΔ'_is).
whenever a formula contains a term or a subformula of the formExternal(t),t must be an instantiation of a schema in the coherent set of external schemas (SectionSchemas for Externally Defined Terms of [RIF-DTB]) associated with thelanguage of RIF-BLD.
ift is an instantiation of a schema in the coherent set of external schemas associated with the language thent can occur only asExternal(t), i.e., as an external term or atomic formula. ☐

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

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

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

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

The syntax of first-order logic is not context-free, so EBNF cannot capture the syntax of RIF-BLD precisely. For instance, it cannot capture somewell-formedness conditions, such as the requirement that external terms must be instances of external schemas. As a result, the EBNF grammar defines a strictsuperset of RIF-BLD: not all formulas that are derivable using the EBNF grammar are well-formed formulas in RIF-BLD.
The EBNF grammar does not address all details of how constants (defined in [RIF-DTB]) and variables are represented, and it is not sufficiently precise about the delimiters and escape symbols. White space is informally used as a delimiter, and is implied in productions that use Kleene star. For instance,TERM* is to be understood asTERM TERM ... TERM, where each space 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 isnot intended as a concrete syntax for a rule language. RIF defines a concrete syntax only forexchanging 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 isnot normative. Recall from theopening paragraph, however, that the RIF-BLD presentation syntax as specified in mathematical English is normative.

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

Rule Language:

  Document       ::= IRIMETA? 'Document' '(' Base? Prefix* Import* Group? ')'  Base           ::= 'Base' '('ANGLEBRACKIRI ')'  Prefix         ::= 'Prefix' '('NCNameANGLEBRACKIRI ')'  Import         ::= IRIMETA? 'Import' '(' LOCATOR PROFILE? ')'  Group          ::= IRIMETA? 'Group' '(' (RULE | Group)* ')'  RULE           ::= (IRIMETA? 'Forall' Var+ '(' CLAUSE ')') | CLAUSE  CLAUSE         ::= Implies | ATOMIC  Implies        ::= IRIMETA? (ATOMIC | 'And' '(' ATOMIC* ')') ':-' FORMULA  LOCATOR        ::=ANGLEBRACKIRI  PROFILE        ::=ANGLEBRACKIRI

Condition Language:

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

Annotations:

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

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

2.6.1 EBNF for the Condition Language

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

The production rule for the non-terminalFORMULA representsRIF condition formulas (defined earlier). The connectivesAnd andOr define conjunctions and disjunctions of conditions, respectively.Exists introduces existentially quantified variables. HereVar+ stands for the list of variables that are free inFORMULA. A RIF-BLDFORMULA can also be anATOMIC term, i.e. anAtom,ExternalAtom,Equal,Member,Subclass, orFrame. ATERM can be a constant, variable,Expr,List, orExternalExpr.

The RIF-BLD presentation syntax does not commit to any particular vocabulary and permits arbitrary Unicode strings in constant symbols, argument names, and variables. Constant symbols can have this form:"UNICODESTRING"^^SYMSPACE, whereSYMSPACE is anANGLEBRACKIRI orCURIE that represents the identifier of the symbol space of the constant.UNICODESTRING,ANGLEBRACKIRI, andCURIE are defined in SectionShortcuts for Constants in RIF's Presentation Syntax of [RIF-DTB]. Constant symbols can also have several shortcut forms, which are represented by the non-terminalCONSTSHORT. These shortcuts are also defined in the same section of [RIF-DTB]. One of them is theCURIE shortcut, which is extensively used in the examples in this document.Names are Unicode character sequences. Variables are composed ofUNICODESTRING symbols prefixed with a?-sign.

Equality, membership, and subclass terms are self-explanatory. AnAtom andExpr (expression) can either be positional or have named arguments. A frame term is a term composed of an object identifier and a collection of attribute-value pairs. The termExternal(Atom) is a call to an externally defined predicate. Likewise,External(Expr) is a call to an externally defined function.

Example 3 (RIF-BLD conditions).

This example shows conditions that are composed of atoms, expressions, equalities with lists, frames, and existentials. In frame formulas, variables are shown in the positions of object identifiers, object properties, and property values. For brevity, we use the shortcut CURIE notationprefix:suffix for constant symbols defined in [RIF-DTB]. This is understood as a shorthand for an IRI obtained by concatenation of theprefix definition andsuffix. Thus, ifbks is a prefix that expands intohttp://example.com/books# thenbks:LeRif is an abbreviation for"http://example.com/books#LeRif"^^rif:iri.

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))

Equalities with list terms:

  ?L = List(?X ?Y ?X)  List(?Head | ?Tail) = List("a"^^rif:local ?Y "c"^^rif:local)

Frames:

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

2.6.2 EBNF for the Rule Language

The presentation syntax for RIF-BLD rules is based on the syntax in SectionEBNF for RIF-BLD Condition Language with the productions shown in the aboverules part.

A RIF-BLDDocument consists of an optionalBase, followed by any number ofPrefixes, followed by any number ofImports, followed by an optionalGroup.Base andPrefix serve as shortcut mechanisms for IRIs.IRI has the form of an internationalized resource identifier as defined by [RFC-3987].AnImport indicates the location of a document to be imported and an optional profile.A RIF-BLDGroup is a collection ofany number ofRULE elements along with any number of nestedGroups.

Rules are generated usingCLAUSE elements. TheRULE production has two alternatives:

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

Var,ATOMIC, andFORMULA were defined as part of the syntax for positive conditions in SectionEBNF for RIF-BLD Condition Language. In theCLAUSE production, anATOMIC is what is usually called afact. AnImpliesrule can have anATOMIC or a conjunction ofATOMIC elements as its conclusion; it has aFORMULA as its premise. Note that, by thedefinition of formulas, externally defined atoms (i.e., formulas of the formExternal(Atom)) are not allowed in the conclusion part of a rule (ATOMIC does not expand toExternal).

Example 4 (RIF-BLD rules).

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

If an item is perishable and it is delivered to John more than 10 days after the scheduled delivery date then the item will be rejected by him.

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

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

a. Universal form:

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

b. Universal-existential form:

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

2.6.3 EBNF for Annotations

The EBNF grammar production for RIF-BLD annotations is shown in the aboveannotations part.

As explained in SectionRIF-BLD Annotations in the Presentation Syntax, each RIF-BLD formula and term can be preceded by one optional annotation,IRIMETA, for identification and metadata.IRIMETA is represented using(*...*)-bracketsthat contain an optionalrif:iri constant,IRICONST, as identifier followed byan optionalFrame or conjunction ofFrames as metadata.

AnIRICONST isrif:iri constant,again permitting the shortcut forms defined in [RIF-DTB].One such specialization is'"' IRI '"^^' 'rif:iri' from theConst production, whereIRI is a sequence of Unicode characters that forms an internationalized resource identifier as defined by [RFC-3987].

Example 5 (A RIF-BLD document containing an annotated group).

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

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

3 Direct Specification of RIF-BLD Semantics

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

Recall that the presentation syntax of RIF-BLD allows shorthand notation,which is specified via thePrefix andBase directives, and various shortcuts for integers, strings, andrif:local symbols.The semantics, below, is described using the full syntax, i.e., weassume that all shortcuts have already been expanded as defined in [RIF-DTB], SectionConstants, Symbol Spaces, and Datatypes.

3.1 Truth Values

The setTV of truth values in RIF-BLD consists of two values,t andf.

3.2 Semantic Structures

The key concept in a model-theoretic semantics for a logic language is the notion of asemantic structure [Enderton01,Mendelson97]. The definition is slightly more general than what is strictly necessary for RIF-BLD alone. This lays the groundwork for extensions to RIF-BLD and makes the connection with thesemantics of the RIF framework for logic-based dialects [RIF-FLD] more obvious.

Definition (Semantic structure).Asemantic structure,I, is a tuple of the form<TV,DTS,D,D_ind,D_func,I_C,I_V,I_F,I_NF,I_list,I_tail,I_frame,I_sub,I_isa,I₌,I_external,I_truth>. HereD is a non-empty set of elements called thedomain ofI, andD_ind,D_func are nonempty subsets ofD.D_ind is used to interpret the elements ofConst thatoccur as individuals andD_func is used to interpret the elements ofConst thatoccur in the context of function symbols. As before,Const denotes the set of all constant symbols andVar the set of all variable symbols.DTS denotes a set of identifiers for datatypes (please refer to SectionDatatypes of [RIF-DTB] for the semantics of datatypes).

The other components ofI aretotal mappings defined as follows:

I_C mapsConst toD.
This mapping interprets constant symbols. In addition:
- If a constant,c ∈ Const,is anindividual then it is required thatI_C(c) ∈ D_ind.
- Ifc ∈ Const, is afunction symbol (positional or with named arguments) then it is required thatI_C(c) ∈ D_func.
I_V mapsVar toD_ind.
This mapping interprets variable symbols.
I_F mapsD to total functionsD*_ind →D (hereD*_ind is a set of all finite sequences over the domainD_ind).
This mapping interprets positional terms. In addition:
- Ifd ∈D_func thenI_F(d) must be a functionD*_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.
I_NF mapsD to the set of total functions of the formSetOfFiniteSets(ArgNames ×D_ind) →D.
This mapping interprets function symbols with named arguments. In addition:
- Ifd ∈D_func thenI_NF(d) must be a functionSetOfFiniteSets(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.
I_list andI_tail are used to interpret lists. They are mappings of the following form:
- I_list :D_ind^* →D_ind
- I_tail :D_ind⁺×D_ind →D_ind
In addition, these mappings are required to satisfy the following conditions:
- The functionI_list is injective (one-to-one).
- The setI_list(D_ind^*), henceforth denotedD_list, is disjoint from the value spaces of all data types inDTS.
- I_tail(a₁, ...,a_k,I_list(a_k+1, ...,a_k+m)) =I_list(a₁, ...,a_k,a_k+1, ...,a_k+m).
Note that the last condition above restrictsI_tail only when its last argument is inD_list. If the last argument ofI_tail is not inD_list, then the list is a general open one and there are no restrictions on the value ofI_tail except that it must be inD_ind.
I_frame mapsD_ind to total functions of the formSetOfFiniteBags(D_ind ×D_ind) →D.
This mapping interprets frame terms. An argument,d ∈D_ind, toI_frame represents an object and the finite bag {<a1,v1>, ..., <ak,vk>} represents a bag of attribute-value pairs ford. We will see shortly howI_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. Such repetitions arise naturally when variables are instantiated with constants. For instance,o[?A->?B ?C->?D] becomeso[a->b a->b] if variables?A and?C are instantiated with the symbola while?B and?D are instantiated withb. (We shall see later thato[a->b a->b] is equivalent too[a->b].)
I_sub gives meaning to the subclass relationship. It is a mapping of the formD_ind ×D_ind →D.
I_sub will be further restricted in SectionInterpretation of Formulas to ensure that the operator## is transitive, i.e., thatc1 ## c2 andc2 ## c3 implyc1 ## c3.
I_isa gives meaning to class membership. It is a mapping of the formD_ind ×D_ind →D.
I_isa will be further restricted in SectionInterpretation of Formulas to ensure that the relationships# and## have the usual property that all members of a subclass are also members of the superclass, i.e., thato # cl andcl ## scl implyo # scl.
I₌ is a mapping of the formD_ind ×D_ind →D.
It gives meaning to the equality operator.
I_truth is a mapping of the formD →TV.
It is used to define truth valuation for formulas.
I_external is a mapping from the coherent set of schemas for externally defined functions to total functionsD* →D. For each external schemaσ = (?X₁ ... ?X_n; τ) in thecoherent set of external schemas associated with thelanguage,I_external(σ) is a function of the formDⁿ →D.
For every external schema,σ, associated with the language,I_external(σ) is assumed to be specified externally in some document (hence the nameexternal schema). In particular, ifσ is a schema of a RIF built-in predicate or function,I_external(σ) is specified in [RIF-DTB] so that:
- Ifσ is a schema of a built-in function thenI_external(σ) must be the function defined in [RIF-DTB].
- Ifσ is a schema of a built-in predicate thenI_truth ο(I_external(σ)) (the composition ofI_truth andI_external(σ), a truth-valued function) must be as specified in [RIF-DTB].

We also define the following mapping from terms toD, which we denote using the same symbolI as the one used for semantic structures. This overloading is convenient and creates no ambiguity.

I(k) =I_C(k), ifk is a symbol inConst
I(?v) =I_V(?v), if?v is a variable inVar
I(f(t₁ ... t_n)) =I_F(I(f))(I(t₁),...,I(t_n))
I(f(s₁->v₁ ... s_n->v_n)) =I_NF(I(f))({<s₁,I(v₁)>,...,<s_n,I(v_n)>})
Here we use {...} to denote a set of argument/value pairs.
For list terms, the mapping is defined as follows:
- I(List()) =I_list(<>).
  Here<> denotes an empty list of elements ofD_ind. (Note that the domain ofI_list isD_ind^*, soD_ind⁰ is an empty list of elements ofD_ind.)
- I(List(t₁ ...t_n)) =I_list(I(t₁), ...,I(t_n)), ifn>0.
- I(List(t₁ ...t_n |t)) =I_tail(I(t₁), ...,I(t_n),I(t)), ifn>0.
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. Jumping ahead, we note that duplicate elements in such a bag do not affect the truth value of a frame formula. Thus, for instance,o[a->b a->b] ando[a->b] always have the same truth value.
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_external(σ)(I(s₁), ...,I(s_n)), ift is an instantiation of the external schemaσ = (?X₁ ... ?X_n; τ) by substitution?X₁/s₁ ... ?X_n/s₁.
Note that, by definition,External(t) is well-formed only ift is an instantiation of an external schema. Furthermore, by thedefinition of coherent sets of external schemas,t can be an instantiation of at most one such schema, soI(External(t)) is well-defined.

Note that the definitions ofI_NF andI(x=y) imply that the terms with named arguments that differ only in the order of their arguments are mapped byI to the same element in the domain. This implies that the equalities liket(a->1 b->2 c->3) = t(c->3 a->1 b->2) are tautologies in RIF-BLD.

The effect of datatypes. The setDTS must include the datatypes described in SectionDatatypes of [RIF-DTB].

The datatype identifiers inDTS impose the following restrictions. Givendt ∈DTS, letLS_dt denote the lexical space ofdt,VS_dt denote its value space, andL_dt:LS_dt →VS_dt the lexical-to-value-space mapping (for the definitions of these concepts, see SectionDatatypes of [RIF-DTB]). Then the following must hold:

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

That is,I_C must map the constants of a datatypedt in accordance withL_dt.

RIF-BLD does not impose restrictions onI_C for constants in symbol spaces that are not datatypes included inDTS. ☐

3.3 RIF-BLD Annotations in the Semantics

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

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

3.4 Interpretation of Non-document Formulas

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

We define a mapping,TVal_I, from the set of all non-document formulas toTV. Note that the definition implies thatTVal_I(φ) is definedonly if the setDTS of the datatypes ofI includes all the datatypes mentioned inφ andI_external is defined on all externally defined functions and predicates inφ.

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

Positional atomic formulas:TVal_I(r(t₁ ... t_n)) =I_truth(I(r(t₁ ... t_n)))
Atomic formulas with named arguments:TVal_I(p(s₁->v₁ ... s_k->v_k)) =I_truth(I(p(s₁->v₁ ... s_k->v_k))).
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 ifI(x) =I(y) andI_truth(I(x = y)) =f otherwise.
- This is tantamount to saying thatTVal_I(x = y) =t if and only ifI(x) =I(y).
Subclass:TVal_I(sc ## cl) =I_truth(I(sc ## cl)).
To ensure that the operator## is transitive, i.e.,c1 ## c2 andc2 ## c3 implyc1 ## c3, the following is required:
- For all well-formed termsc1,c2,c3: ifTVal_I(c1 ## c2) =TVal_I(c2 ## c3) =t thenTVal_I(c1 ## c3) =t.
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 andcl ## scl implyo # scl, the following is required:
- For all well-formed termso,cl,scl: ifTVal_I(o # cl) =TVal_I(cl ## scl) =t then TVal_I(o # scl) =t.
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 associated with an objecto represents the conjunction of assertions represented by these pairs, the following is required, ifk > 0:
- TVal_I(o[a₁->v₁ ... a_k->v_k]) =t if and only ifTVal_I(o[a₁->v₁]) = ... =TVal_I(o[a_k->v_k]) =t.
Externally defined atomic formula:TVal_I(External(t)) =I_truth(I_external(σ)(I(s₁), ...,I(s_n))), ift is an atomic formula that is an instantiation of the external schemaσ = (?X₁ ... ?X_n; τ) by substitution?X₁/s₁ ... ?X_n/s₁.
Note that, by definition,External(t) is well-formed only ift is an instantiation of an external schema. Furthermore, by thedefinition of coherent sets of external schemas,t can be an instantiation of at most one such schema, soI(External(t)) is well-defined.
Conjunction:TVal_I(And(c₁ ... c_n)) =t if and only ifTVal_I(c₁) = ... =TVal_I(c_n) =t. Otherwise,TVal_I(And(c₁ ... c_n)) =f.
The empty conjunction is treated as a tautology, soTVal_I(And()) =t.
Disjunction:TVal_I(Or(c₁ ... c_n)) =f if and only ifTVal_I(c₁) = ... =TVal_I(c_n) =f. Otherwise,TVal_I(Or(c₁ ... c_n)) =t.
The empty disjunction is treated as a contradiction, soTVal_I(Or()) =f.
Quantification:
- TVal_I(Exists ?v₁ ... ?v_n (φ)) =t if and only if for someI*, described below,TVal_I*(φ) =t.
- TVal_I(Forall ?v₁ ... ?v_n (φ)) =t if and only if for everyI*, described below,TVal_I*(φ) =t.
HereI* is a semantic structure of the form <TV,DTS,D,D_ind,D_func,I_C,I*_V,I_F,I_NF,I_list,I_tail,I_frame,I_sub,I_isa,I₌,I_external,I_truth>, which is exactly likeI, except that the mappingI*_V, is used instead ofI_V. I*_V is defined to coincide withI_V on all variables except, possibly, on?v₁,...,?v_n.
Rule implication:
- TVal_I(conclusion :-condition) =t, if eitherTVal_I(conclusion)=t orTVal_I(condition)=f.
- TVal_I(conclusion :-condition) =f otherwise.
Groups of rules:
IfΓ is a group formula of the formGroup(φ₁ ... φ_n) then
- TVal_I(Γ) =t if and only ifTVal_I(φ₁) =t, ...,TVal_I(φ_n) =t.
- TVal_I(Γ) =f otherwise.
This means that a group of rules is treated as a conjunction. In particular, the empty group is treated as a tautology, soTVal_I(Group()) =t. ☐

3.5 Interpretation of Documents

Document formulas are interpreted using the usual semantic structures with two caveats:rif:local must be renamed apart and imported documents must be taken into account.

Definition (Renaming of local constants).Arenaming mapping, ρ, is a function that maps document formulas to document formulas subject to the following restriction:

If ρ(Δ) =Δ' thenΔ' is exactly likeΔ except that all occurrences of somerif:local constants inΔ may be consistently renamed into otherrif:local constants.
By consistent renaming here we mean that different occurrences of the samerif:local constant inΔ are renamed identically. ☐

Definition (Semantic multi-structure).Asemantic multi-structureÎ is a pair (Î_ren,I), where

Î_ren is a renaming mapping; and
I is a semantic structure. ☐

The semantics of RIF documents is now defined as follows.

Definition (Truth valuation of document formulas).LetΔ be a document formula and letΔ₁, ...,Δ_n be all the RIF-BLD document formulas that areimported intoΔ (directly or indirectly, according to DefinitionImported document).LetΓ,Γ₁, ...,Γ_n denote the respective group formulasassociated with these documents. IfÎ = (Î_ren,I) is a semantic multi-structure, then we define:

TVal_Î(Δ) =t if and only ifTVal_I(Î_ren(Γ)) =TVal_I(Î_ren(Γ₁)) = ... =TVal_I(Î_ren(Γ_n)) =t.

That is,Δ evaluates tot iff, after possible renaming ofrif:local constants, its associated group formula as well as the group formulas of all the imported documents evaluate tot.

For non-document formulas, we defineTVal_Î(φ) =TVal_I(Î_ren(φ)). ☐

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

Also note that some of theΓ_i above may be missing since all parts in a document formula are optional. In this case, we assume thatΓ_i is a tautology, such asAnd(), and everyTVal function maps such aΓ_i to the truth valuet.

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

For the relationship betweenrif:local and RDF blank nodes readers are referred to SectionSymbols in RIF Versus RDF/OWL (Informative) of [RIF-RDF+OWL].

3.6 Logical Entailment

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

Definition (Models).A multi-structureÎ is amodel of a formula,φ, written asÎ |= φ, iffTVal_Î(φ) =t. Hereφ can be a document or a non-document formula. ☐

Definition (Logical entailment).Letφ andψ be (document or non-document) formulas. We say thatφentailsψ, written asφ |= ψ, if and only if for every multi-structure,Î,Î |= φ impliesÎ |= ψ. ☐

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

This behavior of local symbols should be contrasted with the behavior ofrif:iri symbols. Suppose, in the above scenario,Δ' also has the fact"http://example.com/ppp"^^rif:iri("http://cde.example.org"^^rif:iri). ThenΔ |= "http://example.com/qqq"^^rif:iri("http://cde.example.org"^^rif:iri)does hold.

4 XML Serialization Syntax for RIF-BLD

The RIF-BLD XML serialization defines

anormative mapping from the RIF-BLD presentation syntax to XML (SectionMapping from the Presentation Syntax to the XML Syntax), and
anormative XML schema for the XML syntax (AppendixXML Schema for BLD).

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

Definition (Valid BLD document in XML syntax).Avalid BLD document in the XML syntax is an XML document that is valid with respect to the XML schema in AppendixXML Schema for BLD. ☐

Definition (Admissible BLD document in XML syntax).Anadmissible BLD document in the XML syntax is a valid BLD document in XML syntax that is the image of a well-formed RIF-BLD document in the presentation syntax (see DefinitionWell-formed formula in SectionFormulas) under the presentation-to-XML syntax mappingχ_bld defined in SectionMapping from the Presentation Syntax to the XML Syntax. ☐

The XML serialization for RIF-BLD is based on analternating orstriped syntax [ANF01]. A striped serialization views XML documents as objects and divides all XML tags into class descriptors, calledtype tags, and property descriptors, calledrole 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 asFORMULA, become XML Schema groups in AppendixXML Schema for BLD. They are not visible in instance markup. The other classes as well as non-terminals and symbols (such asExists or=) become XML elements with optional attributes, as shown below.

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

4.1 XML for the Condition Language

XML serialization of RIF-BLD in SectionEBNF for RIF-BLD Condition Language uses the following elements.

- And       (conjunction)- Or        (disjunction)- Exists    (quantified formula for 'Exists', containing declare and formula roles)- declare   (declare role, containing a Var)- formula   (formula role, containing a FORMULA)- Atom      (atom formula, positional or with named arguments)- External  (external call, containing a content role)- content   (content role, containing an Atom, for predicates, or Expr, for functions)- Member    (member formula)- Subclass  (subclass formula)- Frame     (Frame formula)- object    (Member/Frame role, containing a TERM or an object description)- op        (Atom/Expr role for predicates/functions as operations)- args      (Atom/Expr positional arguments role, with ordered="yes" attribute, containing n TERMs)- instance  (Member instance role)- class     (Member class role)- sub       (Subclass sub-class role)- super     (Subclass super-class role)- slot      (Atom/Expr or Frame slot role, with ordered="yes" attribute, containing a Name or TERM followed by a TERM)- Equal     (prefix version of term equation '=')- left      (Equal left-hand side role)- right     (Equal right-hand side role)- Expr      (expression formula, positional or with named arguments)- List      (list term, closed or open)- items     (list items role, with ordered="yes" attribute, containing n TERMs)- rest      (list rest role, corresponding to '|')- Const     (individual, function, or predicate symbol, with 'type' attribute)- Name      (name of named argument)- Var       (logic variable)   - id        (identifier role, containing IRICONST)- meta      (meta role, containing metadata as a Frame or Frame conjunction)

The name of a base or prefix is not associated with a RIF/XML element, since it is handled via preprocessing as discussed in SectionMapping of the Rule Language.

Theid andmeta elements, which are expansions of theIRIMETA element, can occur optionally as the initial children of any Class element.

For the XML Schema definition of the RIF-BLD condition language see AppendixXML Schema for BLD.

The XML syntax for symbol spaces uses thetype attribute associated with the XML elementConst. For instance, a literal in thexs:dateTime datatype is represented as follows:

<Const type="&xs;dateTime">2007-11-23T03:55:44-02:30</Const>

Thexml:lang attribute, as defined by2.12 Language Identification ofXML 1.0 or its successor specifications in the W3C recommendation track, is optionally used to identify the language for the presentation of theConst to the user. It is allowed only in association with constants of the typerdf:plainLiteral. A compliant implementation MUST ignore thexml:lang attribute if the type of theConst is notrdf:plainLiteral.

RIF-BLD also uses theordered="yes" attribute to indicate that the children ofargs andslot elements are ordered.

Example 6 (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, whose XML form will be illustrated in Example 8:

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

RIF condition:

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

XML serialization:

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

Example 7 (An XML serialization of a RIF condition with a frame and a named-argument term).

This example illustrates XML serialization of RIF conditions that involve terms with named arguments. As in Example 6, we assume the following prefix directives, whose XML form will be illustrated in Example 8:

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

RIF condition:

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

XML serialization:

   <And>     <formula>       <Exists>         <declare><Var>Buyer</Var></declare>         <declare><Var>P</Var></declare>         <formula>           <And>             <formula>               <Member>                 <instance><Var>P</Var></instance>                 <class><Const type="&rif;iri">&cpt;purchase</Const></class>               </Member>             </formula>             <formula>               <Frame>                 <object>                   <Var>P</Var>                 </object>                 <slot ordered="yes">                   <Const type="&rif;iri">&cpt;buyer</Const>                   <Var>Buyer</Var>                 </slot>                 <slot ordered="yes">                   <Const type="&rif;iri">&cpt;seller</Const>                   <Var>Seller</Var>                 </slot>                 <slot ordered="yes">                   <Const type="&rif;iri">&cpt;item</Const>                   <Expr>                     <op><Const type="&rif;iri">&cpt;book</Const></op>                     <slot ordered="yes">                       <Name>&cpt;author</Name>                       <Var>Author</Var>                     </slot>                     <slot ordered="yes">                       <Name>&cpt;title</Name>                       <Const type="&rif;iri">&bks;LeRif</Const>                     </slot>                   </Expr>                 </slot>                 <slot ordered="yes">                   <Const type="&rif;iri">&cpt;price</Const>                   <Const type="&xs;integer">49</Const>                 </slot>                 <slot ordered="yes">                   <Const type="&rif;iri">&cpt;currency</Const>                   <Const type="&rif;iri">&curr;USD</Const>                 </slot>               </Frame>             </formula>           </And>         </formula>       </Exists>     </formula>     <formula>       <Equal>         <left><Var>Seller</Var></left>         <right><Var>Author</Var></right>       </Equal>     </formula>   </And>

4.2 XML for the Rule Language

We now extend the set of RIF-BLD serialization elements from SectionXML for RIF-BLD Condition Language by including rules, along with their enclosing groups and documents, as described in SectionEBNF for RIF-BLD Rule Language. The extended set includes the tags listed below.

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

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

While there is a RIF-BLD element tag for theImport directive, theBase andPrefix directives are not represented by RIF/XML tags: they are handled as follows (see also SectionMapping of the Rule Language).ABase directive in the presentation syntax becomes anxml:base attribute [XML-Base] in the XMLDocument tag.The base IRI specified as the value of that attribute applies to content of the RIF/XML element that deals withrif:iri constants, namely to relative-IRI content of the<Const type="&rif;iri"> element as well as symbol spaces, loation, and profile.A collection ofPrefix directives in the presentation syntax becomes aDOCTYPE DTD [XML1.0] preceding the RIF-BLDDocument and containing a declaration of anENTITY for eachPrefix directive.

Example 8 (Serializing a RIF-BLD document containing an annotated group).

This example shows a serialization for the document from Example 5. For convenience, the presentation syntax is reproduced at the top, and is followed by its serialization.The base IRIhttp://example.com/people# applies to the relativerif:iri constants with contentJohn (twice) andFred (once).

Presentation syntax:

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

XML syntax:

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

4.3 Mapping from the Presentation Syntax to the XML Syntax

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

4.3.1 Mapping of the Condition Language

Theχ_bld mapping from the presentation syntax to the XML syntax of the RIF-BLD Condition Language is specified by the table below. Each row indicates a translationχ_bld(Presentation) =XML. The functionremove-outer-quotes used in the translation removes enclosing double quotes from a string and leaves unquoted strings untouched. Since the presentation syntax of RIF-BLD is context sensitive, the mapping must differentiate between the terms that occur in the position of individuals and the terms that occur as atomic formulas. To this end, in the translation table, the positional and named-argument terms that occur in the context of atomic formulas are denoted by expressions of the formpred(...) and the terms that occur as individuals are denoted by expressions of the formfunc(...).In the table, each metavariable for an (unnamed) positionalargument_i is assumed to be instantiated to values unequal to the instantiations of named argumentsname_j->filler_j. Regarding the last but first row, we assume that shortcuts for constants [RIF-DTB] have already been expanded to their full form ("..."^^symspace).

Presentation Syntax	XML Syntax
And (conjunct₁ . . .conjunct_n )	<And> <formula>`χ_bld`(conjunct₁)</formula> . . . <formula>`χ_bld`(conjunct_n)</formula></And>
Or (disjunct₁ . . .disjunct_n )	<Or> <formula>`χ_bld`(disjunct₁)</formula> . . . <formula>`χ_bld`(disjunct_n)</formula></Or>
Existsvariable₁ . . .variable_n (premise )	<Exists> <declare>`χ_bld`(variable₁)</declare> . . . <declare>`χ_bld`(variable_n)</declare> <formula>`χ_bld`(premise)</formula></Exists>
External (atomexpr )	<External> <content>`χ_bld`(atomexpr)</content></External>
pred ( )	<Atom> <op>`χ_bld`(pred)</op></Atom>
pred (argument₁ . . .argument_m )	<Atom> <op>`χ_bld`(pred)</op> <args ordered="yes">`χ_bld`(argument₁) . . .`χ_bld`(argument_m) </args></Atom>
func ( )	<Expr> <op>`χ_bld`(func)</op></Expr>
func (argument₁ . . .argument_m )	<Expr> <op>`χ_bld`(func)</op> <args ordered="yes">`χ_bld`(argument₁) . . .`χ_bld`(argument_m) </args></Expr>
List (element₁ . . .element_n )	<List> <items ordered="yes">`χ_bld`(element₁) . . .`χ_bld`(element_n) </items></List>
List (element₁ . . .element_n \|remainder )	<List> <items ordered="yes">`χ_bld`(element₁) . . .`χ_bld`(element_n) </items> <rest>`χ_bld`(remainder)</rest></List>
pred (name₁ ->filler₁ . . .name_n ->filler_n )	<Atom> <op>`χ_bld`(pred)</op> <slot ordered="yes"> <Name>`χ_bld`(name₁)</Name>`χ_bld`(filler₁) </slot> . . . <slot ordered="yes"> <Name>`χ_bld`(name_n)</Name>`χ_bld`(filler_n) </slot></Atom>
func (name₁ ->filler₁ . . .name_n ->filler_n )	<Expr> <op>`χ_bld`(func)</op> <slot ordered="yes"> <Name>`χ_bld`(name₁)</Name>`χ_bld`(filler₁) </slot> . . . <slot ordered="yes"> <Name>`χ_bld`(name_n)</Name>`χ_bld`(filler_n) </slot></Expr>
inst [key₁ ->filler₁ . . .key_n ->filler_n ]	<Frame> <object>`χ_bld`(inst)</object> <slot ordered="yes">`χ_bld`(key₁)`χ_bld`(filler₁) </slot> . . . <slot ordered="yes">`χ_bld`(key_n)`χ_bld`(filler_n) </slot></Frame>
inst #class	<Member> <instance>`χ_bld`(inst)</instance> <class>`χ_bld`(class)</class></Member>
sub ##super	<Subclass> <sub>`χ_bld`(sub)</sub> <super>`χ_bld`(super)</super></Subclass>
left =right	<Equal> <left>`χ_bld`(left)</left> <right>`χ_bld`(right)</right></Equal>
"unicodestring"^^symspace	<Const type="symspace">unicodestring</Const>
?name₁	<Var>`χ_bld`(name₁)</Var>
name_i	remove-outer-quotes(name_i)

4.3.2 Mapping of the Rule Language

Theχ_bld mapping from the presentation syntax to the XML syntax of the RIF-BLD Rule Language is specified by the table below. It extends the translation table of SectionMapping of the Condition Language. While theImport directive is handled by the presentation-to-XML syntax mapping, thePrefix andBase directives are not. Instead, these directives should be handled by expanding the associated shortcuts (compact URIs).Namely, a prefix name declared in aPrefix directive is expanded into the associated IRI, while relative IRIs are completed using the IRI declared in theBase directive. The mappingχ_bld applies only to such expanded documents.RIF-BLD also allows other treatments ofPrefix andBase provided that they produce equivalent XML documents. One such treatment is employed in the examples in this document, especially Example 8. It replaces prefix names with definitions of XML entities as follows.EachPrefix declaration becomes anENTITY declaration [XML1.0] within aDOCTYPE DTD attached to the RIF-BLDDocument. TheBase directive is mapped to thexml:base attribute [XML-Base] in the XMLDocument tag.Compact URIs of the formprefix:suffix are then mapped to&prefix;suffix.

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

4.3.3 Mapping of Annotations

Theχ_bld mapping from RIF-BLD annotations in the presentation syntax to the XML syntax is specified by the table below.It extends the translation tables of SectionsMapping of the Condition Language andMapping of the Rule Language.The metavariableTypetag in the presentation and XML syntaxes stands for any of the class namesAnd,Or,External,Document, orGroup, andQuantifier forExists orForall. The dollar sign,$, stands for any of the binary infix operator names#,##,=, or:-, whileBinop stands for their respective class namesMember,Subclass,Equal, orImplies.Again, each metavariable for an (unnamed) positionalargument_i is assumed to be instantiated to values unequal to the instantiations of named argumentsname_j->filler_j.

Presentation Syntax	XML Syntax
(*iriconst?frameconj? )Typetag* (e₁ . . .e_n )	<Typetag> <id>`χ_bld`(iriconst)</id>? <meta>`χ_bld`(frameconj)</meta>?e₁' . . .e_n'</Typetag>`wheree₁', . . .,e_n' are defined by the equationχ_bld(Typetag(e₁ . . .e_n)) = <Typetag>e₁' . . .e_n'</Typetag>`
(*iriconst?frameconj? )Quantifier*variable₁ . . .variable_n (formula )	<Quantifier> <id>`χ_bld`(iriconst)</id>? <meta>`χ_bld`(frameconj)</meta>? <declare>`χ_bld`(variable₁)</declare> . . . <declare>`χ_bld`(variable_n)</declare> <formula>`χ_bld`(formula)</formula></Quantifier>
(*iriconst?frameconj? )pred* (argument₁ . . .argument_n )	<Atom> <id>`χ_bld`(iriconst)</id>? <meta>`χ_bld`(frameconj)</meta>? <op>`χ_bld`(pred)</op> <args ordered="yes">`χ_bld`(argument₁) . . .`χ_bld`(argument_n) </args></Atom>
(*iriconst?frameconj? )func* (argument₁ . . .argument_n )	<Expr> <id>`χ_bld`(iriconst)</id>? <meta>`χ_bld`(frameconj)</meta>? <op>`χ_bld`(func)</op> <args ordered="yes">`χ_bld`(argument₁) . . .`χ_bld`(argument_n) </args></Expr>
(*iriconst?frameconj? )List (element₁* . . .element_n )	<List> <id>`χ_bld`(iriconst)</id>? <meta>`χ_bld`(frameconj)</meta>? <items ordered="yes">`χ_bld`(element₁) . . .`χ_bld`(element_n) </items></List>
(*iriconst?frameconj? )List (element₁* . . .element_n \|remainder )	<List> <id>`χ_bld`(iriconst)</id>? <meta>`χ_bld`(frameconj)</meta>? <items ordered="yes">`χ_bld`(element₁) . . .`χ_bld`(element_n) </items> <rest>`χ_bld`(remainder)</rest></List>
(*iriconst?frameconj? )pred* (name₁ ->filler₁ . . .name_n ->filler_n )	<Atom> <id>`χ_bld`(iriconst)</id>? <meta>`χ_bld`(frameconj)</meta>? <op>`χ_bld`(pred)</op> <slot ordered="yes"> <Name>`χ_bld`(name₁)</Name>`χ_bld`(filler₁) </slot> . . . <slot ordered="yes"> <Name>`χ_bld`(name_n)</Name>`χ_bld`(filler_n) </slot></Atom>
(*iriconst?frameconj? )func* (name₁ ->filler₁ . . .name_n ->filler_n )	<Expr> <id>`χ_bld`(iriconst)</id>? <meta>`χ_bld`(frameconj)</meta>? <op>`χ_bld`(func)</op> <slot ordered="yes"> <Name>`χ_bld`(name₁)</Name>`χ_bld`(filler₁) </slot> . . . <slot ordered="yes"> <Name>`χ_bld`(name_n)</Name>`χ_bld`(filler_n) </slot></Expr>
(*iriconst?frameconj? )inst* [key₁ ->filler₁ . . .key_n ->filler_n ]	<Frame> <id>`χ_bld`(iriconst)</id>? <meta>`χ_bld`(frameconj)</meta>? <object>`χ_bld`(inst)</object> <slot ordered="yes">`χ_bld`(key₁)`χ_bld`(filler₁) </slot> . . . <slot ordered="yes">`χ_bld`(key_n)`χ_bld`(filler_n) </slot></Frame>
(*iriconst?frameconj? *)e₁$e₂	<Binop> <id>`χ_bld`(iriconst)</id>? <meta>`χ_bld`(frameconj)</meta>?e₁'e₂'</Binop>`whereBinop,e₁',e₂' are defined by the equationχ_bld(e₁$e₂) = <Binop>e₁'e₂'</Binop>`
(*iriconst?frameconj? )unicodestring^^symspace*	<Const type="symspace"> <id>`χ_bld`(iriconst)</id>? <meta>`χ_bld`(frameconj)</meta>?unicodestring</Const>
(*iriconst?frameconj? )?name₁*	<Var> <id>`χ_bld`(iriconst)</id>? <meta>`χ_bld`(frameconj)</meta>?`χ_bld`(name₁)</Var>

5 Conformance Clauses

RIF-BLD does not require or expect conformant systems to implement the RIF-BLD presentation syntax. Instead, conformance is described in terms of semantics-preserving transformations between the native syntax of a compliant system and the XML syntax of RIF-BLD.

Let Τ be a set of datatypes and symbol spaces that includes the datatypes specified in[RIF-DTB], and the symbol spacesrif:iri, andrif:local. Suppose Ε is acoherent set of external schemas that includes the built-ins listed in [RIF-DTB]. We say that a formula φ is aBLD_Τ,Ε formula iff

it is a well-formed BLD formula,
all datatypes and symbol spaces used in φ are in Τ, and
all externally defined terms used in φ are instantiations of external schemas from Ε.

A RIF processor is aconformantBLD_Τ,Εconsumer iff it implements asemantics-preserving mapping, μ, from the set of allBLD_Τ,Ε formulas to the languageL of the processor (μ does not need to be an "onto" mapping).

A RIF processor is aconformantBLD_Τ,Εproducer iff it implements asemantics-preserving mapping, ν, from the languageL of the processor to the set of allBLD_Τ,Ε formulas (ν does not need to be an "onto" mapping).

Formally, this means that for any pair φ, ψ of formulas inL for which φ |=_L ψ is defined, φ |=_L ψ iff ν(φ) |=_BLD ν(ψ).

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

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

RIF-BLD specific clauses

Conformant BLD producers and consumers are required to support only the entailments of the form φ |=_BLD ψ, where ψ is aclosed RIF condition formula, i.e., a RIF condition in which every variable,?V, is in the scope of a quantifier of the formExists ?V. In addition, conformant BLD producers and consumersshould preserve all annotations where possible.

Aconformant BLD consumer must reject any document containing features it does not support.

Aconformant BLD producer is a conformant BLD_Τ,Ε producer, which produces documents that include only the datatypes and externals that are required by BLD.

RIF-BLD supports a wide variety of syntactic forms for terms and formulas, which creates infrastructure for exchanging syntactically diverse rule languages. It is important to realize, however, that the above conformance statements make it possible for systems that do not support some of the syntax directly to still support it through syntactic transformations. For instance, disjunctions in rule premises can be eliminated through a standard transformation, such as replacingp :- Or(q r) with a pair of rulesp :- q, p :- r. Terms with named arguments can be reduced to positional terms by ordering the arguments by their names and incorporating the ordered argument names into the predicate name. For instance,p(bb->1 aa->2) can be represented asp_aa_bb(2 1).

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

This normative section describes RIF-BLD by specializing RIF-FLD. The reader isassumed to be familiar with RIF-FLD as described in RIF framework forlogic dialects [RIF-FLD]. The reader who is not interested in how RIF-BLD isderived from the framework can skip this section.

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

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

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

Extension points.
All extension points of RIF-FLD are removed (specialized by replacing them with zero objects).
Alphabet.
The alphabet of the RIF-BLD presentation syntax is the alphabet of RIF-FLD with the symbolsDialect,Neg, andNaf excluded.
Assignment of signatures to each constant and variable symbol.
The signature set of RIF-BLD contains the following signatures:
1. Basic
  - individual{ }
  - atomic{ }
  The signatureindividual{ } represents the context in which individual objects (but not atomic formulas) can appear.
  The signatureatomic{ } represents the context where atomic formulas can occur.
2. Signatures for lists
  - The signaturelist for closed lists. It has the following arrow expressions:() ⇒ individual,(individual) ⇒ individual,(individual individual) ⇒ individual, ...
  - The signatureopenlist for open lists (that have tails). It has the following arrow expressions:(individual individual) ⇒ individual,(individual individual individual) ⇒ individual, ...
3. Signatures for functions, predicates, and external functions and predicates
  - Function signaturef. This signature has the arrow expressions for positional functions:() ⇒ individual,(individual) ⇒ individual,(individual individual) ⇒ individual, ..., plus the arrow expressions for functions with named arguments:(s1->individual ... sk->individual) ⇒ individual}, for all k>0 and alls1, ..., sk ∈ArgNames.
  - Predicate signaturep. This signature has the arrow expressions for positional predicates:() ⇒ atomic,(individual) ⇒ atomic,(individual individual) ⇒ atomic, ..., plus the arrow expressions for predicates with named arguments:(s1->individual ... sk->individual) ⇒ atomic}, for all k>0 and alls1, ..., sk ∈ArgNames.
  In the RIF-BLD specialization of RIF-FLD, the argument namess1, ...,sk must be pairwise distinct.
4. Every symbol inConst has exactly one signature:individual,f, orp.
  A constant cannot have the signatureatomic -- only complex terms can have such signatures. Thus, by itself a symbol,s, cannot be a proposition in RIF-BLD, but a term of the forms() can.
  According to the above, each constant symbol in RIF-BLD can be either an individual, a function, or a predicate. However, the same function or predicate symbol (normal or external) can occur with different numbers of arguments in different places. Also, theadditional restrictions spelled out below ensure that the same symbol cannot represent both an externally defined predicate or function and a regular predicate or function.
5. The constant symbols that correspond to RIF datatypes (XML Schema datatypes,rdf:XMLLiteral,rdf:PlainLiteral, etc.) all have the signatureindividual in RIF-BLD.
6. The symbols of typerif:iri andrif:local can have the following signatures in RIF-BLD:individual,f, orp.
7. All variables are associated with signatureindividual, so they can range only over individuals.
8. The signature for equality is={(individual individual) ⇒atomic}.
  This means that equality can compare only those terms whose signature isindividual; it cannot compare predicate or function symbols. Equality terms are also not allowed to occur inside other terms, since the above signature implies that any term of the formt = s has signatureatomic and notindividual.
9. The frame signature,->, is->{(individual individual individual) ⇒atomic}.
  Note that this precludes the possibility that a frame term might occur as an argument to a predicate, a function, or inside some other term.
10. The membership signature,#, is#{(individual individual) ⇒ atomic}.
  Note that this precludes the possibility that a membership term might occur as an argument to a predicate, a function, or inside some other term.
11. The signature for the subclass relationship is##{(individual individual) ⇒atomic}.
  As with frames and membership terms, this precludes the possibility that a subclass term might occur inside some other term.
RIF-BLD uses no special syntax for declaring signatures. Instead, the rule author specifies signaturescontextually. That is, since RIF-BLD requires that each symbol is associated with a unique signature, the signature is determined from the context in which the symbol is used. If a symbol is used in more than one context, the parser must treat this as a syntax error. If no errors are found, all terms and atomic formulas are guaranteed to be well-formed. Thus, signatures arenot part of the RIF-BLD language, andindividual,atomic,list, etc., are not reserved keywords.
Supported types of terms.
- RIF-BLD supports the following types of terms defined by the syntactic framework (see the SectionTerms of [RIF-FLD]):
  1. constants
  2. variables
  3. positional
  4. with named arguments
  5. equality
  6. frame
  7. membership
  8. subclass
  9. list
  10. external
  11. formula
- Compared to RIF-FLD, terms (both positional and with named arguments) have significant restrictions, which are intended to keep BLD relatively simple.
  - Variables: The signature for the variable symbols does not permit them to occur in the context of predicates, functions, or formulas. In particular, in the RIF-BLD specialization of RIF-FLD, a variable is not an atomic formula.
  - Symbols as atomic formulas: A symbol cannot be an atomic formula by itself. That is, ifs ∈Const thens is not a well-formed atomic formula. However,s() can be an atomic formula. Note that Propositional Logic can thus be expressed in RIF-BLD using zero-argument predicate formulas.
  - Functions and predicates: Signatures permit only constant symbols to occur in the context of functions or predicate. Indeed, RIF-BLD signatures ensure that all variables have the signatureindividual{ } and all other terms, except for the constants fromConst, can have either the signatureindividual{ } oratomic{ }. Therefore, ift is a (non-Const) term thent(...) is not a well-formed term.
  - External:
    - A term,t, may appear as an external term or an external atomic formula (i.e., in the contextExternal(t))if and only ift is an instantiation of an externally defined schema fromthe coherent set of external schemas associated with the language.
      It thus follows that a predicate or a function symbol,s, that occurs in an external termExternal(s(...)) cannot also occur as a non-external symbol.
    - In an externally defined term,External(t), the subtermt can be only a positional or a named-argument term of the forms(...) wheres has the signaturef orp. Compared to RIF-FLD, this restrictst so that it cannot be a constant, a frame, an equality, or a classification term. RIF-FLD's two-argument form ofExternal is not supported in RIF-BLD either.
  - Formula: The formula terms are restricted, as specified inSupported formulas below. In particular, they cannot appear as arguments to predicates, functions, etc.
Noaggregate terms ormodule terms are allowed. (In RIF-FLD, formula terms correspond to compound formulas that involve logical connectives and quantifiers.)
Required symbol spaces.
RIF-BLD requires the symbol spaces defined in SectionConstants, Symbol Spaces, and Datatypes of [RIF-DTB].
Supported formulas.
RIF-BLD supports the following types of formulas (seeWell-formed Terms and Formulas in [RIF-FLD] for the definitions):
- RIF-BLD condition
  A RIF-BLD condition is an atomic formula, and external atomic formula, or a conjunctive or disjunctive combination of such atomic formulas. All these formulas and their combinations can be optionally preceded with existential quantifiers.
- RIF-BLD rule
  A RIF-BLD rule is a universally quantified RIF-FLD rule with the following restrictions:
  - The conclusion of the rule is an atomic formula or a conjunction of atomic formulas.
  - None of the atomic formulas mentioned in the rule conclusion is externally defined (i.e., cannot have the formExternal(...)).
  - The premise of the rule is a RIF-BLD condition.
  - All free (non-quantified) variables in the rule must be quantified withForall outside of the rule (i.e.,Forall ?vars (conclusion :- premise)).
- Universal fact
  A universal fact is a universally quantified atomic formula with no free variables.
- RIF-BLD group
  A RIF-BLD group is a RIF-FLD group that contains only RIF-BLD rules, universal facts, variable-free rule implications, variable-free atomic formulas, and RIF-BLD groups.
- RIF-BLD document
  A RIF-BLD document is a RIF-FLD document that consists of directives and a RIF-BLD group formula. There is noDialect orModule directives, and theImport(<loc>) directive (with one argument) can import RIF-BLD documents only. Hereloc must be a Unicode character sequence that forms an IRI. There are no BLD-specific restrictions on the two-argument directiveImport except that the second argument must be a Unicode sequence of characters of the form<loc>, whereloc is an IRI.
Negation (Neg andNaf) is not allowed in RIF-BLD rules: neither in rule conclusions nor in premises.

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

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

The semantics of the RIF Basic Logic Dialect is defined by specialization from the semantics of thesemantic framework for logic dialects of RIF. SectionSemantics of a RIF Dialect as a Specialization of the RIF Framework in [RIF-FLD] lists the parameters of the semantic framework that can be specialized. Thus, for RIF-BLD, we need to look at the following parameters:

The effect of the syntax.
RIF-BLD does not support negation. This is the only obvious simplification with respect to RIF-FLD as far as the semantics is concerned. The restrictions on the signatures of symbols in RIF-BLD do not affect the semantics in a significant way.
Truth values.
The setTV of truth values in RIF-BLD consists of two values,t andf, such thatf <_tt.
Datatypes.
RIF-BLD supports the datatypes listed in SectionDatatypes of [RIF-DTB].
Logical entailment.
Recall that logical entailment in RIF-FLD is defined with respect to an unspecified set of intended semantic structures and that dialects of RIF must make this notion concrete. For RIF-BLD, this set is defined as the set of all models.
Semantic multi-structures.
Since RIF-BLD has no modules (i.e., all formulas are in the same single module), a semantic multi-structureÎ has the form (Î_ren, {I}), i.e.,Î_set (in RIF-BLD multistructures) has only one semantic structure; the modularization mappingÎ_map plays no role and can be omitted.
Import directive.
The semantics of the two-argumentImport directive is given in [RIF-RDF+OWL]. The semantics of the one-argument directive is the same as in RIF-FLD.

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

SectionMapping from the RIF-FLDPresentation Syntax to the XML Syntax of[RIF-FLD]defines a mapping,χ_fld, from the presentation syntax ofRIF-FLD to its XML serialization. When restricted to well-formedRIF-BLD formulas,χ_fld coincides with theBLD-to-XML mappingχ_bld.In this way, the XML serialization of RIF-BLD is a specialization of theRIF-FLD XML Serialization Frameworkdefined in [RIF-FLD].

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

If T is a set of datatypes and symbol spaces and E acoherent set of external schemas for functions and predicates, then the general definition ofconformance in RIF-FLD yields the notion of conformant BLD_T,E producers and consumers.

BLD further requiresstrictness, i.e., that a conformant producer produces only the documents where T are precisely the datatypes/symbol spaces and E are the external schemas specified in [RIF-DTB], and that a conformant consumer consumes only such documents.

7 Acknowledgements

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

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

8 References

8.1 Normative References

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

[RFC-3066]: RFC 3066 - Tags for the Identification of Languages, H. Alvestrand, IETF, January 2001. This document is athttp://www.ietf.org/rfc/rfc3066.

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

[RIF-Core]: RIF Core Dialect (Second Edition) Harold Boley, Gary Hallmark, Michael Kifer, Adrian Paschke, Axel Polleres, Dave Reynolds, eds. W3C Recommendation, 5 February 2013,http://www.w3.org/TR/2013/REC-rif-core-20130205/. Latest version available athttp://www.w3.org/TR/rif-core/.

[RIF-DTB]: RIF Datatypes and Built-Ins 1.0 (Second Edition) Axel Polleres, Harold Boley, Michael Kifer, eds. W3C Recommendation, 5 February 2013,http://www.w3.org/TR/2013/REC-rif-dtb-20130205/. Latest version available athttp://www.w3.org/TR/rif-dtb/.

[RIF-FLD]: RIF Framework for Logic Dialects (Second Edition) Harold Boley, Michael Kifer, eds. W3C Recommendation, 5 February 2013,http://www.w3.org/TR/2013/REC-rif-fld-20130205/. Latest version available athttp://www.w3.org/TR/rif-fld/.

[RIF-PRD]: RIF Production Rule Dialect (Second Edition) Christian de Sainte Marie, Gary Hallmark, Adrian Paschke, eds. W3C Recommendation, 5 February 2013,http://www.w3.org/TR/2013/REC-rif-prd-20130205/. Latest version available athttp://www.w3.org/TR/rif-prd/.

[RIF-RDF+OWL]: RIF RDF and OWL Compatibility (Second Edition) Jos de Bruijn, Chris Welty, eds. W3C Recommendation, 5 February 2013,http://www.w3.org/TR/2013/REC-rif-rdf-owl-20130205/. Latest version available athttp://www.w3.org/TR/rif-rdf-owl/.

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

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

[XML Schema Datatypes]: W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson, Shudi Gao, Ashok Malhotra, C. M. Sperberg-McQueen, and Henry S. Thompson, eds. W3C Recommendation, 5 April 2012,http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/. Latest version available ashttp://www.w3.org/TR/xmlschema11-2/.

8.2 Informational References

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

[AG08]: The Expressive Power of SPARQL, Renzo Angles and Claudio Gutierrez.International Semantic Web Conference 2008: 114-129

[AP07]: From SPARQL to rules (and back), Axel Polleres.WWW 2007: 787-796

[CG]: Information Processing, John Sowa, inMind and Machine. JReading, MA: Addison-Wesley Publ., 1984.

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

[CL07]: ISO/IEC 24707:2007. The ISO Common Logic Standard. Available throughhttp://common-logic.org

[CURIE]: CURIE Syntax 1.0, S. McCarron, M. Birbeck, Editors, W3C Working Group Note, 16 December 2010,http://www.w3.org/TR/2010/NOTE-curie-20101216 . Latest version available athttp://www.w3.org/TR/curie.

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

[KIF]: Knowledge Interchange Format, M. Genesereth, et al. 1998. Available athttp://logic.stanford.edu/kif/dpans.html

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

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

[OWL-Reference]: OWL Web Ontology Language Reference, M. Dean, G. Schreiber, Editors, W3C Recommendation, 10 February 2004. Latest version available athttp://www.w3.org/TR/owl-ref/.

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

[RIF-UCR]: RIF Use Cases and Requirements (Second Edition) Adrian Paschke, Leora Morgenstern, David Hirtle, Allen Ginsberg, Paula-Lavinia Patranjan, Frank McCabe, eds. W3C Working Group Note, 5 February 2013,http://www.w3.org/TR/2013/NOTE-rif-ucr-20130205/. Latest version available athttp://www.w3.org/TR/rif-ucr/.

[Steele90]: Common LISP: The Language, Second Edition, G. L. Steele Jr. Digital Press, 1990.

[TRT03]: Object-Oriented RuleML: User-Level Roles, URI-Grounded Clauses, and Order-Sorted Terms, H. Boley. Springer LNCS 2876, Oct. 2003, pp. 1-16. Available athttp://nparc.cisti-icist.nrc-cnrc.gc.ca/npsi/ctrl?action=rtdoc&an=5764336&article=19&fd=pdf.

[URD08]: Uncertainty Treatment in the Rule Interchange Format: From Encoding to Extension, J. Zhao, H. Boley. 4th Int’l Workshop on Uncertainty Reasoning for the Semantic Web (URSW 2008). Available athttp://c4i.gmu.edu/ursw/2008/papers/URSW2008_F9_ZhaoBoley.pdf.

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

9 Appendix: XML Schema for RIF-BLD

Thenamespace of RIF is "http://www.w3.org/2007/rif#".

XML schemas for the RIF-BLD sublanguages are defined below and are also available athttp://www.w3.org/2010/rif-schema/bld/ with additional examples.

9.1 Condition Language

<?xml version="1.0" encoding="UTF-8"?>  <xs:schema   xmlns:xs="http://www.w3.org/2001/XMLSchema"   xmlns:xml="http://www.w3.org/XML/1998/namespace"  xmlns="http://www.w3.org/2007/rif#"  targetNamespace="http://www.w3.org/2007/rif#"  elementFormDefault="qualified"  version="Id: BLDCond.xsd, v. 1.6, 2010-05-08, dhirtle/hboley"> <xs:import namespace='http://www.w3.org/XML/1998/namespace'            schemaLocation='http://www.w3.org/2001/xml.xsd'/>    <xs:annotation>    <xs:documentation>    This is the XML schema for the Condition Language as defined by    the Last Call Draft of the RIF Basic Logic Dialect.        The schema is based on the following EBNF for the RIF-BLD Condition Language:   FORMULA        ::= IRIMETA? 'And' '(' FORMULA* ')' |                     IRIMETA? 'Or' '(' FORMULA* ')' |                     IRIMETA? 'Exists' Var+ '(' FORMULA ')' |                     ATOMIC |                     IRIMETA? 'External' '(' Atom ')'  ATOMIC         ::= IRIMETA? (Atom | Equal | Member | Subclass | Frame)  Atom           ::= UNITERM  UNITERM        ::= Const '(' (TERM* | (Name '->' TERM)*) ')'  Equal          ::= TERM '=' TERM  Member         ::= TERM '#' TERM  Subclass       ::= TERM '##' TERM  Frame          ::= TERM '[' (TERM '->' TERM)* ']'  TERM           ::= IRIMETA? (Const | Var | Expr | List | 'External' '(' Expr ')')  Expr           ::= UNITERM  List           ::= 'List' '(' TERM* ')' | 'List' '(' TERM+ '|' TERM ')'  Const          ::= '"' UNICODESTRING '"^^' SYMSPACE | CONSTSHORT  Var            ::= '?' Name  Name           ::= NCName | '"' UNICODESTRING '"'  SYMSPACE       ::= ANGLEBRACKIRI | CURIE   IRIMETA        ::= '(*' IRICONST? (Frame | 'And' '(' Frame* ')')? '*)'     </xs:documentation>  </xs:annotation>    <xs:group name="FORMULA">      <!--  FORMULA        ::= IRIMETA? 'And' '(' FORMULA* ')' |                     IRIMETA? 'Or' '(' FORMULA* ')' |                     IRIMETA? 'Exists' Var+ '(' FORMULA ')' |                     ATOMIC |                     IRIMETA? 'External' '(' Atom ')'    -->    <xs:choice>      <xs:element ref="And"/>      <xs:element ref="Or"/>      <xs:element ref="Exists"/>      <xs:group ref="ATOMIC"/>      <xs:element name="External" type="External-FORMULA.type"/>    </xs:choice>  </xs:group>    <xs:complexType name="External-FORMULA.type">    <!-- sensitive to FORMULA (Atom) context-->    <xs:sequence>      <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>      <xs:element name="content" type="content-FORMULA.type"/>    </xs:sequence>  </xs:complexType>    <xs:complexType name="content-FORMULA.type">    <!-- sensitive to FORMULA (Atom) context-->    <xs:sequence>      <xs:element ref="Atom"/>    </xs:sequence>  </xs:complexType>   <xs:element name="And">    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="formula" minOccurs="0" maxOccurs="unbounded"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="Or">    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="formula" minOccurs="0" maxOccurs="unbounded"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="Exists">    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="declare" minOccurs="1" maxOccurs="unbounded"/>        <xs:element ref="formula"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="formula">    <xs:complexType>      <xs:sequence>        <xs:group ref="FORMULA"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="declare">    <xs:complexType>      <xs:sequence>        <xs:element ref="Var"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:group name="ATOMIC">    <!--  ATOMIC         ::= IRIMETA? (Atom | Equal | Member | Subclass | Frame)    -->    <xs:choice>      <xs:element ref="Atom"/>      <xs:element ref="Equal"/>      <xs:element ref="Member"/>      <xs:element ref="Subclass"/>      <xs:element ref="Frame"/>    </xs:choice>  </xs:group>    <xs:element name="Atom">    <!--  Atom           ::= UNITERM    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="UNITERM"/>      </xs:sequence>    </xs:complexType>  </xs:element>      <xs:group name="UNITERM">    <!--  UNITERM        ::= Const '(' (TERM* | (Name '->' TERM)*) ')'    -->    <xs:sequence>      <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>      <xs:element ref="op"/>      <xs:choice>        <xs:element ref="args" minOccurs="0" maxOccurs="1"/>        <xs:element name="slot" type="slot-UNITERM.type" minOccurs="0" maxOccurs="unbounded"/>      </xs:choice>    </xs:sequence>  </xs:group>   <xs:element name="op">    <xs:complexType>      <xs:sequence>        <xs:element ref="Const"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="args">    <xs:complexType>      <xs:sequence>        <xs:group ref="TERM" minOccurs="1" maxOccurs="unbounded"/>      </xs:sequence>      <xs:attribute name="ordered" type="xs:string" fixed="yes"/>    </xs:complexType>  </xs:element>   <xs:complexType name="slot-UNITERM.type">    <!-- sensitive to UNITERM (Name) context-->    <xs:sequence>      <xs:element ref="Name"/>      <xs:group ref="TERM"/>    </xs:sequence>    <xs:attribute name="ordered" type="xs:string" fixed="yes"/>  </xs:complexType>   <xs:element name="Equal">    <!--  Equal          ::= TERM '=' TERM    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="left"/>        <xs:element ref="right"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="left">    <xs:complexType>      <xs:sequence>        <xs:group ref="TERM"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="right">    <xs:complexType>      <xs:sequence>        <xs:group ref="TERM"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="Member">    <!--  Member         ::= TERM '#' TERM    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="instance"/>        <xs:element ref="class"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="Subclass">    <!--  Subclass       ::= TERM '##' TERM    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="sub"/>        <xs:element ref="super"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="instance">    <xs:complexType>      <xs:sequence>        <xs:group ref="TERM"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="class">    <xs:complexType>      <xs:sequence>        <xs:group ref="TERM"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="sub">    <xs:complexType>      <xs:sequence>        <xs:group ref="TERM"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="super">    <xs:complexType>      <xs:sequence>        <xs:group ref="TERM"/>      </xs:sequence>    </xs:complexType>  </xs:element>      <xs:element name="Frame">    <!--  Frame          ::= TERM '[' (TERM '->' TERM)* ']'    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="object"/>        <xs:element name="slot" type="slot-Frame.type" minOccurs="0" maxOccurs="unbounded"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="object">    <xs:complexType>      <xs:sequence>        <xs:group ref="TERM"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:complexType name="slot-Frame.type">    <!-- sensitive to Frame (TERM) context-->    <xs:sequence>      <xs:group ref="TERM"/>      <xs:group ref="TERM"/>    </xs:sequence>    <xs:attribute name="ordered" type="xs:string" fixed="yes"/>  </xs:complexType>   <xs:group name="TERM">      <!--  TERM           ::= IRIMETA? (Const | Var | Expr | List | 'External' '(' Expr ')')    -->      <xs:choice>         <xs:element ref="Const"/>         <xs:element ref="Var"/>         <xs:element ref="Expr"/>         <xs:element ref="List"/>         <xs:element name="External" type="External-TERM.type"/>      </xs:choice>  </xs:group>  <xs:element name="List">      <!--  List           ::= 'List' '(' TERM* ')' | 'List' '(' TERM+ '|' TERM ')'             rewritten as  List           ::= 'List' '(' LISTELEMENTS? ')'    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:group ref="LISTELEMENTS" minOccurs="0" maxOccurs="1"/>      </xs:sequence>    </xs:complexType>  </xs:element>  <xs:group name="LISTELEMENTS">    <!--  LISTELEMENTS   ::= TERM+ ('|' TERM)?    -->    <xs:sequence>      <xs:element ref="items"/>      <xs:element ref="rest" minOccurs="0" maxOccurs="1"/>    </xs:sequence>  </xs:group>    <xs:element name="items">    <xs:complexType>      <xs:sequence>        <xs:group ref="TERM" minOccurs="1" maxOccurs="unbounded"/>      </xs:sequence>      <xs:attribute name="ordered" type="xs:string" fixed="yes"/>    </xs:complexType>  </xs:element>  <xs:element name="rest">    <xs:complexType>      <xs:sequence>        <xs:group ref="TERM"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:complexType name="External-TERM.type">    <!-- sensitive to TERM (Expr) context-->    <xs:sequence>      <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>      <xs:element name="content" type="content-TERM.type"/>    </xs:sequence>  </xs:complexType>    <xs:complexType name="content-TERM.type">    <!-- sensitive to TERM (Expr) context-->    <xs:sequence>      <xs:element ref="Expr"/>    </xs:sequence>  </xs:complexType>   <xs:element name="Expr">    <!--  Expr           ::= UNITERM    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="UNITERM"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="Const">    <!--  Const          ::= '"' UNICODESTRING '"^^' SYMSPACE | CONSTSHORT    -->    <xs:complexType mixed="true">      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>      </xs:sequence>      <xs:attribute name="type" type="xs:anyURI" use="required"/>       <xs:attribute ref="xml:lang"/>    </xs:complexType>  </xs:element>    <xs:element name="Name" type="xs:string">    <!--  Name           ::= NCName | '"' UNICODESTRING '"'     ... i.e., 'Name' stands for either the NCName string or the UNICODESTRING with the outer quotes stripped off.    -->  </xs:element>   <xs:element name="Var">    <!--  Var            ::= '?' Name    -->    <xs:complexType mixed="true">      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:group name="IRIMETA">    <!--  IRIMETA   ::= '(*' IRICONST? (Frame | 'And' '(' Frame* ')')? '*)'    -->    <xs:sequence>      <xs:element ref="id" minOccurs="0" maxOccurs="1"/>      <xs:element ref="meta" minOccurs="0" maxOccurs="1"/>    </xs:sequence>  </xs:group>   <xs:element name="id">    <xs:complexType>      <xs:sequence>        <xs:element name="Const" type="IRICONST.type"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="meta">    <xs:complexType>     <xs:choice>       <xs:element ref="Frame"/>       <xs:element name="And" type="And-meta.type"/>     </xs:choice>    </xs:complexType>  </xs:element>    <xs:complexType name="And-meta.type">  <!-- sensitive to meta (Frame) context-->    <xs:sequence>      <xs:element name="formula" type="formula-meta.type" minOccurs="0" maxOccurs="unbounded"/>    </xs:sequence>  </xs:complexType>   <xs:complexType name="formula-meta.type">    <!-- sensitive to meta (Frame) context-->    <xs:sequence>      <xs:element ref="Frame"/>    </xs:sequence>  </xs:complexType>    <xs:complexType name="IRICONST.type" mixed="true">    <!-- sensitive to location/id context-->    <xs:sequence/>    <xs:attribute name="type" type="xs:anyURI" use="required" fixed="http://www.w3.org/2007/rif#iri"/>  </xs:complexType>   </xs:schema>

9.2 Rule Language

<?xml version="1.0" encoding="UTF-8"?>  <xs:schema   xmlns:xs="http://www.w3.org/2001/XMLSchema"   xmlns:xml="http://www.w3.org/XML/1998/namespace"  xmlns="http://www.w3.org/2007/rif#"  targetNamespace="http://www.w3.org/2007/rif#"  elementFormDefault="qualified"  version="Id: BLDRule.xsd, v. 1.6, 2010-02-02, dhirtle/hboley">   <xs:annotation>    <xs:documentation>    This is the XML schema for the Rule Language as defined by    the Last Call Draft of the RIF Basic Logic Dialect.        The schema is based on the following EBNF for the RIF-BLD Rule Language:    Document  ::= IRIMETA? 'Document' '(' Base? Prefix* Import* Group? ')'  Base      ::= 'Base' '(' ANGLEBRACKIRI ')'  Prefix    ::= 'Prefix' '(' NCName ANGLEBRACKIRI ')'  Import    ::= IRIMETA? 'Import' '(' LOCATOR PROFILE? ')'  Group     ::= IRIMETA? 'Group' '(' (RULE | Group)* ')'  RULE      ::= (IRIMETA? 'Forall' Var+ '(' CLAUSE ')') | CLAUSE  CLAUSE    ::= Implies | ATOMIC  Implies   ::= IRIMETA? (ATOMIC | 'And' '(' ATOMIC* ')') ':-' FORMULA  LOCATOR   ::= ANGLEBRACKIRI  PROFILE   ::= ANGLEBRACKIRI          Note that this is an extension of the syntax for the RIF-BLD Condition Language (BLDCond.xsd).    </xs:documentation>  </xs:annotation>   <!-- The Rule Language includes the Condition Language from the same directory -->  <xs:include schemaLocation="BLDCond.xsd"/>   <xs:element name="Document">    <!--  Document  ::= IRIMETA? 'Document' '(' Base? Prefix* Import* Group? ')'    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="directive" minOccurs="0" maxOccurs="unbounded"/>        <xs:element ref="payload" minOccurs="0" maxOccurs="1"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="directive">    <!--  Base and Prefix represented directly in XML    -->    <xs:complexType>      <xs:sequence>        <xs:element ref="Import"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="payload">    <xs:complexType>      <xs:sequence>        <xs:element ref="Group"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="Import">    <!--  Import    ::= IRIMETA? 'Import' '(' LOCATOR PROFILE? ')'  LOCATOR   ::= ANGLEBRACKIRI  PROFILE   ::= ANGLEBRACKIRI    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>         <xs:element ref="location"/>        <xs:element ref="profile" minOccurs="0" maxOccurs="1"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="location" type="xs:anyURI"/>   <xs:element name="profile" type="xs:anyURI"/>    <xs:element name="Group">    <!--  Group     ::= IRIMETA? 'Group' '(' (RULE | Group)* ')'    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="sentence" minOccurs="0" maxOccurs="unbounded"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="sentence">   <xs:complexType>     <xs:choice>       <xs:group ref="RULE"/>       <xs:element ref="Group"/>     </xs:choice>   </xs:complexType> </xs:element>    <xs:group name="RULE">    <!--  RULE      ::= (IRIMETA? 'Forall' Var+ '(' CLAUSE ')') | CLAUSE    -->    <xs:choice>      <xs:element ref="Forall"/>      <xs:group ref="CLAUSE"/>    </xs:choice>  </xs:group>   <xs:element name="Forall">    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="declare" minOccurs="1" maxOccurs="unbounded"/>        <!-- different from formula in And, Or and Exists -->        <xs:element name="formula">          <xs:complexType>            <xs:group ref="CLAUSE"/>          </xs:complexType>        </xs:element>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:group name="CLAUSE">      <!--  CLAUSE   ::= Implies | ATOMIC    -->    <xs:choice>      <xs:element ref="Implies"/>      <xs:group ref="ATOMIC"/>    </xs:choice>  </xs:group>    <xs:element name="Implies">    <!--  Implies   ::= IRIMETA? (ATOMIC | 'And' '(' ATOMIC* ')') ':-' FORMULA    -->    <xs:complexType>      <xs:sequence>        <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/>        <xs:element ref="if"/>        <xs:element ref="then"/>      </xs:sequence>    </xs:complexType>  </xs:element>   <xs:element name="if">    <xs:complexType>      <xs:sequence>        <xs:group ref="FORMULA"/>      </xs:sequence>    </xs:complexType>  </xs:element>    <xs:element name="then">    <xs:complexType>     <xs:choice>       <xs:group ref="ATOMIC"/>       <xs:element name="And" type="And-then.type"/>     </xs:choice>    </xs:complexType>  </xs:element>   <xs:complexType name="And-then.type">    <!-- sensitive to then (ATOMIC) context-->    <xs:sequence>      <xs:element name="formula" type="formula-then.type" minOccurs="0" maxOccurs="unbounded"/>    </xs:sequence>  </xs:complexType>   <xs:complexType name="formula-then.type">    <!-- sensitive to then (ATOMIC) context-->    <xs:sequence>      <xs:group ref="ATOMIC"/>    </xs:sequence>  </xs:complexType>    </xs:schema>

10 Appendix: Change Log (Informative)

This appendix summarizes the main changes to this document.

Changes since thedraft of July 30, 2008.

The definition of entailment in SectionLogical Entailment relied on the notion of a "query document," which was not defined. The definitions in SectionsInterpretation of Documents andLogical Entailment has been changed to eliminate this and related problems.
SectionEBNF Grammar for the Presentation Syntax of RIF-BLD now presents the EBNF of the entire language in one place. Previously the EBNF was given forst for the condition sublanguage and then repeated again when the entire rule language is defined.
Symbols can now have many different arities.
Lists have been added.
Import: the first argument is now a character sequence that forms and IRI.
Base, Prefix, Import: IRIs are now delimited with angle brackets.
Numerous clarifications and explanations were added in response to the public comments.
A number of typos were found and fixed.

Changes since thedraft of July 3, 2009.

A definedness condition was added to the definition of logical entailment.
The bag of attribute/value pairs example was better explained.
IRICONST was replaced with ANYURICONST in BLDRule.xsd, v. 1.5.
A number of typos were found and fixed.
"instance" of an external schema was replaced with "instantiation" of an external schema.

Changes since theCandidate Recommendation of October 1, 2009.

Import's anyURIs were moved directly into location and profile.
A number of typos was fixed and various clarifications added.
Simplified notion of conformant BLD consumer.
Fixed List by permitting IRIMETA and aligning syntax to Expr and Atom.

Changes since theRecommendation of June 22 2010.

Definitions in SectionInterpretation of Documents have been rewritten and significantly simplified.
In SectionThe Semantics of RIF-BLD as a Specialization of RIF-FLD, a paragraph added about specialization from RIF-FLD semantic multi-structures.
Other minor corrections (seehere andhere).
Two new rows added in the table of SectionMapping of the Condition Language for empty args in Atom and Expr; restriction of earlier Atom and Expr rows to non-empty args (replaced n with m).

[8]ページ先頭