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 05:02:54PM -0400, Eric Prud'hommeaux wrote:
> On Tue, Aug 02, 2005 at 04:01:25PM -0400, Tim Berners-Lee wrote:
> > 
> > On Aug 2, 2005, at 12:47, 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
> > 
> > 
> > False, note.
> > 
> > >>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 .
> > 
> > Should that be 0?
> 
> There is no way to report typeErrors encountered when testing the
> bindings in a particular solution. This is typical of query langs
> like XPath (as used in either in XQuery or XSLT) and SQL. The
> distinction between a "type error" and "suppressed", identified
> above, is unobservable.
> 
> I answered a slightly different question to demonstrate where the
> type error would have an observable effect.

As an experiment, I modified my SPARQL engine to not throw away
solutions simply because the FILTER was unable to execute on an
extended type. Instead, it either annotates the solution set to
say that some solutions were eliminated based on insifficient
knowledge about theinvolved datatypes or annotates those solutions
with the errors. A typical run looks like:

+-------------+-----------+----------------------------------------------------+
|smokeDetected|temperature|                                                    |
|-------------|-----------|                                                    |
|            1|      "314"|Unknown type ...degreesK encountered while calling >|
+-------------+-----------+----------------------------------------------------+

Every function or operator checks its arguments. If an unknown
argument type causes the function to fail, I used to throw an
exception which would ultimately eliminate that solution. For this
experiment, I annotate the solution, and let the test pass. This
was a slightly tedious because I had to differentiate between the
wrong parameters and unknown parameters.

Their are two obvious ways to report that some rows have been
eliminated, simply state the fact, perhaps including the count of
eliminated rows, or include them in the result set, with
annotations marking the suspect rows. Both would require expanding
the XML Report Format.

> > >*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 [] .
> > >
> > 
> > 
> > I suspect with no smoke detected the result would be no  results,  
> > when in fact the temperature is too high.   Please try it with 505K  
> > to make the point! :-)
> > 
> > (505K =  273+((451-32)*5/9)K )
> 
>     unagi:/home/eric$ units
> 2084 units, 71 prefixes, 32 nonlinear units
> 
> You have: 40 degrees C
> You want: degrees Kelvin
> Unknown unit 'Kelvin'
> You want: degrees K
> conformability error
>         0.6981317 A radian s
>         0.017453293 K radian
> 
> stupid units program
> 
> I was assuming that you meant degrees C; 273.15+40 < 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.