- From: Geoff Chappell <geoff@sover.net>
- Date: Tue, 29 Mar 2005 16:15:16 -0500
- To: <public-rdf-dawg-comments@w3.org>

The test: http://www.w3.org/2001/sw/DataAccess/tests/#test-boolean-effective-value-opt ional implies that the boolean effective value of an unknown datatype is false (by not including #x3 in the results). The next test: http://www.w3.org/2001/sw/DataAccess/tests/#test-boolean-effective-value-unk nown-types implies that boolean effective value of an unknown datatype is true (by not including #x3 in the results) Which is correct? Similarly, the first test implies that the boolean effective value of an unbound variable is either false or a non-match (i.e. solution is discarded) while the second test implies that it is either true or a non-match. So it appears that it is meant to be a non-match. Is that correct? If so, I'll just relate that I've found that in order to produce expected results in all situations, I've had to take the approach that a constraint function always succeeds but signals an error (e.g. invalid parameter) by returning a distinguished value and the boolean effective value of that distinguished value is false. For example if the filter clause of: SELECT ?title ?price WHERE { ?book dc:title ?title . OPTIONAL { ?book x:price ?price } . FILTER ( ! bound(?price) ) || ( ?price < 15 ) . } is understood to mean: sop:logical-or( fn:not(sop:bound(?price)), op:numeric-less-than(?price, 15))) If an unbound value of price causes op:numeric-less-than to fail (as in discard the solution as opposed to returning a value of false), then the solution is tossed despite the fact that the sop:logical-or would return true given the chance (since the other leg is true). Now if sop:logical-or behaved logically (i.e. passed the solution when true, failed it when false) this wouldn't be a problem, but it doesn't behave that way - e.g. the ebv of: sop:str(sop:logical-or(false, false)) is true. I'm not sure if this is an implementation difficulty or a spec difficulty (I know it's at least a difficulty with implementing the spec on a logic platform). My guess is, though, that it is a general problem due to the slightly differing models between constraints and the rest of the language. So just to reiterate, the solution I found was to make the Boolean effective value of an unbound variable to be false. Geoff

Received on Tuesday, 29 March 2005 21:15:34 UTC