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