Re: Weird value testing situations

On Mon, Aug 14, 2006 at 05:02:32AM +0100, Bijan Parsia wrote:
> 
> As I was working on DISTINCT, I realized that there were other  
> corners of RDF semantics that might be a bit odd. Forgive me if these  
> have been raised already. They are mostly inspired by Jeremy  
> Carroll's weird datatype tricks shown to me at WWW in Japan.
> 
> We have some text that sort of addresses this issue:
> 
> """3.4 Matching Values and RDF D-entailment
> RDF defines D-Entailment where extra semantic conditions are allowed  
> for datatypes. When matching RDF literals in graph patterns, the  
> datatype lexical-to-value mapping may be reflected into the  
> underlying RDF graph, leading to additional matches where it is known  
> that two literals are the same value. RDF semantics does not require  
> this of all RDF graphs."""
> 
> I don't understand this last bit, especially if it is to be some sort  
> of loophole. I would think that the presence of typed literals would  
> require datatyped interpretations. We could, I supposed, designate a  
> mode where all matching was done on the lexical form, or something  
> similar. But I don't see that we *have* done that.
> 
> Let me just give some of the very simple ones, and see if there's  
> anything to discuss:
> 
> :bob rdf:type  xsd:negativeIntegerr.
> :mary rdf:type xsd:positiveInteger.

Query1:
> 	SELECT ?x
> 	WHERE {?x rdf:type _:type.
> 			 ?y rdf:type _:type. FILTER ?x < ?y}
> 
> Should this have an answer? that is :bob? How about:
> 
> :bob rdf:type  xsd:negativeInteger.
> :mary age "10"^^xsd:integer.

Query2:
> 	SELECT ?x ?y
> 	WHERE {?x rdf:type _:type.
> 			 :mary age ?y. FILTER ?x < ?y}
> 
> How about this? <;bob, 10^^xsd:integer>?
> 
> More complex examples are possible with range or domain that are,  
> perhaps, a little less artificial. But I hope these are clear. You  
> could replace the URIs with BNodes as well.
> 
> The type testing functions (e.g., isLiteral()) are similarly doggy if  
> you consider :bob rdf:type rdfs:Literal.

Huh, interesting problem. I would certainly expect the naive
implementation (not supporting D-entailment) to conclude:
  isLiteral(?x) => F
  isBlank(?x) => T
Having a D-entailment implementation say that isLiteral(?x) => T would
violate the monotinicity rules we appear to have set down for ourselves
(wrongly or rightly). Thus, I think that isLiteral has to operate on
the symbol in the graph, and not on what we may know that symbol to
represent.

>From this, I would expect Query1 to give no answers as evaluating
  :bob < :mary

would result in a type error as A < B is only valid for paris of
{numeric, simple literal, xsd:string, xsd:boolean, xsd:dateTime}.
I also expect Query2 to yield no answers as
  :bob < "10"^^xsd:integer
is also a type error.


Is there a way the current wording could be improved?
Do we need another paragraph on what not to expect from D-entailment?

> Of course, we could understand all the functions, as they seem to be  
> implicitly, as applying strictly to the lexical form. But that's not  
> quite right since the comparison operators, for example, operate on  
> the value space. :bob *has a value* in the value space, we just don't  
> have access to it.
> 
> Cheers,
> Bijan.
> 
> 

-- 
-eric

home-office: +1.617.395.1213 (usually 900-2300 CET)
	    +33.1.45.35.62.14
cell:       +33.6.73.84.87.26

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Monday, 14 August 2006 10:52:39 UTC