I would be in favor of option 1, remove initial binding support all together. It is already fairly broken, and doesn't work for remote queries, while VALUES provides a standards-compliant mechanism to do what initial bindings used to do.
-Stephen On Fri, Aug 2, 2013 at 12:52 PM, Rob Vesse <[email protected]> wrote: > Hi All > > Holger's question ( > http://mail-archives.apache.org/mod_mbox/jena-users/201308.mbox/%[email protected]%3e) > about a regression in ARQs treatment of initial bindings raises an > interesting disconnect between the interpretation of SPARQL and the Initial > Bindings API. > > Initial bindings in their current form allows for users to essentially > change the semantics of a query in a non-intuitive way. Take his example > query: > > ASK { FILTER(?a = ?b) } > > Intuitively that query MUST always return false yet with initial bindings > in the mix the query can be made to return true, at least prior to 2.10.2 > which introduces a new optimizer which includes special case recognition > for this. > > The problem is that using initial bindings can fundamentally change the > semantics of queries in non-intuitive ways when I believe the intention of > the API was merely to allow for improved performance by guiding the engine. > > To me this suggests that initial bindings as currently implemented is > fundamentally flawed and I would suggest that we think about > re-architecting this feature in a future release (not the next release). I > believe there are probably several ways of doing this: > > 1 – Remove support for initial bindings on queries entirely (as we already > did for updates) in favor of using ParameterizedSparqlString > > 2 – Change initial bindings to be a pre-optimization algebra > transformation of the query > > As we've discussed previously in the context of ParameterizedSparqlString > there is potential to do the substitution at the algebra tree level rather > than at the textual level. This allows for stronger syntax checking and > actually changes the query appropriately. The problem with this is that it > doesn't work if we want to inject multiple values for a variable, hence > Option 3 > > 3 – Change initial bindings to be done by injection of VALUES clauses > > This approach is again by algebra transform and would involve inserting > VALUES clauses at each leaf of the algebra tree. So Holger's query with > initial bindings applied would be rewritten like so: > > ASK > { > VALUES ( ?a ?b ) { ( true true ) } > FILTER (?a = b) > } > > However this approach might get rather complex for larger queries and also > runs into issues of scope, what if we insert the VALUES clause inside of a > sub-query which doesn't propagate those initial bindings outside of it etc. > > 4 – Skip optimization when initial bindings are involved > > This is the easiest approach but we can't enforce this on other query > engine implementations and it could seriously harm performance for those > that use initial bindings extensively. > > There may also be other approaches I haven't thought so please suggest > anything that makes sense. Bottom line is that initial bindings in its > current form seems fundamentally broken to me and we should be thinking of > how to fix this in the future. > > Rob >
