RIF Datatypes and Built-Ins 1.0

W3C ProposedRecommendation 11 May22 June 2010

This version:
Latest version:
Previous version:
http://www.w3.org/TR/2009/CR-rif-dtb-20091001/http://www.w3.org/TR/2010/PR-rif-dtb-20100511/ (color-coded diff)
Axel Polleres, DERI
Harold Boley, National Research Council Canada
Michael Kifer, State University of New York at Stony Brook

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

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

See also translations.


This document, developed by the Rule Interchange Format (RIF) Working Group, specifies a list of datatypes, built-in functions and built-in predicates expected to be supported by RIF dialects such as the RIF Core Dialect, the RIF Basic Logic Dialect, and the RIF Production Rules Dialect. Each dialect supporting a superset or subset of the datatypes, built-in functions and built-in predicates defined here shall specify these additions or restrictions. Some of the datatypes are adapted from [XML Schema Datatypes]. A large part of the definitions of the listed functions and operators are adapted from [XPath-Functions]. The rdf:PlainLiteral datatype as well as functions and operators associated with that datatype are adopted from [RDF-PLAINLITERAL].

Status of this Document

May Be Superseded

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

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

  1. RIF Overview
  2. RIF Core Dialect
  3. RIF Basic Logic Dialect
  4. RIF Production Rule Dialect
  5. RIF Framework for Logic Dialects
  6. RIF Datatypes and Built-Ins 1.0 (this document)
  7. RIF RDF and OWL Compatibility
  8. OWL 2 RL in RIF
  9. RIF Combination with XML data
  10. RIF In RDF
  11. RIF Test Cases

XML Schema Datatypes Dependency

RIF is defined to use datatypes defined in the XML Schema Definition Language (XSD). As of this writing, the latest W3C Recommendation for XSD is version 1.0, with version 1.1 progressing toward Recommendation. RIF has been designed to take advantage of the new datatypes and clearer explanations available in XSD 1.1, but for now those advantages are being partially put on hold. Specifically, until XSD 1.1 becomes a W3C Recommendation, the elements of RIF which are based on it should be considered optional, as detailed in Datatypes and Builtins, section 2.3. Upon the publication of XSD 1.1 as a W3C Recommendation, those elements will cease to be optional and are to be considered required as otherwise specified.

We suggest that for now developers and users follow the XSD 1.1 Last Call Working Draft. Based on discussions between the Schema, RIF and OWL Working Groups, we do not expect any implementation changes will be necessary as XSD 1.1 advances to Recommendation.

Summary of ChangesDocument Unchanged

There have been no substantivechanges to the body of this document since the previous version. For details on the minor changesearlier changes, see the change log and color-coded diff.

W3C MembersPlease Review By 8 June 2010 The W3C Director seeks review and feedback from W3C Advisory Committee representatives, via their review form by 8 June 2010. This will allow the Director to assess consensus and determine whetherSend Comments

Please send any comments to issuepublic-rif-comments@w3.org (public archive). Although work on this document as a W3C Recommendation. Others are encouragedby the Rule Interchange Format (RIF) Working Group to continue to send reports of implementation experience, and other feedback, to public-rif-comments@w3.org ( public archive ). Reports of any success or difficulty withis complete, comments may be addressed in the test cases are encouraged.errata or in future revisions. Open discussion among developers is welcome at public-rif-dev@w3.org (public archive).

Support The advancement ofEndorsed By W3C

This Proposed Recommendation is supporteddocument has been reviewed by the disposition of comments on the Candidate Recommendation, the Test Suite ,W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the list of implementations . No Endorsement PublicationDirector as a Proposed Recommendation does not imply endorsement by theW3C Membership. ThisRecommendation. It is a draftstable document and may be updated, replacedused as reference material or obsoleted by other documents at any time. Itcited from another document. W3C's role in making the Recommendation is inappropriateto citedraw attention to the specification and to promote its widespread deployment. This document as other than work in progress.enhances the functionality and interoperability of the Web.


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 .Table of Contents

1 Overview

This specification develops RIF-DTB (Datatypes and Built-Ins of the Rule Interchange Format). It lists the datatypes, built-in functions and built-in predicates expected to be supported by RIF dialects such as the RIF Core Dialect, the RIF Basic Logic Dialect, and the RIF Production Rules Dialect.

Some of the datatypes are adapted from [XML Schema Datatypes]. A large part of the definitions of the listed functions and operators are adapted from [XPath-Functions]. The rdf:PlainLiteral datatype as well as functions and operators associated with that datatype are adopted from [RDF-PLAINLITERAL]. Unlike the earlier SWRL built-ins [SWRL], which write n-ary functions as (1+n)-ary relations, functional RIF-DTB built-ins remain functions.

Currently in 1.0, RIF-DTB can also help in the interoperation of RIF with other (Semantic) Web formalisms by providing a general infrastructure of datatypes and built-ins.

2 Constants, Symbol Spaces, and Datatypes

2.1 Constants and Symbol Spaces

Each constant (that is, each non-keyword symbol) in RIF belongs to a particular symbol space. A constant in a particular RIF symbol space has the following presentation syntax:


where literal is called the lexical part of the symbol, and symbolSpaceIri is the (absolute or relative) IRI identifying the symbol space. Here literal is a Unicode string that must be an element in the lexical space of the symbol space identified by the IRI symbolSpaceIri.

2.2 The Base and Prefix Directives

Since IRIs typically require long strings of characters, many Web languages have special provisions for abbreviating these strings. One well-known technique is called compact URI [CURIE], and RIF uses a similar technique by allowing RIF documents to have the directives Base and Prefix.

The precise way in which these directives work is explained in Section Shortcuts for Constants in RIF's Presentation Syntax.

To avoid writing down long IRIs, this document will assume that the following Prefix directives have been specified in all the RIF documents under consideration:

Using these prefixes and the shorthand mechanism defined in Section Shortcuts for Constants in RIF's Presentation Syntax, we can, for example, abbreviate a constant such as "http://www.example.org"^^<http://www.w3.org/2007/rif#iri> into "http://www.example.org"^^rif:iri.

2.2.1 Symbol Spaces

Formally, we define symbol spaces as follows.

Definition (Symbol space). A symbol space is a named subset of the set of all constants, Const in RIF. Each symbol in Const belongs to exactly one symbol space.

Each symbol space has an associated lexical space, a unique IRI identifying it and a short name. More precisely,

The identifiers of symbol spaces are not themselves constant symbols in RIF.

For convenience we will often use symbol space identifiers to refer to the actual symbol spaces (for instance, we may use "symbol space xs:string" instead of "symbol space identified by xs:string").

RIF dialects are expected to include the symbol spaces listed in the following. However, rule sets that are exchanged through RIF can use additional symbol spaces.

In the following list we introduce short names for some of the symbol spaces. Short names are NCNames, typically the character sequence after the last '/' or '#' in the symbol space IRI (similar to the XML local name part of a QName). Short names are used for the predicates in Sections Guard Predicates for Datatypes and Negative Guard Predicates for Datatypes below.

The lexical spaces of the above symbol spaces are defined in the document [XML Schema Datatypes].

These two symbol spaces represent two subtypes of the XML Schema datatype xs:duration. The lexical spaces of the above symbol spaces are defined in the document [XDM].

The rdf:PlainLiteral symbol space represents text strings with a language tag attached. The lexical space of rdf:PlainLiteral is defined in the document [RDF-PLAINLITERAL].

The rdf:XMLLiteral symbol space represents XML content. The lexical space of rdf:XMLLiteral is defined in the document [RDF-CONCEPTS].

Constants in the rif:iri symbol space are intended to be used in a way similar to RDF resources [RDF-SCHEMA]. The lexical space consists of all absolute IRIs as specified in [RFC-3987]; it is unrelated to the XML primitive type xs:anyURI.

Constants in the rif:local symbol space are local to the RIF documents in which they occur. This means that occurrences of the same rif:local constant in different documents are viewed as unrelated distinct constants, but occurrences of the same rif:local constant in the same document must refer to the same object. The lexical space of rif:local is the same as the lexical space of xs:string.

Note that, by the associated lexical space, not all Unicode strings are syntactically valid lexical parts for all symbol spaces. That is, for instance, "1.2"^^xs:decimal and "1"^^xs:integer are syntactically valid constant because 1.2 and 1 are members of the lexical space of symbol spaces xs:decimal and xs:integer, respectively. On the other hand, "a+2"^^xs:decimal is not a syntactically valid constant, since a+2 is not part of the lexical space of xs:decimal.

We will often refer to constant symbols that come from a particular symbol space, X, as X constants, where X is the (short) name of the respective symbol space. For instance, the constants in the symbol space rif:iri will be referred to as IRI constants or rif:iri constants and the constants found in the symbol space rif:local as local constants or rif:local constants.

2.2.2 Shortcuts for Constants in RIF's Presentation Syntax

Besides the basic notion


RIF's presentation syntax introduces several shortcuts for particular symbol spaces, in order to make the presentation syntax more readable. RIF's presentation syntax for constants is defined by the following EBNF.

  CURIE         ::= PNAME_LN | PNAME_NS
  Const         ::= '"' UNICODESTRING '"^^' SYMSPACE | CONSTSHORT
  CONSTSHORT    ::= ANGLEBRACKIRI              // shortcut for "..."^^rif:iri
                  | CURIE                      // shortcut for "..."^^rif:iri
                  | '"' UNICODESTRING '"'      // shortcut for "..."^^xs:string
                  | NumericLiteral             // shortcut for "..."^^xs:integer,xs:decimal,xs:double
                  | '_' NCName                   // shortcut for "..."^^rif:local
                  | '"' UNICODESTRING '"' '@' langtag             // shortcut for "...@..."^^rdf:PlainLiteral

The EBNF grammar relies on reuse of nonterminals defined in the following grammar productions from other documents:

In this grammar, CURIE stands for compact IRIs [CURIE], which are used to abbreviate symbol space IRIs. For instance, one can write "http://www.example.org"^^rif:iri instead of "http://www.example.org"^^<http://www.w3.org/2007/rif#iri>, where rif is a prefix defined in Section Base and Prefix Directives.

Apart from compact IRIs, there exist convenient shortcut notations for constants in specific symbol spaces, namely for constants in the symbol spaces rif:iri, xs:string, xs:integer, xs:decimal, xs:double, and rif:local:

2.2.3 Relative IRIs

Relative IRIs in RIF documents are resolved with respect to the base IRI. Relative IRIs are combined with base IRIs as per Uniform Resource Identifier (URI): Generic Syntax [RFC-3986] using only the basic algorithm in Section 5.2. Neither Syntax-Based Normalization nor Scheme-Based Normalization (described in Sections 6.2.2 and 6.2.3 of RFC-3986) are performed. Characters additionally allowed in IRI references are treated in the same way that unreserved characters are treated in URI references, per Section 6.5 of Internationalized Resource Identifiers (IRIs) [RFC-3987].

Base IRIs are specified using the Base directive described in Section Base and Prefix Directives. At most one base directive per document is allowed. In the XML syntax, base IRIs are specified using the attribute xml:base.

For instance, the constant <./xyz> or "./xyz"^^rif:iri are both valid abbreviations in RIF for the constant http://www.example.org/xyz"^^rif:iri, if the following directive is present in the document:


2.3 Datatypes

Datatypes in RIF are symbol spaces which have special semantics. That is, each datatype is characterized by a fixed lexical space, value space and lexical-to-value-mapping.

Definition (Datatype). A datatype is a symbol space that has

Semantic structures are always defined with respect to a particular set of datatypes, denoted by DTS. In a concrete dialect, DTS always includes the datatypes supported by that dialect. RIF dialects are expected to support the following datatypes. However, RIF dialects may include additional datatypes. Subitems in the following lists indicate derived datatypes.

Their value spaces and the lexical-to-value-space mappings are defined as follows:

2.3.1 XML Schema Datatypes

As of the publication of this document, XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes [XML Schema Datatypes] is not yet a W3C Recommendation. Both the RIF Working Group and the XML Schema Working Group are confident that there will be only minor changes before it becomes a W3C Recommendation. In order to take advantage of the anticipated corrections and new features sooner, while also providing stability in case the specification does not advance as expected, conformance to RIF as it relates to XML Schema Datatypes is defined as follows:

This "change in normative reference" is effective as of the publication of XSD 1.1 as a W3C Recommendation. However, W3C expects to publish a new edition of RIF Datatypes and Built-Ins 1.0 once XSD 1.1 becomes a Recommendation to update the reference explicitly.

3 Syntax and Semantics of Built-ins

3.1 Syntax of Built-ins

A RIF built-in function or predicate is a special case of externally defined terms, which are defined in RIF Framework for Logic Dialects and also reproduced in the direct definition of RIF Basic Logic Dialect (RIF-BLD).

In RIF's presentation syntax built-in predicates and functions are syntactically represented as external terms of the form:

'External' '(' Expr ')'

where Expr is a positional term as defined in RIF Framework for Logic Dialects (see also in RIF Basic Logic Dialect). For RIF's normative syntax, see the XML Serialization Framework in RIF-FLD, or, specifically for RIF-BLD, see XML Serialization Syntax for RIF-BLD.

RIF-FLD introduces the notion of an external schema to describe both the syntax and semantics of exernally defined terms. In the special case of a RIF built-in, external schemas have an especially simple form. A built-in named f that takes n arguments has the schema

( ?X1 ... ?Xn;   f(?X1 ... ?Xn) )

Here f(?X1 ... ?Xn) is the actual positional term that is used to refer to the built-in (in expressions of the form External(f(?X1 ... ?Xn))) and ?X1 ... ?Xn is the list of all variables in that term.

Note that RIF-BLD allows additional forms of built-ins, which includes named-argument terms.

RIF-FLD defines a very general notion of external terms and schemas, but RIF-BLD and the present document use more restricted notions. For convenience, we present a complete definition of these restricted notions in Appendix: Schemas for Externally Defined Terms.

3.2 Semantics of Built-ins

The semantics of external terms is defined using two mappings: Iexternal and Itruth ο Iexternal.

4 List of RIF Built-in Predicates and Functions

This section provides a catalogue defining the syntax and semantics of a list of built-in predicates and functions in RIF. For each built-in, the following is defined:

  1. The name of the built-in.
  2. The external schema of the built-in.
  3. For a built-in function, how it maps its arguments into a result.

    As explained in Section Semantics of Built-ins, this corresponds to the mapping Iexternal(σ) in the formal semantics of RIF-FLD and RIF-BLD, where σ is the external schema of the built-in.

  4. For a built-in predicate, its truth value when the arguments are substituted with values in the domain.

    As explained in Section Semantics of Built-ins, this corresponds to the mapping Itruth ο Iexternal(σ) in the formal semantics of RIF-FLD and RIF-BLD, where σ is the external schema of the built-in.

  5. The domains for the arguments of the built-in.

    Typically, built-in functions and predicates are defined over the value spaces of appropriate datatypes, i.e. the domains of the arguments. When an argument falls outside of its domain, it is understood as an error. Since this document defines a model-theoretic semantics for RIF built-ins, which does not support the notion of an error, the definitions leave the values of the built-in predicates and functions unspecified in such cases. This means that if one or more of the arguments is not in its domain, the value of Iexternal(σ)(a1 ... an) is unspecified. In particular, this means it can vary from one implementation to another. Similarly, Itruth ο Iexternal(σ)(a1 ... an) is unspecified when an argument is not in its domain.

    This indeterminacy in case of an error implies that applications should not make any assumptions about the values of built-ins in such situations. Implementations are even allowed to abort in such cases and the only safe way to communicate rule sets that contain built-ins among RIF-compliant systems is to use datatype guards.

Many built-in functions and predicates described below are adapted from [XPath-Functions] and, when appropriate, we will refer to the definitions in that specification in order to avoid copying them. The differences from the original [XPath-Functions] include the handling of errors, the differentiation between predicates and functions, and a few specific differences noted in the definitions below.

4.1 Predicates for all Datatypes

4.1.1 Comparison for Literals

RIF supports identity for typed literals through the "=" predicate in all dialects that extend RIF-Core. Identity for typed literals is defined as being the same point in the value space for that type. Certain datatypes use more specific notions of equality that allow for multiple points in the value space to be considered equal. For each datatype specific notion of equality we refer to the supported predicate for that datatype.

Since the basic RIF dialects do not support negation, dialects that extend RIF-Core define a built-in for checking the non-identity of two typed literals. pred:literal-not-identical

4.2 Guard Predicates for Datatypes

RIF defines guard predicates for all datatypes in Section Datatypes.

Accordingly, the following schemas are defined.

Future dialects may extend this list of guards to other datatypes, but RIF does not require guards for all datatypes.

4.3 Negative Guard Predicates for Datatypes

Likewise, RIF defines negative guard predicates for all datatypes in Section Datatypes.

Accordingly, the following schemas are defined.

Future dialects may extend this list of negative guards to other datatypes, but RIF does not require negative guards for all datatypes.

Note: The semantics of negative guards may be surprising. The is-literal-not-String guard essentially asks, "Is this a literal, and (if it is) is it something other than a String?" It could also be read as "Is this a decimal or a float or a double or a date or a dateTime, etc, [for every datatype except string] ?". The negative guards are formulated like this to allow for rules which detect, for instance, some kinds of bad inputs, while still using the open world assumption of some RIF dialects.

4.4 Datatype Conversion and Casting

In the following, we adapt several cast functions according to the conversions defined in Section 17.1 of [XPath-Functions]. Note that some of these conversions are only partially defined, which affects the domains of these cast functions.

Likewise we define a conversion predicate useful for converting between rif:iri constants and strings, as well as a predicate to check the datatype of a constant.

4.4.1 Casting to XML Schema Datatypes

The casting functions in Section 17.1 of [XPath-Functions] define mappings from source values SV, which are data values, annotated with source types ST, to target values TV, annotated with target types TT. The data values V we consider are not necessarily explicitly annotated with types. However, one can view the datatypes D1,...,Dn whose value spaces include a data value V as the types of V. We assume in the following that any of the data types D1,...,Dn is used as the annotation of the source value SV; the conversions in [XPath-Functions] are defined equivalently for all such datatypes.

Accordingly, the following schemas are defined:

4.4.2 Casting to rdf:XMLLiteral

4.4.3 Casting to rdf:PlainLiteral

4.4.4 pred:iri-string

Conversions from rif:iri to xs:string and vice versa cannot be defined by the casting functions as above since rif:iri is not a datatype with a well-defined value space.

To this end, since conversions from IRIs (resources) to strings are a needed feature, for instance, for conversions between RDF formats (see example below), we introduce a built-in predicate which supports such conversions.

4.5 Numeric Functions and Predicates

The following functions and predicates are adapted from the respective numeric functions and operators in [XPath-Functions].

4.5.1 Numeric Functions

The following numeric binary built-in functions func:numeric-add, func:numeric-subtract, func:numeric-multiply, func:numeric-divide, func:numeric-integer-divide, and func:numeric-mod are defined in accordance with their corresponding operators in [XPath-Functions].

Accordingly, the following schemas are defined:

4.5.2 Numeric Predicates pred:numeric-equal (adapted from op:numeric-equal) pred:numeric-less-than (adapted from op:numeric-less-than) pred:numeric-greater-than (adapted from op:numeric-greater-than) pred:numeric-not-equal

The predicate pred:numeric-not-equal has the same domains as pred:numeric-equal and is true whenever pred:numeric-equal is false and false otherwise. pred:numeric-less-than-or-equal

The predicate pred:numeric-less-than-or-equal has the same domains as pred:numeric-equal and is true whenever pred:numeric-equal is true or pred:numeric-less-than is true and false otherwise. pred:numeric-greater-than-or-equal

The predicate pred:numeric-greater-than-or-equal has the same domains as pred:numeric-equal and is true whenever pred:numeric-equal is true or pred:numeric-greater-than is true and false otherwise.

4.6 Functions and Predicates on Boolean Values

The following functions and predicates are adapted from the respective functions and operators on boolean values in [XPath-Functions].

4.6.1 Functions on Boolean Values func:not (adapted from fn:not)

4.6.2 Predicates on Boolean Values pred:boolean-equal (adapted from op:boolean-equal)

The following built-in predicates pred:boolean-less-than and pred:boolean-greater-than are defined analogously with respect to their corresponding operators in [XPath-Functions]. pred:boolean-less-than (adapted from op:boolean-less-than) pred:boolean-greater-than (adapted from op:boolean-greater-than)

4.7 Functions and Predicates on Strings

The following functions and predicates are adapted from the respective functions and operators on strings in [XPath-Functions].

4.7.1 Functions on Strings func:compare (adapted from fn:compare) func:concat (adapted from fn:concat) func:string-join (adapted from fn:string-join) func:substring (adapted from fn:substring)

Note that, as in XPath-Functions, the first character of a string is located at position 1, not position 0. func:string-length (adapted from fn:string-length) func:upper-case (adapted from fn:upper-case) func:lower-case (adapted from fn:lower-case) func:encode-for-uri (adapted from fn:encode-for-uri) func:iri-to-uri (adapted from fn:iri-to-uri) func:escape-html-uri (adapted from fn:escape-html-uri) func:substring-before (adapted from fn:substring-before) func:substring-after (adapted from fn:substring-after) func:replace (adapted from fn:replace)

4.7.2 Predicates on Strings pred:contains (adapted from fn:contains) pred:starts-with (adapted from fn:starts-with) pred:ends-with (adapted from fn:ends-with) pred:matches (adapted from fn:matches)

4.8 Functions and Predicates on Dates, Times, and Durations

If not stated otherwise, in the following we define schemas for functions and operators defined on the date, time and duration datatypes in [XPath-Functions].

As defined in Section 3.3.2 Dates and Times, xs:dateTime, xs:date, xs:time, xs:gYearMonth, xs:gYear, xs:gMonthDay, xs:gMonth, xs:gDay values, referred to collectively as date/time values, are represented as seven components or properties: year, month, day, hour, minute, second and timezone. The value of the first five components are xs:integers. The value of the second component is an xs:decimal and the value of the timezone component is an xs:dayTimeDuration. For all the date/time datatypes, the timezone property is optional and may or may not be present. Depending on the datatype, some of the remaining six properties must be present and some must be absent. Absent, or missing, properties are represented by the empty sequence. This value is referred to as the local value in that the value is in the given timezone. Before comparing or subtracting xs:dateTime values, this local value must be translated or normalized to UTC.

4.8.1 Functions on Dates, Times, and Durations func:year-from-dateTime (adapted from fn:year-from-dateTime)

Note that we we slightly deviate here from the original definition of fn:year-from-dateTime which says: "If ?arg is the empty sequence, returns the empty sequence." The RIF version of func:year-from-dateTime does not support "empty sequences". func:month-from-dateTime (adapted from fn:month-from-dateTime) func:day-from-dateTime (adapted from fn:day-from-dateTime) func:hours-from-dateTime (adapted from fn:hours-from-dateTime) func:minutes-from-dateTime (adapted from fn:minutes-from-dateTime) func:seconds-from-dateTime (adapted from fn:seconds-from-dateTime) func:year-from-date (adapted from fn:year-from-date) func:month-from-date (adapted from fn:month-from-date) func:day-from-date (adapted from fn:day-from-date) func:hours-from-time (adapted from fn:hours-from-time) func:minutes-from-time (adapted from fn:minutes-from-time) func:seconds-from-time (adapted from fn:seconds-from-time) func:years-from-duration (adapted from fn:years-from-duration) func:months-from-duration (adapted from fn:months-from-duration) func:days-from-duration (adapted from fn:days-from-duration) func:hours-from-duration (adapted from fn:hours-from-duration) func:minutes-from-duration (adapted from fn:minutes-from-duration) func:seconds-from-duration (adapted from fn:seconds-from-duration) func:timezone-from-dateTime (adapted from fn:timezone-from-dateTime)

The following two functions are defined analogously for domains xs:date and xs:time func:timezone-from-date (adapted from fn:timezone-from-date) func:timezone-from-time (adapted from fn:timezone-from-time) func:subtract-dateTimes (adapted from op:subtract-dateTimes) func:subtract-dates (adapted from op:subtract-dates) func:subtract-times (adapted from op:subtract-times) func:add-yearMonthDurations (adapted from op:add-yearMonthDurations) func:subtract-yearMonthDurations (adapted from op:subtract-yearMonthDurations) func:multiply-yearMonthDuration (adapted from op:multiply-yearMonthDuration) func:divide-yearMonthDuration (adapted from op:divide-yearMonthDuration) func:divide-yearMonthDuration-by-yearMonthDuration (adapted from op:divide-yearMonthDuration-by-yearMonthDuration) func:add-dayTimeDurations (adapted from op:add-dayTimeDurations) func:subtract-dayTimeDurations (adapted from op:subtract-dayTimeDurations) func:multiply-dayTimeDuration (adapted from op:multiply-dayTimeDuration) func:divide-dayTimeDuration (adapted from op:divide-dayTimeDuration) func:divide-dayTimeDuration-by-dayTimeDuration (adapted from op:divide-dayTimeDuration-by-dayTimeDuration) func:add-yearMonthDuration-to-dateTime (adapted from op:add-yearMonthDuration-to-dateTime) func:add-yearMonthDuration-to-date (adapted from op:add-yearMonthDuration-to-date) func:add-dayTimeDuration-to-dateTime (adapted from op:add-dayTimeDuration-to-dateTime) func:add-dayTimeDuration-to-date (adapted from op:add-dayTimeDuration-to-date) func:add-dayTimeDuration-to-time (adapted from op:add-dayTimeDuration-to-time) func:subtract-yearMonthDuration-from-dateTime (adapted from op:subtract-yearMonthDuration-from-dateTime) func:subtract-yearMonthDuration-from-date (adapted from op:subtract-yearMonthDuration-from-date) func:subtract-dayTimeDuration-from-dateTime (adapted from op:subtract-dayTimeDuration-from-dateTime) func:subtract-dayTimeDuration-from-date (adapted from op:subtract-dayTimeDuration-from-date) func:subtract-dayTimeDuration-from-time (adapted from op:subtract-dayTimeDuration-from-time)

4.8.2 Predicates on Dates, Times, and Durations pred:dateTime-equal (adapted from op:dateTime-equal) pred:dateTime-less-than (adapted from op:dateTime-less-than) pred:dateTime-greater-than (adapted from op:dateTime-greater-than) pred:date-equal (adapted from op:date-equal) pred:date-less-than (adapted from op:date-less-than) pred:date-greater-than (adapted from op:date-greater-than) pred:time-equal (adapted from op:time-equal) pred:time-less-than (adapted from op:time-less-than) pred:time-greater-than (adapted from op:time-greater-than) pred:duration-equal (adapted from op:duration-equal) pred:dayTimeDuration-less-than (adapted from op:dayTimeDuration-less-than) pred:dayTimeDuration-greater-than (adapted from op:dayTimeDuration-greater-than) pred:yearMonthDuration-less-than (adapted from op:yearMonthDuration-less-than) pred:yearMonthDuration-greater-than (adapted from op:yearMonthDuration-greater-than) pred:dateTime-not-equal

The predicate pred:dateTime-not-equal has the same domains as pred:dateTime-equal and is true whenever pred:dateTime-equal is false. pred:dateTime-less-than-or-equal

The predicate pred:dateTime-less-than-or-equal has the same domains as pred:dateTime-equal and is true whenever pred:dateTime-equal is true or pred:dateTime-less-than is true. pred:dateTime-greater-than-or-equal

The predicate pred:dateTime-greater-than-or-equal has the same domains as pred:dateTime-equal and is true whenever pred:dateTime-equal is true or pred:dateTime-greater-than is true. pred:date-not-equal

The predicate pred:date-not-equal has the same domains as pred:date-equal and is true whenever pred:date-equal is false. pred:date-less-than-or-equal

The predicate pred:date-less-than-or-equal has the same domains as pred:date-equal and is true whenever pred:date-equal is true or pred:date-less-than is true. pred:date-greater-than-or-equal

The predicate pred:date-greater-than-or-equal has the same domains as pred:date-equal and is true whenever pred:date-equal is true or pred:date-greater-than is true. pred:time-not-equal

The predicate pred:time-not-equal has the same domains as pred:time-equal and is true whenever pred:time-equal is false. pred:time-less-than-or-equal

The predicate pred:time-less-than-or-equal has the same domains as pred:time-equal and is true whenever pred:time-equal is true or pred:time-less-than is true. pred:time-greater-than-or-equal

The predicate pred:time-greater-than-or-equal has the same domains as pred:time-equal and is true whenever pred:time-equal is true or pred:time-greater-than is true. pred:duration-not-equal

The predicate pred:duration-equal has the same domains as pred:duration-equal and is true whenever pred:duration-equal is false. pred:dayTimeDuration-less-than-or-equal

The predicate pred:dayTimeDuration-less-than-or-equal has the same domains as pred:dayTimeDuration-less-than and is true whenever pred:duration-equal is true or pred:dayTimeDuration-less-than is true. pred:dayTimeDuration-greater-than-or-equal

The predicate pred:dayTimeDuration-greater-than-or-equal has the same domains as pred:dayTimeDuration-greater-than and is true whenever pred:duration-equal is true or pred:dayTimeDuration-greater-than is true. pred:yearMonthDuration-less-than-or-equal

The predicate pred:yearMonthDuration-less-than-or-equal has the same domains as pred:yearMonthDuration-less-than and is true whenever pred:duration-equal is true or pred:yearMonthDuration-less-than is true. pred:yearMonthDuration-greater-than-or-equal

The predicate pred:yearMonthDuration-greater-than-or-equal has the same domains as pred:yearMonthDuration-greater-than and is true whenever pred:duration-equal is true or pred:yearMonthDuration-greater-than is true.

4.9 Functions and Predicates on rdf:XMLLiterals

4.9.1 pred:XMLLiteral-equal

4.9.2 pred:XMLLiteral-not-equal

The predicate pred:time-not-equal has the same domains as pred:XMLLiteral-equal and is true whenever pred:XMLLiteral-equal is false.

4.10 Functions and Predicates on rdf:PlainLiteral

The following functions and predicates are adapted from the respective functions and operators in [RDF-PLAINLITERAL].

4.10.1 Functions on rdf:PlainLiteral func:PlainLiteral-from-string-lang (adapted from plfn:PlainLiteral-from-string-lang) func:string-from-PlainLiteral (adapted from plfn:string-from-PlainLiteral) func:lang-from-PlainLiteral (adapted from plfn:lang-from-PlainLiteral) func:PlainLiteral-compare (adapted from plfn:compare) func:PlainLiteral-length (adapted from plfn:length)

4.10.2 Predicates on rdf:PlainLiteral pred:matches-language-range (adapted from plfn:matches-language-range)

4.11 Functions and Predicates on RIF Lists

RIF Lists are similar to list and array types in many systems, as well as XPath/XQuery Sequences [XPath-Functions]. They differ from XPath as follows:

4.11.1 Position Numbering

The positions in a list are numbered starting with zero. That is, in a list of length n+1, the first item has position 0, and the last item has position n. When a negative position number is provided to a builtin, the length of the list is added to it before it is used, so it effectively counts backward from the end of the list: position -1 points to the last item in the list, i.e. corresponds effectively to position n, etc.

4.11.2 Item Comparison

List items are compared for equality (as required by many of these builtins) using normal RIF equality testing, not datatype equality (e.g., pred:numeric-equal).

Several list builtins need to establish inequality in order to compute a result. If all the compared items are literals or lists, this is not a problem, but if they are rif:local or rif:iri terms, the knowledge base is unlikely to contain inequality information. This may lead to counter-intuitive results. For example, the empty ruleset does not entail External(func:index-of( List(ex:foo ex:bar) ex:foo) ) == List(0), because the empty ruleset provides no indication whether eg:foo = eg:bar.

4.11.3 Predicates on RIF Lists pred:is-list pred:list-contains

4.11.4 Functions on RIF Lists func:make-list func:count (adapted from fn:count) func:get func:sublist (adapted from fn:subsequence) func:append func:concatenate (adapted from fn:concatenate) func:insert-before (adapted from fn:insert-before) func:remove (adapted from fn:remove) func:reverse (adapted from fn:reverse) func:index-of (adapted from fn:index-of) func:union (inspired by fn:union) func:distinct-values (adapted from fn:distinct-values) func:intersect (inspired by fn:intersect) func:except (inspired by fn:except)

5 References

BCP 47 - Tags for the Identification of Languages, A. Phillips, M. Davis, IETF, Sep 2006, http://tools.ietf.org/html/bcp47.

CURIE Syntax 1.0, M. Birbeck, S. McCarron, W3C Candidate Recommendation, 16 January 2009, http://www.w3.org/TR/2009/CR-curie-20090116/. Latest version available at http://www.w3.org/TR/curie/.

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

RDF Semantics, P. Hayes, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/. Latest version available at http://www.w3.org/TR/rdf-mt/.

RDF Vocabulary Description Language 1.0: RDF Schema, B. McBride, Editor, W3C Recommendation 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-schema-20040210/. Latest version available at http://www.w3.org/TR/rdf-schema/.
rdf:PlainLiteral: A Datatype for RDF Plain Literals, J. Bao, S. Hawke, B. Motik, P.F. Patel-Schneider, A. Polleres (Editors), W3C Candidate Recommendation, 11 June 2009, http://www.w3.org/TR/2009/CR-rdf-plain-literal-20090611/. Latest version available at http://www.w3.org/TR/rdf-plain-literal/.

RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, IETF, January 2005, http://www.ietf.org/rfc/rfc3986.txt.

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

RIF Basic Logic Dialect Harold Boley, Michael Kifer, eds. W3C ProposedRecommendation, 11 May22 June 2010, http://www.w3.org/TR/2010/PR-rif-bld-20100511/http://www.w3.org/TR/2010/REC-rif-bld-20100622/. Latest version available at http://www.w3.org/TR/rif-bld/.

RIF Core Dialect Harold Boley, Gary Hallmark, Michael Kifer, Adrian Paschke, Axel Polleres, Dave Reynolds, eds. W3C ProposedRecommendation, 11 May22 June 2010, http://www.w3.org/TR/2010/PR-rif-core-20100511/http://www.w3.org/TR/2010/REC-rif-core-20100622/. Latest version available at http://www.w3.org/TR/rif-core/.

RIF Framework for Logic Dialects Harold Boley, Michael Kifer, eds. W3C ProposedRecommendation, 11 May22 June 2010, http://www.w3.org/TR/2010/PR-rif-fld-20100511/http://www.w3.org/TR/2010/REC-rif-fld-20100622/. Latest version available at http://www.w3.org/TR/rif-fld/.

RIF Production Rule Dialect Christian de Sainte Marie, Gary Hallmark, Adrian Paschke, eds. W3C ProposedRecommendation, 11 May22 June 2010, http://www.w3.org/TR/2010/PR-rif-prd-20100511/http://www.w3.org/TR/2010/REC-rif-prd-20100622/. Latest version available at http://www.w3.org/TR/rif-prd/.

SPARQL Query Language for RDF, E. Prud'hommeaux, A. Seaborne (Editors), W3C Recommendation, World Wide Web Consortium, 12 January 2008, http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/. Latest version available at http://www.w3.org/TR/rdf-sparql-query/.

SWRL: A Semantic Web Rule Language Combining OWL and RuleML, I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Tabet, B., M. Dean, W3C Member Submission, 21 May 2004, http://www.w3.org/Submission/2004/SUBM-SWRL-20040521/. Latest version available at http://www.w3.org/Submission/SWRL/.

XQuery 1.0 and XPath 2.0 Data Model (XDM), M. Fernández, A. Malhotra, J. Marsh, M. Nagy, N. Walsh (Editors), W3C Recommendation, World Wide Web Consortium, 23 January 2007. This version is http://www.w3.org/TR/2007/REC-xpath-datamodel-20070123/. Latest version available at http://www.w3.org/TR/xpath-datamodel/.

Namespaces in XML 1.1 (Second Edition), T. Bray, D. Hollander, A. Layman, R. Tobin (Editors), W3C Recommendation, World Wide Web Consortium, 16 August 2006, http://www.w3.org/TR/2006/REC-xml-names11-20060816/. Latest version available at http://www.w3.org/TR/xml-names11/.
[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 Candidate Recommendation, 30 April 2009, http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/. Latest version available as http://www.w3.org/TR/xmlschema11-2/.

XML Path Language (XPath) 2.0, A. Berglund, S. Boag, D. Chamberlin, M. F. Fernández, M, Kay, J. Robie, J. Siméon (Editors), W3C Recommendation, World Wide Web Consortium, 23 January 2007, http://www.w3.org/TR/2007/REC-xpath20-20070123/. Latest version available at http://www.w3.org/TR/xpath20/.

XQuery 1.0 and XPath 2.0 Functions and Operators, A. Malhotra, J. Melton, N. Walsh (Editors), W3C Recommendation, World Wide Web Consortium, 23 January 2007, http://www.w3.org/TR/2007/REC-xpath-functions-20070123/. Latest version available at http://www.w3.org/TR/xpath-functions/.

6 Appendix: Schemas for Externally Defined Terms

The RIF Framework for Logic Dialects introduces a general notion of externally defined terms and their schemes. However, RIF-BLD and the present document use only restricted kinds of external terms. To make this document self-contained, this appendix provides a complete description of these restricted notions.

In RIF-FLD, an external term is an expression of the form External(id τ), where id is a term that identifies the source that defines the term τ and τ itself can be a constant, a positional or named-arguments term, a frame, an equality, or a classification term. In RIF-BLD, only positional and named-argument terms are allowed as τ, and RIF-DTB builtins can only be positional terms. So, only a restricted kind of external terms is used: External(τ), where τ has one of the aforementioned forms. If τ is a term of the form p(...) then External(τ) is treated as a shorthand for External(p τ), but this extended 2-argument form of External itself is not allowed in RIF-BLD.

External schemas serve as templates for externally defined terms. These schemas determine which externally defined terms are acceptable in a RIF dialect. Externally defined terms include RIF built-ins, but are more general. They are designed to also accommodate the ideas of procedural attachments and querying of external data sources.

Definition (Schema for external term). An external schema is a statement of the form (?X1 ... ?Xn; τ) where

The names of the variables in an external schema are immaterial, but their order is important. For instance, (?X ?Y;  ?X[foo->?Y]) and (?V ?W;  ?V[foo->?W]) are considered to be indistinguishable, but (?X ?Y;  ?X[foo->?Y]) and (?Y ?X;  ?X[foo->?Y]) are viewed as different schemas.

Note that RIF-FLD defines external schemas as triples (id; ?X1 ... ?Xn; τ), where id is the identifying term for the schema's source. However, since RIF-BLD uses a simplified version of externally defined terms in which id is determined by the predicate/function name in τ, the id-part is omitted in the above simplified version of external schemas.

A term t is an instantiation of an external schema (?X1 ... ?Xn; τ) iff t can be obtained from τ by a simultaneous substitution ?X1/s1 ... ?Xn/sn of the variables ?X1 ... ?Xn with terms s1 ... sn, respectively. Some of the terms si can be variables themselves. For example, ?Z[foo->f(a ?P)] is an instantiation of (?X ?Y; ?X[foo->?Y]) by the substitution ?X/?Z  ?Y/f(a ?P).    ☐

Observe that a variable cannot be an instantiation of an external schema, since τ in the above definition cannot be a variable. It will be seen later that this implies that a term of the form External(?X) is not well-formed in RIF.

The intuition behind the notion of an external schema, such as (?X ?Y;  ?X["foo"^^xs:string->?Y]) or (?V;  "pred:isTime"^^rif:iri(?V)), is that ?X["foo"^^xs:string->?Y] or "pred:isTime"^^rif:iri(?V) are invocation patterns for querying external sources, and instantiations of those schemas correspond to concrete invocations. Thus, External("http://foo.bar.com"^^rif:iri["foo"^^xs:string->"123"^^xs:integer]) and External("pred:isTime"^^rif:iri("22:33:44"^^xs:time) are examples of invocations of external terms -- one querying an external source and another invoking a built-in.

Definition (Coherent set of external schemas). A set of external schemas is coherent if there is no term, t, that is an instantiation of two distinct schemas in the set.    ☐

The intuition behind this notion is to ensure that any use of an external term is associated with at most one external schema. This assumption is relied upon in the definition of the semantics of externally defined terms. Note that the coherence condition is easy to verify syntactically and that it implies that schemas like (?X ?Y;  ?X[foo->?Y]) and (?Y ?X;  ?X[foo->?Y]), which differ only in the order of their variables, cannot be in the same coherent set.

It is important to keep in mind that external schemas are not part of the language in RIF, since they do not appear anywhere in RIF statements. Instead, they are best thought of as part of the grammar of the language.

7 Appendix: Changes from Candidate Recommendation Version of October 1, 2010