Ah, that makes my distinction pretty meaningless! This abstraction seems meant to rub out just such differences.
This does remind me of another potential nice small feature: a Stream<Triple> construct(Query query) method, maybe at first via QueryExecution::execConstructTriples. The AutoCloseable-ity of QueryExecution could pass through Stream's QueryExecution AutoCloseable-ity. With clever implementation eventually, some of the methods on Stream (e.g. filter) could get passed through to SPARQL execution. --- A. Soroka The University of Virginia Library On Aug 5, 2015, at 9:37 AM, Rob Vesse <[email protected]> wrote: > The main complicating factor is that clear and delete are only separate > operations if the storage layer stores graph names separately from graph > data which the SPARQL specification specifically do not require > > For storage systems like TDB where only quads are stored the existence of > a named graph is predicated by the existence of some quads in that graph > and so delete is equivalent to clear because if you remove all quads for a > graph TDB doesn't know about that graph any more > > The SPARQL specifications actually explicitly call this complication out > in several places (search for empty graphs in the SPARQL 1.1 update spec) > and various SPARQL Updates behaviours may differ depending on whether the > storage layer records the presence of empty graphs or not > > Rob > > On 05/08/2015 13:44, "[email protected]" <[email protected]> wrote: > >> Just a thought on "ergonomics": it might be nice to separate "clear" and >> "delete", so instead of RDFConnection::delete either clearing or deleting >> a graph depending on whether it is the default graph, you have finer >> control and can clear a non-default graph. >> >> --- >> A. Soroka >> The University of Virginia Library >> >> On Aug 4, 2015, at 6:21 PM, Andy Seaborne <[email protected]> wrote: >> >>> There's a note in the interface >>> >>> // ---- Query >>> // Maybe more query forms: querySelect(Query)? select(Query)? >>> >>> At the moment, the operations are the basic ones (the SPARQL protocols >>> for query, update and GSP). There's scope to add forms on top. >>> >>> void execSelect(Query query, Consumer<QuerySolution> action) >>> >>> is one possibility. >>> >>> Andy >>> >>> On 04/08/15 16:14, [email protected] wrote: >>>> Is this a little bit like Sesame 4's new Repository helper type? Not >>>> totally the same thing, but similar in that it's bringing a lot of >>>> convenience together around the notion of dataset? >>>> >>>> >>>> http://rdf4j.org/doc/4/programming.docbook?view#Stream_based_querying_an >>>> d_transaction_handling >>>> >>>> --- >>>> A. Soroka >>>> The University of Virginia Library >>>> >>>> On Aug 2, 2015, at 3:05 PM, Andy Seaborne <[email protected]> wrote: >>>> >>>>> Stephen, all, >>>>> >>>>> Recently on users@ there was a question about the s-* in java. That >>>>> got me thinking about an interface to pull together all SPARQL >>>>> operations into one application-facing place. We have jena-jdbc, and >>>>> jena-client already - this is my sketch take. >>>>> >>>>> [1] RDFConnection >>>>> >>>>> Currently, it's a sketch-for-discussion; it's a bit >>>>> DatasetAccessor-like + SPARQL query + SPARQL Update. And some >>>>> whole-dataset-REST-ish operations (that Fuseki happens to support). >>>>> It's a chance to redo things a bit. >>>>> >>>>> RDFConnection uses the existing SPARQL+RDF classes and abstractions >>>>> in ARQ, not strings, [*] rather than putting all app-visible clases >>>>> in one package. >>>>> >>>>> Adding an equivalent of DatabaseClient to represent one place would >>>>> be good - and add the admin operations, for Fuseki at least. Also, a >>>>> streaming load possibility. >>>>> >>>>> Comments? >>>>> Specific use cases? >>>>> >>>>> Andy >>>>> >>>>> (multi-operation transactions ... later!) >>>>> >>>>> [*] You can use strings as well - that's the way to get arbitrary >>>>> non-standard extensions through. >>>>> >>>>> [1] >>>>> https://github.com/afs/AFS-Dev/blob/master/src/main/java/projects/rdfco >>>>> nnection/RDFConnection.java >>>> >>> >> > > > >
