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

Steve Harris wrote:
> On Wed, Dec 22, 2004 at 08:43:48AM -0600, Dan Connolly wrote:
> 
>>>PREFIX : <http://example.org/ns#>
>>>
>>>SELECT ?person
>>>WHERE  (?person :email ?e1)
>>>    OPTIONAL { (?person :email ?e2) AND ?e2 NE ?e1 }
>>>    AND ! &dawg:bound(?e2)
>>>
>>>using the same method Steve had of using optional, then inverting the sense
>>>of the match with dawg:bound.
>>
>>I thought dawg:bound was sort of wishful thinking in an earlier
>>message... I had trouble finding it in the editor's draft...
>>do you mean isBound in 11.2.2?
>>  http://www.w3.org/2001/sw/DataAccess/rq23/#sparqlTests
> 
> 
> It was wishful thinking when I was using it. I should have checked the
> draft though.
>  
> 
>>"Return true if its argument, which may be an expression, is defined.
>>NaNs and INFs count as defined."
>>
>>Surely the arguments to operators are the *values* of expressions,
>>right?
>>
>>for example
>>
>>"fn:compare Compare two strings.. Returns -1, 0, or 1, according to the
>>rules of the collation used."
>>
>>If I write
>>  fn:compare(?x, "abc")
>>
>>it's not comparing the 3-character string "?x" with the
>>5-character string '"abc"'; rather, it's comparing whatever
>>?x is bound to with the 3-character string "abc", right?
>>
>>So the specification of isBound has use/mention bugs... operators
>>can't see variable names. isBound would have to be a language
>>keyword, like UNSAID or SOURCE.
> 
> 
> 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.

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.

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

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.

	Andy


> 
> - Steve
>

Received on Wednesday, 22 December 2004 17:26:39 UTC