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:
- RIF Use Cases and
Requirements
- RIF Basic Logic
Dialect
- RIF Framework for
Logic Dialects
- RIF RDF and OWL
Compatibility
- RIF Production
Rule Dialect
- RIF Datatypes and
Built-Ins 1.0 (this document)
Please Comment By 2008-07-28
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,
built-in functions and built-in predicates expected to be supported
by RIF dialects such as the RIF
Basic Logic Dialect. Each dialect supporting a superset or
subset of the primitive datatypes, built-in functions and built-in
predicates defined here shall specify these additions or
restrictions. Some of the datatypes are adopted from [XML-SCHEMA2]. A large part of the
definitions of the listed functions and operators are adapted from
[XPath-Functions].
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:
- the xs: prefix stands for the XML Schema namespace URI
http://www.w3.org/2001/XMLSchema#,
- the rdf: prefix stands for
http://www.w3.org/1999/02/22-rdf-syntax-ns#,
- the rif: prefix stands for
http://www.w3.org/2007/rif#,
- the func: prefix stands for
http://www.w3.org/2007/rif-builtin-function#, and
- the pred: prefix stands for
http://www.w3.org/2007/rif-builtin-predicate#
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
Datatypes
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"^^<symbolSpaceIri>
where literal is called the lexical
part of the symbol, and symbolSpaceIri is
an (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. 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 lexical space of a symbol space is a
non-empty set of Unicode character strings.
- The identifier of a symbol space is a sequence of
Unicode characters that form an absolute IRI.
- Different symbol spaces supported by a dialect cannot share the
same identifier.
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 following symbol spaces.
However, rule sets that are exchanged through RIF can use
additional symbol spaces.
- xs:string
(http://www.w3.org/2001/XMLSchema#string)
- xs:time
(http://www.w3.org/2001/XMLSchema#time)
- xs:date
(http://www.w3.org/2001/XMLSchema#date)
- xs:dateTime
(http://www.w3.org/2001/XMLSchema#dateTime)
- xs:double
(http://www.w3.org/2001/XMLSchema#double)
- xs:integer
(http://www.w3.org/2001/XMLSchema#integer)
- xs:decimal
(http://www.w3.org/2001/XMLSchema#decimal)
The lexical spaces of the above symbol spaces are defined in the
document [XML-SCHEMA2].
- xs:dayTimeDuration
(http://www.w3.org/2001/XMLSchema#dayTimeDuration)
- xs:yearMonthDuration
(http://www.w3.org/2001/XMLSchema#yearMonthDuration)
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].
- rdf:XMLLiteral
(http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral).
This symbol space represents XML content. The lexical space of
rdf:XMLLiteral is defined in the document [RDF-CONCEPTS].
- rif:text
(http://www.w3.org/2007/rif#text, for text strings with
language tags attached).
This symbol space represents text strings with a language tag
attached. The lexical space of rif:text is the set of all
Unicode strings of the form ...@LANG, i.e., strings that
end with @LANG where LANG is a language
identifier as defined in [BCP-47].
Editor's Note:
rif:text (in particular, its identifying IRI) is an AT RISK
feature. We expect a joint effort with the OWL WG to discuss
rif:text and the equivalent OWL datatype, striving for a uniform
symbol space for such text strings with a language tag.
- rif:iri
(http://www.w3.org/2007/rif#iri, for
internationalized resource identifiers or
IRIs).
Constants in this 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 anyURI. A
rif:iri constant must be interpreted as a reference to one
and the same object regardless of the context in which that
constant occurs.
- rif:local
(http://www.w3.org/2007/rif#local, for constant symbols
that are not visible outside of the RIF document in which they
occur).
Constants in this 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.
2.1.2 Shortcuts for Constants in RIF's
Presentation Syntax
Besides the basic notion
"literal"^^<identifier>
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.
ANGLEBRACKIRI ::= IRI_REF
SYMSPACE ::= ANGLEBRACKIRI | CURIE
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
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]. First, compact IRIs can
be used for abbreviating symbol space IRIs, for instance it is
allowed to write "http://www.example.org"^^rif:iri instead
of
"http://www.example.org"^^<http://www.w3.org/2007/rif#iri>,
assuming that rif is a prefix defined for the 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].
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:
-
Constants in the the symbol space rif:iri can be
abbreviated in two ways, either by simply using an absolute or
relative IRI enclosed in angle brackets, or by simply writing a
compact IRI. The symbol space identifier is dropped in both these
alternatives. That is, for instance
<http://www.example.org/xyz> is a valid abbreviation
for "http://www.example.org/xyz"^^rif:iri; likewise,
ex:xyz is a valid abbreviation for this constant, in case
a respective prefix directive
Prefix( ex http://www.example.org/ )
is present in the preamble
of the RIF document at hand.
- Constants in the symbol space xs:string can be
abbreviated by simply using quoted strings, i.e. "My
String!" is a valid abbreviation for the constant "My
String!"^^xs:string (which in turn is itself an abbreviation
for "My
String!"^^<http://www.w3.org/2001/XMLSchema#string>).
- Numeric constants can be abbreviated using the grammar rules
for NumericLiterals
from the [SPARQL] grammar:
Integers can be written directly (without quotation marks and
explicit symbol space identifier) and are interpreted as constants
in the symbol space xs:integer; decimal numbers for which
there is '.' in the number but no exponent are interpreted as
constants in the symbol space xs:decimal; and numbers with
exponents are interpreted as xs:double. For instance, one
could use 1.2 and 1 as shortcuts for
"1.2"^^xs:decimal and "1"^^xs:integer,
respectively. However, there is no shortcut for
"1"^^xs:decimal.
- The shortcut notation for rif:local applies to only a
subset of the lexical space of syntactically valid lexical parts of
constants in this symbol space: We allow "_"-prefixed unicode
strings which are also valid XML NCNames
as defined in [XML-NS]. For
other constants in the rif:local symbol space one has to
use the long notation. That is, for instance
_myLocalConstant is a valid abbreviation for the constant
"myLocalConstant"^^rif:local, whereas
"http://www.example.org"^^rif:local cannot be
abbreviated.
Editor's Note: We
might introduce additional shortcuts, e.g. for rif:text in
future versions of this draft.
2.1.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 RFC3986)
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].
A single base directive in the preamble
of a RIF document in presentation syntax [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 Encapsulating Entity" defines
how the Base IRI may come from an encapsulating document, such as a
SOAP envelope with an xml:base directive, containing a RIF
ruleset as payload. The "Retrieval URI" identified in 5.1.3, Base
"URI from the Retrieval URI", is the URL from which a particular
RIF document was retrieved. If none of the above specifies the Base
URI, or several ambiguous base directives are present in the
preamble of a RIF document in presentation syntax, the
default Base URI (section 5.1.4 of RFC3986, "Default Base URI") is
used.
For instance, the constant <./xyz> or "./xyz"^^rif:iri are
both valid abbreviations for the constant
"http://www.example.org/xyz"^^rif:iri in a RIF document in
presentation syntax that has the single base directive
Base( http://www.example.org )
in its preamble.
2.2 Primitive 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
(Primitive datatype). A primitive datatype (or
just a datatype, for short) is a symbol space that has
- an associated set, called the value space,
and
- a mapping from the lexical space of the symbol space to the
value space, called lexical-to-value-space mapping.
☐
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
primitive datatypes. However, RIF dialects may include additional
datatypes.
- xs:string
- xs:time
- xs:date
- xs:dateTime
- xs:double
- xs:integer
- xs:decimal
- xs:dayTimeDuration
- xs:yearMonthDuration
- rdf:XMLLiteral
- rif:text
Editor's Note:
rif:text (in particular, its identifying IRI) is an AT
RISK feature. We expect a joint effort with the OWL WG to
discuss rif:text and the equivalent OWL datatype, striving for a
uniform symbol space for such text strings with a language tag.
Their value spaces and the lexical-to-value-space mappings are
defined as follows:
- For the XML Schema datatypes of RIF, namely xs:double,
xs:integer, xs:decimal, xs:string,
xs:time, and xs:dateTime, the value spaces and
the lexical-to-value-space mappings are defined in the XML Schema
specification [XML-SCHEMA2].
- The value spaces and the lexical-to-value-space mappings for
the primitive datatypes xs:dayTimeDuration and
xs:yearMonthDuration are defined in the XQuery 1.0 and
XPath 2.0 Data Model [XDM].
- The value space and lexical-to-value-space mapping for the
primitive datatype rdf:XMLLiteral is defined in RDF
[RDF-CONCEPTS].
- The value space rif:text is the set of all pairs of
the form (string, lang), where string is a
Unicode character sequence and lang is a lowercase Unicode
character sequence which is a language identifier as defined by
[BCP-47]. The
lexical-to-value-space mapping of rif:text, denoted
Lrif:text, maps each symbol
string@lang in the lexical space of rif:text to
(string, lower-case(lang)), where
lower-case(lang) is lang written in all-lowercase
letters.
The value 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 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 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 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.
- Iexternal. This mapping takes an
external schema, σ, and returns a mapping,
Iexternal(σ).
If σ represents a built-in function,
Iexternal(σ) must be that
function.
For each built-in function with external schema σ, the
present document specifies the mapping
Iexternal(σ).
- Itruth. This mapping takes an element
of the domain of interpretation and returns a truth value.
In RIF logical semantics, this mapping is used to assign truth
values to formulas. In the special case of RIF built-ins, it is
used to assign truth values to RIF built-in predicates. The
built-in predicates can have the truth values t or f
only.
For a built-in predicate with schema σ, RIF-FLD and
RIF-BLD require that the truth-valued mapping
Itruth ο
Iexternal(σ) must agree with the
specification of the corresponding built-in predicate.
For each RIF built-in predicate with schema σ, the
present document specifies 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:
- The name of the built-in.
- The external schema of the built-in.
- 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.
- 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.
- The intended domains for the arguments of the
built-in.
Typically, built-in functions and predicates are defined over
the value spaces of appropriate datatypes. 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 if one or more of the arguments is
not in its intended domain, the value of
Iexternal(σ)(a1
... an) can vary from one semantic structure to
another. Similarly, Itruth ο
Iexternal(σ)(a1
... an) can be t in some interpretations and
f in others when an argument is not in the intended
domain.
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 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 Guard Predicates for
Datatypes
RIF defines guard predicates for all datatypes in Section
Primitive
Datatypes.
- Schema: The schemas for these predicates have the
general form
( ?arg1; pred:isDATATYPE
( ?arg1 ) )
Here, DATATYPE is the short name for a datatype. As a
naming convention we use the capitalized non-prefix XML
local name part of the IRI denoting the datatype, for instance
we use pred:isString for the guard predicate for
xs:string, or pred:isText for the guard predicate
for rif:text. Parties defining their own datatypes to be
used in RIF exchanged rules may define their own guard predicates
for these datatypes. Labels used for such additional guard
predicates for datatypes not mentioned in the present document MAY
follow the same naming convention where applicable without creating
ambiguities with predicate names defined in the present
document.
Editor's Note:
The naming convention for guard predicates, particularly whether
third parties defining their own datatypes should be
encouraged/discouraged to reuse the standard pred: and
func: namespaces to define their own built-in predicates
and functions, are still under discussion in the working group.
- Intended domain:
Guard predicates do not depend on a specific intended
domain.
- Mapping:
Itruth ο
Iexternal( ?arg1;
pred:isDATATYPE ( ?arg1 ) )(s1) =
t if and only if s1 is in the value space of
DATATYPE and f otherwise.
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:isDate
4.1.7 pred:isDateTime
4.1.8
pred:isDayTimeDuration
4.1.9
pred:isYearMonthDuration
4.1.10
pred:isXMLLiteral
4.1.11 pred:isText
Editor's Note: It
was noted in discussions of the working group, that except guard
predicates, also an analogous built-in function or predicate to
SPARQL's
datatype function is needed. This however has some
technical implications, see
http://lists.w3.org/Archives/Public/public-rif-wg/2008Jul/0096.html
4.2 Negative Guard Predicates for
Datatypes
Likewise, RIF defines negative guard predicates for all
datatypes in Section Primitive Datatypes.
- Schema: The schemas for negative guards have the
general form
( ?arg1; pred:isNotDATATYPE
( ?arg1 ) )
Here, DATATYPE is the short name for one of the datatypes
mentioned in this document. As a naming convention we use the
capitalized non-prefix XML
local name part of the IRI denoting the datatype, for instance
we use pred:isNotString for the negative guard predicate
for xs:string, or pred:isNotText for the negative
guard predicate for rif:text. Parties defining their own
datatypes to be used in RIF exchanged rules may define their own
negative guard predicates for these datatypes. Labels used for such
additional negative guard predicates for datatypes not mentioned in
the present document MAY follow the same naming convention where
applicable without creating ambiguities with predicate names
defined in the present document.
Editor's Note:
The naming convention for negative guard predicates, particularly
whether third parties defining their own datatypes should be
encouraged/discouraged to reuse the standard pred: and
func: namespaces to define their own built-in predicates
and functions, are still under discussion in the working group.
- Intended domain:
Negative guard predicates do not depend on a specific intended
domain.
- Mapping:
Itruth ο
Iexternal( ?arg1;
pred:isNotDATATYPE ( ?arg1 )
)(s1) = f if and only if s1 is in the
value space of DATATYPE and t otherwise.
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:isNotDate
4.2.7
pred:isNotDateTime
4.2.8
pred:isNotDayTimeDuration
4.2.9
pred:isNotYearMonthDuration
4.2.10
pred:isNotXMLLiteral
4.2.11 pred:isNotText
Future dialects may extend this list of guards to other
datatypes, but RIF does not require guards for all datatypes.
4.3 Cast Functions and Conversion
Predicates for Datatypes and rif:iri
RIF defines cast functions for all datatypes mentioned in this
document, i.e. for each datatype with IRI DATATYPEIRI there
is an external function with the following schema:
We now discuss the intended domains and mappings for these cast
functions.
Editor's Note: In
the following, we adapt several cast functions from [XPath-Functions]. Due to the
subtle differences in e.g. error handling between RIF and [XPath-Functions], these
definitions might still need refinement in future versions of this
draft.
4.3.1 xs:double,
xs:integer, xs:decimal, xs:time,
xs:date, xs:date,xs:dateTime,
xs:dayTimeDuration,
xs:yearMonthDuration
- Schemata:
( ?arg1; xs:double ( ?arg1 )
)
( ?arg1; xs:integer ( ?arg1
) ) and accordingly for all subtypes of
xs:integer
( ?arg1; xs:decimal ( ?arg1
) )
( ?arg1; xs:time ( ?arg1 )
)
( ?arg1; xs:date ( ?arg1 )
)
( ?arg1; xs:dateTime ( ?arg1
) )
( ?arg1; xs:dayTimeDuration
( ?arg1 ) )
( ?arg1; xs:yearMonthDuration
( ?arg1 ) )
- Intended domains:
The value spaces of datatypes castable to
xs:DATATYPE according to
Section 17.1 of [XPath-Functions].
- Mappings:
Iexternal( ?arg1;
xs:DATATYPE ( ?arg1 ) )(s1) =
s1' such that s1' is the conversion of
s1 to the value space of xs:DATATYPE
according to
Section 17.1 of [XPath-Functions]. Note that these conversions are only
partial and note further that the subtypes of xs:integer
do appear in the conversion table. Conversions from and to subtypes
of xs:integer follow the same considerations as
xs:integer in that table, by the XPath, XQuery type
hierarchy in
Section 1.6 of [XPath-Functions].
If the argument value is outside of the intended domain or
outside the partial conversions defined in [XPath-Functions], the value of
the function is left unspecified and can vary from one semantic
structure to another.
Editor's Note: We
might split this subsection into separate subsections per casting
function in future versions of this document, following the
convention of having one separate subsection per funtcion/predicate
in the rest of the document. 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
- Schema:
( ?arg1; xs:string ( ?arg1 )
)
- Intended domain:
The union of the value space of rif:text with the value
spaces of datatypes castable to xs:string according to the
table in
Section 17.1 of [XPath-Functions].
- Mapping:
Iexternal( ?arg1;
xs:DATATYPE ( ?arg1 ) )(s1) =
s1' such that s1' is the conversion of
s1 to the value space of xs:string
- according to the table in
Section 17.1 of [XPath-Functions], in case s1 is in the
value space of a datatype mentioned in that table.
- by preserving the lexical value of its string part, if
s1 is in the value space of
rif:text.
If the argument is outside the intended domain, the value of the
function is left unspecified and can vary from one semantic
structure to another.
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
- Schema:
( ?arg1; rdf:XMLLiteral
( ?arg1 ) )
- Intended domain:
The intersection of the value space of xs:string with
the lexical space of rdf:XMLLiteral, i.e. an
xs:string can be cast to rdf:XMLLiteral if and
only if its value is in the lexical space of
rdf:XMLLiteral as defined in Resource
Description Framework (RDF): Concepts and Abstract Syntax
- Mapping:
Iexternal( ?arg1;
xs:DATATYPE ( ?arg1 ) )(s1) =
s1' such that s1' is the XMLLiteral
corresponding to the given string s1.
If the argument value is outside of the intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
4.3.4 rif:text
- Schema:
( ?arg1; rif:text
( ?arg1 ?arg2 ) )
- Intended domains:
The value space of xs:string for
?arg1 and the intersection of the value space
of xs:string with all Unicode character sequences which
are language identifiers as defined by [BCP-47] for ?arg2.
- Mapping:
Iexternal( ?arg1;
rif:text ( ?arg1 ?arg2 )
)(s1 s2) = s' where s1 is a
Unicode string and s2 is a Unicode character sequence
which is language as defined by [BCP-47]. Then s' is defined exactly as the pair
(s1, lowercase(s2)).
If the argument values are outside of the intended domains, the
value of the function is left unspecified and can vary from one
semantic structure to another.
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 a datatype. For
details, 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 we
allow conversions to constants in the rif:iri symbol 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, defining the semantics via a fixed mapping
Iexternal for an external schema
( ?arg1; rif:iri ( ?arg1 )
), since rif:iri is not a datatype with a fixed value
space 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 following equalities hold in every RIF interpretation for
each unicode string a which is in the lexical space of the
rif:iri symbol space:
- rif:iri("a"^^xs:string) =
"a"^^rif:iri
Thus, although there is no explicit schema
( ?arg1; rif:iri ( ?arg1 )
) in RIF, casts between xs:strings and
rif:iris are 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 from rif:iri to xs:string is still
under discussion in the working group since rif:iri is not
a datatype. For details, we refer to
Issue-61. The following is a strawman proposal which might
still change in future versions of this working draft.
Conversions from rif:iri to xs:string are not
covered by the xs:string
casting function above. Note here, that we cannot apply axiomatic
equalities as for the rif:iri casting function; if we assume
equalities
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
and a ruleset asserted an additional equality
"http://example.org/iriA"^^rif:iri =
"http://example.org/iriB"^^rif:iri
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 definition of 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 IRIs (resources) to strings
are a needed feature for instance for conversions between RDF
formats (see example below), we add a built-in predicate which
supports such conversions.
- Schema:
( ?arg1; pred:iri-to-string
( ?arg1, ?arg2 ) )
- Intended domains:
The first argument is not restricted by a specific domain, the
second argument is the value space of xs:string.
- Mapping:
Iexternal( ?arg1 ?arg2;
pred:iri-to-string ( ?arg1 ?arg2 )
)(iri1 str1) = t if and only if
str1 is an element in the lexical space of
rif:iri and iri1 is an element of the domain
such that I(
"str1"^^rif:iri ) = iri1
holds in the current interpretation.
Note that this definition rather restricts the allowed
interpretations of pred:iri-to-string with respect to the
current interpretation of the symbols in the rif:iri
symbol space for the first argument and elements of the
xs:string value space for the second argument. The truth
value of the predcate is left unspecified for other elements of the
domain and can vary from one semantic structure to another.
This predicate could be usable for instance to map telephone
numbers between an RDF Format for vCard (http://www.w3.org/TR/vcard-rdf)
and FOAF (http://xmlns.com/foaf/0.1/). vCard
stores telephone numbers as string literals, whereas FOAF uses
resources, i.e., URIs with the tel: URI-scheme. So, a mapping from
FOAF to vCard would need to convert the tel: URI to a
string and then cut off the first four characters ("tel:"). Such a
mapping expressed in RIF could involve e.g. a rule as follows:
...
Prefix( VCard http://www.w3.org/TR/vcard-rdf#)
Prefix( foaf http://xmlns.com/foaf/0.1/)
...
Forall ?X ?foafTelIri ?foafTelString (
?X[ VCard:tel -> External( func:substring( ?foafTelString 4 ) ] :-
And ( ?X[ foaf:phone -> ?foafTelIri ]
External( pred:iri-to-string( ?foafTelIri ?foafTelString ) ) )
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
4.4.1.1 func:numeric-add
(adapted from op:numeric-add)
- Schema:
(?arg1 ?arg2;
func:numeric-add(?arg1 ?arg2))
- Intended domains:
The value spaces of xs:integer, xs:double, or
xs:decimal for both arguments.
- Mapping:
When both s1 and s2
belong to their intended domains,
External(func:numeric-add(s1 s2))
evaluates to the result of op:numeric-add(s1,
s2) as defined in [XPath-Functions].
If an argument value is outside of the intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
The following numeric built-in functions
func:numeric-subtract, func:numeric-multiply,
func:numeric-divide, func:numeric-integer-divide,
and func:numeric-mod are defined accordingly with respect
to their corresponding operators in [XPath-Functions] and we will only add further
explanations where needed.
4.4.1.2 func:numeric-subtract
(adapted from op:numeric-subtract)
4.4.1.3 func:numeric-multiply
(adapted from op:numeric-multiply)
4.4.1.4 func:numeric-divide
(adapted from op:numeric-divide)
- Schema:
(?arg1 ?arg2;
func:numeric-divide( ?arg1 ?arg2)
)
- Intended domains:
The value spaces of xs:integer, xs:double, or
xs:decimal for the first argument and xs:integer,
xs:double, or xs:decimal without zero for the
second argument.
- Mapping:
This function backs up the "div" operator and returns the
arithmetic quotient of its operands
If an argument value is outside of the intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another, which here particularly means that
RIF does not prescribe the behavior on division by zero.
4.4.1.5
func:numeric-integer-divide (adapted from
op:numeric-integer-divide)
- Schema:
(?arg1 ?arg2;
func:numeric-integer-divide( ?arg1 ?arg2)
)
- Intended domains:
The value spaces of xs:integer, xs:double, or
xs:decimal for the first argument and xs:integer,
xs:double, or xs:decimal without zero for the
second argument.
- Mapping:
This function backs up the "idiv" operator and performs an
integer division: that is, it divides the first argument by the
second, and returns the integer obtained by truncating the
fractional part of the result.
If an argument value is outside of the intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another, which here particularly means that
RIF does not prescribe the behavior on division by zero.
4.4.1.6 func:numeric-mod
(adapted from op:numeric-mod)
- Schema:
(?arg1 ?arg2;
func:numeric-mod( ?arg1 ?arg2)
)
- Intended domains:
The value spaces of xs:integer, xs:double, or
xs:decimal for the first argument and xs:integer,
xs:double, or xs:decimal without zero for the
second argument.
- Mapping:
Backs up the "mod" operator.
If an argument value is outside of the intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another, which here particularly means that
RIF does not prescribe the behavior if the second argument is
zero.
4.4.2 Numeric Predicates
4.4.2.1 pred:numeric-equal
(adapted from op:numeric-equal)
- Schema:
(?arg1 ?arg2;
pred:numeric-equal(?arg1 ?arg2))
- Intended domains:
The value spaces of xs:integer, xs:double, or
xs:decimal for both arguments.
- Mapping:
When both s1 and s2
belong to their intended domains,
External(pred:numeric-equal(s1 s2))
is t if and only if op:numeric-equal(s1,
s2) returns true, as defined in [XPath-Functions].
If an argument value is outside of the intended domain, the
truth value of the function is left unspecified and can vary from
one semantic structure to another.
The following numeric built-in predicates
pred:numeric-less-than and
pred:numeric-greater-than are defined acordingly with
respect to their corresponding operators in [XPath-Functions]. The predicate
pred:numeric-not-equal has the same intended domain as
pred:numeric-equal and is true whenever
pred:numeric-equal is false. The predicates
pred:numeric-less-than-or-equal (and
pred:numeric-greater-than-or-equal, respectively) are true
whenever pred:numeric-equal is true or
pred:numeric-less-than
(pred:numeric-greater-than-or-equal, respectively) is
true.
4.4.2.2 pred:numeric-less-than
(adapted from op:numeric-less-than)
4.4.2.3
pred:numeric-greater-than (adapted from op:numeric-greater-than)
4.4.2.4
pred:numeric-not-equal
4.4.2.5
pred:numeric-less-than-or-equal
4.4.2.6
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 allow the equivalent
forms 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
4.5.1.1 func:compare (adapted
from fn:compare)
- Schema:
( ?comparand1 ?comparand2;
func:compare1(?comparand1 ?comparand2)
)
( ?comparand1 $comparand2
$collation;
func:compare2(?comparand1 ?comparand2 ?collation)
)
- Intended domains:
The value space of xs:string for all arguments.
- Mapping:
Iexternal(
( ?comparand1 ?comparand2;
func:compare1(?comparand1 ?comparand2)
)(s1 s2) = res such that res =
-1, 0, or 0 (from the value space of
xs:integer), depending on whether the value of the
s1 is respectively less than, equal to, or greater than
the value of s2, according to the rules of the collation
that is used.
If an argument value is outside of the intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
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-not-equal,
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 datatypes.
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.
4.5.1.2 func:concat (adapted
from fn:concat)
- Schema:
( ?arg1; func:concat1( ?arg1
) )
( ?arg1 ?arg2;
func:concat2(?arg1 ?arg2 ) )
...
( ?arg1 ?arg2
... ?argn;
func:concatn(?arg1 ?arg2
... ?argn ) )
- Intended domains:
Following the definition of fn:concat
this function accepts xs:anyAtomicType arguments and casts them to
xs:string. Thus, the intended domain for all arguments is
the union of all value spaces castable to String xs:string
as defined in Section Cast Functions
and Conversion Predicates for Datatypes and rif:iri above.
- Mapping:
Returns the xs:string that is the concatenation of the
values of its arguments after conversion.
If an argument value is outside of the intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
4.5.1.3 func:string-join
(adapted from fn:string-join)
- Schema:
( ?arg1 ?arg2;
func:string-join2(?arg1 ?arg2 )
)
( ?arg1 ?arg2 ?arg3;
func:string-join3(?arg1 ?arg2 ?arg3
) )
...
( ?arg1 ?arg2
... ?argn;
func:string-joinn(?arg1 ?arg2
... ?argn ) )
- Intended domains:
The value space of xs:string for all arguments.
- Mapping:
Returns a xs:string created by concatenating the arguments 1 to
(n-1) using the nth argument as a
separator.
If an argument value is outside of the intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
4.5.1.4 func:substring (adapted
from fn:substring)
- Schema:
( ?sourceString ?startingLoc;
func:substring1( ?sourceString ?startingLoc) )
( ?sourceString ?startingLoc ?length ;
func:substring2( ?sourceString ?startingLoc ?length)
)
- Intended domains:
The value space of xs:string for ?sourceString
and the union of the value spaces of xs:integer,
xs:long, or xs:decimal for the remaining two
arguments.
- Mapping:
Returns the portion of the value of ?sourceString beginning
at the position indicated by the value of ?startingLoc and
continuing for the number of characters indicated by the value
of ?length. The characters returned do not extend
beyond ?sourceString. If ?startingLoc is zero or
negative, only those characters in positions greater than zero are
returned.
If an argument value is outside of its intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
4.5.1.5 func:string-length
(adapted from fn:string-length)
- Schema:
( func:string-length1() )
( ?arg ; func:string-length2( ?arg )
)
- Intended domains:
The value space of xs:string for ?arg.
- Mapping:
Returns an xs:integer equal to the length in characters
of the argument if it is a xs:string.
If the argument value is outside of its intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
4.5.1.6 func:upper-case (adapted
from fn:upper-case)
- Schema:
( ?arg ; func:upper-case( ?arg ) )
- Intended domain:
The value space of xs:string for ?arg.
- Mapping:
Returns the value of ?arg after translating every character
to its upper-case correspondent as defined in the appropriate case
mappings section in the Unicode standard.
If the argument value is outside of its intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
4.5.1.7 func:lower-case (adapted
from fn:lower-case)
- Schema:
( ?arg ; func:lower-case( ?arg ) )
- Intended domain:
The value space of xs:string for ?arg.
- Mapping:
Returns the value of ?arg after translating every character
to its lower-case correspondent as defined in the appropriate case
mappings section in the Unicode standard.
If the argument value is outside of its intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
4.5.1.8 func:encode-for-uri
(adapted from fn:encode-for-uri)
- Schema:
( ?arg ; func:encode-for-uri( ?arg )
)
- Intended domains:
The value space of xs:string for ?arg.
- Mapping:
This function encodes reserved characters in an
xs:string that is intended to be used in the path segment
of a URI. It is invertible but not idempotent.
If the argument value is outside of its intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
4.5.1.9 func:iri-to-uri (adapted
from fn:iri-to-uri)
- Schema:
( ?iri ; func:iri-to-uri ( ?iri ) )
- Intended domains:
The value space of xs:string for ?iri.
- Mapping:
This function converts an xs:string containing an IRI
into a URI according to the rules spelled out in Section 3.1 of
RFC 3987. It is
idempotent but not invertible.
If the argument value is outside of its intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
4.5.1.10 func:escape-html-uri
(adapted from fn:escape-html-uri)
- Schema:
( ?uri ;func:escape-html-uri( ?uri )
)
- Intended domains:
The value space of xs:string for ?uri.
- Mapping:
This function escapes all characters except printable characters
of the US-ASCII coded character set, specifically the octets
ranging from 32 to 126 (decimal). The effect of the function is to
escape a URI in the manner html user agents handle attribute values
that expect URIs. Each character in $uri to be escaped is replaced
by an escape sequence, which is formed by encoding the character as
a sequence of octets in UTF-8, and then representing each of these
octets in the form %HH, where HH is the hexadecimal representation
of the octet. This function must always generate hexadecimal values
using the upper-case letters A-F.
If the argument value is outside of its intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
4.5.1.11 func:substring-before
(adapted from fn:substring-before)
- Schema:
( ?arg1 ?arg2;
func:substring-before1( ?arg1 ?arg2
) )
( ?arg1 ?arg2 ?collation;
func:substring-before2( ?arg1 ?arg2 ?collation
) )
- Intended domains:
The value space of xs:string for all arguments.
- Mapping:
Returns the substring of the value of ?arg1 that precedes
in the value of ?arg1 the first occurrence of a sequence of
collation units that provides a minimal match to the collation
units of ?arg2 according to the collation that is used.
If any argument value is outside of its intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
4.5.1.12 func:substring-after
(adapted from fn:substring-after)
- Schema:
( ?arg1 ?arg2;
func:substring-after1( ?arg1 ?arg2
) )
( ?arg1 ?arg2 ?collation;
func:substring-after2( ?arg1 ?arg2 ?collation
) )
- Intended domains:
The value space of xs:string for all arguments.
- Mapping:
Returns the substring of the value of ?arg1 that follows in
the value of ?arg1 the first occurrence of a sequence of
collation units that provides a minimal match to the collation
units of ?arg2 according to the collation that is used.
If any argument value is outside of its intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
4.5.1.13 func:replace (adapted
from fn:replace)
- Schema:
( ?input ?pattern ?replacement;
func:replace1( ?input ?pattern ?replacement )
)
( ?input ?pattern ?replacement ?flags;
func:replace2( ?input ?pattern ?replacement ?flags
) )
- Intended domains:
The value space of xs:string for all arguments.
- Mapping:
The function returns the xs:string that is obtained by
replacing each non-overlapping substring of ?input that
matches the given ?pattern with an occurrence of
the ?replacement string.
If any argument value is outside of its intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
4.5.2 Predicates on Strings
4.5.2.1 pred:contains (adapted
from fn:contains)
- Schema:
( ?arg1 ?arg2;
pred:contains1( ?arg1 ?arg2 )
)
( ?arg1 ?arg2 ?collation ;
pred:contains2( ?arg1 ?arg2 ?collation
) )
- Intended domains:
The value space of xs:string for all arguments.
- Mapping:
Returns true or false indicating whether or not the value
of ?arg1 contains (at the beginning, at the end, or anywhere
within) at least one sequence of collation units that provides a
minimal match to the collation units in the value of ?arg2,
according to the collation that is used. "Minimal match" is defined
in Unicode
Collation Algorithm.
If an argument value is outside of the intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
4.5.2.2 pred:starts-with
(adapted from fn:starts-with)
- Schema:
( ?arg1 ?arg2;
pred:starts-with1( ?arg1 ?arg2
)
( ?arg1 ?arg2 ?collation;
pred:starts-with2( ?arg1 ?arg2 ?collation)
- Intended domains:
The value space of xs:string for all arguments.
- Mapping:
Returns true or false indicating whether or not the value
of ?arg1 starts with a sequence of collation units that
provides a minimal match to the collation units of ?arg2
according to the collation that is used.
If an argument value is outside of the intended domain, the
value of the function is left unspecified and can vary from one
semantic structure to another.
4.5.2.3 pred:ends-with (adapted
from fn:ends-with)
- Schema:
(?arg1 ?arg2;
fn:ends-with1( ?arg1 ?arg2 )
)
(?arg1 ?arg2 ?collation;
fn:ends-with2( ?arg1 ?arg2 ?collation)
)
- Intended domains:
The value space of xs:string for all arguments.
- Mapping:
Returns true or false indicating whether or not the value
of ?arg1 ends with a sequence of collation units that provides
a minimal match to the collation units of ?arg2 according to
the collation that is used.
If an argument value is outside