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

From: Axel Polleres <axel.polleres@deri.org>
Date: Fri, 13 Jun 2008 00:22:56 +0200
Message-ID: <4851A1C0.2080209@deri.org>

CC: Jos de Bruijn <debruijn@inf.unibz.it>, Rule Interchange Format Working Group WG <public-rif-wg@w3.org>
```
Michael Kifer wrote:
> I was just checking if this was the intent.
>
> I think it is enough to define this function by a bunch of axioms
>
> iriToStr("a"^^rif:iri  "a"^^xs:string).

You mean basically that these axioms are implicit in RIF for all
strings? Well, why not... we get infinitly many axiomatic facts with
that in RIF (which is a thing which some people don't like about RDF...)
but so would we with Jos solution, indeed, I do not see what the

I think this brings us to a proper solution:
We can get something which looks like a *real* casting function by the
same means, not having to go the nasty bypath of having a predicate by
replacing

"iriToStr("a"^^rif:iri "a"^^xsd:string) is satisfied in every RIF
interpretation."

with the following:

"The following equalities hold in every RIF interpretation:

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

and

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

why didn't we realize this earlier...
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:

----------------------

==== <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 06:49:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:51 UTC