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

Jos de Bruijn wrote:
> 
> 
> Axel Polleres wrote:
>> 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.
> 
> The issue is that it is not a cast function in the way the other cast 
> functions are.  For example, to a query
> 
> ?x=rif:iri("a")
> 
> The user may get two answers
> "a"^^rif:iri
> "b"^^rif:iri

which is totally ok, since '=' is not an assignment but equality,
you have the same issue for any other casting functions, as soon as you 
can infer equality, don't you?

If you assert as a fact:

<http://www.ex.org/myInts/1> = "1"^^xsd:integer

now... if I want the entailments, what answers would be "expected" for

?x=xsd:integer("1.0"^^xsd:decimal)


> So, the end result would not be what the user expects.

What does the user expect?

> Plus, we need the predicate for conversion between strings and IRIs 
> anyway.  So, the choice is between (a) function + predicate and (b) 
> predicate.  (b) is clearly simpler than (a).

hmmm, "clearly simpler" appears to me a subjective judgement here.

Axel

> Best, Jos
> 
>>
>>> 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 Monday, 23 June 2008 06:17:40 UTC