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
