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

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

> 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.
It seems simpler to have just a predicate.  We need to define fewer 
things and the users will need to learn fewer things.

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