W3C home > Mailing lists > Public > public-rif-wg@w3.org > June 2007

ACTION-293,Prepare a datatype conversion proposal

From: Axel Polleres <axel.polleres@deri.org>
Date: Fri, 01 Jun 2007 21:24:22 +0200
Message-ID: <46607266.4070208@deri.org>
To: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Here is my proposal for datatype conversions (in RIF Core, to be 
extendable by other dialects.

Basically, the only concern I had was related to rif:iri which is not an 
XSD type and thus not covered by the casting in [6]. If we can treat
rif:iri more or less like xs:anyURI then we shouldn't run into major 
troubles reusing the casting/conversions from [6]:

RIF Core supports currently [1] the following basic datatypes:


In the last Telecon, we discussed the need for conversions between these 
datatypes, as an example where the conversion from an IRI to strings 
might be necessary, take for instance a conversion from foaf:phone [1] 
using the tel: URI scheme to vCard which in its RDF [2] version uses 
strings to represent telehpone numbers as (plain) literals  , ie 

(Remark: I assume for the moment that plain literals are default typed 
to xsd:string... the RDF-semantics [4] says likewise that plain literals 
are the same as the respective xsd:string typed literal for all 

I propose the following conversions to be defined in RIF Core and
extensible for other dialects:

Casting and conversions between the types
are defined as in the conversion table in Section 17.1 of [6].
Note that the types xs:long and rif:iri do not appear in that table:
- The conversions from and to xs:long follow the same considerations as 
xs:integer in that table, by the XPath, XQuery type hierarchy in Sec 1.6 
of [6].
- The conversiond from and to rif:iri follow the same considerations as


- Can we declare rif:iri as a subtype of xs:anyURI
in the type hierarchy of XPAth/XQuery (Sec 1.6 of [6])? We might need to
check whether there are issues on this conversions for the differences 
between IRIs and URIs, but these are probably minor, what worries me 
more is: Can we say that: each rif:iri is a xs:anyURI but not vice 
versa, or is any subsort relation here unwanted?)
- Shall we include anyURI and xs:integer in the basic datatypes of Core?

By these two cases, we have defined a list of compatible conversions 
with XPath XQuery,

Explicit and Implicit conversion:

Casts/conversions can be either
- explicit or
- implicit (in multisorted RIF).
corresponding to constructor functions and cast expressions
in XPath/XQuery.

Explicit conversion:

The name of the constructor function for explicit conversion is the same 
as the name of the built-in [XML Schema Part 2: Datatypes Second 
Edition] datatype or the datatype defined in Section 2.6 Types^DM of 
[XQuery 1.0 and XPath 2.0 Data Model]. Note that, the constructor 
functions are external functions, thus the considerations on issue [5] 

Implicit casting:

in functions and predicates in multi-sorted RIF, implicit casting could 
work  according to

  - arrow sorrts and boolean sorts
  - given the availability of conversion functions

2 Remarks:
a) What I don't have 100% clear, and what is important for casting, is 
whether boolean sorts and arrow sorts are unique per constant/arity.
otherwise, ie. if we allow overloading, casting is ambiguous.
b) whether such implicit casting conflicts with the definition of 
well-formedness of terms in Rif Core [1]

Note in the context of a) that also XPath/XQuery does not support 
overloading: "that functions that have multiple signatures with the same 
name and the same number of parameters are not supported." [6]

- Sub_Sorts probably do not need to be casted/converted in implicit casting.

2. http://xmlns.com/foaf/spec
3. http://www.w3.org/TR/vcard-rdf
4. http://www.w3.org/TR/rdf-mt/
5. http://www.w3.org/2005/rules/wg/track/actions/296
6. http://www.w3.org/TR/xpath-functions

Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/
Received on Friday, 1 June 2007 19:26:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:45 UTC