On Wed, Nov 14, 2012 at 2:13 PM, Andy Seaborne <[email protected]> wrote:
> On 13/11/12 13:21, Reto Bachmann-Gmür wrote: > >> SPARQL: I would not deal with parsing SPARQL queries but rather >>> >forward them as is to the underlaying implementation. If doing so the >>> >API would only need to border with result sets. This would also avoid >>> >the need to deal with "Datasets". This is not arguing against a >>> >fallback (e.g. the trick Clerezza does by using the Jena SPARQL >>> >implementation) but in practice efficient SPARQL executions can only >>> >happen natively within the TripleStore. Trying to do otherwise will >>> >only trick users into use cases that will not scale. >>> > >>> >> +1 for sparql fastlane, some parsing is still needed to see if the query >> is >> against graphs that all come from one and the same backend and which one >> this is. >> > > I don't understand that (a lack of knowledge of zz probbaly) - what is the > parser looking for? The target for a query execution can be defined > separately from the query, and so the query string does not need analysis. > Sort of local version of protocol: endpoint + query. > You need to know to which backend to forward the query and if the query is against graphs from multiple backends it cannot be fastlaned. Reto > > Andy >
