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

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