Re: [Fwd: Re: [DTB] Datatypes and Built-ins first run to clean up and extend the initial list]

Jos de Bruijn wrote:
>>>> In our framework, we have to give a fixed interpretation.
>>>> It says that this function is only defined for certain datatypes as 
>>>> "input", but in out framework the "input" is always a TERM and for 
>>>> evaluating I_F(xsd:string( "01"^^xsd:integer) )
>>>> I need to consider the actual domain value which "01"^^xsd:integer
>>>> is mapped to and reconvert it to a string. For that example, it is 
>>>> still easy, because there is a canonical string "1" which we can 
>>>> return.
>>
>> ... for datatypes which have canonical values for their representation
>> (I think this is fullfilled in general, yes?), it should be fine.
> 
> Each individual cast function needs to be defined.  I suspect we do not 
> need much more than the ones defined by XQuery, so we can use those 
> definition immediately.
> 
>>
>>>> Now what about
>>>>
>>>>    xsd:string( "http://www.example.org/theNumberOne"^^rif:iri)
>>>>
>>>> ??? Now what is the truth value of this? Depends on the current 
>>>> interpretation, or no? If the curent interpretation maps the iri
>>>> http://www.example.org/theNumberOne to an element in the value space of
>>>> e.g. xsd:integer the function should return a value, if it doesn't map
>>>> http://www.example.org/theNumberOne to an element in a compatible value
>>>> space for string conversions, the function returns an error. Yes?
>>>
>>> right.
>>
>> anyway, if this occurs in a rule body, no particular value for
>>
>>   xsd:string( "http://www.example.org/theNumberOne"^^rif:iri)
>>
>> would be entailed, neither error nor a particular string? ... even if 
>> I have a fixed interpretation for the built-in function.
> 
> values cannot be entailed.  Only formulas can.

By "entailed value" I meant to say that (by having a fixed 
interpretation) a certain ground function term would, in all 
interpretations have the same value.

> imagine you have a rule set R with the fact:
> p(xsd:string(blah^^rif:iri))
> 
> In some interpretations, blah^^rif:iri is mapped to a value for which 
> the casting function xsd:string is defined; in some interpretations it 
> is not.  Let's just consider two interpretations:
> I1 interprets xsd:string(blah^^rif:iri) as some string "foobar"
> I2 interprets xsd:string(blah^^rif:iri) as the domain element error
> 
> if we assume that in I1 "foobar"  is in the interpretation of p, i.e. 
> IR(p)(<"foobar">)=t, then I1 is a model of R.
> 
> According to the way we deal with errors in RIF (as decided on the last 
> face-to-face), the user decides what the truth value is of IR(p)(error) 
> in I2.
> 
> So it will be up to the user what the entailments are of R.  If the user 
> happens to decide that IR(p)(error)=f, then it will be the case that in 
> every model of R there is some string s such that IR(p)(s)=t; however, 
> the string is not the same in all models.  So, the following formula 
> will be entailed:
> (*) exists x (isString(x) and p(x))
>  but the following formula will not be entailed for any string s:
> p(s)
> 
> If the user decides that IR(p)(error)=t, then (*) will not be entailed, 
> because error is not a string.


I understand all that, the problem is that we cannot address the use 
case "convert from [2] to [1]"

>>>> I am not sure at the moment whether this is a problem, but it is at 
>>>> least a bit contrived.
>>>
>>> In what sense?  It seems completely reasonable to me that if you want 
>>> to do typecasting, but the cast fails, you have an error.
>>
>> Hmmm, wouldn't that imply that use case to convert from [2] to [1] out 
>> of scope of RIF then? That would be at the very least "surprising" for 
>> people who expected something like a usable rules language for e.g. 
>> describing RDF mappings from RIF, I guess.
> 
> My comment referred to the fact that you were calling the usual 
> definition for casting functions "contrived".

Converting between datatype literals is fine, as you said probably only 
a matter of going through the definitions. What is contrived (i.e. 
impossible), and you seem to confirm this, is casting for iris or 
getting anything out of their lexical representation, which is the use 
case "convert from [2] to [1]" but still doesn't seem to be possible:
As for your proposal, I have some doubts, let's see:

"Let I be an interpretation, let u be an element in the domain of I, and
let (i1, ..., in) be the lexicographically ordered sequence of IRIs that
denote u, i.e. for each ij (1 <= j = n) IC(ij)=u.  If n=0, then
iriToString(u)=error; otherwise, iriToString(u) = "i1"."

I am not sure, but that does not seem to help, because we have no 
guarantee that this function is injective ... that would only be the 
case if we restrict ourselves to Herbrand interpretations ... so, still 
I cannot refer to "the"  lexicographical representation of a rif:iri... 
i1 could - for the example iri 
"http://www.example.org/theNumberOne"^^rif:iri - still be ANY string 
lexicographically smaller than "http://www.example.org/theNumberOne"
depending on the actual interpretation, or no?

So, the simple rif condition:

  iriToString("http://www.example.org/theNumberOne"^^rif:iri) =
  "http://www.example.org/theNumberOne"

would still not be implied by the empty ruleset, would it?

Axel

> See [1] for a possible definition of a conversion function for IRIs 
> (note that it is not a typecasting function, because rif:iri is not a 
> type).
> 
> 
> Best, Jos
> 
> [1] http://lists.w3.org/Archives/Public/public-rif-wg/2008Mar/0019.html
> 
>>
>> If the majority of the group thinks that such rules are out of scope 
>> for RIF then I see a big problem to our relation with the RDF 
>> community. I personally do think it should be in scope.
>>
>>
>> Axel
>>
>>
>> 1. http://www.w3.org/TR/vcard-rdf
>> 2. http://xmlns.com/foaf/spec/
>>
>>>> best,
>>>> Axel
>>>>
>>>>
>>>>>> So how do I convince all the rest of the world to change that 
>>>>>> likewise?
>>>>>> Even the RDF Primer [2] (Example 6):
>>>>>> ---------------------------------------------------------------------- 
>>>>>>
>>>>>>       <rdf:Description rdf:nodeID="abc">
>>>>>>          <exterms:fullName>Dave Beckett</exterms:fullName>
>>>>>>          <exterms:homePage 
>>>>>> rdf:resource="http://purl.org/net/dajobe/"/>
>>>>>>       </rdf:Description>
>>>>>> ---------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>> or the SPARQL spec [3] (examples in Section 6):
>>>>>>
>>>>>> ---------------------------------------------------------------------- 
>>>>>>
>>>>>>   @prefix foaf:       <http://xmlns.com/foaf/0.1/> .
>>>>>>   @prefix rdf:        <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>>>>>>
>>>>>>   _:a  rdf:type        foaf:Person .
>>>>>>   _:a  foaf:name       "Alice" .
>>>>>>   _:a  foaf:mbox       <mailto:alice@example.com> .
>>>>>>   _:a  foaf:homepage   <http://work.example.org/alice/> .
>>>>>> ---------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>> promote the use of rdf:resources for URLs (homepages, 
>>>>>> email-adresses, etc.). It might be arguable with respect to the 
>>>>>> concepts, but people *do* use URIs like that and it is even done 
>>>>>> in the specs of RDF as we see here.
>>>>>>
>>>>>> How do we cater for it?  By just stating I cannot get a substring 
>>>>>> out of a homepage-URL or email-address... just because 
>>>>>> rdf:resource (and rif:iri, respectively) are not datatypes?
>>>>>>
>>>>>> I knew somehow why I put that in my signature ;-)
>>>>>>
>>>>>> Axel
>>>>>>
>>>>>>
>>>>>> 1. http://xmlns.com/foaf/spec/
>>>>>> 2. http://www.w3.org/TR/REC-rdf-syntax/
>>>>>> 3. http://www.w3.org/TR/rdf-sparql-query/
>>>>>>
>>>>>> -- 
>>>>>> Dr. Axel Polleres
>>>>>> email: axel@polleres.net  url: http://www.polleres.net/
>>>>>>
>>>>>> rdfs:Resource owl:differentFrom xsd:anyURI .
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

rdfs:Resource owl:differentFrom xsd:anyURI .

Received on Tuesday, 4 March 2008 14:20:54 UTC