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

On 23 Jul 2010, at 17:46, Andy Seaborne wrote:
> 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.

correct. I had the impression that several people were unhappy with named 
graphs as we have them (pairs graph-name). My idea/suggestion was to try out
another definition which might be more what these people expect in an 
upwards compatible way with SPARQL1.0.

There is a reason, why I "don't like" the graph store being decoupled from the 
(default) dataset of a SPARQL endpoint: It means that they can be completely 
different a SPARQL endpoint can have an update interface, but the updates have no effect 
whatsoever on the queries I can do on that endpoint. That doesn't make sense to me, respectively, 
if I want to support that, then why not having a different endpoint for update and 
query in first place. I think coupling the default data set and the graph store makes sense 
in most cases and is intuitive.

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

yes.

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

Agreed. Let me make up the following "excuse" on the fly ;-)  
I wanted to put this definition on the table also in order to see whether 
such a definition could be updwards compatible with SPARQL1.0 or, resp. if 
we keep the SPARQL1.0 definition and RDF2 would adopt something closer to 
mine, whether that could work together... I agree, and had said that also 
in earlier mails to sandro, that it is indeed wiser to keep those 
kind of changes outside of SPARQL and for RDF2. 

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

yes. true, it also should work with the current def of dataset... 
in which my personal main concern about the the fact that dataset 
and graphstore used different definitions is settled. Or at least with that 
GS-1 definition I find the connection intuitive.

Axel

>  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 21:12:52 UTC