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

Jos de Bruijn wrote:
>> 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.

Hmmm, thanks, now I see/remember, ouch yes.
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.
If I understood michael correctly, the other direction

   rif:iri("b"^^xsd:string) = "b"^^rif:iri

can still work, yes?
At least that would save the casts *to* rif:iri, and we only need the 
predicate for  string-to-iri ... yes?


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


-- 
Dr. Axel Polleres, Digital Enterprise Research Institute (DERI)
email: axel.polleres@deri.org  url: http://www.polleres.net/

Everything is possible:
rdfs:subClassOf rdfs:subPropertyOf rdfs:Resource.
rdfs:subClassOf rdfs:subPropertyOf rdfs:subPropertyOf.
rdf:type rdfs:subPropertyOf rdfs:subClassOf.
rdfs:subClassOf rdf:type owl:SymmetricProperty.

Received on Friday, 13 June 2008 09:33:40 UTC