On 09/12/15 13:22, A. Soroka wrote:
I now understand a little what I did not understand at all a few
months ago: how very hard the MRMW problem for RDF datasets is.
:-)
So
I’ve been casting about for some simple ways to deliver cheap and
very limited forms of MRMW that might provide some “bang for the
buck” for Jena users. One to which I keep coming back is the idea of
a dataset with per-graph transaction locking.
That might combine well with using the Graph Store Protocol for graph
management where default union graph is common.
Another locking strategy is "graph node" i.e. a subject-in-a-graph and
all its in and out links. Then it's MW when working on different parts
of a graph. Different characteristics.
In other words, a
dataset wherein each named graph has a SW lock and the dataset as a
whole can support MRMW, as long as every writer is working in a
different graph.
What isolation levels do you want to support? With MW, this now matters.
If it is "read committed" even BGPs are unstable, not if it's SW per
graph though a variation that is unstable is:
SELECT * {
GRAPH <g1> { ... }
GRAPH <g2> { ... }
}
and also default union graph.
Counting and aggregates generally, can yield answers that never exist in
any snapshot of the whole database.
That's not to say it's a bad idea - but that what "it" is matters.
Some examples of where this could be helpful:
* Linked Data persistence backends in which the graph about each
HTTP-accessible resource is stored in a separate named graph.
SPARQL graph Store Protocol.
* Fast loading of quads from a sorted file (using multiple cursors).
Different problem? That's threading inside a single SW?
* Persistence backends that use RDF (like the one that Claude
recently mentioned on users@) if they can be configured to take
advantage of named graphs.
Does this sound like it would be useful enough for me to spend some
time working out a design (after finishing what’s needed to
RC-release the MR+SW in-memory dataset)? I know we can never be sure
about what users will find handy until they start relying on it and
praise it and complain about it… {grin}
--- A. Soroka The University of Virginia Library
Andy
