Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document, developed by the Rule
Interchange Format (RIF) Working Group, specifies athe Basic
format,Logic Dialect, RIF-BLD, a format that allows logic rules to be
exchanged between rule systems. The RIF-BLD presentation syntax and
semantics are specified both directly and as specializations of the
RIF Framework.Framework for Logic-based Dialects. The XML serialization
syntax of RIF-BLD, obtained via a mapping from the presentation
syntax, is specified inusing XML Schema.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is being published as one of a set of 26 documents:
The Rule Interchange Format (RIF) Working Group seeks public feedback on these Working Drafts. Please send your comments to public-rif-comments@w3.org (public archive). If possible, please offer specific changes to the text that would address your concern. You may also wish to check the Wiki Version of this document for internal-review comments and changes being drafted which may address your concerns.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This specification
develops RIF-BLD (the Basic Logic
Dialect of the Rule Interchange
Format). From a theoretical perspective, RIF-BLD corresponds
to the language of definite Horn rules (see Horn Logic )with equality and witha standard
first-order semantics.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
data types.datatypes [XML-SCHEMA2]. In
addition, the documentRIF RDF and OWL Compatibility [RIF-RDF+OWL] defines the syntax and semantics of
integrated RIF-BLD/RDF and RIF-BLD/OWL languages. These features
make RIF-BLD a Web-aware language. However, it should be kept in
mind that RIF is designed to enable interoperability among rule
languages in general, and its uses are not limited to the Web.
RIF-BLD is defined in two different ways -- both normative:
Independently of the RIF framework for logic dialects, for the benefit of those who desire a quicker path to RIF-BLD, e.g. as prospective implementers, and are not interested in the extensibility issues. This version of the RIF-BLD specification is given first.Logic-based RIF dialects that specialize or extend RIF-BLD in
accordance with the RIF Framework for Logic Dialects [RIF-FLD] will be developed in other
specifications by thisthe RIF working group.
To give a preview, here is a simple complete RIF-BLD example deriving a ternary relation from its inverse.
Example 1 (An introductory RIF-BLD example).
An EnglishA rule can be usedwritten in English to derive buy
relationships (rather than tostore any of them) from sell
relationships (e.g., stored as Englishfacts, as exemplified by the second
line):
The fact Mary buys LeRif from John can be logically derived by a modus ponens argument. Assuming Web IRIs for the predicates buy and sell, as well as for the individuals John, Mary, and LeRif, the above English text can be represented in RIF-BLD Presentation Syntax as follows.
Document( Prefix(cpt http://example.com/concepts#) Prefix(ppl http://example.com/people#) Prefix(bks http://example.com/books#) Group ( Forall ?Buyer ?Item ?Seller ( cpt:buy(?Buyer ?Item ?Seller) :- cpt:sell(?Seller ?Item ?Buyer) ) cpt:sell(ppl:John bks:LeRif ppl:Mary) ) )
For the interchange of such rule (and fact) documents, an equivalent RIF-BLD XML Syntax is given in this specification. To formalize their meaning, a RIF-BLD Semantics is specified.
This normative section specifies the syntax of RIF-BLD directly,
without relying on [RIF-FLD .].
We define both the presentation syntax (below) and an
XML syntax.syntax in Section XML
Serialization Syntax for RIF-BLD. The presentation syntax is
normative, but not intended to be a concrete syntax for
RIF-BLD. It is defined in mathematical English and is meant to be
used in the definitions and examples. This syntax deliberately
leaves out details such as the delimiters of the various
syntactic components, escape symbols, parenthesizing, precedence of
operators, and the like. Since RIF is an interchange format, it
uses XML as its concrete syntax and RIF-BLD conformance is described in terms of semantics-preserving
transformations.
Note to the reader: this section depends on Section Constants, Symbol
Spaces, and Data TypesDatatypes of the document Data Types and Built-Ins, Version 1.0 .[RIF-DTB].
Definition (Alphabet). The alphabet of the presentation language of RIF-BLD consists of
The set of connective symbols, quantifiers, =, etc., is disjoint from Const and Var. The argument names in ArgNames are written as unicode strings that must not start with a question mark, "?". Variables are written as Unicode strings preceded with the symbol "?".
Constants are written as "literal"^^symspace, where
literal is a sequence of Unicode characters and
symspace is an identifier for a symbol space. Symbol
spaces are defined in Section Constants and
Symbol Spaces of the document Data Types and Built-Ins, Version 1.0 .[RIF-DTB].
The symbols =, #, and ## are used in
formulas that define equality, class membership, and subclass
relationships. The symbol -> is used in terms that have
named arguments and in frame formulas. The symbol External
indicates that an atomic formula or a function term is defined
externally (e.g., a builtin)built-in) and the symbols Prefix and
Base are used in abridged representations of IRIs.
The symbol Document is used to specify RIF-BLD documents, Import is an import directive, and the symbol Group is used to organize RIF-BLD formulas into collections. ☐
The language of RIF-BLD is the set of formulas constructed using the above alphabet according to the rules given below.
RIF-BLD defines several kinds of terms: constants and variables, positional terms, terms with named arguments, plus equality, membership, subclass, frame, and external terms. The word "term" will be used to refer to any of these constructs.
To simplify the language in the next definition, we will use the following terminology:
Definition (Term).
The constant t here represents a predicate or a function; s1, ..., sn represent argument names; and v1, ..., vn represent argument values. The argument names, s1, ..., sn, are required to be pairwise distinct. Terms with named arguments are like positional terms except that the arguments are named and their order is immaterial. Note that a term of the form f() is both positional and with named arguments.
Membership, subclass, and frame terms are used to describe objects and class hierarchies.
Such terms are used for representing builtinbuilt-in functions and
predicates as well as "procedurally attached" terms or predicates,
which might exist in various rule-based systems, but are not
specified by RIF.
Note that frame terms are allowed to be externally defined. Therefore, externally defined objects can be accessed using the more natural frame-based interface. For instance, External("http://example.com/acme"^^rif:iri["http://example.com/mycompany/president"^^rif:iri(?Year) -> ?Pres]) could be an interface provided to access an externally defined method "http://example.com/mycompany/president"^^rif:iri of an external object "http://example.com/acme"^^rif:iri. ☐
Feature At Risk #1: External frames
Note: This feature is "at risk" and may be removed from this specification based on feedback. Please send feedback to public-rif-comments@w3.org.
Observe that the argument names of frame terms,
p1, ..., pn, are base terms
and, as a special case, can be variables. In contrast, terms with
named arguments can use only the symbols from ArgNames to
represent their argument names. They cannot be constants from
Const or variables from Var. The(The reason for this
restriction has to do with the complexity of unification, which is
integral part of manyused by several inference rules underlyingmechanisms of first-order logic.logic.)
Any term (positional or with named arguments) of Termsthe set of all symbols, Constform
p(...), where p is partitioned into positional predicate symbols predicate symbols with named arguments positional function symbols function symbols with named arguments individuals. The symbols in Const that belong to the supported RIF data types are individuals. Eacha predicate and function symbol has precisely one aritysymbol, is also an
atomic formula. For positional symbols,Equality, membership, subclass, and
frame terms are also atomic formulas. An arity is a non-negative integer that tells how many argumentsexternally defined term of
the symbol can take. For symbols that take named arguments,form External(φ), where φ is an arityatomic
formula, is a set {s 1 ... s k } of argument names ( s i ∈ ArgNames )also an atomic formula, called an externally
defined atomic formula.
Note that simple terms (constants and variables) are allowed for that symbol.not
formulas.
More general formulas are constructed out of the arityatomic formulas
with the help of logical connectives.
Definition
(Formula). A symbol (or whether itformula is a predicate, a function, or an individual)statement that has one
of the following forms:
Condition formulas are intended to be used inside some other term.the aritypremises
of rules. Next we define the symbolnotion of RIF-BLD rules, sets of
rules, and its typeRIF documents.
Feature At Risk #2: Equality in the rule conclusion (φ in the above)
Note: This feature is "at risk"
and Built-Ins, Version 1.0may be removed from this specification based on feedback.
Please send feedback to public-rif-comments@w3.org.
Universal facts are often considered to be rules without premises (or having true as their premises).
Group formulas are used to represent sets of rules and facts.
Note that is always true. Disjunction : If φ 1 , ...,some of the φ n , n ≥ 0 , are well-formed conditioni's can be group
formulas then so is Or(φthemselves, which means that groups can be nested.
Like prefix directives, base directives do not affect the
rule conclusion ( φsemantics. They are used as syntactic shortcuts for expanding
relative IRIs into full IRIs, as described in Section Constants and
Symbol Spaces of [RIF-DTB].
Prefix Forall ?V 1 ... ?V n . Quantified rules will also be referred to as RIF-BLD rules . Group : If ρ 1 , ..., ρ n are RIF-BLD rules or well-formed group formulas (they can be mixed) then Group(ρ 1 ... ρ n ) is a well-formed group formula . Group formulasdirectives do not affect the semantics of RIF documents.
Instead, they are used as shorthands to represent sets of rules. Note that some of the ρ i 's can be group formulas themselves, which means that groups can be nested. Document : An expressionallow more concise
representation of the form Document( directive 1 ... directive n Γ) is a well-formed RIF-BLD document formula (or simply a document formula ), if ΓIRI constants. This mechanism is a well-formed group formula that makes the actual logical content of the document. directive 1 , ..., directive n are directives . A directive can be an import directive , a prefix directive , or a base directiveexplained in
[RIF-DTB], Section Constants and
Symbol Spaces.
Section Direct
Specification of RIF-BLD Semantics of this document defines the
semantics for the directive Import(t) only. The semantics
of the directive Import(t p) is given in the document RIF RDF and OWL Compatibility .[RIF-RDF+OWL]. It is used for importing
non-RIF-BLD logical entities, such as RDF data and OWL ontologies.
The profile specifies what kind of entity is being imported and
under what semantics (for instance, the various RDF entailment
regimes).
A prefixThere can be at most one Base directive hasin the form Prefix(p v) , where p is an alphanumeric string that serves assequence
of directives in a document formula. It must be the first directive
in the sequence, if present, followed by a sequence of
Prefix name and v isdirectives (again, if present), followed by a
macro-expansion for p --sequence of Import directives.
In this definition, the component formulas φ, φi, ψi, and Γ are said to be subformulas of the respective formulas (condition, rule, group, etc.) that are built with the help of these components. ☐
The above definitions endow RIF-BLD with a wide variety of
syntactic forms for terms and formulas, which creates
infrastructure for exchanging syntactically diverse rule languages.
Systems that do not support some of the syntax directly can still
support it through syntactic transformations. For instance,
disjunctions in the rule body can be eliminated through a standard
transformation, such as replacing p :- Or(q r) with a
pair of rules p :- q, p :- r. Terms with
named arguments can be reduced to positional terms by ordering the
arguments by their names and incorporating them into the predicate
name. For instance, p(bb->1 aa->2) can be
represented as p_aa_bb(2,1).
RIF-BLD allows every term and formula (including terms and formulas that occur inside other terms and formulas) to be optionally preceded by an annotation of the form (* id φ *), where id is a rif:iri constant and φ is a frame formula or a conjunction of frame formulas. Both items inside the annotation are optional. The id part represents the identifier of the term/formula to which the annotation is attached and φ is the metadata part of the annotation. RIF-BLD does not impose any restrictions on φ apart from what is stated above. In particular, it may include variables, function symbols, rif:local constants, and so on.
Document formulas with and without annotations will be referred to as RIF-BLD documents.
A conventionconvention is used to avoid a syntactic ambiguity in the above
definition. For instance, in (* id φ *) t[w -> v] the
metadata annotation could be attributed to the term t or
to the entire frame t[w -> v]. The convention in
RIF-BLD is that the above annotation is considered to be
syntactically attached to the entire frame. Yet, since φ
is a conjunction, some conjuncts can be used to provide metadata
targeted to the object part, t, of the frame. Generally,
the convention associates each annotation to the largest term or
formula it precedes.
It is suggested to use Dublin Core, RDFS, and OWL properties for metadata, along the lines of Section 7.1 of [OWL-Reference]-- specifically owl:versionInfo, rdfs:label, rdfs:comment, rdfs:seeAlso, rdfs:isDefinedBy, dc:creator, dc:description, dc:date, and foaf:maker.
Not all formulas and thus not all documents are well-formed in RIF-BLD: a requirement is that no constant is allowed to appear in more than one context. What this means precisely is explained below.
The set of all constant symbols, Const, is partitioned into several subsets as follows:
Again, one subset per symbol arity and symbols for externally defined predicates are in their own subsets.
As before, one subset per symbol arity and symbols with named arguments and for externally defined predicates are in their own subsets.
The symbols in Const that belong to the primitive datatypes are required to be individuals.
Each predicate and function symbol has precisely one arity.
An important point is that neither the above partitioning of constant symbols nor the arity are specified explicitly. Instead, the arity of a symbol and its type is determined by the context in which the symbol is used.
Definition (Context of a symbol). The context of an occurrence of a symbol, s∈Const, in a formula, φ, is determined as follows:
Definition (Imported document). Let Δ be a document formula and Import(t) be one of its import directives, where t is an IRI constant that identifies another document formula, Δ'. We say that Δ' is directly imported into Δ.
A document formula Δ' is said to be imported into Δ if it is either directly imported into Δ or it is imported (directly or not) into some other formula that is directly imported into Δ. ☐
Definition
(Well-formed formula). A formula φ is
used to avoid a syntactic ambiguitywell-formed iff:
Definition
(Language of RIF-BLD). The frame. Generally, the convention associates each annotation tolanguage of RIF-BLD
consists of the largest term or formula it precedes. It is suggested to use Dublin Core, RDFS,set of all well-formed formulas and OWL properties for metadata, alongis determined
by:
So far, the syntax of RIF-BLD has been specified in mathematical English. Tool developers, however, may prefer EBNF notation, which provides a more succinct overview of the syntax. Several points should be kept in mind regarding this notation.
The Condition Language represents formulas that can be used in the body of RIF-BLD rules. The EBNF grammar for a superset of the RIF-BLD condition language is as follows.
FORMULA ::= IRIMETA? 'And' '(' FORMULA* ')' | IRIMETA? 'Or' '(' FORMULA* ')' | IRIMETA? 'Exists' Var+ '(' FORMULA ')' | ATOMIC | IRIMETA? 'External' '(' Atom | Frame ')' ATOMIC ::= IRIMETA? (Atom | Equal | Member | Subclass | Frame) Atom ::= UNITERM UNITERM ::= Const '(' (TERM* | (Name '->' TERM)*) ')' Equal ::= TERM '=' TERM Member ::= TERM '#' TERM Subclass ::= TERM '##' TERM Frame ::= TERM '[' (TERM '->' TERM)* ']' TERM ::= IRIMETA? (Const | Var | Expr | 'External' '(' Expr ')') Expr ::= UNITERM Const ::= '"' UNICODESTRING '"^^' SYMSPACE | CONSTSHORT IRICONST ::= '"' IRI '"^^' 'rif:iri' Name ::= UNICODESTRING Var ::= '?' UNICODESTRING SYMSPACE ::=UNICODESTRINGANGLEBRACKIRI | CURIE IRIMETA ::= '(*' IRICONST? (Frame | 'And' '(' Frame* ')')? '*)'
As explained in Section RIF-BLD Annotations in the Presentation Syntax,
RIF-BLD formulas and terms can be prefixed with optional
annotations, IRIMETA,IRIMETA, for identification and metadata, will be further explained in Section EBNF for RIF-BLD Rule Language .metadata.
IRIMETA is represented using (*...*)-brackets that contain
an optional IRI constant, IRICONST, as identifier
followed by an optional Frame or conjunction of
Frames as metadata. The IRI of an
IRICONST has the form of an internationalized resource
identifier as defined by [RFC-3987].
The production rule for the non-terminal FORMULA represents RIF condition formulas (defined earlier). The connectives And and Or define conjunctions and disjunctions of conditions, respectively. Exists introduces existentially quantified variables. Here Var+ stands for the list of variables that are free in FORMULA. RIF-BLD conditions permit only existential variables. A RIF-BLD FORMULA can also be an ATOMIC term, i.e. an Atom, External Atom, Equal, Member, Subclass, or Frame. A TERM can be a constant, variable, Expr, or External Expr.
The RIF-BLD presentation syntax does not commit to any
particular vocabulary and permits arbitrary Unicode strings in
constant symbols, argument names, and variables. Constant symbols
can have thethis form: "UNICODESTRING"^^SYMSPACE, where
SYMSPACE is a Unicode stringANGLEBRACKIRI or CURIE
that represents an identifier or an aliasof the symbol space of the constant,
and UNICODESTRING is a Unicode string from the lexical
space of that symbol space. Shortcuts for constantsANGLEBRACKIRI and
CURIE are defined in Section Shortcuts for Constants in RIF's Presentation Syntax of
[RIF-DTB]. Constant symbols can
also have several shortcut forms, which are represented by the
document Data Types and Built-Ins, Version 1.0non-terminal CONSTSHORT. These shortcuts are also defined
in the same section of [RIF-DTB]. One of them is the CURIE shortcut, which
is extensively used in the examples in this document. Names are
denoted byUnicode character sequences. Variables are denoted by acomposed of
UNICODESTRING symbols prefixed with a ?-sign.
Equality, membership, and subclass terms are self-explanatory. An Atom and Expr (expression) can either be positional or with named arguments. A frame term is a term composed of an object Id and a collection of attribute-value pairs. An External(Atom) is a call to an externally defined predicate; External(Frame) is a call to an externally defined frame. Likewise, External(Expr) is a call to an externally defined function.
Example 2 (RIF-BLD conditions).
This example shows conditions that are composed of atoms,
expressions, frames, and existentials. In frame formulas variables
are shown in the positions of object Ids, object properties, and
property values. For brevity, we use the CURIE shortcut
notation prefix:suffix ,for constant symbols, which is
understood as a macro that expands into an IRI obtained by
concatenation of the prefix definition and
suffix. Thus, if bks is a prefix that expands
into http://example.com/books# then bks:LeRif is
an abbreviation for
"http://example.com/books#LeRif"^^rif:iri. This and other
shortcuts are defined in the document Data Types and Built-Ins, Version 1.0 .[RIF-DTB]. Assume that the following prefix directives appear
in the preamble to the document:
Prefix(bks http://example.com/books#) Prefix(auth http://example.com/authors#) Prefix(cpt http://example.com/concepts#)
Positional terms: cpt:book(auth:rifwg bks:LeRif) Exists ?X (cpt:book(?X bks:LeRif)) Terms with named arguments: cpt:book(cpt:author->auth:rifwg cpt:title->bks:LeRif) Exists ?X (cpt:book(cpt:author->?X cpt:title->bks:LeRif)) Frames: bks:wd1[cpt:author->auth:rifwg cpt:title->bks:LeRif] Exists ?X (bks:wd2[cpt:author->?X cpt:title->bks:LeRif]) Exists ?X (And (bks:wd2#cpt:book bks:wd2[cpt:author->?X cpt:title->bks:LeRif])) Exists ?I ?X (?I[cpt:author->?X cpt:title->bks:LeRif]) Exists ?I ?X (And (?I#cpt:book ?I[cpt:author->?X cpt:title->bks:LeRif])) Exists ?S (bks:wd2[cpt:author->auth:rifwg ?S->bks:LeRif]) Exists ?X ?S (bks:wd2[cpt:author->?X ?S->bks:LeRif]) Exists ?I ?X ?S (And (?I#cpt:book ?I[author->?X ?S->bks:LeRif]))
The presentation syntax for RIF-BLD rules extends the syntax in Section EBNF for RIF-BLD Condition Language with the following productions.
Document ::= IRIMETA? 'Document' '('DIRECTIVE*Base? Prefix* Import* Group? ')'DIRECTIVE::=Import|Prefix|BaseImport::=IRIMETA?'Import''Base' '('IRICONSTProfile?IRI ')' Prefix ::= 'Prefix' '(' Name IRI ')'BaseImport ::='Base'IRIMETA? 'Import' '('IRIIRICONST PROFILE? ')' Group ::= IRIMETA? 'Group' '(' (RULE | Group)* ')' RULE ::= (IRIMETA? 'Forall' Var+ '(' CLAUSE ')') | CLAUSE CLAUSE ::= Implies | ATOMIC Implies ::= IRIMETA? (ATOMIC | 'And' '('ATOMIC*')')':-'FORMULAIRICONST::='"'IRI'"^^''rif:iri'Profile::=UNICODESTRINGIRIMETA::='(*'IRICONST?(Frame|'And''('Frame*')')?'*)'ATOMIC* ')') ':-' FORMULA PROFILE ::= TERM
For convenience, we reproduce the condition language part of the EBNF below.
FORMULA ::= IRIMETA? 'And' '(' FORMULA* ')' | IRIMETA? 'Or' '(' FORMULA* ')' | IRIMETA? 'Exists' Var+ '(' FORMULA ')' | ATOMIC | IRIMETA? 'External' '(' Atom | Frame ')' ATOMIC ::= IRIMETA? (Atom | Equal | Member | Subclass | Frame) Atom ::= UNITERM UNITERM ::= Const '(' (TERM* | (Name '->' TERM)*) ')' Equal ::= TERM '=' TERM Member ::= TERM '#' TERM Subclass ::= TERM '##' TERM Frame ::= TERM '[' (TERM '->' TERM)* ']' TERM ::= IRIMETA? (Const | Var | Expr | 'External' '(' Expr ')') Expr ::= UNITERM Const ::= '"' UNICODESTRING '"^^' SYMSPACE | CONSTSHORT IRICONST ::= '"' IRI '"^^' 'rif:iri' Name ::= UNICODESTRING Var ::= '?' UNICODESTRING SYMSPACE ::=UNICODESTRINGAsexplainedinSectionRIF-BLDAnnotationsinthePresentationSyntax,RIF-BLDformulasandtermscanbeprefixedwithoptionalannotations,IRIMETA,foridentificationandmetadata.ANGLEBRACKIRI | CURIE IRIMETAisrepresentedusing(*...*)-brackets::= '(*' IRICONST? (Frame | 'And' '(' Frame* ')')? '*)'
Recall that contain an optional IRI constant as identifier followed by an optional Frame or conjunction of Frame s as metadata.an IRI has the form of an internationalized
resource identifier as defined by [RFC-3987].
A RIF-BLD
Document consists of an optional DIRECTIVE preamble and an optional Group main part. A DIRECTIVE can beBase, followed
by any number of Import s,Prefixes, or Basefollowed by any number of
Imports, the latter twofollowed by an optional Group.
Base and Prefix just servingserve as shortcut mechanisms
for (long) IRIs. An Import indicates the location of a
document to be imported and an optional profile. A RIF-BLD
Group is a nested collection of any number of
RULE selements along with any number of nested
Groups.
Rules are generated byusing CLAUSE , which can beelements. The
RULE production has two alternatives:
Frame, Var, ATOMIC, and
FORMULA were defined as part of the syntax for positive
conditions in Section EBNF for RIF-BLD Condition Language. In the CLAUSE
production, an ATOMIC is what is usually called a
fact. An Implies rule can have an
ATOMIC or a conjunction of ATOMIC selements as
conclusion; it has a FORMULA as premise. Note that, by a
definition in Section Formulas, formulas that query externally defined atoms
(i.e., formulas of the form External(Atom(...))) are not
allowed in the conclusion part of a rule (ATOMIC does not
expand to External).
Example 3 (RIF-BLD rules).
This example shows a business rule borrowed from the document RIF Use Cases and Requirements:
As before, for better readability we use the compact URI
notation defined in Data Types and Built-Ins, Version 1.0 ,[[RIF-DTB],
Section Constants and Symbol Spaces. Again, prefix directives are
assumed in the preamble to the document. Then, two versions of the
main part of the document are given.
Prefix(ppl http://example.com/people#) Prefix(cpt http://example.com/concepts#) Prefix(func http://www.w3.org/2007/rif-builtin-function#) Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#) a. Universal form: Forall ?item ?deliverydate ?scheduledate ?diffduration ?diffdays ( cpt:reject(ppl:John ?item) :- And(cpt:perishable(?item) cpt:delivered(?item ?deliverydate ppl:John) cpt:scheduled(?item ?scheduledate) ?diffduration = External(func:subtract-dateTimes(?deliverydate ?scheduledate)) ?diffdays = External(func:days-from-duration(?diffduration)) External(pred:numeric-greater-than(?diffdays 10))) ) b. Universal-existential form: Forall ?item ( cpt:reject(ppl:John ?item ) :- Exists ?deliverydate ?scheduledate ?diffduration ?diffdays ( And(cpt:perishable(?item) cpt:delivered(?item ?deliverydate ppl:John) cpt:scheduled(?item ?scheduledate) ?diffduration = External(func:subtract-dateTimes(?deliverydate ?scheduledate)) ?diffdays = External(func:days-from-duration(?diffduration)) External(pred:numeric-greater-than(?diffdays 10))) ) )
Example 4 (A RIF-BLD document containing an annotated
group).
This example shows a complete document containing a group formula that consists of two RIF-BLD rules. The first of these rules is copied from Example 3a. The group is annotated with an IRI identifier and frame-represented Dublin Core metadata.
Document( Prefix(ppl http://example.com/people#) Prefix(cpt http://example.com/concepts#) Prefix(dc http://purl.org/dc/terms/) Prefix(func http://www.w3.org/2007/rif-builtin-function#) Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#) Prefix(xs http://www.w3.org/2001/XMLSchema#) (* "http://sample.org"^^rif:iri pd[dc:publisher -> http://www.w3.org/ dc:date -> "2008-04-04"^^xs:date] *) Group ( Forall ?item ?deliverydate ?scheduledate ?diffduration ?diffdays ( cpt:reject(ppl:John ?item) :- And(cpt:perishable(?item) cpt:delivered(?item ?deliverydate ppl:John) cpt:scheduled(?item ?scheduledate) ?diffduration = External(func:subtract-dateTimes(?deliverydate ?scheduledate)) ?diffdays = External(func:days-from-duration(?diffduration)) External(pred:numeric-greater-than(?diffdays 10))) ) Forall ?item ( cpt:reject(ppl:Fred ?item) :- cpt:unsolicited(?item) ) ) )
This normative section specifies the semantics of RIF-BLD
directly, without relying on [RIF-FLD .].
Recall that the presentation syntax of RIF-BLD allows the use of
macros, which are specified via the Prefix and
Base directives. The semantics, below, is described using
the full syntax, i.e., the description assumes that all macros have
already been expanded as explained in Data Types and Built-Ins, Version 1.0 ,[RIF-DTB], Section Constants and
Symbol Spaces.
The set TV of truth values in RIF-BLD consists of just two values, t and f.
The key concept in a model-theoretic semantics of a logic
language is the notion of a semantic structure. The
definition, below, is a little bit more general than necessary.
This is done in order to better see the connection with the
semantics of the RIF framework .described in [RIF-FLD].
Definition (Semantic structure). A semantic
structure, I, is a tuple of the form
<TV, DTS, D,
Dind, Dfunc,
IC, IV,
IF, Iframe,
ISF, Isub,
Iisa, I=,
Iexternal,
Itruth>. Here D is a
non-empty set of elements called the domain of
I, and Dind,
Dfunc are nonempty subsets of
D. Dind is used to interpret
the elements of Const , which denotethat are individuals and
Dfunc is used to interpret the elements of
Const , which denotethat are function symbols. As before, Const
denotes the set of all constant symbols and Var the set of
all variable symbols. TV denotes the set of truth
values that the semantic structure uses and DTS is a
set of identifiers for primitive data typesdatatypes (please refer to Section
Data TypesDatatypes of the document Data Types and Built-Ins, Version 1.0[RIF-DTB] for the semantics of data types).datatypes).
The other components of I are total mappings defined as follows:
This mapping interprets constant symbols. In addition:
This mapping interprets variable symbols.
This mapping interprets positional terms. In addition:
This mapping interprets function symbols with named arguments. In addition:
This mapping interprets frame terms. An argument, d ∈ Dind, to Iframe represent an object and the finite bag {<a1,v1>, ..., <ak,vk>} represents a bag of attribute-value pairs for d. We will see shortly how Iframe is used to determine the truth valuation of frame terms.
Bags (multi-sets) are used here because the order of the attribute/value pairs in a frame is immaterial and pairs may repeat: o[a->b a->b]. Such repetitions arise naturally when variables are instantiated with constants. For instance, o[?A->?B ?C->?D] becomes o[a->b a->b] if variables ?A and ?C are instantiated with the symbol a and ?B, ?D with b.
The operator ## is required to be transitive, i.e., c1 ## c2 and c2 ## c3 must imply c1 ## c3. This is ensured by a restriction in Section Interpretation of Formulas.
The relationships # and ## are required to have the usual property that all members of a subclass are also members of the superclass, i.e., o # cl and cl ## scl must imply o # scl. This is ensured by a restriction in Section Interpretation of Formulas.
It gives meaning to the equality operator.
It is used to define truth valuation for formulas.
For every external schema, σ, associated with the
language, Iexternal(σ) is assumed
to be specified externally in some document (hence the name
external schema). In particular, if σ is a schema
of a RIF builtinbuilt-in predicate or function,
Iexternal(σ) is specified in
the document Data Types and Built-Ins, Version 1.0[RIF-DTB] so that:
For convenience, we also define the following mapping I from terms to D:
Here we use {...} to denote a set of argument/value pairs.
Here {...} denotes a bag of attribute/value pairs.
Note that, by definition, External(t) is well formed only if t is an instance of an external schema. Furthermore, by the definition of coherent sets of external schemas, t can be an instance of at most one such schema, so I(External(t)) is well-defined.
The effect of data types.datatypes. The set DTS
must include the data typesdatatypes described in Section Primitive
Data TypesDatatypes of [RIF-DTB].
The document Data Types and Built-Ins, Version 1.0 . The data typesdatatype identifiers in DTS impose the following
restrictions. IfGiven dt ∈ DTS is a symbol space identifier of a data type,, let
LSdt denote the lexical space of
dt, VSdt denote its value space,
and Ldt: LSdt →
VSdt the lexical-to-value-space mapping
(for the definitions of these concepts, see Section Primitive
Data TypesDatatypes of the document Data Types and Built-Ins, Version 1.0 ).[RIF-DTB].
Then the following must hold:
That is, IC must map the constants of a
data typedatatype dt in accordance with
Ldt.
RIF-BLD does not impose restrictions on
IC for constants in the lexicalsymbol spaces that doare
not correspond to primitivedatatypes mentioned in DTS. ☐
Observe thatRIF-BLD annotations are ignored by allstripped before the mappings that
constitue RIF-BLD semantic structures, sostructures are applied. Likewise, they
are stripped before applying the truth valuation,
TValI, in the next section. Thus, identifiers and
metadata have no effect on the formal semantics.
Note that although identifiers and metadata associated with
RIF-BLD formulas are ignored by the semantics, they can be
extracted by XML tools. Since metadata is represented byThe frame terms, itterms used to represent RIF-BLD
metadata can then be reasoned with byfed into other RIF-BLD rules.rules, thus enabling
reasoning about metadata.
This section defines how a semantic structure, I, determines the truth value TValI(φ) of a RIF-BLD formula, φ, where φ is any formula other than a document formula. Truth valuation of document formulas is defined in the next section.
To this end, we define a mapping, TValI, from
the set of all non-document formulas to TV. Note that
the definition implies that TValI(φ) is
defined only if the set DTS of the data typesdatatypes
of I includes all the data typesdatatypes mentioned in
φ and Iexternal is defined on all
externally defined functions and predicates in φ.
Definition (Truth valuation). Truth valuation for well-formed formulas in RIF-BLD is determined using the following function, denoted TValI:
To ensure that the operator ## is transitive, i.e., c1 ## c2 and c2 ## c3 imply c1 ## c3, the following is required:
To ensure that all members of a subclass are also members of the superclass, i.e., o # cl and cl ## scl implies o # scl, the following is required:
Since the bag of attribute/value pairs represents the
conjunctions of all the pairs, the following is required:required, if k
> 0:
Note that, by definition, External(t) is well-formed only if t is an instance of an external schema. Furthermore, by the definition of coherent sets of external schemas, t can be an instance of at most one such schema, so I(External(t)) is well-defined.
The empty conjunction is treated as a tautology, so TValI(And()) = t.
The empty disjunction is treated as a contradiction, so TValI(Or()) = f.
Here I* is a semantic structure of the form
<TV, DTS, D,
Dind, Dfunc,
IC, I*V,
IF, Iframe,
ISF, Isub,
Iisa, I=,
I externslexternal,
Itruth>, which is exactly like
I, except that the mapping
I*V, is used instead of
IV. I*V is
defined to coincide with IV on all
variables except, possibly, on
?v1,...,?vn.
If Γ is a group formula of the form
Group(ρGroup(φ1 ... ρφn) then
This means that a group of rules is treated as a conjunction. ☐
Document formulas are interpreted using semantic multi-structures.
Definition (Semantic multi-structures).multi-structure). A semantic
multi-structure is a set
{IΔ1, ...,
IΔn}, n>0, where
IΔ1, ...,
IΔn are semantic
structures labeled with document formulas. These structures must be identical in all respects except that the mappings I C Δ 1 , ..., I C Δ n might differ on the constants in Const that belong to the rif:local symbol space. The above set is allowed to have at most one semantic structure with the same label. ☐ Definition (Imported document). Let Δ be a document formula and Import(t) be one of its import directives, which references another document formula, Δ' . In this case, we say that Δ' is directly imported into Δ . A document formula Δ' is said toformulas. These structures must be
imported intoidentical in all respects except that the mappings
ICΔ if it is either directly imported into1, ...,
ICΔ or it is imported (directly or not) into another formula, whichn might
differ on the constants in Const that belong to the
rif:local symbol space. The above set is directly imported into Δ .allowed to have
at most one semantic structure with the same label.
☐
With the help of semantic multi-structures we can now explain the semantics of RIF documents.
Definition (Truth valuation of a document formulas).formula). Let
Δ be a document formula and let Δ1,
..., Δk be all the RIF-BLD document formulas
that are imported (directly or indirectly, according to
the previous definition)Definition Imported
document) into Δ. Let Γ,
Γ1, ..., Γk denote the
respective group formulas associated with these documents. If any
of these Γi is missing (which is a possibility,
since every part of a document is optional), assume that it is a
tautology, such as a = a, so that every TVal
function maps such a Γi to the truth value
t. Let I =
{IΔ,
IΔ1, ...,
IΔk, ...} be a
semantic multi-structure, which contains semantic structures
labeled with at least the documents Δ,
Δ1, ..., Δk. Then we
define:
Note that this definition considers only those document formulas
that are reachable via the one-argument import directives. Two
argument import directives are ignored here. Their semantics is
defined by the document RIF RDF and OWL Compatibility .[RIF-RDF+OWL].
☐
The above definitions make the intent behind the rif:local
constants clear: rif:localoccurrences of such constants that occurin different
documents can be interpreted differently even if they have the same
name. Therefore, each document can choose the names for the
rif:local constants freely and without regard to the names
of such constants used in the imported documents.
We now define what it means for a set of RIF-BLD rules (such as
a group or a document formula) to entail another RIF-BLD formula.
In RIF-BLD we are mostly interested in entailment of RIF condition
formulas, which play the role ofcan be viewed as queries to theRIF-BLD knowledge base.documents.
Therefore, entailment of condition formulas provides formal
underpinning to RIF-BLD queries.
From now on, every formula is assumed to be part of some document.
If it is not physically part of any document, it will be said to
belong to a special query document. If I is a
semantic multi-structure, Δ is the document of φ,
and IΔ is the component structure
in I that corresponds to Δ, then
TValI(φ) is defined as
TValIΔ(φ). Otherwise,
TValI(φ) is undefined.
Definition (Models). A multi-structure I is a
model of a formula, φ, written as
I |=φ |= φ, iff
TValI(φ) is defined and equals t.
☐
Definition
(Logical entailment). Let Γ and φ be RIF-BLD
formulas. We say that Γ entails φ,
written as Γ |= φ, if and only if for every
multi-structure, I, for which both
TValI(Γ) and
TValI(φ) are defined,
I |=Γ |= Γ implies
I |=φ |= φ. ☐
Note that one consequence of the multi-document semantics of
RIF-BLD is that local constants specified in one document cannot be
queried from another document. In particular, they cannot be
returned as query answers. For instance, if one document,
Δ', has the fact
"http://example.com/ppp"^^rif:iri("abc"^^rif:local) while
another document formula, Δ, imports Δ' and has
the rule "http://example.com/qqq"^^rif:iri(?X) :-
"http://example.com/ppp"^^rif:iri(?X) , then Δ |=
"http://example.com/qqq"^^rif:iri("abc"^^rif:local) does
not hold. This is because "abc"^^rif:local in
Δ' and "abc"^^rif:local in the query on the
right-hand side of |= are treated as different constants
by semantic multi-structures.
The RIF-BLD XML serialization defines
Recall that the syntax of RIF-BLD is not context-free and thus cannot be fully captured by EBNF and XML Schema. Still, validity with respect to XML Schema can be a useful test. To reflect this state of affairs, we define two notions of syntactic correctness. The weaker notion checks correctness only with respect to XML Schema, while the stricter notion represents "true" syntactic correctness.
Definition (Valid BLD document in XML syntax). A valid BLD document in the XML syntax is an XML document that is valid w.r.t. the XML schema in Appendix XML Schema for BLD. ☐
Definition (Conformant BLD document in XML syntax). A conformant BLD document in the XML syntax is a valid BLD document in the XML syntax that is the image of a well-formed RIF-BLD document in the presentation syntax (see Definition Well-formed formula in Section Formulas) under the presentation-to-XML syntax mapping χbld defined in Section Translation Between the RIF-BLD Presentation and XML Syntaxes. ☐
The XML serialization for RIF-BLD is alternating or fully striped [ANF01]. A fully striped serialization views XML documents as objects and divides all XML tags into class descriptors, called type tags, and property descriptors, called role tags [TRT03]. We follow the tradition of using capitalized names for type tags and lowercase names for role tags.
The all-uppercase classes in the presentation syntax, such as FORMULA, become XML Schema groups in Appendix XML Schema for BLD. They act like macros and are not visible in instance markup. The other classes as well as non-terminals and symbols (such as Exists or =) become XML elements with optional attributes, as shown below.
RIF-BLD uses [XML1.0] for its XML syntax.
XML serialization of RIF-BLD in Section EBNF for RIF-BLD Condition Language uses the following elements.
- And (conjunction) - Or (disjunction) - Exists (quantified formula for 'Exists', containing declare and formula roles) - declare (declare role, containing a Var) - formula (formula role, containing a FORMULA) - Atom (atom formula, positional or with named arguments) - External (external call, containing a content role) - content (content role, containing an Atom, for predicates, or Expr, for functions) - Member (member formula) - Subclass (subclass formula) - Frame (Frame formula) - object (Member/Frame role, containing a TERM or an object description) - op (Atom/Expr role for predicates/functions as operations) - args (Atom/Expr positional arguments role, containing n TERMs) - instance (Member instance role) - class (Member class role) - sub (Subclass sub-class role) - super (Subclass super-class role) - slot (Atom/Expr or Frame slot role, containing a Name or TERM followed by a TERM) - Equal (prefix version of term equation '=') - Expr (expression formula, positional or with named arguments) - left (Equal left-hand side role) - right (Equal right-hand side role) - Const (individual, function, or predicate symbol, with optional 'type' attribute) - Name (name of named argument) - Var (logic variable) - id (identifier role, containing IRICONST) - meta (meta role, containing metadata as a Frame or Frame conjunction)
The id and meta elements, which are expansions of the IRIMETA element, can occur optionally as the initial children of any Class element.
For the XML Schema definition of the RIF-BLD condition language see Appendix XML Schema for BLD.
The XML syntax for symbol spaces utilizes the type
attribute associated with XML term elements such as Const.
For instance, a literal in the xs:dateTime data typedatatype can be
represented as
<Const type="&xs;dateTime">2007-11-23T03:55:44-02:30</Const>.
RIF-BLD also utilizes the ordered attribute to indicate
the orderedness of children of the elements args and
slot it is associated with.
Example 5 (A RIF condition and its XML serialization).
This example illustrates XML serialization for RIF conditions. As before, the compact URI notation is used for better readability. Assume that the following prefix directives are found in the preamble to the document:
Prefix(bks http://example.com/books#) Prefix(cpt http://example.com/concepts#) Prefix(curr http://example.com/currencies#) Prefix(rif http://www.w3.org/2007/rif#) Prefix(xs http://www.w3.org/2001/XMLSchema#)
RIF condition And (Exists ?Buyer (cpt:purchase(?Buyer ?Seller cpt:book(?Author bks:LeRif) curr:USD(49))) ?Seller=?Author ) XML serialization <And> <formula> <Exists> <declare><Var>Buyer</Var></declare> <formula> <Atom> <op><Const type="&rif;iri">&cpt;purchase</Const></op> <args ordered="yes"> <Var>Buyer</Var> <Var>Seller</Var> <Expr> <op><Const type="&rif;iri">&cpt;book</Const></op> <args ordered="yes"> <Var>Author</Var> <Const type="&rif;iri">&bks;LeRif</Const> </args> </Expr> <Expr> <op><Const type="&rif;iri">&curr;USD</Const></op> <args ordered="yes"><Const type="&xs;integer">49</Const></args> </Expr> </args> </Atom> </formula> </Exists> </formula> <formula> <Equal> <left><Var>Seller</Var></left> <right><Var>Author</Var></right> </Equal> </formula> </And>
Example 6 (A RIF condition with named arguments and its XML
serialization).
This example illustrates XML serialization of RIF conditions that involve terms with named arguments. As in Example 5, we assume the following prefix directives:
Prefix(bks http://example.com/books#) Prefix(cpt http://example.com/concepts#) Prefix(curr http://example.com/currencies#) Prefix(rif http://www.w3.org/2007/rif#) Prefix(xs http://www.w3.org/2001/XMLSchema#)
RIF condition: And (Exists ?Buyer ?P ( And (?P#cpt:purchase ?P[cpt:buyer->?Buyer cpt:seller->?Seller cpt:item->cpt:book(cpt:author->?Author cpt:title->bks:LeRif) cpt:price->49 cpt:currency->curr:USD])) ?Seller=?Author) XML serialization: <And> <formula> <Exists> <declare><Var>Buyer</Var></declare> <declare><Var>P</Var></declare> <formula> <And> <formula> <Member> <instance><Var>P</Var></instance> <class><Const type="&rif;iri">&cpt;purchase</Const></class> </Member> </formula> <formula> <Frame> <object> <Var>P</Var> </object> <slot ordered="yes"> <Const type="&rif;iri">&cpt;buyer</Const> <Var>Buyer</Var> </slot> <slot ordered="yes"> <Const type="&rif;iri">&cpt;seller</Const> <Var>Seller</Var> </slot> <slot ordered="yes"> <Const type="&rif;iri">&cpt;item</Const> <Expr> <op><Const type="&rif;iri">&cpt;book</Const></op> <slot ordered="yes"> <Name>&cpt;author</Name> <Var>Author</Var> </slot> <slot ordered="yes"> <Name>&cpt;title</Name> <Const type="&rif;iri">&bks;LeRif</Const> </slot> </Expr> </slot> <slot ordered="yes"> <Const type="&rif;iri">&cpt;price</Const> <Const type="&xs;integer">49</Const> </slot> <slot ordered="yes"> <Const type="&rif;iri">&cpt;currency</Const> <Const type="&rif;iri">&curr;USD</Const> </slot> </Frame> </formula> </And> </formula> </Exists> </formula> <formula> <Equal> <left><Var>Seller</Var></left> <right><Var>Author</Var></right> </Equal> </formula> </And>
We now extend the RIF-BLD serialization from Section XML for RIF-BLD Condition
Language by including rules, along with their enclosing groups
and documents, as described in Section EBNF for RIF-BLD Rule
Language. The extended serialization uses the following
additional tags. While there is a RIF-BLD element tag for the
Import directive, there are none for the Prefix
and Base directives (they can be representeddirectives: they are handled as discussed in
Section Mapping of the
RIF-BLD Rule Language )..
- Document (document, containing optionaldirectivesdirective andpayload)payload roles) - directive (directive role, containingImport,Prefix,orBase)Import) - payload (payload role, containing Group) - Import (importation, containing location and optional profile) - location (location role, containing IRICONST) - profile (profile role, containing PROFILE) - Group (nested collection of sentences) - sentence (sentence role, containing RULE or Group) - Forall (quantified formula for 'Forall', containing declare and formula roles) - Implies (implication, containing if and then roles) - if (antecedent role, containing FORMULA) - then (consequent role, containing ATOMIC or conjunction of ATOMICs)
- id (identifier role, containing IRICONST) - meta (meta role, containing metadata as a Frame or Frame conjunction) The id and meta elements, which are expansions of the IRIMETA element, can occur optionally as the initial children of any Class element.The XML Schema Definition of RIF-BLD is given in Appendix
XML Schema for BLD.
Example 7 (Serializing a RIF-BLD document containing an
annotated group).
This example shows a serialization for the document from Example 4. For convenience, the document is reproduced at the top and then is followed by its serialization.
Presentation syntax: Document( Prefix(ppl http://example.com/people#) Prefix(cpt http://example.com/concepts#) Prefix(dc http://purl.org/dc/terms/) Prefix(rif http://www.w3.org/2007/rif#) Prefix(func http://www.w3.org/2007/rif-builtin-function#) Prefix(pred http://www.w3.org/2007/rif-builtin-predicate#) Prefix(xs http://www.w3.org/2001/XMLSchema#) (* "http://sample.org"^^rif:iri pd[dc:publisher -> http://www.w3.org/ dc:date -> "2008-04-04"^^xs:date] *) Group ( Forall ?item ?deliverydate ?scheduledate ?diffduration ?diffdays ( cpt:reject(ppl:John ?item) :- And(cpt:perishable(?item) cpt:delivered(?item ?deliverydate ppl:John) cpt:scheduled(?item ?scheduledate) ?diffduration = External(func:subtract-dateTimes(?deliverydate ?scheduledate)) ?diffdays = External(func:days-from-duration(?diffduration)) External(pred:numeric-greater-than(?diffdays 10))) ) Forall ?item ( cpt:reject(ppl:Fred ?item) :- cpt:unsolicited(?item) ) ) ) XML syntax: <!DOCTYPE Document [ <!ENTITY ppl "http://example.com/people#"> <!ENTITY cpt "http://example.com/concepts#"> <!ENTITY dc "http://purl.org/dc/terms/"> <!ENTITY rif "http://www.w3.org/2007/rif#"> <!ENTITY func "http://www.w3.org/2007/rif-builtin-function#"> <!ENTITY pred "http://www.w3.org/2007/rif-builtin-predicate#"> <!ENTITY xs "http://www.w3.org/2001/XMLSchema#"> ]> <Document xmlns="http://www.w3.org/2007/rif#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema#"> <payload> <Group> <id> <Const type="&rif;iri">http://sample.org</Const> </id> <meta> <Frame> <object> <Const type="&rif;local">pd</Const> </object> <slot ordered="yes"> <Const type="&rif;iri">&dc;publisher</Const> <Const type="&rif;iri">http://www.w3.org/</Const> </slot> <slot ordered="yes"> <Const type="&rif;iri">&dc;date</Const> <Const type="&xs;date">2008-04-04</Const> </slot> </Frame> </meta> <sentence> <Forall> <declare><Var>item</Var></declare> <declare><Var>deliverydate</Var></declare> <declare><Var>scheduledate</Var></declare> <declare><Var>diffduration</Var></declare> <declare><Var>diffdays</Var></declare> <formula> <Implies> <if> <And> <formula> <Atom> <op><Const type="&rif;iri">&cpt;perishable</Const></op> <args ordered="yes"><Var>item</Var></args> </Atom> </formula> <formula> <Atom> <op><Const type="&rif;iri">&cpt;delivered</Const></op> <args ordered="yes"> <Var>item</Var> <Var>deliverydate</Var> <Const type="&rif;iri">&ppl;John</Const> </args> </Atom> </formula> <formula> <Atom> <op><Const type="&rif;iri">&cpt;scheduled</Const></op> <args ordered="yes"> <Var>item</Var> <Var>scheduledate</Var> </args> </Atom> </formula> <formula> <Equal> <left><Var>diffduration</Var></left> <right> <External> <content> <Atom> <op><Const type="&rif;iri">&func;subtract-dateTimes</Const></op> <args ordered="yes"> <Var>deliverydate</Var> <Var>scheduledate</Var> </args> </Atom> </content> </External> </right> </Equal> </formula> <formula> <Equal> <left><Var>diffdays</Var></left> <right> <External> <content> <Atom> <op><Const type="&rif;iri">&func;days-from-duration</Const></op> <args ordered="yes"> <Var>diffduration</Var> </args> </Atom> </content> </External> </right> </Equal> </formula> <formula> <External> <content> <Atom> <op><Const type="&rif;iri">&pred;numeric-greater-than</Const></op> <args ordered="yes"> <Var>diffdays</Var> <Const type="&xs;integer">10</Const> </args> </Atom> </content> </External> </formula> </And> </if> <then> <Atom> <op><Const type="&rif;iri">&cpt;reject</Const></op> <args ordered="yes"> <Const type="&rif;iri">&ppl;John</Const> <Var>item</Var> </args> </Atom> </then> </Implies> </formula> </Forall> </sentence> <sentence> <Forall> <declare><Var>item</Var></declare> <formula> <Implies> <if> <Atom> <op><Const type="&rif;iri">&cpt;unsolicited</Const></op> <args ordered="yes"><Var>item</Var></args> </Atom> </if> <then> <Atom> <op><Const type="&rif;iri">&cpt;reject</Const></op> <args ordered="yes"> <Const type="&rif;iri">&ppl;Fred</Const> <Var>item</Var> </args> </Atom> </then> </Implies> </formula> </Forall> </sentence> </Group> </payload> </Document>
This section defines a normative mapping, χbld, from the presentation syntax to the XML syntax of RIF-BLD. The mapping is given via tables where each row specifies the mapping of a particular syntactic pattern in the presentation syntax. These patterns appear in the first column of the tables and the bold-italic symbols represent metavariables. The second column represents the corresponding XML patterns, which may contain applications of the mapping χbld to these metavariables. When an expression χbld(metavar) occurs in an XML pattern in the right column of a translation table, it should be understood as a recursive application of χbld to the presentation syntax represented by the metavariable. The XML syntax result of such an application is substituted for the expression χbld(metavar). A sequence of terms containing metavariables with subscripts is indicated by an ellipsis. A metavariable or a well-formed XML subelement is marked as optional by appending a bold-italic question mark, ?, on its right.
The χbld mapping from the presentation
syntax to the XML syntax of the RIF-BLD Condition Language is
givenspecified by the table below. Each row "Presentation |
XML" indicates a χbld translation:
χbld(Presentation) = XML.
Since the presentation syntax of RIF-BLD is context sensitive, the
mapping must differentiate between the terms that occur in the
position of the individuals from terms that occur as atomic
formulas. To this end, in the translation table, the positional and
named argument terms that occur in the context of atomic formulas
are denoted by the expressions of the form pred(...)
and the terms that occur as individuals are denoted by expressions
of the form func(...). In the table, each
metavariable for an (unnamed) positional
argumenti is assumed to be instantiated to
values unequal to the instantiations of named arguments
unicodestringj ->
fillerj.
Presentation Syntax | XML Syntax |
---|---|
And ( conjunct1 . . . conjunctn ) |
<And> <formula>χbld(conjunct1)</formula> . . . <formula>χbld(conjunctn)</formula> </And> |
Or ( disjunct1 . . . disjunctn ) |
<Or> <formula>χbld(disjunct1)</formula> . . . <formula>χbld(disjunctn)</formula> </Or> |
Exists variable1 . . . variablen ( body ) |
<Exists> <declare>χbld(variable1)</declare> . . . <declare>χbld(variablen)</declare> <formula>χbld(body)</formula> </Exists> |
External ( atomframexpr ) |
<External> <content>χbld(atomframexpr)</content> </External> |
pred ( argument1 . . . argumentn ) |
<Atom> <op>χbld(pred)</op> <args ordered="yes"> χbld(argument1) . . . χbld(argumentn) </args> </Atom> |
func ( argument1 . . . argumentn ) |
<Expr> <op>χbld(func)</op> <args ordered="yes"> χbld(argument1) . . . χbld(argumentn) </args> </Expr> |
pred ( unicodestring1 -> filler1 . . . unicodestringn -> fillern ) |
<Atom> <op>χbld(pred)</op> <slot ordered="yes"> <Name>unicodestring1</Name> χbld(filler1) </slot> . . . <slot ordered="yes"> <Name>unicodestringn</Name> χbld(fillern) </slot> </Atom> |
func ( unicodestring1 -> filler1 . . . unicodestringn -> fillern ) |
<Expr> <op>χbld(func)</op> <slot ordered="yes"> <Name>unicodestring1</Name> χbld(filler1) </slot> . . . <slot ordered="yes"> <Name>unicodestringn</Name> χbld(fillern) </slot> </Expr> |
inst [ key1 -> filler1 . . . keyn -> fillern ] |
<Frame> <object>χbld(inst)</object> <slot ordered="yes"> χbld(key1) χbld(filler1) </slot> . . . <slot ordered="yes"> χbld(keyn) χbld(fillern) </slot> </Frame> |
inst # class |
<Member> <instance>χbld(inst)</instance> <class>χbld(class)</class> </Member> |
sub ## super |
<Subclass> <sub>χbld(sub)</sub> <super>χbld(super)</super> </Subclass> |
left = right |
<Equal> <left>χbld(left)</left> <right>χbld(right)</right> </Equal> |
unicodestring^^ |
<Const type=" |
?unicodestring |
<Var>unicodestring</Var> |
The χbld mapping from the presentation
syntax to the XML syntax of the RIF-BLD Rule Language is givenspecified
by the table below;below. It extends the translation table of Section
Translation
of RIF-BLD Condition Language. While the Import
directive is handled by the presentation-to-XML syntax mapping, the
Prefix and Base directives are not. Instead,
Prefix and Basethese directives should be dealt with by macro-expanding these shortcuts declared inthe
presentation syntax.associated shortcuts (compact URIs). Namely, a prefix name declared
in a Prefix directive is expanded into the associated IRI,
while relative IRIs are completed using the IRI declared in the
Base directive. The mapping χbld
applies only to such macro-expanded documents. RIF-BLD also allows
other treatments of Prefix and Base provided that
they produce equivalent XML documents. One such treatment is
employed in the examples in this document, especially Example 7. It
replaces prefix names with definitions of XML entities as follows.
Each Prefix declaration becomes an ENTITY
declaration [XML1.0]
within a DOCTYPE DTD attached to the RIF-BLD
Document. The Base directive is mapped to the
xml:base attribute [XML-Base] in the XML Document tag. Compact URIs of
the form prefix:suffix are then mapped to
&prefix;suffix.
Presentation Syntax | XML Syntax |
---|---|
Document( Import(loc1 |
<Document> <directive> <Import> <location>χbld(loc1)</location> |
Group( clause1 . . . clausen ) |
<Group> <sentence>χbld(clause1)</sentence> . . . <sentence>χbld(clausen)</sentence> </Group> |
Forall variable1 . . . variablen ( rule ) |
<Forall> <declare>χbld(variable1)</declare> . . . <declare>χbld(variablen)</declare> <formula>χbld(rule)</formula> </Forall> |
conclusion :- condition |
<Implies> <if>χbld(condition)</if> <then>χbld(conclusion)</then> </Implies> |
The χbld mapping from theRIF-BLD annotations in
the presentation syntax and into the XML syntax is givenspecified by the table
below. It extends the arrow symbol ==> between two rows indicates atranslation tables of the lower row conditional on theSections Translation resultof
the upper row.RIF-BLD Condition Language and Translation of RIF-BLD
Rule Language. The metavariable Typetag can standin the
presentation and XML syntaxes stands for any of the XMLclass descriptornames
And, Or, External, Document, or
Group, etc.and Quantifier for Exists or
Forall. The dollar signsign, $, stands for any of the
binary infix operator names #, ##, =, andor
:-, while Binop stands for their respective
class names Member, Subclass, Equal, or
Implies. Again, each metavariable for an (unnamed)
positional argumenti is assumed to be
instantiated to values unequal to the instantiations of named
arguments unicodestringj ->
fillerj.
Presentation Syntax | XML Syntax |
---|---|
(* iriconst? frameconj? *) Typetag ( e1 . . . en ) |
<Typetag> <id>χbld(iriconst)</id>? <meta>χbld(frameconj)</meta>? e1 |
(* iriconst? frameconj? *) Quantifier variable1 . . . |
< |
(* iriconst? frameconj? *) pred ( |
|
(* iriconst? frameconj? *) func ( |
|
(* iriconst? frameconj? *) |
|
(* iriconst? frameconj? *) func ( unicodestring1 -> filler1 . . . |
<Expr> <id>χbld( |
(* iriconst? frameconj? *) inst [ |
<Frame> <id>χbld(iriconst)</id>? <meta>χbld(frameconj)</meta>? <object>χbld(inst)</object> <slot ordered="yes"> χbld( |
|
< |
|
<Const type=" |
|
<Var> <id>χbld(iriconst)</id>? <meta>χbld(frameconj)</meta>? unicodestring </Var> |
RIF-BLD does not require or expect the conformant systems to
implement the RIF-BLD presentation syntax. Instead, complianceconformance is
described in terms of semantics-preserving transformations.
Let Τ be a set of data types,datatypes, which includes the data typesdatatypes
specified in the[RIF-DTB document ,], and
suppose Ε is a set of external predicates and functions, which
includes the built-ins listed in the[RIF-DTB document.]. Let D be a RIF dialect (e.g., RIF-BLD). We
say that a formula φ is a DΤ,Ε formula iff
A RIF processor is a conformant DΤ,Ε consumer iff it implements a semantics-preserving mapping, μ, from the set of all DΤ,Ε formulas to the language L of the processor.
Formally, this means that for any pair φ, ψ of DΤ,Ε formulas for which φ |=D ψ is defined, φ |=D ψ iff μ(φ) |=L μ(ψ). Here |=D denotes the logical entailment in the RIF dialect D and |=L is the logical entailment in the language L of the RIF processor.
In addition, a D Τ,Ε conformant consumer must reject any document that contains a non- D Τ,Ε formula.A RIF processor is a conformant
DΤ,Ε producer iff it implements a
semantics-preserving mapping, μ, from a subset of the language
L of the processor to a set of DΤ,Ε
formulas.
Formally this means that for any pair φ, ψ of formulas in L for which φ |=L ψ is defined, φ |=L ψ iff μ(φ) |=D μ(ψ).
A conformant document is one which conforms to all
the syntactic constraints of the dialect, including ones that
cannot be checked by an XML Schema validator (cf. Definition
Conformant BLD document
in XML syntax).
RIF-BLD specific clauses
Feature At Risk #3: Strictness Requirement
Note: This feature is "at risk" and may be removed from this specification based on feedback. Please send feedback to public-rif-comments@w3.org.
The two preceding clauses are features AT RISK. In particular, the "strictness" requirement is under discussion.
This normative section describes RIF-BLD by specializing
RIF-FLD. The reader is assumed to be familiar with RIF-FLD as
described in RIF Framework for Logic-Based Dialects .[RIF-FLD]. The reader who is not
interested in how RIF-BLD is derived from the framework can skip
this section.
This section defines the precise relationship between the presentation syntax of RIF-BLD and the syntactic framework of RIF-FLD.
The presentation syntax of the RIF Basic Logic Dialect is
defined by specialization from the presentation syntax of the
RIF Syntactic Framework for Logic Dialects .described in
[RIF-FLD]. Section Syntax of a
RIF Dialect as a Specialization of the RIF Framework in
that document[RIF-FLD] lists the parameters
of the syntactic framework in mathematical English, which we will
now specialize for RIF-BLD.
The signature set of RIF-BLD contains the following signatures:
The signature individual{ } represents the context
in which individual objects (but not atomic formulas) can
appear.
The signature atomic{ } represents the context where
atomic formulas can occur.
These represent function and predicate symbols of arity n (each of the above cases has n individuals as arguments inside the parentheses).
Thus, in RIF-BLD each constant symbol can be either an individual, a function of one particular arity or with certain argument names, a predicate of one particular arity or with certain argument names, an externally defined function of one particular arity, or an externally defined predicate symbol of one particular arity -- it is not possible for the same symbol to play more than one role.
This means that equality can compare only those terms whose signature is individual; it cannot compare predicate names or function symbols. Equality terms are also not allowed to occur inside other terms, since the above signature implies that any term of the form t = s has signature atomic and not individual.
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.
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.
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 author specifies signatures contextually. That
is, since RIF-BLD requires that each symbol is associated with a
unique signature, the signature is determined from the context in
which the symbol is used. If a symbol is used in more than one
context, the parser must treat this as a syntax error. If no errors
are found, all terms and atomic formulas are guaranteed to be
well-formed. Thus, signatures are not part of the RIF-BLD
language, and individual and atomic are not
reserved keywords in RIF-BLD.keywords.
SupportedCombined with the fact that in a well-formed term of the form
External(t) the subterm t must be an instance of
an external schema (by the definition of well-formed external terms in RIF-FLD), it
follows that a predicate or a function symbol, p, that
occurs in an external term External(p(...)) cannot also
occur as a non-external symbol.
RIF-BLD supportsrequires the following symbol spaces defined in Section
Constants and Symbol Spaces of the document Data Types and Built-Ins, Version 1.0 .[RIF-DTB].
RIF-BLD supports the following types of formulas (see Well-formed Terms and Formulas in [RIF-FLD] for the definitions):
A RIF-BLD condition is an atomic formula, a conjunctive or disjunctive combination of atomic formulas with optional existential quantification of variables, or an external atomic formula.
A RIF-BLD rule is a universally quantified RIF-FLD rule with the following restrictions:
Note: This feature (Equality in the rule conclusion) is "at risk". See feature at risk #2
A universal fact is a universally quantified atomic formula with no free variables.
A RIF-BLD group is a RIF-FLD group that contains only RIF-BLD
rulesrules, universal facts, variable-free rule implications,
variable-free atomic formulas, and RIF-BLD groups.
A RIF-BLD document is a RIF-FLD document that consists of
directives and a RIF-BLD group formula. There is no
Dialect directive and the import-directives are allowed toImport(loc) directive
(with one argument) can import onlyRIF-BLD documents.documents only. There are no
BLD-specific restrictions on the two-argument directive
Import.
Recall that negation (classical or default) is not supported by RIF-BLD in either the rule head or the body.
This normative section defines the precise relationship between the semantics of RIF-BLD and the semantic framework of RIF-FLD. Specification of the semantics that does not rely on RIF-FLD is given in Section Direct Specification of RIF-BLD Semantics.
The semantics of the RIF Basic Logic Dialect is defined by
specialization from the semantics of the Semantic Framework for Logic
Dialects of RIF. Section Semantics of a RIF Dialect as a Specialization of the RIF
Framework in that document[RIF-FLD]
lists the parameters of the semantic framework, which one need to
specialize. Thus, for RIF-BLD, we need to look at the following
parameters:
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.
The set TV of truth values in RIF-BLD consists of just two values, t and f such that f <t t. The order <t is total.
RIF-BLD supports the data typesdatatypes listed in Section Data TypesDatatypes of
the document Data Types and Built-Ins, Version 1.0 .[RIF-DTB].
Recall that logical entailment in RIF-FLD is defined with respect to an unspecified set of intended semantic structures and that dialects of RIF must make this notion concrete. For RIF-BLD, this set is defined in one of the two following equivalent ways:
These two definitions are equivalent for entailment of existentially closed RIF-BLD conditions by RIF-BLD documents (i.e., formulas where every variable, ?V, occurs in a subformula of the form Exists ...?V...(ψ)), since all rules in RIF-BLD are Horn -- it is a classical result of Van Emden and Kowalski [vEK76].
The semantics of the two-argument Import directive is given in [RIF-RDF+OWL]. The semantics of the one-argument directive is the same as in RIF-FLD.
Section Mapping from the RIF-FLD Presentation Syntax to the XML Syntax of [RIF-FLD] defines a mapping, χfld, from the presentation syntax of RIF-FLD to its XML serialization. When restricted to well-formed RIF-BLD formulas, χfld coincides with the BLD-to-XML mapping χbld. In this way, the XML serialization of RIF-BLD is a specialization of the RIF-FLD XML Serialization Framework defined in [RIF-FLD].
This document is the product of the Rules Interchange Format (RIF) Working Group (see below) whose members deserve recognition for their time and commitment. Special thanks to: Jos de Bruijn, David Hirtle, Stella Mitchell, Leora Morgenstern, Igor Mozetic, Axel Polleres, and Dave Reynolds, for their thorough reviews and insightful discussions. The working group chairs, Chris Welty and Christian de Sainte-Marie, provided invaluable technical help and inspirational leadership throughout the long and difficult trials leading to this draft. Last, but not least, our W3C team contact, Sandro Hawke, was a constant source of ideas, help, and feedback.
The regular attendees at meetings of the Rule Interchange Format
(RIF) Working Group at the time of the publication were: Adrian
Paschke (REWERSE), Axel Polleres (DERI), Chris Welty (IBM),
Christian de Sainte Marie (ILOG), Dave Reynolds (HP), Gary Hallmark
(ORACLE), Harold Boley (NRC), Hassan Aït-Kaci (ILOG), Igor Mozetic
(JFI), John Hall (OMG), Jos de Bruijn (FUB), Leora Morgenstern
(IBM), Michael Kifer (Stony Brook), Mike Dean (BBN), Sandro Hawke
(W3C/MIT), and Stella Mitchell (IBM). We would also like to thank
two past members of the working group, Allen Ginsberg and
Paula-Lavinia Patranjan.
The namespace of RIF is http://www.w3.org/2007/rif#.
XML schemas for the RIF-BLD sublanguages are availabledefined below and
online ,are also available here with additional
examples.
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2007/rif#" targetNamespace="http://www.w3.org/2007/rif#" elementFormDefault="qualified" version="Id:BLDCond.xsd,v0.92008-07-02BLDCond.xsd, v. 1.0, 2008-07-14, dhirtle/hboley"> <xs:annotation> <xs:documentation> This is the XML schema for the Condition Language as defined byWorkingthe Last Call Draft2of the RIF Basic Logic Dialect. The schema is based on the following EBNF for the RIF-BLD Condition Language: FORMULA ::= IRIMETA? 'And' '(' FORMULA* ')' | IRIMETA? 'Or' '(' FORMULA* ')' | IRIMETA? 'Exists' Var+ '(' FORMULA ')' | ATOMIC | IRIMETA? 'External' '(' Atom | Frame ')' ATOMIC ::= IRIMETA? (Atom | Equal | Member | Subclass | Frame) Atom ::= UNITERM UNITERM ::= Const '(' (TERM* | (Name '->' TERM)*) ')' Equal ::= TERM '=' TERM Member ::= TERM '#' TERM Subclass ::= TERM '##' TERM Frame ::= TERM '[' (TERM '->' TERM)* ']' TERM ::= IRIMETA? (Const | Var | Expr | 'External' '(' Expr ')') Expr ::= UNITERM Const ::= '"' UNICODESTRING '"^^' SYMSPACE | CONSTSHORT IRICONST ::= '"' IRI '"^^' 'rif:iri' Name ::= UNICODESTRING Var ::= '?' UNICODESTRING SYMSPACE ::=UNICODESTRINGANGLEBRACKIRI | CURIE IRIMETA ::= '(*' IRICONST? (Frame | 'And' '(' Frame* ')')? '*)' </xs:documentation> </xs:annotation> <xs:group name="FORMULA"> <xs:choice> <xs:element ref="And"/> <xs:element ref="Or"/> <xs:element ref="Exists"/> <xs:group ref="ATOMIC"/> <xs:element name="External" type="External-FORMULA.type"/> </xs:choice> </xs:group> <xs:complexType name="External-FORMULA.type"> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> <xs:element name="content" type="content-FORMULA.type"/> </xs:sequence> </xs:complexType> <xs:complexType name="content-FORMULA.type"> <xs:sequence> <xs:choice> <xs:element ref="Atom"/> <xs:element ref="Frame"/> </xs:choice> </xs:sequence> </xs:complexType> <xs:element name="And"> <xs:complexType> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> <xs:element ref="formula" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Or"> <xs:complexType> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> <xs:element ref="formula" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Exists"> <xs:complexType> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> <xs:element ref="declare" minOccurs="1" maxOccurs="unbounded"/> <xs:element ref="formula"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="formula"> <xs:complexType> <xs:sequence> <xs:group ref="FORMULA"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="declare"> <xs:complexType> <xs:sequence> <xs:element ref="Var"/> </xs:sequence> </xs:complexType> </xs:element> <xs:group name="ATOMIC"> <xs:choice> <xs:element ref="Atom"/> <xs:element ref="Equal"/> <xs:element ref="Member"/> <xs:element ref="Subclass"/> <xs:element ref="Frame"/> </xs:choice> </xs:group> <xs:element name="Atom"> <xs:complexType> <xs:sequence> <xs:group ref="UNITERM"/> </xs:sequence> </xs:complexType> </xs:element> <xs:group name="UNITERM"> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> <xs:element ref="op"/> <xs:choice> <xs:element ref="args" minOccurs="0" maxOccurs="1"/> <xs:element name="slot" type="slot-UNITERM.type" minOccurs="0" maxOccurs="unbounded"/> </xs:choice> </xs:sequence> </xs:group> <xs:element name="op"> <xs:complexType> <xs:sequence> <xs:element ref="Const"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="args"> <xs:complexType> <xs:sequence> <xs:group ref="TERM" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="ordered" type="xs:string" fixed="yes"/> </xs:complexType> </xs:element> <xs:complexType name="slot-UNITERM.type"> <xs:sequence> <xs:element ref="Name"/> <xs:group ref="TERM"/> </xs:sequence> <xs:attribute name="ordered" type="xs:string" fixed="yes"/> </xs:complexType> <xs:element name="Equal"> <xs:complexType> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> <xs:element ref="left"/> <xs:element ref="right"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="left"> <xs:complexType> <xs:sequence> <xs:group ref="TERM"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="right"> <xs:complexType> <xs:sequence> <xs:group ref="TERM"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Member"> <xs:complexType> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> <xs:element ref="instance"/> <xs:element ref="class"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Subclass"> <xs:complexType> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> <xs:element ref="sub"/> <xs:element ref="super"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="instance"> <xs:complexType> <xs:sequence> <xs:group ref="TERM"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="class"> <xs:complexType> <xs:sequence> <xs:group ref="TERM"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="sub"> <xs:complexType> <xs:sequence> <xs:group ref="TERM"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="super"> <xs:complexType> <xs:sequence> <xs:group ref="TERM"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Frame"> <xs:complexType> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> <xs:element ref="object"/> <xs:element name="slot" type="slot-Frame.type" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="object"> <xs:complexType> <xs:sequence> <xs:group ref="TERM"/> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="slot-Frame.type"> <xs:sequence> <xs:group ref="TERM"/> <xs:group ref="TERM"/> </xs:sequence> <xs:attribute name="ordered" type="xs:string" fixed="yes"/> </xs:complexType> <xs:group name="TERM"> <xs:choice> <xs:element ref="Const"/> <xs:element ref="Var"/> <xs:element ref="Expr"/> <xs:element name="External" type="External-TERM.type"/> </xs:choice> </xs:group> <xs:complexType name="External-TERM.type"> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> <xs:element name="content" type="content-TERM.type"/> </xs:sequence> </xs:complexType> <xs:complexType name="content-TERM.type"> <xs:sequence> <xs:element ref="Expr"/> </xs:sequence> </xs:complexType> <xs:element name="Expr"> <xs:complexType> <xs:sequence> <xs:group ref="UNITERM"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Const"> <xs:complexType mixed="true"> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> </xs:sequence> <xs:attribute name="type" type="xs:anyURI" use="required"/> </xs:complexType> </xs:element> <xs:element name="Name" type="xs:string"> </xs:element> <xs:element name="Var"> <xs:complexType mixed="true"> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType> </xs:element> <xs:group name="IRIMETA"> <xs:sequence> <xs:element ref="id" minOccurs="0" maxOccurs="1"/> <xs:element ref="meta" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:group> <xs:element name="id"> <xs:complexType> <xs:sequence> <xs:element name="Const" type="IRICONST.type"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="meta"> <xs:complexType> <xs:choice> <xs:element ref="Frame"/> <xs:element name="And" type="And-meta.type"/> </xs:choice> </xs:complexType> </xs:element> <xs:complexType name="And-meta.type"> <xs:sequence> <xs:element name="formula" type="formula-meta.type" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="formula-meta.type"> <xs:sequence> <xs:element ref="Frame"/> </xs:sequence> </xs:complexType> <xs:complexType name="IRICONST.type" mixed="true"> <xs:sequence/> <xs:attribute name="type" type="xs:anyURI" use="required" fixed="http://www.w3.org/2007/rif#iri"/> </xs:complexType> </xs:schema>
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2007/rif#" targetNamespace="http://www.w3.org/2007/rif#" elementFormDefault="qualified" version="Id:BLDRule.xsd,v0.92008-06-28BLDRule.xsd, v. 1.0, 2008-07-16, dhirtle/hboley"> <xs:annotation> <xs:documentation> This is the XML schema for the Rule Language as defined byWorkingthe Last Call Draft2of the RIF Basic Logic Dialect. The schema is based on the following EBNF for the RIF-BLD Rule Language: Document ::= IRIMETA? 'Document' '('DIRECTIVE*Base? Prefix* Import* Group? ')'DIRECTIVE::=Import|Prefix|BaseImport::=IRIMETA?'Import''Base' '('IRICONSTProfile?IRI ')' Prefix ::= 'Prefix' '(' Name IRI ')'BaseImport ::='Base'IRIMETA? 'Import' '('IRIIRICONST PROFILE? ')' Group ::= IRIMETA? 'Group' '(' (RULE | Group)* ')' RULE ::= (IRIMETA? 'Forall' Var+ '(' CLAUSE ')') | CLAUSE CLAUSE ::= Implies | ATOMIC Implies ::= IRIMETA? (ATOMIC | 'And' '(' ATOMIC* ')') ':-' FORMULAIRICONST::='"'IRI'"^^''rif:iri'PROFILE ::=UNICODESTRINGIRIMETA::='(*'IRICONST?(Frame|'And''('Frame*')')?'*)'TERM Note that this is an extension of the syntax for the RIF-BLD Condition Language (BLDCond.xsd). </xs:documentation> </xs:annotation> <xs:include schemaLocation="BLDCond.xsd"/> <xs:element name="Document"> <xs:complexType> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> <xs:element ref="directive" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="payload" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="directive"> <xs:complexType> <xs:sequence><xs:groupref="DIRECTIVE"/><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:groupname="DIRECTIVE"><xs:choice><xs:elementref="Import"/></xs:choice></xs:group><xs:element name="Import"> <xs:complexType> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> <xs:element ref="location"/> <xs:element ref="profile" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="location"> <xs:complexType> <xs:sequence> <xs:element name="Const" type="IRICONST.type"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="profile"> <xs:complexType> <xs:sequence><xs:elementref="Profile"/><xs:group ref="TERM"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Group"> <xs:complexType> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> <xs:element ref="sentence" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="sentence"> <xs:complexType> <xs:choice> <xs:group ref="RULE"/> <xs:element ref="Group"/> </xs:choice> </xs:complexType> </xs:element> <xs:group name="RULE"> <xs:choice> <xs:element ref="Forall"/> <xs:group ref="CLAUSE"/> </xs:choice> </xs:group> <xs:element name="Forall"> <xs:complexType> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> <xs:element ref="declare" minOccurs="1" maxOccurs="unbounded"/> <xs:element name="formula"> <xs:complexType> <xs:group ref="CLAUSE"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:group name="CLAUSE"> <xs:choice> <xs:element ref="Implies"/> <xs:group ref="ATOMIC"/> </xs:choice> </xs:group> <xs:element name="Implies"> <xs:complexType> <xs:sequence> <xs:group ref="IRIMETA" minOccurs="0" maxOccurs="1"/> <xs:element ref="if"/> <xs:element ref="then"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="if"> <xs:complexType> <xs:sequence> <xs:group ref="FORMULA"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="then"> <xs:complexType> <xs:choice> <xs:group ref="ATOMIC"/> <xs:element name="And" type="And-then.type"/> </xs:choice> </xs:complexType> </xs:element> <xs:complexType name="And-then.type"> <xs:sequence> <xs:element name="formula" type="formula-then.type" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="formula-then.type"> <xs:sequence> <xs:group ref="ATOMIC"/> </xs:sequence> </xs:complexType><xs:elementname="Profile"type="xs:string"></xs:element><xs:groupname="IRIMETA"><xs:sequence><xs:elementref="id"minOccurs="0"maxOccurs="1"/><xs:elementref="meta"minOccurs="0"maxOccurs="1"/></xs:sequence></xs:group><xs:elementname="id"><xs:complexType><xs:sequence><xs:elementname="Const"type="IRICONST.type"/></xs:sequence></xs:complexType></xs:element><xs:elementname="meta"><xs:complexType><xs:choice><xs:elementref="Frame"/><xs:elementname="And"type="And-meta.type"/></xs:choice></xs:complexType></xs:element><xs:complexTypename="And-meta.type"><xs:sequence><xs:elementname="formula"type="formula-meta.type"minOccurs="0"maxOccurs="unbounded"/></xs:sequence></xs:complexType><xs:complexTypename="formula-meta.type"><xs:sequence><xs:elementref="Frame"/></xs:sequence></xs:complexType><xs:complexTypename="IRICONST.type"mixed="true"><xs:sequence/><xs:attributename="type"type="xs:anyURI"use="required"fixed="http://www.w3.org/2007/rif#iri"/></xs:complexType></xs:schema>
The anticipated RIF media type is "application/rif+xml". The draft registration for this media type (pending IETF discussion and approval by the IESG) follows.
Type name: application Subtype name: rif+xml Required parameters: none Optional parameters: charset, as per RFC 3023 (XML Media Types) Encoding considerations: same as RFC 3023 (XML Media Types) Security considerations: Systems which consume RIF documents are potentially vulnerable to attack by malicious producers of RIF documents. The vulnerabilities and forms of attack are similar to those of other Web-based formats with programming or scripting capabilities, such as HTML with embedded Javascript. Excessive Resource Use / Denial of Service Attacks Full and complete processing of a RIF document, even one conforming to the RIF-BLD dialect, may require unlimited CPU and memory resources. Through the use of "import", it may also require arbitrary URI dereferencing, which may consume all available network resources on the consuming system or other systems. RIF consuming systems SHOULD implement reasonable defenses against these attacks. Exploiting Implementation Flaws RIF is a relatively complex format, and rule engines can be extremely sophisticated, so it is likely that some RIF consuming systems will have bugs which allow specially constructed RIF documents to perform inappropriate operations. We urge RIF implementors to make systems which carefully anticipate and handle all possible inputs, including those which present syntactic or semantic errors. External (Application) Functions Because RIF may be extended with local, application defineddatatypesdatatypes and functions, arbitrary vulnerabilities may be introduced. Before being installed on systems which consume untrusted RIF documents, these external functions should be closely reviewed for their own vulnerabilities and for the vulnerabilities that may occur when they are used in unexpected combinations, like "cross-site scripting" attacks. In addition, as this media type uses the "+xml" convention, it shares the same security considerations as other XML formats; see RFC 3023 (XML Media Types). Interoperability considerations: This media type is intended to be shared with other RIF dialects, to be specified in the future. Interoperation between the dialects is governed by the RIF specifications. Published specification: RIF Basic Logic Dialect W3C Working Draft (Recommendation Track) http://www.w3.org/TR/rif-bld/ This media type is intended to be shared with other RIF dialects, to be specified in the future. Applications that use this media type: Unknown at the time of this draft. Multiple applications are expected, however, before the specification reaches W3C Proposed Recommendation status. Additional information: Magic number(s): As with XML in general (See RFC 3023 (XML Media Types)), there is no magic number for this format. However, the XML namespace "http://www.w3.org/ns/rif" will normally be present in the document. It may theoretically be missing if the document uses XML entities in an obfuscatory manner. The hex form of that namespace will depend on the charset. For utf-8, the hex is: 68 74 74 70 3a 2f 2f 77 77 77 2e 77 33 2e 6f 72. File extension(s): .rif (or .xml) Macintosh file type code(s): "TEXT" (like other XML) Person & email address to contact for further information: Sandro Hawke, sandro@w3.org. Please send technical comments and questions about RIF to public-rif-comments@w3.org, a mailing list a public archive at http://lists.w3.org/Archives/Public/public-rif-comments/ Intended usage: COMMON Restrictions on usage: None Author: The editor and contact for this media type registration is Sandro Hawke, sandro@w3.org. Change controller: RIF is a product of the Rule Interchange Format (RIF) Working Group of the World Wide Web Consortium (W3C). See http://www.w3.org/2005/rules/wg for information on the group. The W3C (currently acting through this working group) has change control over the RIF specification. (Any other information that the author deems interesting may be added below this line.)