Re: [OK?] Bug: "A value disjunction that encounters a type error on only one branch will return the result of evaluating the other branch."

On Tue, Aug 02, 2005 at 12:47:11PM -0400, Eric Prud'hommeaux wrote:
> On Tue, Aug 02, 2005 at 11:27:24AM -0400, Tim Berners-Lee wrote:
> > 
> > The current last call draft states,
> > 
> > "A value disjunction that encounters a type error on only one branch  
> > will return the result of evaluating the other branch."
> > 
> > This seems to be a bug: inconsistent with the logic one would expect.
> >  It is inconsistent with the general rule that the disjunction of  
> > false with x is x for all x. The disjunction of false with a type  
> > error is therefore a type error.  If not, the type error is masked.
> > 
> > Example in english:  An alarm should fire if either ?smokeDetected or  
> > the ?temperature is above 40.  Suppose the ?smokeDetected is false  
> > and the temperature is (because of a bug) bound to something which  
> > can't be compared to 40 without a type error.  The result should be  
> > that the alarm is a type error.  Instead, with the wording above, the  
> > alarm is suppressed.
> 
> I tried making this concrete, but found it supporting the spec's
> current wording.
> 
> DATA:
> 
> @prefix : <asdf> .
> :detector :temp \"314\"^^:degreesK ;
>           :smokeDetects 1 .
> 
> *note* degreesK is not known by this SPARQL engine and therefor is not
> known to be numeric and therefor throws a type error at the > operator.
> 
> QUERY:
> 
> PREFIX : <asdf> 
> SELECT ?smokeDetected ?temperature
>  WHERE { :detector :smokeDetects ?smokeDetected .
>        :detector :temp ?temperature .
>        FILTER (?temperature > 40 || ?smokeDetected) }
> 
> RESULTS:
>   under current semantics:
> [] fire:eek [] .

oops, did two runs, one with construct, (above results) and one with
select:
+-------------+-----------+
|smokeDetected|temperature|
|-------------|-----------|
|            1|      "314"|
+-------------+-----------+

>   if the type error passes through the disjunction there are no results.
> 
> Does this clarify the effect of || masking type errors?
> Is this effect now acceptable?
> Would you like clarifying wording in the spec?
> 
> > Yosi Scharf found also that this rule for union means that de  
> > Morgan's laws don't hold properly, making the  compilation and  
> > optimization of queries more difficult or impossible.
> > 
> > Tim Berners-Lee
> > MIT/CSAIL/DIG
> 



-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.