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:
rif:iri
xsd:long
xsd:decimal
xsd:time
xsd:string
xsd:dateTime
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
xsd:strings...
(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
XSD-interpretations.)
I propose the following conversions to be defined in RIF Core and
extensible for other dialects:
Casting and conversions between the types
xsd:decimal
xsd:time
xsd:string
xsd:dateTime
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
xs:anyURI.
(Remarks/Questions:
- 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]
apply.
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.
1.
http://burns.w3.org/cgi-bin/wiki_tr?source=http%3A%2F%2Fwww.w3.org%2F2005%2Frules%2Fwg%2Fwiki%2FCore&Go=Go
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/