Testcase comment and question

From: Geoff Chappell <geoff@sover.net>
Date: Tue, 29 Mar 2005 08:49:01 -0500

Message-ID: <014001c53466\$110843b0\$6401a8c0@gsclaptop>
```
The file:

http://www.w3.org/2001/sw/DataAccess/tests/data/bound/bound1.rq

doesn't match the documentation at:

http://www.w3.org/2001/sw/DataAccess/tests/#dawg-bound-query-001

(docs appear correct, file uses older syntax)

http://www.w3.org/2001/sw/DataAccess/tests/#optional-filter

I'm wondering if the results are correct. The query is:

SELECT  ?title ?price
WHERE
{ ?book dc:title ?title .
OPTIONAL
{ ?book x:price ?price .
FILTER ?price < 15 .
} .
}

If OPTIONAL A = A or NOT A then:

OPTIONAL (A and B) = (A and B) or NOT(A and B) = A and B or NOT A or NOT B

Or in this case (with some abuse of notation):

{ ?book dc:title ?title .
{ ?book x:price ?price .
FILTER ?price < 15 .
} .
}
OR
{ ?book dc:title ?title .
NOT
{ ?book x:price ?price .}
}
OR
{ ?book dc:title ?title .
NOT
{ FILTER ?price < 15.}
}

The first two terms are straight forward - they return the results:

"Title 1" 10  	# by first term
"Title 3"		# by second term

The last term is the problematic one - it's got several potential
interpretations (none of which yields the intended results of the testcase):

1.  If op:numeric-less-than(?price, 15) doesn't match (i.e. fails the
solution) since it can't handle the unbound value then NOT
(ebv(op:numeric-less-than(?price, 15))=true) passes everything - i.e. all
books are passed with a NULL/unbound value for price adding:

"Title 1"
"Title 2"
"Title 3"

to the resultset

2. If NOT FILTER (x) is translated to EBV(X) = FALSE
where X = op:numeric-less-than(?price, 15))
If op:numeric-less-than doesn't match any values in this case then no books
will be added to the resultset. If op:numeric-less-than returns a NULL value
(as a response to a NULL parameter) and EBV(NULL) = FALSE, then all books
are passed (as in case 1). (BTW, I'm not sure if this is a spec issue or an
implementation issue - i.e. spec implies that functions may both return
values and pass/fail a solution which I think can lead to inconsistent
behavior)

The only way to get the results the testcase requires is to treat the last
term as:

{ ?book dc:title ?title .
NOT
{ ?book x:price ?price. FILTER ?price < 15.}
}

but offhand I can't see a justification for treating it this way. Perhaps
another way of stating this issue:

Does:
OPTIONAL (A AND B)
Equal:
OPTIONAL A AND OPTIONAL B
?

I realize the whole question assumes an acceptance of the logical
interpretation of OPTIONAL. Whether or not the working group considers that
to be valid, I think this test case clearly illustrates the need for some
formal definition of the semantics of OPTIONAL (i.e. I don't think you can
use test cases alone to define the behavior).

Geoff
```
Received on Tuesday, 29 March 2005 13:51:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:05 UTC