On Sun, Jan 1, 2017 at 6:59 PM, Andy Seaborne <[email protected]> wrote: > > > On 01/01/17 12:53, Martynas Jusevičius wrote: >> I am wondering if there is a way to "intercept" > > > Any thing can be intercepted with a custom OpExecutor.
Any examples? What should it extend/where should it plug in? > >> the HTTP request that >> is being generated by the SERVICE clause? > > > See Service.configureQuery for the use of serviceContext Yes I have used Context, but I don't think that is enough, as it does not provide full control of the request. (Again, I think the HTTP access would be much cleaner using JAX-RS API, but that is probably off-topic). >> As you might know, some triplestores (RDF4J, Dydra) provide an >> extension of the SPARQL protocol that allows sending query bindings >> separately from the query string. (Too bad it's not standardized and >> I'm not even able to find a good reference right now, but that is >> another topic). > > > What semantics do they have? Specifically, is it replace name-by-value > regardless? (so inside nested SELECT where it can be a "different" > variable)? What about aggregates? Does James' answer help clarify that? As for the original Sesame protocol, it's hard to find the spec these days (maybe it is deprecated?), but here's a short note about variable bindings with N-Triples-encoded values: http://graphdb.ontotext.com/sesame/system/ch08.html#d0e247 >> We have implemented it with a custom SPARQL client, but how can we >> plug it into the federated query execution? > > > You can have query string parameters in the SERVICE URL. For GET requests? What about POST body params, does Service take care of that? It should be possible to use POST for large query strings. And what about headers? Such as Cache-Control, for example?
