On 31/07/14 10:33, Rob Walpole wrote:
Thanks for the explanation Andy. I'm still a bit confused about what is
meant by the default graph though TBH... I thought starting Fuseki with
"tdb:unionDefaultGraph true" might mean that queries and updates would work
without specifying the graph name? It certainly seems to be true of queries
(Elda just works with no change) - but perhaps this is because only the
WHERE clause is affected by this configuration?
unionDefaultGraph only applies to queries - as far as the query engine
is concerned, the default graph of the dataset is the (computed on the
fly) union.
For update, the default storage graph is always the target for default
graph changes.
The unionDefaultGraph is read-only as well as query only -- changes
would have to go into some graph somewhere and it gets complicated (tm)
if there is a delete of a triple which is in two named graphs what
should happen? if there is a add, where does it go?
It works by the acess to the
(S P O) becomes the quad pattern (G=ANY S P O)
then the results are reduced to set semantics (only one triple revealed).
(S P O) == distinct (? S P O)
except its excessively smart and does a "reduce" nowadays, not a
"distinct" because the TDB solver knows which index will be used and
it's always one with the graph name in the last slot so repeated triples
across graphs are adjacent. "distinct" with no hints is expensive
(takes space).
As for updates.. if we use the Fuseki command line s-post tool this also
appears to work but only if we specify the graph name to update as a
parameter (i.e. the named graph URI and not "default") so I guess this is
somehow modifying the underlying update?
Example?
s-post, and all the s-* tools, do not modify the request. They are just
more convenient ways to write the HTTP operations. You can use curl or
wget if you want. Makes no difference to the server - there are only
HTTP requests.
As we have written our own Fuseki
client to use the SPARQL protocol it seems we need to modify the updates
that go through here to include WITH.. but we will bite the bullet as you
suggest :)
Changing the DB graph structure is much like changing the SQL schema ... :-|
Andy
Cheers
Rob
On Wed, Jul 30, 2014 at 6:12 PM, Andy Seaborne <[email protected]> wrote:
On 30/07/14 16:10, Rob Walpole wrote:
Hi Andy,
What's the problem with using WITH?
The problem is that we are want to switch our default dataset from one
using a single unnamed graph as the default graph to one using two named
graphs as the default graph. We have figured out how to do the data part
of
the switch but we already have a lot of SPARQL update queries in various
places which we wanted to avoid having to modify.
I'd bite the bullet and change them -- it's style thing but hacking the
protocol to effectively modify operation makes for long-term confusion
where someone maintaining one of those updates isn't aware of the layer
that modifies the operation via the protocol.
Doing updates really does presume knowing the physical dataset. Your
updates using USING were successfully changing the (empty!) default graph.
I was hoping that the
using-named-graph-uri query parameter would just do this - but I
understand
from your explanation and re-reading the spec that it only affects the
WHERE clause. This seems slightly odd as the spec implies to me it is an
alternative to WITH...
"""
The RDF Dataset for an update operation may be specified either in the
operation string itself using the USING,USING NAMED, and/or WITH keywords,
or it may be specified via the using-graph-uri and using-named-graph-uri
parameters.
"""
..but I guess it just cannot be used with a WITH.
USING etc behaves like FROM -- in TDB, that means pick out of the dataset
but in a different implementation it may be pick off the web. WITH always
picks from the dataset -- it is syntactic sugar for teh 2*GRAPH form.
WITH is a different mechanism - it does specify a dataset for the update,
one where the default graph is different for both access (WHERE) and change
(DELETE, INSERT).
But WITH is not a form of USING - each has it's own use and they are
different.
What's sort of missing is a protocol argument "with-graph-uri".
Andy
Cheers
Rob
