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 13:19:06 +0200
Message-ID: <485257AA.6060101@deri.org>
To: Jos de Bruijn <debruijn@inf.unibz.it>
CC: kifer@cs.sunysb.edu, Rule Interchange Format Working Group WG <public-rif-wg@w3.org>

For all: I added a strawman for the

  pred:iri-to-string( iri string )

in the DTB document. Comments welcome!
more remarks to jos' reply inline below.

Jos de Bruijn wrote:
> 
>> 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.
> 
> Why?  It's not function, so you should not lead people to believe that 
> it is.

...

>> If I understood michael correctly, the other direction
>>
>>   rif:iri("b"^^xsd:string) = "b"^^rif:iri
>>
>> can still work, yes?
 >
> I see no technical problem with it.

... so, it *is* a function then, right? in the rif:iri direction, i 
mean, it is just that the definition is slightly different than the
other built-in functions.

>> At least that would save the casts *to* rif:iri, and we only need the 
>> predicate for  string-to-iri ... yes?
> 
> It seems to me that this just complicates matters; users need to learn 
> both the predicate and the "function", which probably doesn't really 
> behave as they expect.

*users* don't need to learn anything new, they can use cast functions 
just like for data types, which is intuitive. If we add new predicates, 
they need to learn something new, this is why I want to keep functions 
for conversions wherever possible.

> It seems simpler to have just a predicate.  We need to define fewer 
> things and the users will need to learn fewer things.

Please look at the current state of the document, and let me know what 
you think now...

Axel

> Best Jos
> 
>>
>>
>> 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 11:19:53 GMT

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