Aklakan commented on PR #3511:
URL: https://github.com/apache/jena/pull/3511#issuecomment-3952953961

   @namedgraph
   
   >  [...] and then detecting at build time that it's not actually local 
storage is a round-trip through the wrong layer.
   
   DatasetGraph does not mandate local storage. As @afs noted before, at the 
core this is about facilitating low-level adapters (DatasetGraph) over 
high-level abstractions (third-party SPARQL engines/endpoints).
   
   The adapter system of this PR is about making *specifically* the 
`DatasetGraph` ecosystem work *consistently* and *efficiently* over different 
backends - including HTTP SPARQL endpoints. With ecosystem I mean the 
query/update builders and their use throughout Jena including assemblers and 
Fuseki.
   It gives users the option to write application logic on the DatasetGraph 
level that can operate on third-party backends - its the users that have to 
decide whether this abstraction fits their use case.
   
   Your proposal to abstract DatasetGraph with 
[SPARQLEndpoint](https://github.com/AtomGraph/Core/blob/master/src/main/java/com/atomgraph/core/model/SPARQLEndpoint.java)
 is simply the adapter in the other direction (high-level over low-level).
   
   p.s:
   The reason I mentioned Virtuoso is because it is quite well-known prior art 
that provides its custom `VirtDataset` implementation. It allows RDF operations 
to be carried out against a Virtuoso endpoint using Jena's Dataset API. [This 
mention is 8+ years 
old.](https://stackoverflow.com/questions/44011156/loading-and-querying-default-and-named-rdf-graphs-in-openlink-virtuoso)
 The problem is, that querying requires `VirtuosoQueryExecutionFactory` in 
order to bypass ARQ, thus tying application logic to Virtuoso. While this PR is 
not about Virtuoso, it addresses exactly this issue where its abstraction 
breaks.
    


-- 
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]

Reply via email to