W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2004

Re: UNSAID - two test cases (dawg:unbound, issues#useMentionOp)

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Wed, 22 Dec 2004 18:46:09 +0000
Message-ID: <41C9C0F1.8000303@hp.com>
To: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>



Steve Harris wrote:
> On Wed, Dec 22, 2004 at 05:26:01PM +0000, Andy Seaborne wrote:
> 
>>>Yes, but SQL for eg. has tri-value logic (true, false and NULL), so you
>>>can meaningfully apply operators and functions to unbound values (NULL).
>>
>>It doesn't quite work out that simply.  It's fine for operators and 
>>functions but pattern matching isn't so straight forward.
>>
>>OPTIONAL (<x> ?p ?o)
>> (?o ?q <y>)
>>
>>so ?o may be NULL then we have the (?o ?q <y>) and it needs to handle
>>?o = NULL differently.  NULL is different.
> 
> 
> Yes, bun in RDF you cant have a triple like (NULL ?q <y>), so that match
> will always fail. Unless I'm missing something.

So if (NULL, ?q <y>) does not match then

OPTIONAL (<x> ?p ?o)
(?o ?q <y>)

fails when there is no (<x> ?p ?o). It's as if there is no optional on the 
first triple pattern.

The reverse,

(?o ?q <y>)
OPTIONAL (<x> ?p ?o)

will work as an optional.

Hence, NULL has to be handled specially and whether we talk about NULLs or 
unbound variables, they are both handled differently (procedurally and 
declaratively).

	Andy




>  
> 
>>Talking about NULLs, with all it special cases for matching and function 
>>handling, like NULL != NULL, is no different to talking about unbound 
>>variables.  Both need special handling.
> 
> 
> There are no special cases. Any arithemtic operation involving NULL is
> NULL, so NULL == NULL is NULL, NULL > 3 is NULL, ...
>  
> 
>>>I have said a few times that DAWG I think should come down off the fence
>>>about tri-value logic. 
>>
>>Do you have a test case where it makes a difference?  I have difficulty 
>>seeing this as other than a difference of linguistic approach, trying to 
>>use the same language for matching and for operators.
> 
> 
> Yes,
> 
> 	SELECT ?foo
> 	WHERE [ (?foo :p ?x) ] [ (?foo :q ?y) ]
> 	AND ?x != ?y
> 
> In a tri-value logic, this will only succeeed if ?x and ?y are bound, I
> think.
> 
> 
>>It seems to me that we have to say what happens with op:numeric-less-than 
>>encounters anything unexpected through the casting rules of F&O extended 
>>for bNodes anyway.
> 
> 
> Yes, but what. The Perl/PHP/ECMAScript convention is that 
> 
> 	?x is unbound, ?y = 3
> 
> 	?x != ?y is true
> 	?x > 3 is false (for various reasons)
> 	
> In SQL they are both NULL, again, I think, My SQL is rusty. e.g:
> 
> 	$y = 3;
> 	if ($x != $y) { print "true\n"; } else { print "false\n"; }
> 	if ($x > 3) { print "true\n"; } else { print "false\n"; }
> 
> prints
> 
> 	true
> 	false
> 
> In PHP and Perl.
> 
> In Perl $x > -1 is true (unbound = 0, I guess), in PHP its false.
> 
> - Steve
> 
Received on Wednesday, 22 December 2004 18:46:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:21 GMT