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
