namedgraph commented on PR #3511: URL: https://github.com/apache/jena/pull/3511#issuecomment-3951555704
@Aklakan sorry, but I have to push back on this again :) The uniform local/remote execution you're after can be achieved more simply by putting the abstraction boundary at the **SPARQL Protocol** level rather than the `DatasetGraph` level. `DatasetGraph` is a storage abstraction (quads, add/delete/find). Wrapping a remote SPARQL endpoint as a `DatasetGraph` and then detecting at build time that it's not actually local storage is a round-trip through the wrong layer. For reference, [AtomGraph Core](https://github.com/AtomGraph/Core) solves this with a simple [`SPARQLEndpoint`](https://github.com/AtomGraph/Core/blob/master/src/main/java/com/atomgraph/core/model/SPARQLEndpoint.java) interface that maps directly to the SPARQL Protocol spec. The local implementation executes against a Jena `Dataset`; the [`remote.SPARQLEndpoint`](https://github.com/AtomGraph/Core/blob/master/src/main/java/com/atomgraph/core/model/remote/SPARQLEndpoint.java) extends it with `getURI()` and `getSPARQLClient()` and delegates over HTTP. Polymorphism at the protocol level keeps things straightforward. This also handles your Virtuoso `bif:contains` case naturally: the remote implementation passes the query string straight to the endpoint without touching the ARQ parser, because it operates at the HTTP level. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
