Andy,
Great, thanks! Using 0.2.5-SNAPSHOT is working for me in my queries, with the original BIND interpretation. -Elli ________________________________ From: Andy Seaborne <[email protected]> To: [email protected] Sent: Wednesday, September 19, 2012 2:37 PM Subject: Re: Change in execution order between Jena 2.7.2 and 2.7.3 On 19/09/12 18:55, Elli Schwarz wrote: > I've been following this email thread with great interest, as well as the > emails to the SPARQL Working Group comments regarding BIND semantics. I use > BINDs heavily in my queries, and when I upgraded to Jena 2.7.3 I noticed that > many of my queries no longer worked properly, so I reverted back to using > Jena 2.7.2 (and Fuseki 2.3.0) until the issue was sorted out. > > > I see that the SPARQL working group has now clarified how BIND should work, > and that it reverted the changes made in Last Call 3, so my understanding is > BIND will work similar to the way it worked in Jena 2.7.2. Is there a > timeline for when a new version of Jena/Fuseki will be released that will > contain the fix for BIND? There are several bug fixes I needed that were > fixed in Jena 2.7.3, but since I had to revert I don't have these fixes > anymore. > You can use the development SNAPSHOT build to ensure that what you expect is there. Testing development builds helps prepare for releases. https://repository.apache.org/content/repositories/snapshots/org/apache/jena/ Andy > > Thank you, > > Elli > > > > ________________________________ > From: Holger Knublauch <[email protected]> > To: [email protected] > Sent: Wednesday, August 15, 2012 3:20 AM > Subject: Re: Change in execution order between Jena 2.7.2 and 2.7.3 > > On 8/13/2012 5:20, Andy Seaborne wrote: >> On 12/08/12 02:46, Holger Knublauch wrote: >> ... >>> but we and our customers have an unknown number of queries in >>> production >> ... >> >> TQ gets Jena for free. > > Yes and this is greatly appreciated. You guys are doing an amazing job. We > have built quite an empire on top of that. You will understand why I am > especially sensitive to surprising changes to the foundation of our software > stack. Please accept my apologies if I sounded too frustrated. > >> What would help is if TQ tested against the nightly snapshot builds >> especially just before a release. The project makes available development >> builds at all times so we can deal with such issues early, before a release. > > This would be good, but would be limited to cases in which the Jena API > itself remains stable. Usually there are always some API changes that won't > even make our stuff compile without changes. This plus the overhead of > setting up the infrastructure has prevented us from doing continuous testing. > >> >>> I believe TQ will need to raise this issue with the SPARQL 1.1 WG >>> again, although it seems we are very late in the process. >> >> You are, of course, welcome to. >> >> Referring to specification text would strengthen your case. Referring to >> implementation bugs is, IMO, not a strong case. They happen, that's life. >> >> Using the sub-query form will remove duplicating BIND statements. >> Sub-queries allow applying BIND after FILTER. > > As you have seen I have written to the WG. From a user's perspective, I > believe > > { > [Anything] > BIND (... AS ?x) > } > > should be equivalent to > > { > SELECT (... AS ?x) > WHERE { > [Anything] > } > } > > But let's see what comes out of the WG mailing list discussion. > > Thanks > Holger > > >> >>> And yes, optimizing the FILTER placement would be great and would >>> remove some of the pain and allow query authors to improve query >>> performance. >> >> I've raised JENA-293 to track this optimization. Please submit a patch. >> >> https://issues.apache.org/jira/browse/JENA-293 >> >>> >>> Thanks, Holger >> >> Andy
