Re: Testcase comment and question

Geoff Chappell wrote:
> 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)
> 
> 
> 
> Also, a question/comment about: 
> 
> 	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))

There seems to be a problem where - evaluation of an expression that leads to a 
failure (here - unbound variable) does not lead to true/false condition that can 
be negated.

"Fail" becomes 'reject solution' but also not("Fail") becomes 'reject solution'.

Passing a filter means that it is a positive claim to be true.  For unboudn 
variables, it is not known either way what the state of the constraint is, so 
the solution is not part of the results.  Open world assumption : if the price 
is unknown, then we can't allow either "?price < 15" nor allow "?price >= 15".

	Andy

> 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 Wednesday, 30 March 2005 12:53:17 UTC