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

<snip/>

>> 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).
> 
> hmmm, "clearly simpler" appears to me a subjective judgement here.

Any judgment is subjective, but you must agree with me that defining one 
predicate is simpler than defining that same predicate plus an 
additional function.

Best, Jos

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

-- 
Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
----------------------------------------------
Public speaking is the art of diluting a two-
minute idea with a two-hour vocabulary.
   - Evan Esar

Received on Monday, 23 June 2008 11:43:53 UTC