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

Re: ISSUE-61 (IRI-Casts): Casting to/from rif:iri [DTB]

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Tue, 17 Jun 2008 08:31:24 +0200
Message-ID: <48575A3C.7060409@inf.unibz.it>
To: Axel Polleres <axel.polleres@deri.org>
CC: kifer@cs.sunysb.edu, Rule Interchange Format Working Group WG <public-rif-wg@w3.org>


Axel Polleres wrote:
> For all: I added a strawman for the
> 
>  pred:iri-to-string( iri string )
> 
> in the DTB document. Comments welcome!
> more remarks to jos' reply inline below.
> 
> Jos de Bruijn wrote:
>>
>>> So, my point for that proposal was that - at least syntactically - I 
>>> would like this to look like a cast function and not a predicate.
>>
>> Why?  It's not function, so you should not lead people to believe that 
>> it is.
> 
> ...
> 
>>> If I understood michael correctly, the other direction
>>>
>>>   rif:iri("b"^^xsd:string) = "b"^^rif:iri
>>>
>>> can still work, yes?
>  >
>> I see no technical problem with it.
> 
> ... so, it *is* a function then, right? in the rif:iri direction, i 
> mean, it is just that the definition is slightly different than the
> other built-in functions.
> 
>>> At least that would save the casts *to* rif:iri, and we only need the 
>>> predicate for  string-to-iri ... yes?
>>
>> It seems to me that this just complicates matters; users need to learn 
>> both the predicate and the "function", which probably doesn't really 
>> behave as they expect.
> 
> *users* don't need to learn anything new, they can use cast functions 
> just like for data types, which is intuitive. If we add new predicates, 
> they need to learn something new, this is why I want to keep functions 
> for conversions wherever possible.

The issue is that it is not a cast function in the way the other cast 
functions are.  For example, to a query

?x=rif:iri("a")

The user may get two answers
"a"^^rif:iri
"b"^^rif:iri

So, the end result would not be what the user expects.

Plus, we need the predicate for conversion between strings and IRIs 
anyway.  So, the choice is between (a) function + predicate and (b) 
predicate.  (b) is clearly simpler than (a).

Best, Jos

> 
>> It seems simpler to have just a predicate.  We need to define fewer 
>> things and the users will need to learn fewer things.
> 
> Please look at the current state of the document, and let me know what 
> you think now...
> 
> Axel
> 
>> Best Jos
>>
>>>
>>>
>>> but michael was swinging the sword of damocles also here:
>>>
>>>  >  (The second group seems ok, but I would not be
>>>  >   surprised if it also has problems.)
>>>
>>> Hope that this still works at least... any more insights/thoughts on 
>>> that?
>>>
>>> For the moment, I removed/reworded the "nasty" direction in the 
>>> equalities, and added your counterexample, but didn't add a predicate 
>>> for string-to-iri yet.
>>>
>>> Axel
>>>
>>>
>>>> So, you prohibit stating equalities between IRIs.
>>>>
>>>>
>>>> Best, Jos
>>>>
>>>>>
>>>>>> (The second group seems ok, but I would not be
>>>>>> surprised if it also has problems.)
>>>>>
>>>>> since the first one doesn't seem to  have problems - at least not 
>>>>> the ones you mention -  I don't expect so. :-)
>>>>>
>>>>>>> This is more elegant than having a predicate for one cast and 
>>>>>>> functions
>>>>>>> for all others. Also, this form of equalities has the elegance that
>>>>>>> additional equalities (e.g. by iris referrng to the same object) 
>>>>>>> are not
>>>>>>> a problem at all with this.
>>>>>>>
>>>>>>> Accordingly, I changed the respective section on casting from an 
>>>>>>> d to
>>>>>>> rif:iri to the following text:
>>>>>>
>>>>>> I am afraid you will have to change back :-)
>>>>>
>>>>> If you find a problem (apart from the above which isn't a problem 
>>>>> unless I got you wrong), then certainly I will.
>>>>>
>>>>> Axel
>>>>>
>>>>>>> ----------------------
>>>>>>>
>>>>>>> ==== <tt>rif:iri</tt> ====
>>>>>>> {|
>>>>>>> | style="background-color: #80FF80" rowspan="1" colspan="1" |
>>>>>>> Editor's note: Casting from and to is still under discussion in 
>>>>>>> the working group since <tt>rif:iri</tt> is not a datatype. For 
>>>>>>> details, we refer to 
>>>>>>> [http://www.w3.org/mid/20080610143044.5698ABF57@nelson.w3.org 
>>>>>>> Issue-61]. The following is a strawman proposal which might still 
>>>>>>> change in future versions of this working draft.
>>>>>>> |}
>>>>>>>
>>>>>>> <p>Additionally to the built-in cast functions for datatyes we 
>>>>>>> allow conversions from and to constants in the  <tt>rif:iri</tt> 
>>>>>>> symbol space to and from <tt>xsd:string</tt>s following similar 
>>>>>>> considerations as conversions from and to <tt>xsd:anyURI</tt> in 
>>>>>>> <nowiki>[</nowiki>[[#ref-xpath-functions|XPath-Functions]]]. 
>>>>>>> Technically speaking, we cannot proceed as with the other cast 
>>>>>>> functions, defining the semantics via a fixed mapping 
>>>>>>> '''''I'''''<sub>external</sub> for an external schema <tt> ( 
>>>>>>> ?arg<sub>1</sub>; rif:iri ( ?arg<sub>1</sub> ) )</tt>, since 
>>>>>>> <tt>rif:iri</tt> is not a datatype with a fixed value space and 
>>>>>>> fixed lexical-to value mapping.  Instead, casts between 
>>>>>>> <tt>rif:iri</tt> and <tt>xsd:string</tt> are defined via an 
>>>>>>> infinite set of axiomatic equalities in every RIF interpretation 
>>>>>>> as follows.</p>
>>>>>>>
>>>>>>> <p>The following equalities hold in every RIF interpretation for 
>>>>>>> each unicode string <i>a</i>:</p>
>>>>>>> <ul>
>>>>>>>   <li><tt>xsd:string("</tt><i>a</i><tt>"^^rif:iri) = 
>>>>>>> "</tt><i>a</i><tt>"^^xsd:string</tt></li>
>>>>>>>   <li><tt>rif:iri("</tt><i>a</i><tt>"^^xsd:string) = 
>>>>>>> "</tt><i>a</i><tt>"^^xsd:iri</tt></li>
>>>>>>> </ul>
>>>>>>>
>>>>>>> <p>Thus, although there is no explicit schema  <tt> ( 
>>>>>>> ?arg<sub>1</sub>; rif:iri ( ?arg<sub>1</sub> ) )</tt> in RIF, 
>>>>>>> casts between <tt>xsd:string<tt>s and <tt>rif:iri</tt>s 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.
>>>>>>> </p>
>>>>>>> ----------------------
>>>>>>>
>>>>>>> I like this solution :-)
>>>>>>>
>>>>>>> Axel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> and not bother with the preceding text in your message. It is 
>>>>>>>> much simpler that way.
>>>>>>>>
>>>>>>>> michael
>>>>>>>>
>>>>>>>> On Tue, 10 Jun 2008 19:22:10 +0200
>>>>>>>> Jos de Bruijn <debruijn@inf.unibz.it> wrote:
>>>>>>>>
>>>>>>>>> Well, it was the only reasonable alternative I could think of 
>>>>>>>>> for casting IRIs to strings.
>>>>>>>>>
>>>>>>>>> I am personally actually not convinced that we even need such a 
>>>>>>>>> casting function, but there are some people who think it is 
>>>>>>>>> useful.
>>>>>>>>>
>>>>>>>>> Best, Jos
>>>>>>>>>
>>>>>>>>> Michael Kifer wrote:
>>>>>>>>>> This makes iriToString a multivalued function (i.e., the same 
>>>>>>>>>> iri has several
>>>>>>>>>> string interpretations). Is this what we want?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     --michael On Tue, 10 Jun 2008 16:40:04 +0200
>>>>>>>>>> Jos de Bruijn <debruijn@inf.unibz.it> wrote:
>>>>>>>>>>
>>>>>>>>>>> See [1] and preceding the messages in the thread for a 
>>>>>>>>>>> description of the semantic problems.  In [1] I also proposed 
>>>>>>>>>>> a casting predicate that seems to work.
>>>>>>>>>>>
>>>>>>>>>>> In summary, the biggest semantic challenge in casting IRIs to 
>>>>>>>>>>> strings is that several different IRIs may be mapped to the 
>>>>>>>>>>> same string.  The following was my proposal:
>>>>>>>>>>>
>>>>>>>>>>> "Let I be an interpretation, let u be an element in the 
>>>>>>>>>>> domain of I, and
>>>>>>>>>>> let {i1, ..., in} be the set of IRIs that denote u, i.e. for 
>>>>>>>>>>> each ij (1
>>>>>>>>>>> <= j <= n), IC(ij)=u.  IR(iriToString)(u,"ij")=t for (1 <= j 
>>>>>>>>>>> <= n);
>>>>>>>>>>> IR(iriToString)(u,s)=f for every element s not in {"i1", ..., 
>>>>>>>>>>> "in"}."
>>>>>>>>>>>
>>>>>>>>>>> The rule set
>>>>>>>>>>> iriToString("b"^^rif:iri,"b"^^xsd:string)
>>>>>>>>>>>
>>>>>>>>>>> is satisfied in every RIF interpretation.
>>>>>>>>>>>
>>>>>>>>>>> I think this predicates should be sufficient for most of the 
>>>>>>>>>>> use cases.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best, Jos
>>>>>>>>>>>
>>>>>>>>>>> Rule Interchange Format Working Group Issue Tracker wrote:
>>>>>>>>>>>> ISSUE-61 (IRI-Casts): Casting to/from rif:iri [DTB]
>>>>>>>>>>>>
>>>>>>>>>>>> http://www.w3.org/2005/rules/wg/track/issues/
>>>>>>>>>>>>
>>>>>>>>>>>> Raised by: Christopher Welty
>>>>>>>>>>>> On product: DTB
>>>>>>>>>>>>
>>>>>>>>>>>> It is clear users of RIF dialects such as BLD will want to 
>>>>>>>>>>>> be able to convert (cast) instances of rif:iri to/from other 
>>>>>>>>>>>> datatypes, in particular strings and possibly rif:text.
>>>>>>>>>>>>
>>>>>>>>>>>> In general, a casting mechanism is not present in DTB and 
>>>>>>>>>>>> should be added.
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 
> 

-- 
                          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



Received on Tuesday, 17 June 2008 10:03:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:49 GMT