W3C home > Mailing lists > Public > public-rif-wg@w3.org > June 2008

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

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Fri, 13 Jun 2008 03:22:38 -0400
To: Axel Polleres <axel.polleres@deri.org>
Cc: Jos de Bruijn <debruijn@inf.unibz.it>, Rule Interchange Format Working Group WG <public-rif-wg@w3.org>
Message-ID: <20080613032238.6ee3f8d2@cs.sunysb.edu>



On Fri, 13 Jun 2008 00:22:56 +0200
Axel Polleres <axel.polleres@deri.org> wrote:

> 
> 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
> preceding paragraph adds.

The two solutions are equivalent. Jos wanted it to be semantically defined and
I proposed a simpler, syntactic definition (which has slight disadvantages).

> I think this brings us to a proper solution:

Do not rush to judgement.

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

We realized this, but did not propose, because it is wrong :-)
For instance, the first group of equalities will prohibit different IRIs from
denoting the same resource. (The second group seems ok, but I would not be
surprised if it also has problems.)

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


	--michael  


> ----------------------
> 
> ==== <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.
Received on Friday, 13 June 2008 07:23:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:49 GMT