Testcase comment and question

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