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

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

From: Axel Polleres <axel.polleres@deri.org>
Date: Fri, 13 Jun 2008 09:48:15 +0200
Message-ID: <4852263F.4030009@deri.org>
To: kifer@cs.sunysb.edu
CC: Jos de Bruijn <debruijn@inf.unibz.it>, Rule Interchange Format Working Group WG <public-rif-wg@w3.org>


I don't think that what you point out is a problem... see below.

Michael Kifer wrote:
> 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. 

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.

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


>> ----------------------
>> ==== <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 07:48:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:07:45 UTC