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

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

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Tue, 04 Mar 2008 14:44:13 +0100
Message-ID: <47CD522D.7010606@inf.unibz.it>
To: axel@polleres.net
CC: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
>>> 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.

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

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

-- 
                          debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
One man that has a mind and knows it can
always beat ten men who haven't and don't.
   -- George Bernard Shaw


Received on Tuesday, 4 March 2008 13:44:34 GMT

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