Re: [Fwd: Re: [DTB] Datatypes and Built-ins first run to clean up and extend the initial list]

>> I am wondering why you would want to extract telephone numbers or even 
>> IRIs from identifiers in a rules language. The agent that is actually 
>> going to make the phone call or browse the homepage will use the 
>> syntactical representation of some query answers.
> 
> Axel's point was that there are different vocabularies which use 
> different encodings (Foaf and vcard in Axel's example). One of our core 
> agreed use cases for RIF is translation between vocabularies in 
> precisely this way. This has nothing directly to do with the end agents 
> it is part of mediating between those agents.

I see your point.
Thinking a bit about, I believe we can use a similar trick as I 
mentioned in the context of isIRI in [1], although the definition would 
be anything but elegant; one of the issues is that a given object may be 
represented by multiple IRIs.  The definition could look something like 
like:

Let I be an interpretation, let u be an element in the domain of I, and 
let (i1, ..., in) be the lexicographically ordered sequence of IRIs that 
denote u, i.e. for each ij (1 <= j = n) IC(ij)=u.  If n=0, then 
iriToString(u)=error; otherwise, iriToString(u) = "i1".

[1] http://lists.w3.org/Archives/Public/public-rif-wg/2008Mar/0010.html

> 
> RIF's apparent inability to meet this use case is of serious concern for 
> me but unfortunately I don't have a proposed solution.
> 
>>> But I am unsure whether we can by any means accomodate for that.
>>> Anyway, I think that casts are not trivial to define even for typed
>>> literals or no? Since the lex-to-val mapping is not injective in 
>>> general, how can I define for instance  the cast
>>>
>>>    xsd:string( "01"^^xsd:integer)
>>
>> we should use the definition of XQuery functions; i.e., use the 
>> canonical representation of integers.
> 
> I can see some sense in that. However, in practice users place 
> unreasonable demands on round tripping. In Jena we preserve both the 
> lexical form and the value form of typed literals and distinguish 
> semantic equality from Java equality as the only way to satisfy user 
> requirements.
> 
> I would prefer the RIF definitions to be compatible with SPARQL and not 
> imply any normalization of lexical form of supplied values, of course 
> computed values must use a canonical lexical form.

It is not proposed to normalize the lexical forms in the RIF syntax.  It 
is only necessary for casting between types.

Best, Jos

> 
> Dave

-- 
                          debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
One man that has a mind and knows it can
always beat ten men who haven't and don't.
   -- George Bernard Shaw