W3C


RIF Data Types and Built-Ins 1.0

W3C Editor's Draft 09 June02 July 2008

This version:
http://www.w3.org/2005/rules/wg/draft/ED-rif-dtb-20080609/http://www.w3.org/2005/rules/wg/draft/ED-rif-dtb-20080702/
Latest editor's draft:
http://www.w3.org/2005/rules/wg/draft/rif-dtb/
Previous version:
http://www.w3.org/2005/rules/wg/draft/ED-rif-dtb-20080518/http://www.w3.org/2005/rules/wg/draft/ED-rif-dtb-20080609/ (color-coded diff)
Editors:
Axel Polleres, DERI
Harold Boley, National Research Council Canada
Michael Kifer, State University of New York at Stony Brook

Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

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

  1. RIF Use Cases and Requirements
  2. RIF Basic Logic Dialect RIF Framework for Logic Dialects RIF RDF and OWL Compatibility RIF Production Rule Dialect RIFData Types and Built-Ins 1.0 (this document)

Please Comment By 2008-06-132008-07-07

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.

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.

Patents

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 document, developed by the Rule Interchange Format (RIF) Working Group, specifies a list of primitive datatypes,data types, built-in functions and built-in predicates requiredexpected to be supported by RIF dialects such as the RIF Basic Logic Dialect. This list shall be viewed asEach dialect supporting a catalogue which dialects can use by referencing which datatypes and builtins must be supported by implementationssuperset or subset of the primitive data types, built-in functions and built-in predicates defined here shall specify these specific dialects.additions or restrictions. Some of the datatypesdata types are adopted from [XML-SCHEMA2]. A large part of the definitions of the listed functions and operators are adapted from [XPath-Functions].


Contents

1 Naming and notational conventions used in this document

Throughout this document we use the following prefixes for compact IRIs [CURIE] used for symbol spaces or for IRI constants in RIF's presentation syntax:

In RIF documents in presentation syntax, these prefixes can be defined using respective prefix directives in the preamble of the RIF document at hand [BLD].


2 Constants, Symbol Spaces, and Data Types

2.1 Constants and Symbol Spaces

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

"literal"^^< identifiersymbolSpaceIri>

where literal is called the lexical part of the symbol, and identifiersymbolSpaceIri is an (absolute or relative) IRI identifying the symbol space.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. We often also use abbreviated syntax for denoting IRIs such as symbol space identifiers, i.e., for example the constant "http://www.example.org"^^<http://www.w3.org/2007/rif#iri> can be abbreviated as "http://www.example.org"^^rif:iri in RIF's presentation syntax. More details about this and other shortcut notations are given below.

2.1.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 and a unique IRI identifying it. More precisely,

The identifiers of symbol spaces are not themselves constant symbols in RIF. However, to simplify the language, we will often use symbol space identifiers to refer to the actual symbol spaces (for instance, we may use "symbol space xsd:stringxs:string" instead of "symbol space identified by xsd:stringxs:string").


RIF requires that all dialects include the following symbol spaces. Rule sets that are exchanged through RIF can use additional symbol spaces.

Namely, we allowNote that, by the associated lexical space, not all unicode strings whichare alsosyntactically valid XML NCName s as definedlexical 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.


2.1.2 Shortcuts for Constants in [ XML-NS ].RIF's Presentation Syntax

Syntactically, RIF's presentation syntax introduces, besides the basic notion several shortcuts for particular symbol spaces

"literal"^^<identifier>

in order to make the presentation syntax more readable. That is, RIF's presentation syntax for constants is defined by the following EBNF. 
  ANGLEBRACKIRI ::=  '<'IRI_REF
   '>'STRING        ::= '"' UNICODESTRING '"'
  CURIE         ::=  PNAME_LN | PNAME_NS
  Const         ::= STRING '^^'ANGLEBRACKIRI
                 | STRING '^^' CURIE
                 | ANGLEBRACKIRI       → shortcut for rif:iri
                 | CURIE               → shortcut for rif:iri
                 | STRING              → shortcut for  xsd:stringxs:string
                 | NumericLiteral      → shortcut for  xsd:integer,xsd:decimal,xsd:doublexs:integer,xs:decimal,xs:double
                 | '_' LocalName       → shortcut for rif:local

ThisThe EBNF grammar relies on reuse of nonterminals defined in the following grammar productions defined infrom other documents:

In this grammar, CURIE stands for compact IRIs [CURIE]. First, compact IRIs can be used for instance, "1.2"^^xsd:decimal and "1"^^xsd:decimal are legal symbols because 1.2 and 1 are members of the lexicalabbreviating symbol space of the XML Schema data type xsd:decimal . On the other hand, "a+2"^^xsd:decimal is not a legal symbol, since a+2IRIs, for instance it is not part of the lexical spaceallowed to write "http://www.example.org"^^rif:iri instead of xsd:decimal . 2.2 Data Types Data types in RIF are symbol spaces which have special semantics."http://www.example.org"^^<http://www.w3.org/2007/rif#iri>, assuming that is, each datatyperif is characterized by a fixed lexical space, value space and lexical-to-value-mapping. Definition (Primitive data type). A primitive data type (or justa data type ,prefix defined for short) isthe IRI http://www.w3.org/2007/rif#iri in a respective prefix directive

Prefix( rif http://www.w3.org/2007/rif# )

in the preamble of the RIF document at hand [BLD].

Furthermore, there exist convenient shortcut notations for constants in specific symbol space that has an associated set, calledspaces, namely for constants in the value spacesymbol spaces rif:iri, xs:string, xs:integer, xs:decimal, xs:double, and a mapping fromrif:local:

Editor's Note: We might introduce additional shortcuts, e.g. for rif:text defined herein future versions of this draft.

2.1.3 Relative IRIs

Relative IRIs in RIF documents are compatibleresolved with RDF's semantics for stringsrespect to the base IRI. Relative IRIs are combined with named tags [ RDF-SEMANTICS ]. 3base 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 Semantics of Built-ins 3.1 Syntax of Built-ins A RIF built-in function or predicate is a special case6.2.3 of externally defined terms, whichRFC3986) are definedperformed. Characters additionally allowed in RIF Framework for Logic Dialects and also reproducedIRI references are treated in the direct definitionsame way that unreserved characters are treated in URI references, per section 6.5 of Internationalized Resource Identifiers (IRIs) [RFC-3987].

A single base directive in the preamble of a RIF Basic Logic Dialect (RIF-BLD).document in RIF'spresentation syntax built-in predicates and functions are syntactically represented as external terms[BLD] or an xml:base directive in a RIF/XML document define the Base IRI used to resolve relative IRIs per RFC3986 section 5.1.1, "Base URI Embedded in Content". Section 5.1.2 of RFC3986, "Base URI from the form: 'External' '(' Expr ')' where Expr isEncapsulating Entity" defines how the Base IRI may come from an encapsulating document, such as a positional termSOAP envelope with an xml:base directive, containing a RIF ruleset as defined inpayload. The "Retrieval URI" identified in 5.1.3, Base "URI from the Retrieval URI", is the URL from which a particular RIF Framework for Logic Dialects (see alsodocument was retrieved. If none of the above specifies the Base URI, or several ambiguous base directives are present in the preamble of a RIF Basic Logic Dialect ). For RIF's normativedocument in presentation syntax, see XML Serialization Syntax for RIF-BLD . RIF-FLD introducesthe notiondefault Base URI (section 5.1.4 of an external schema to describeRFC3986, "Default Base URI") is used.

For instance, the constant <./xyz> or "./xyz"^^rif:iri are both valid abbreviations for the well-formed externally defined terms and their semantics.constant "http://www.example.org/xyz"^^rif:iri in the special case ofa RIF built-in, external schemas have especially simple form. A built-in named fdocument in presentation syntax that takes n argumentshas the schema ( ?X 1 ... ?X n ;   f(?X 1 ... ?X nsingle base directive

Base( http://www.example.org )

) Here f(?X 1 ... ?X n ) is the actual termin its preamble.

2.2 Primitive Data Types

Data types in RIF are symbol spaces which have special semantics. That is, each data type is used to refer to the built-in (in expressions of the form External(f(?X 1 ... ?X n )) )characterized by a fixed lexical space, value space and ?X 1 ... ?X nlexical-to-value-mapping.

Definition (Primitive data type). A primitive data type (or just a data type, for short) is the list of all variables ina symbol space that term. For convenience,has

Semantic structures are always defined with respect to formulas.a particular set of data types, denoted by DTS. In a concrete dialect, DTS always includes the special case ofdata types supported by that dialect. All RIF built-ins, itdialects must support the following primitive data types:

Editor's Note: rif:text (in particular, its identifying IRI) is used to assign truth values to RIF built-in predicates.an AT RISK feature. We expect a joint effort with the built-in predicates can haveOWL WG to discuss rif:text and the truth values t or f only.equivalent OWL data type, striving for a built-in predicateuniform symbol space for such text strings with schema σ , RIF-FLDa language tag.

Their value spaces and RIF-BLD require thatthe truth-valued mapping I truth ο I external ( σ ) must agree withlexical-to-value-space mappings are defined as follows:

The external schemavalue space and the lexical-to-value-space mapping for rif:text defined here are compatible with RDF's semantics for strings with named tags [RDF-SEMANTICS].

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 in RIF Framework for Logic Dialects (see also in RIF Basic Logic Dialect). For RIF's normative syntax, see XML Serialization Syntax for RIF-BLD.

RIF-FLD introduces the notion of an external schema to describe both the well-formed externally defined terms and their semantics. In the special case of a RIF built-in, external schemas have 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 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.

For convenience, a complete definition of external schemas is reproduced in Appendix: Schemas for Externally Defined Terms.


3.2 Semantics of Built-ins

The semantics of external terms in RIF-FLD and RIF-BLD is defined using two mappings: Iexternal and Itruth ο Iexternal.

4 List of Supported Built-in Predicates and Functions

This section defines the syntax and semantics of all 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 intended domains for the arguments of the built-in.

    Typically, built-in functions and predicates are defined over the value spaces of appropriate data types. These are the intended domains of the arguments. When an argument falls outside of its intended 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 for different semantic structures, the value of Iexternal(σ)(a1 ... an) can be anything if one of the arguments is not in its intended domain. Similarly, Itruth ο Iexternal(σ)(a1 ... an) can be t in some interpretations and f in others.

    This indeterminacy in case of an error implies that applications must 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 data type 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 Guard Predicates for Data Types

RIF defines guard predicates for all data types in Section Primitive Data Types.

Accordingly, the following schemas are defined.

4.1.1 pred:isInteger

4.1.2 pred:isDecimal

4.1.3 pred:isDouble

4.1.4 pred:isString

4.1.5 pred:isTime

4.1.6 pred:isDateTime

4.1.7 pred:isDayTimeDuration

4.1.8 pred:isYearMonthDuration

4.1.9 pred:isXMLLiteral

4.1.10 pred:isText

4.2 Negative Guard Predicates for Data Types

Likewise, RIF defines negative guard predicates for all data types in Section Primitive Data Types.

Accordingly, the following schemas are defined.

4.2.1 pred:isNotInteger

4.2.2 pred:isNotDecimal

4.2.3 pred:isNotDouble

4.2.4 pred:isNotString

4.2.5 pred:isNotTime

4.2.6 pred:isNotDateTime

4.2.7 pred:isNotDayTimeDuration

4.2.8 pred:isNotYearMonthDuration

4.2.9 pred:isNotXMLLiteral

4.2.10 pred:isNotText

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

4.3 Cast Functions and Conversion Predicates for Data Types and rif:iri

RIF defines cast functions for all data types mentioned in this document, i.e. for each data type with IRI DATATYPEIRI there is an external function with the following schema:

We now discuss the built-in.intended domains and mappings for a built-in predicate, its truth value when the arguments are substituted with valuesthese cast functions.

Editor's Note: In the domain. As explained in Section Semantics of Built-ins , this correspondsfollowing, we adapt several cast functions from [XPath-Functions]. Due to the mapping I truth ο I external ( σ )subtle differences in the formal semantics of RIF-FLDe.g. error handling between RIF and RIF-BLD[XPath-Functions], these definitions might still need refinement in future versions of this draft.


4.3.1 xs:long, where σ is the external schemaxs:integer, xs:decimal, xs:time, xs:dateTime, xs:dayTimeDuration, xs:yearMonthDuration

Editor's Note: We might split this subsection into separate subsections per casting function in that specificationfuture versions of this document, following the convention of having one separate subsection per funtcion/predicate in order to avoid copying them. 4.1 Guard Predicates for Datatypes RIF requires guard predicates for all its supported datatypes. Schema :the schemas for these predicates haverest of the general formdocument. However, it seemed convenient here to group the cast functions which purely rely on XML Schema datatype casting into one common subsection.

4.3.2 xs:string

Editor's Note: The cast from rif:text to xs:string is still under discussion, i.e. whether the lang tag should be included when casting to xs:string or not.

4.3.3 rdf:XMLLiteral

4.3.4 rif:text

4.3.5 rif:iri

Editor's Note: Casting to rif:iri is still under discussion in the working group since rif:iri is not require guardsa data type. For all datatypes. 4.3details, we refer to Issue-61. The following is a strawman proposal which might still change in future versions of this working draft.

Additionally to the built-in cast functions for Datatypes anddata types we allow conversions to constants in the rif:iri RIF requiressymbol space from xs:strings following similar considerations as conversions from xs:string to xs:anyURI in [XPath-Functions]. Technically speaking, we cannot proceed as with the other cast functions for all its supported datatypes, i.e.functions, defining the semantics via a fixed mapping Iexternal for each datatype DATATYPE there isan external function as follows:schema :( ?arg1; DATATYPErif:iri ( ?arg1 ) ) Intended domain : The, since rif:iri is not a data type with a fixed value spaces of datatypes castable to DATATYPE accordingspace and fixed lexical-to value mapping. Instead, casts to rif:iri are defined via an infinite set of axiomatic equalities in every RIF interpretation as follows.

The tablefollowing equalities hold in Section 17.1 of [ XPath-Functions ]. Mapping: I externalevery RIF interpretation for each unicode string a:

Thus, although there is no explicit schema ( ?arg1; DATATYPErif:iri ( ?arg1 ) )(s 1) =in RIF, casts between xs:strings 1 ' such thatand rif:iris 1 ' isare still possible in RIF with the intended semantics that the IRI represented by a particular string can be cast to this very string and vice versa.

4.3.6 pred:iri-to-string

Editor's Note: Conversion of s 1from rif:iri to xs:string is still under discussion in the value space of xsd: DATATYPE accordingworking group since rif:iri is not a data type. For details, we refer to Issue-61. The tablefollowing is a strawman proposal which might still change in Section 17.1future versions of [ XPath-Functions ]. Note that thesethis working draft.

Conversions from rif:iri to xs:string are only partial. If an argument value is outside of the intended domain or outside the partial conversions defined in [ XPath-Functions ], the value ofnot covered by the xs:string casting function is left unspecified and can vary from one semantic structure to another.above. Note here, that neither the remaining data types, i.e. the subtypes of xsd:integer and rif:XMLLiteral , norwe cannot apply axiomatic equalities as for the symbol spacerif:iri do appearcasting function; if we assume equalitiies

xs:string("http://example.org/iriA"^^rif:iri) = "http://example.org/iriA"^^xs:string
xs:string("http://example.org/iriB"^^rif:iri) = "http://example.org/iriB"^^xs:string

this would immediately result in

"http://example.org/iriA"^^xs:string = "http://example.org/iriB"^^xs:string

which is inconsistent in RIF due to the conversion tabledefinition of [ XPath-Functions ], but the following considerations apply:the lexical-to-value mapping for xs:string which maps two distinct strings to two distinct domain elements in every interpretation.

To this end, since conversions from andIRIs (resources) to subtypes of xsd:integer follow the same considerations as xsd:integer in that table, bystrings are a needed feature for instance for conversions between RDF formats (see example below), we add a built-in predicate which supports such conversions.

4.4 Numeric Functions and Predicates

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

4.4.1 Numeric Functions

1.4.4.1.1 func:numeric-add (adapted from op:numeric-add)

The following numeric built-in functions are defined accordingly with respect to their corresponding operators in [XPath-Functions] and we will only add further explanations where needed.

2.4.4.1.2 func:numeric-subtract (adapted from op:numeric-subtract)

3.4.4.1.3 func:numeric-multiply (adapted from op:numeric-multiply)

4.4.4.1.4 func:numeric-divide (adapted from op:numeric-divide)

5.4.4.1.5 func:numeric-integer-divide (adapted from op:numeric-integer-divide)

6.4.4.1.6 func:numeric-mod (adapted from op:numeric-mod)

4.4.2 Numeric Predicates

1.4.4.2.1 pred:numeric-equal (adapted from op:numeric-equal)

The following numeric built-in predicates are defined acordingly with respect to their corresponding operators in [XPath-Functions].

2.4.4.2.2 pred:numeric-less-than (adapted from op:numeric-less-than)

3.4.4.2.3 pred:numeric-greater-than (adapted from op:numeric-greater-than)

4.4.4.2.4 pred:numeric-less-than-or-equal

5.4.4.2.5 pred:numeric-greater-than-or-equal

4.5 Functions and Predicates on Strings

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

Editor's Note: The following treatment of built-ins which may have multiple arities is a strawman proposal currently under discussion in the working group.

In the following, we encounter several versions of some built-ins with varying arity, since XPath and XQuery allow overloading, i.e. the same function or operator name occurring with different arities. We treat this likewise in RIF, by numbering the different versions of the respective built-ins and treating the unnumbered version as syntactic sugar, i.e. for instance instead of External( func:concat2( str1, str2) ) and External( func:concat3( str1 str2 str3 ) ) we equally allow simply to write External( func:concat( str1, str2) ) and External( func:concat( str1 str2 str3 ) ). Note that this is really purely syntactic sugar, and does not mean that for external predicates and functions we lift the restriction made in BLD that each function and predicate has a unique assigned arity. Those schemata for which we allow this syntactic sugar, appear in the same box.

4.5.1 Functions on Strings

1.4.5.1.1 func:compare (adapted from fn:compare)

Editor's Note: The working group is currently discussing, whether in addition to adopting the fn:compare function from [XPath-Functions], own predicates pred:string-equal, pred:string-less-than, pred:string-greater-than, pred:string-less-than-or-equal, pred:string-greater-than-or-equal not defined in [XPath-Functions] shall be introduced, following the convention of having such predicates for other data types.

The following schemata are defined analogously with respect to their corresponding operators as defined in [XPath-Functions] and we only give informal descriptions of the respective mappings Iexternal.

2.4.5.1.2 func:concat (adapted from fn:concat)

3.4.5.1.3 func:string-join (adapted from fn:string-join)

4.4.5.1.4 func:substring (adapted from fn:substring)

5.4.5.1.5 func:string-length (adapted from fn:string-length)

6.4.5.1.6 func:upper-case (adapted from fn:upper-case)

7.4.5.1.7 func:lower-case (adapted from fn:lower-case)

8.4.5.1.8 func:encode-for-uri (adapted from fn:encode-for-uri)

9.4.5.1.9 func:iri-to-uri (adapted from fn:iri-to-uri)

10.4.5.1.10 func:escape-html-uri (adapted from fn:escape-html-uri)

11.4.5.1.11 func:substring-before (adapted from fn:substring-before)

12.4.5.1.12 func:substring-after (adapted from fn:substring-after)

13.4.5.1.13 func:replace (adapted from fn:replace)

4.5.2 Predicates on Strings

1.4.5.2.1 pred:contains (adapted from fn:contains)


2.4.5.2.2 pred:starts-with (adapted from fn:starts-with)


3.4.5.2.3 pred:ends-with (adapted from fn:ends-with)

4.4.5.2.4 pred:matches (adapted from fn:matches)

4.6 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 and time datatypesdata types in [XPath-Functions].

As defined in Section 3.3.2 Dates and Times, xsd:dateTime, xsd:date, xsd:time, xsd:gYearMonth, xsd:gYear, xsd:gMonthDay, xsd:gMonth, xsd:gDayxs: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 xsd:integers.xs:integers. The value of the second component is an xsd:decimalxs:decimal and the value of the timezone component is an xsd:dayTimeDuration.xs:dayTimeDuration. For all the date/time datatypes,data types, the timezone property is optional and may or may not be present. Depending on the datatype,data type, 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 xsd:dateTimexs:dateTime values, this local value must be translated or normalized to UTC.

4.6.1 Functions on Dates, Times, and Durations

1.4.6.1.1 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." We have no terminology of "sequence". The following schemata are defined analogously with respect to their corresponding operators as defined in [XPath-Functions] and we only give informal descriptions of the respective mappings Iexternal.

2.4.6.1.2 func:month-from-dateTime (adapted from fn:month-from-dateTime)

3.4.6.1.3 func:day-from-dateTime (adapted from fn:day-from-dateTime)

4.4.6.1.4 func:hours-from-dateTime (adapted from fn:hours-from-dateTime)

5.4.6.1.5 func:minutes-from-dateTime (adapted from fn:minutes-from-dateTime)

6.4.6.1.6 func:seconds-from-dateTime (adapted from fn:seconds-from-dateTime)

7.4.6.1.7 func:year-from-date (adapted from fn:year-from-date)

8.4.6.1.8 func:month-from-date (adapted from fn:month-from-date)

9.4.6.1.9 func:day-from-date (adapted from fn:day-from-date)

10.4.6.1.10 func:hours-from-time (adapted from fn:hours-from-time)

11.4.6.1.11 func:minutes-from-time (adapted from fn:minutes-from-time)

12.4.6.1.12 func:seconds-from-time (adapted from fn:seconds-from-time)

13.4.6.1.13 func:years-from-duration (adapted from fn:years-from-duration)

14.4.6.1.14 func:months-from-duration (adapted from fn:months-from-duration)

15.4.6.1.15 func:days-from-duration (adapted from fn:days-from-duration)

16.4.6.1.16 func:hours-from-duration (adapted from fn:hours-from-duration)

17.4.6.1.17 func:minutes-from-duration (adapted from fn:minutes-from-duration)

18.4.6.1.18 func:seconds-from-duration (adapted from fn:seconds-from-duration)

19.4.6.1.19 func:timezone-from-dateTime (adapted from fn:timezone-from-dateTime)

The following two functions are defined analogously for intended domains xsd:datexs:date and xsd:time 20.xs:time

4.6.1.20 func:timezone-from-date (adapted from fn:timezone-from-date)

4.6.1.21 func:timezone-from-time (adapted from fn:timezone-from-time)

4.6.1.22 func:subtract-dateTimes (adapted from op:subtract-dateTimes)

Subtracts two xs:dateTimes. Returns an xs:xs:dayTimeDuration.

4.6.1.23 func:subtract-dates (adapted from op:subtract-dates)

Subtracts two xs:dates. Returns an xs:xs:dayTimeDuration.

4.6.1.24 func:subtract-times (adapted from op:subtract-times)

Subtracts two xs:times. Returns an xs:xs:dayTimeDuration.

4.6.1.25 func:add-yearMonthDurations (adapted from op:add-yearMonthDurations)

Adds two xs:yearMonthDurations. Returns an xs:yearMonthDuration.

4.6.1.26 func:subtract-yearMonthDurations (adapted from op:subtract-yearMonthDurations)

Subtracts one xs:yearMonthDuration from another. Returns an xs:yearMonthDuration.

4.6.1.27 func:multiply-yearMonthDuration (adapted from op:multiply-yearMonthDuration)

Multiplies an xs:yearMonthDuration by an xs:double. Returns an xs:yearMonthDuration.

4.6.1.28 func:divide-yearMonthDuration (adapted from op:divide-yearMonthDuration)

21. fn:timezone-from-dateDivides an xs:yearMonthDuration by an xs:double. Returns an xs:yearMonthDuration.

4.6.1.29 func:divide-by-yearMonthDuration (adapted from op:divide-yearMonthDuration-by-yearMonthDuration)

22. op:add-yearMonthDurationsDivides an xs:yearMonthDuration by an xs:yearMonthDuration. Returns an xs:decimal.

4.6.1.30 func:add-dayTimeDurations (adapted from op:add-dayTimeDurations)

Adds two xsd:yearMonthDurationxs:dayTimeDurations. Returns an xsd:yearMonthDurationxs:dayTimeDuration.

22. op:subtract-yearMonthDurations4.6.1.31 func:subtract-dayTimeDurations (adapted from op:subtract-dayTimeDurations)

Subtracts one xsd:yearMonthDurationxs:dayTimeDuration from another. Returns an xs:yearMonthDurationxs:dayTimeDuration.

23. op:multiply-yearMonthDuration4.6.1.32 func:multiply-dayTimeDuration (adapted from op:multiply-dayTimeDuration)

Multiplies an xsd:yearMonthDurationxs:dayTimeDuration by a xs:double. Returns an xs:dayTimeDuration.

4.6.1.33 func:divide-dayTimeDuration (adapted from op:divide-dayTimeDuration)

Divides an xs:dayTimeDuration by an xsd:doublexs:double. Returns an xsd:yearMonthDurationxs:dayTimeDuration.

24. op:divide-yearMonthDuration4.6.1.34 func:divide-dayTimeDuration-by-dayTimeDuration (adapted from op:divide-dayTimeDuration-by-dayTimeDuration)

Divides an xsd:yearMonthDurationxs:dayTimeDuration by an xsd:doublexs:dayTimeDuration. Returns an xsd:yearMonthDurationxs:decimal.

25. op:divide-yearMonthDuration-by-yearMonthDuration4.6.1.35 func:op:add-yearMonthDuration-to-dateTime (adapted from op:add-yearMonthDuration-to-dateTime)

Adds a xs:yearMonthDuration (?arg2) to a xs:dateTime (?arg1). Returns an xs:dateTime.

4.6.1.36 func:op:add-yearMonthDuration-to-date (adapted from op:add-yearMonthDuration-to-date)

Adds a xs:yearMonthDuration (?arg2) to a xs:date (?arg1). Returns an xs:date.

4.6.1.37 func:op:add-dayTimeDuration-to-dateTime (adapted from op:add-dayTimeDuration-to-dateTime)

Adds a xs:dayTimeDuration (?arg2) to a xs:dateTime (?arg1). Returns an xs:dateTime.

4.6.1.38 func:op:add-dayTimeDuration-to-date (adapted from op:add-dayTimeDuration-to-date)

Adds a xs:dayTimeDuration (?arg2) to a xs:date (?arg1). Returns an xs:date.

4.6.1.39 func:op:add-dayTimeDuration-to-time (adapted from op:add-dayTimeDuration-to-time)

Adds a xs:dayTimeDuration (?arg2) Divides an xsd:yearMonthDuration by an xsd:yearMonthDuration .to a xs:time (?arg1). Returns an xsd:decimalxs:time.

26. op:add-dayTimeDurations4.6.1.40 func:op:subtract-yearMonthDuration-from-dateTime (adapted from op:subtract-yearMonthDuration-from-dateTime)

Adds two xsd:dayTimeDuration s.Subtracts a xs:yearMonthDuration (?arg2) from a xs:dateTime (?arg1). Returns an xsd:dayTimeDurationxs:dateTime.

27. op:subtract-dayTimeDurations4.6.1.41 func:op:subtract-yearMonthDuration-from-date (adapted from op:subtract-yearMonthDuration-from-date)

Subtracts one xsd:dayTimeDurationa xs:yearMonthDuration (?arg2) from another.a xs:date (?arg1). Returns an xsd:dayTimeDurationxs:date.

28. op:multiply-dayTimeDuration4.6.1.42 func:op:subtract-dayTimeDuration-from-dateTime (adapted from op:subtract-dayTimeDuration-from-dateTime)

Multiplies an xsd:dayTimeDuration bySubtracts a xsd:double .xs:dayTimeDuration (?arg2) from a xs:dateTime (?arg1). Returns an xsd:dayTimeDurationxs:dateTime.

29. op:divide-dayTimeDuration4.6.1.43 func:op:subtract-dayTimeDuration-from-date (adapted from op:subtract-dayTimeDuration-from-date)

Divides an xsd:dayTimeDuration by an xsd:double .Subtracts a xs:dayTimeDuration (?arg2) from a xs:date (?arg1). Returns an xsd:dayTimeDurationxs:date.

30. op:divide-dayTimeDuration-by-dayTimeDuration4.6.1.44 func:op:subtract-dayTimeDuration-from-time (adapted from op:subtract-dayTimeDuration-from-time)

Divides an xsd:dayTimeDuration by an xsd:dayTimeDuration .Subtracts a xs:dayTimeDuration (?arg2) from a xs:time (?arg1). Returns an xsd:decimalxs:time.

4.6.2 Predicates on Dates, Times, and Durations

1.4.6.2.1 pred:dateTime-equal (adapted from op:dateTime-equal)

The following schemata for comparison operators are defined analogously with respect to their corresponding operators as defined in [XPath-Functions], where the intended domain for both arguments is implicit by the operator name and we only give additional details on intended domains and mapping as needed.

2.4.6.2.2 pred:dateTime-less-than (adapted from op:dateTime-less-than)

3.4.6.2.3 pred:dateTime-greater-thanl (adapted from op:dateTime-greater-than)

4.4.6.2.4 pred:date-equal (adapted from op:date-equal)

5.4.6.2.5 pred:date-less-than (adapted from op:date-less-than)

6.4.6.2.6 pred:date-greater-than (adapted from op:date-greater-than)

7.4.6.2.7 pred:time-equal (adapted from op:time-equal)

8.4.6.2.8 pred:time-less-than (adapted from op:time-less-than)

9.4.6.2.9 pred:time-greater-than (adapted from op:time-greater-than)

10.4.6.2.10 pred:duration-equal (adapted from op:duration-equal)

11.4.6.2.11 pred:dateTimeDuration-less-than (adapted from op:dayTimeDuration-less-than)

12.4.6.2.12 pred:dayTimeDuration-greater-than (adapted from op:dayTimeDuration-greater-than)

13.4.6.2.13 pred:yearMonthDuration-less-than (adapted from op:yearMonthDuration-less-than)

14.4.6.2.14 pred:yearMonthDuration-greater-than (adapted from op:yearMonthDuration-greater-than)

15.4.6.2.15 pred:dateTime-less-than-or-equal

16.4.6.2.16 pred:dateTime-greater-than-or-equal

17.4.6.2.17 pred:date-less-than-or-equal

18.4.6.2.18 pred:date-greater-than-or-equal

19.4.6.2.19 pred:time-less-than-or-equal

20.4.6.2.20 pred:time-greater-than-or-equal

Editor's Note: No less-than-or-equal or greater-than-or-equal predicates are defined in this draft for durations, since thethere are no separate equalsop:dayTimeDuration-equal nor op:yearMonthDuration-equalpredicates for yearMonthDuration and dayTimeDurationin [XPath-Functions ].], but only a common predicate op:duration-equal. Future versionversions of this working draft may resolve this by introducing separatenew equality predicates pred:dayTimeDuration-equal and pred:yearMonthDuration-equal with restricted intended domains.


4.7 Functions and Predicates on rif:text

The following function serves to extract the language tag from values in the rif:text value space.

4.7.1 func:lang (adapted from SPARQL's lang function)

Editor's Note: The current name of this function is still under disscussion in the working group. Alternative proposals include e.g. func:lang-from-text rather following the XPath/XQuery naming convention for extraction functions from data types than the SPARQL naming convention.

5 References

[CURIE]
CURIE Syntax 1.0: A syntax for expressing Compact URIs, Mark Birbeck, Shane McCarron. W3C Working Draft 2 April 2008. Available at http://www.w3.org/TR/curie/.

[BLD]
RIF Basic Logic Dialect, Boley H., Kifer M. (Editors), W3C Working Draft. Latest version available at http://www.w3.org/2005/rules/wiki/BLD (Reference will be adapted at publication time.).

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

[RDF-SEMANTICS]
RDF Semantics, Patrick 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-SCHEMA]
RDF Vocabulary Description Language 1.0: RDF Schema, Brian 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/.

[RFC-3066]
RFC 3066 - Tags for the Identification of Languages, H. Alvestrand, IETF, January 2001, http://www.isi.edu/in-notes/rfc3066.txt.

[RFC-3986]
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]
RFC 3987 - Internationalized Resource Identifiers (IRIs), M. Duerst and M. Suignard, IETF, January 2005, http://www.ietf.org/rfc/rfc3987.txt.

[SPARQL]
SPARQL Query Language for RDF, 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/.

[XDM]
XQuery 1.0 and XPath 2.0 Data Model (XDM), 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/.

[XML-NS]
Namespaces in XML 1.1 (Second Edition), 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-SCHEMA2]
XML Schema Part 2: Datatypes Second Edition, W3C Recommendation, World Wide Web Consortium, 2 May 2001, http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. Latest version available at http://www.w3.org/TR/xmlschema-2/.

[XPath-Functions]
XQuery 1.0 and XPath 2.0 Functions and Operators, 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

This section is an edited copy of a section from RIF Framework for Logic Dialects. It is reproduced here for convenience of the reader of the RIF-BLD document who might not be familiar with RIF-FLD.

This section defines external schemas, which 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. Because of the need to accommodate many difference possibilities, the RIF logical framework supports a very general notion of an externally defined term. Such a term is not necessarily a function or a predicate -- it can be a frame, a classification term, and so on.

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 the same schema, but (?X ?Y;  ?X[foo->?Y]) and (?Y ?X;  ?X[foo->?Y]) are viewed as different 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"^^xsd:string->?Y])(?X ?Y;  ?X["foo"^^xs:string->?Y]) or (?V;  "pred:isTime"^^rif:iri(?V)), is that ?X["foo"^^xsd:string->?Y]?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"^^xsd:string->"123"^^xsd:integer])External("http://foo.bar.com"^^rif:iri["foo"^^xs:string->"123"^^xs:integer]) and External("pred:isTime"^^rif:iri("22:33:44"^^xsd:time)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 can be no term, t, that is an instance of two distinct schemas.    ☐

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 understand 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.