RIF Datatypes and Built-Ins 1.0

W3C Working Draft 3 July 2009

This version:
Latest version:
Previous version:
Axel Polleres, DERI
Harold Boley, National Research Council Canada
Michael Kifer, State University of New York at Stony Brook

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


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 6 documents:

  1. RIF Core Dialect
  2. RIF Basic Logic Dialect
  3. RIF Framework for Logic Dialects
  4. RIF RDF and OWL Compatibility
  5. RIF Datatypes and Built-Ins 1.0 (this document)
  6. RIF Production Rule Dialect

Summary of Changes

Since the last version, the rdf:text datatype has been renamed rdf:PlainLiteral, and list functions have been added, in addition to general editorial improvements.

Last Call

The Working Group believes it has completed its design work for the technologies specified in this document, so this is a "Last Call" draft. The design is not expected to change significantly going forward, and now is the key time for external review, before the implementation phase.

Please Comment By 31 July 2009

The Rule Interchange Format (RIF) Working Group seeks public feedback on this Working Draft. 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 and see if the relevant text has already been updated.

No Endorsement

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.

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 adopted from [XML-SCHEMA2]. A large part of the definitions of the listed functions and operators are adopted 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-SCHEMA2].

These two symbol spaces represent two subtypes of the XML Schema datatype xs:duration with well-defined value spaces, since xs:duration does not have a well-defined value space (this may be corrected in later revisions of XML Schema datatypes, in which case the revised datatype would be suitable for RIF DTB). 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
                  | '_' LocalName              // shortcut for "..."^^rif:local
                  | '"' UNICODESTRING '"' '@' languageTag             // 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:

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.

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.

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

Editor's Note: Issues which are still open in the rdf:PlainLiteral specification might imply future changes on the functions and predicates defined here. For instance plfn:compare and plfn:length are curently marked AT RISK. We could subsume these functions under a single func:compare and func:compare function, instead of defining separate functions for xs:string and rdf:PlainLiteral, or drop them alltogether for redundancy. Moreover, references and links to the [RDF-PLAINLITERAL] document will be updated in future versions of this document.

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 the first item being zero. 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 is the last item in the list, 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 (eg 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 index-of(list(eg:foo eg:bar), eg: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 (adapted from fn:union) func:distinct-values (adapted from fn:distinct-values) func:intersect (adapted from fn:intersect) func:except (adapted from 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 Working Draft, 6 May 2008, http://www.w3.org/TR/2007/WD-curie-20071126/. 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 Working Draft, 3 July 2009, http://www.w3.org/TR/2009/WD-rif-bld-20090703/. 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 Working Draft, 3 July 2009, http://www.w3.org/TR/2009/WD-rif-core-20090703/. Latest version available at http://www.w3.org/TR/rif-core/.

RIF Framework for Logic Dialects Harold Boley, Michael Kifer, eds. W3C Working Draft, 3 July 2009, http://www.w3.org/TR/2009/WD-rif-fld-20090703/. Latest version available at http://www.w3.org/TR/rif-fld/.

RIF Production Rule Dialect Christian de Sainte Marie, Adrian Paschke, Gary Hallmark, eds. W3C Working Draft, 3 July 2009, http://www.w3.org/TR/2009/WD-rif-prd-20090703/. 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/.

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 instance 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 instance of (?X ?Y; ?X[foo->?Y]) by the substitution ?X/?Z  ?Y/f(a ?P).    ☐

Observe that a variable cannot be an instance 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 instances 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 instance 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.