Re: Mutability and graphs [was: Re: page about the term "named graphs"]

The message is only about the graph store - other points in a different 
message.

Overall remarks:

What is the advantage of RDF dataset the same as Graph Store?

I don't see any reason to make any change unless there is an advantage 
to doing so and you don't present any.   All you say is:

> It seems that if we
> could do that, we'd also be able to use the same definition for
dataset and
> graphstore (the distinction being something I don't really like, but,
given the
> current definition of dataset seeming indeed to be inevitable)
>

so "use same definition" and "don't like".

But we can only use the same definition if we change the SPARQL 1.0 
definition.


There is an alternative version of a graph store where the slots hold 
mutable containers of triples.  In practice, that is what systems do. It 
has a not-so-small issue of the same triple-container referenced by two 
names - and both slots may be used in the same update operation - which 
is why I showed a version that didn't have this problem. Putting graph 
values in slots and assigning graphs to slots at the very end of the 
operation avoids needing to define all the overlap issues of shared 
mutable containers.

The graph store is still itself mutable as you can add and remove named 
slots+graph value them via CREATE and DROP.

So we have 3 ways here:

GS-1: A graph store is a container of a datasets and operations change 
the state of the graph store from one dataset to another.

GS-2: A graph store is a mutable container with one unnamed and zero or 
more named slots, each slot holds a graph (value).

GS-3: A graph store is a mutable container with one unnamed and zero or 
more named slots, each slot holds a mutable container of triples.

GS-1 is the way you describe at the end of your message.  More below.

None of these require changing the SPARQL 1.0 RDF dataset definition. 
All require a simple graph store -> dataset mapping.

> which avoids the indirection of defining named graphs
> as pairs instead of graphs:

Why avoid it? What's the problem you are solving by this?
Or are you really trying to get a blessing for the direct naming of 
graphs?  Surely that is for a future RDF WG? If you want to alter SPARQL 
1.0 about named graphs, then I think you must get buy-in from the 
community, not use the new WG as chance to rework something. Otherwise 
it is just change for changes sake.

As far as I'm concerned, defining directly named graphs that will be in 
scope for any RDF-Next WG and is outside the (moral) charter for SPARQL-WG.

> I think "Graphstore" could also use this definition of dataset,
meaning that a graphstore
> is defined by a sequence of datasets DS_0 to DS_n determined by a
sequence of
> updates

NB: This does not use mutable datasets.

That style of definition works with declarative RDF dataset as defined 
by SPARQL 1.0 because at no point are you changing (mutating) the 
dataset.  You are assigning a new state to the graph store and the state 
is a dataset.  The graph store has one slot, it changes the value in 
that slot from one dataset to another.  GS-1 above.

	Andy

Received on Friday, 23 July 2010 16:46:39 UTC