On 09/06/15 17:01, [email protected] wrote:
On Jun 8, 2015, at 6:35 PM, Andy Seaborne <[email protected]> wrote:
less - there is no transactionality across the contained graphs.
(Model.graph transactions aren't connected to dataset
transactions)
Ah, glad I asked! {grin}
As far as model-as-views-of-datasets: is it true that all that is
needed for this is a good in-memory dataset?
It would be useful for working in-memory. For example default union
graph can bne made to work efficiently, as can dataset
transactions.
Okay, so it's more that having a good in-memory dataset would be
helpful here? I'm just trying to establish if you see the in-memory
dataset improvement as _blocking_ models-as-views or just that
models-as-views would be worth more and work better accompanied by a
better in-memory dataset.
Models-as-views already exists in TDB and it's general code
(oaj.sparql.coreGraphView).
So given a dataset implementation, providing the getDefaultModel,
getModel (named graph) is already done.
Union graphs needs a scope - a union of what? - which is a dataset. In
the general dataset case, that isn't provided; it would be "GRAPH ?g {
single triple pattern }" and some state to get the triple counting
right. If its a complete implement, then, like TDB, it can be done
better. TDB goes to one index, e.g. POSG, and does a "reduce" not a
distinct to get non-duplicates as required of a graph. "Reduce" is
cheap - it removed adjacent duplicates only.
What about datasets that are much too large for memory? Or impls
of Dataset that incur network latency in operation? Or do these
cases just imply the need for the right kinds of laziness in
views on Datasets?
Models from TDB are already views. public class GraphTDB extends
GraphView …
Cool. So we already have that laziness in hand in the form of
GraphView.
--- A. Soroka The University of Virginia Library
