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

> That is not a problem, as far as I can see... we do not restrict 
> *additional* equalitities in these axioms, i.e. we don't say that 
> inequalities hold for the other, we do not prohibit anything.

If you say:
xsd:string("a"^^rif:iri) = "a"^^xsd:string
and
xsd:string("b"^^rif:iri) = "b"^^xsd:string

Then the statement
"a"^^rif:iri = "b"^^rif:iri
becomes inconsistent.
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