On further investigation this was some sort of change in behavior but was down to the interaction between our custom query executor which was intercepting the quad patterns and the MINUS
So any previous incorrect behavior was down to our custom executor and not ARQ as far as I can tell Rob On 7/4/12 12:42 AM, "Andy Seaborne" <[email protected]> wrote: >On 04/07/12 01:56, Stephen Allen wrote: >> On Tue, Jul 3, 2012 at 5:47 PM, Stephen Allen <[email protected]> wrote: >>> On Tue, Jul 3, 2012 at 5:08 PM, Rob Vesse <[email protected]> wrote: >>>> I've noticed what may be a regression in MINUS behavior but may be >>>>wrong. Long ago one of our developers wrote the following query as a >>>>test case: >>>> >>>> >>>> SELECT * >>>> >>>> WHERE { >>>> >>>> ?n0 ?n1 ?n2 . >>>> >>>> MINUS { <http://www.cray.com/n0-2> <http://www.cray.com/n1-2> >>>><http://www.cray.com/n2-2> .} >>>> >>>> } >>>> >>>> >>>> I.e. They are minusing a concrete triple pattern from some variables, >>>>prior to ARQ 2.9.2 this worked but from 2.9.2 onwards it doesn't >>>>(likely because of Paul Gearon's changes) >>>> >>> >>> I'm not clear on what you mean by "worked". What do you expect the >>> results to be? >>> >>>> >>>> Now I'm not sure if this should ever have worked since the spec says >>>>that a MINUS with no shared variables has no effect. I only >>>>discovered the query (which was buried away in some Spring context >>>>oh joy!) because bumping the ARQ version to the 2.9.3-SNAPSHOT to pick >>>>up some of mine and Andy's recent SPARQL TSV improvements caused this >>>>test to start failing. >>>> >>>> >>>> What is the expected behavior in this case? >>>> >>> >>> The working draft seems to address this directly [1], you should get >>> back all the triples in the default graph (as the MINUS evaluates to >>> no bindings and thus no solutions are eliminated from the LHS). >>> >>>> >>>> If this is a regression can someone open a bug and take a look at >>>>fixing this, if this isn't a bug and the new ARQ behavior is actually >>>>now correct let me know as a query like this should be added to the >>>>DAWG test suite so I'll send a formal comment (unless Paul/Andy just >>>>want to propose this at the next WG telecom themselves?) >>>> >>>> >>> >>> I tested the example in the working draft against both Fuseki 0.2.3 >>> (ARQ 2.9.2) and against Fuseki 0.2.4-SNAPSHOT (ARQ 2.9.3-SNAPSHOT) [2] >>> and got the results indicated in the spec. >>> >> >> Realized you said "prior to ARQ 2.9.2", so I tested against Fuseki >> 0.2.1-incubating (ARQ 2.9.0) as well, and I get the same results. >> > >Same here. I tried > >Jena 2.7.2 >Jena 2.7.1 >ARQ 2.8.{9,8,7,6} > >with a file of one triple and each time get the same results - one row >out, which is what I expect. > >I tried with data of > ><s> <p> <o> . ><http://www.cray.com/n0-2> <http://www.cray.com/n1-2> ><http://www.cray.com/n2-2> . > >also with data of one triple which is all the cases I can think of. > > Andy
