- From: Axel Polleres <axel.polleres@deri.org>
- Date: Fri, 01 Jun 2007 21:24:22 +0200
- 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: 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/
Received on Friday, 1 June 2007 19:26:37 UTC