Re: Making progress on graphs

On 2012-05-16, at 15:20, Alex Hall wrote:

> On Wed, May 16, 2012 at 7:30 AM, Sandro Hawke <sandro@w3.org> wrote:
> On Wed, 2012-05-16 at 13:20 +0200, Guus Schreiber wrote:
> > On 14-05-2012 08:03, Pat Hayes wrote:
> > >
> > > On May 13, 2012, at 3:54 PM, Richard Cyganiak wrote:
> > >
> > >> Hi Ivan,
> > >>
> > >> On 13 May 2012, at 16:15, Ivan Herman wrote:
> > >>> it looks to me that Sandro's draft document:
> > >>>
> > >>> https://dvcs.w3.org/hg/rdf/raw-file/d96c16480e42/rdf-spaces/index.html
> > >>>
> > >>> would be a good way to 'settle' things (see [1]), too.
> > >>
> > >> Sandro's draft takes explicit position on a *all* issues, many of which are highly controversial. By bundling non-controversial and controversial issues all into one big package, this blocks progress on the sub-issues where we actually seem to all agree. So I repeat:
> > >>
> > >>
> > >> PROPOSAL: The abstract syntax for working with multiple graphs in RDF consists of a default graph and zero or more pairs of IRI and graph. This resolves ISSUE-5 (“no”), ISSUE-22 (“yes”), ISSUE-28 (“no”), ISSUE-29 (“yes”), ISSUE-30 (“they are isomorphic”), ISSUE-33 (“no”).
> > >>
> > >>
> > >> So far I have heard no objections to this.
> > >
> > > +1 to all of this. FWIW, I have been operating under these assumptions for at least the last two months.
> >
> > I've added the proposal from Richard to the agenda.  As a minimum we
> > should have straw polls on all the them, as proposed by Sandro early on
> > in this thread. Resolving them appears more controversial, although this
> > last remark from Pat is an important "data point" for me.
> 
> And, for the few lazy people who haven't read every message in this
> thread  :-)   I'm formally objecting to that proposal as written.   I
> read it as saying that quadstores and quad syntaxes would not be capable
> of storing this abstract syntax.  But I think quads are a very useful
> and widely used model, and it would be a serious mistake to exclude
> them.  Richard doesn't seem to think he is excluding them, so there may
> be a solution that just involves wording tweaks, but I can't see it
> right now, and Richard sent his regrets for today.
> 
> Just for the record -- quad stores are perfectly capable of storing datasets with empty graphs without losing the existence of those graphs. Nothing says that the internal data structures used by the quad store have to exactly match the structure of the dataset. All that matters is that the store is capable of reproducing the dataset when queried, exported, etc.
> 
> For instance, Mulgara (a quad store) uses an internal system graph to track the existence of all graphs that it stores. For an empty graph, there will simply be a quad recording the existence of that graph IRI in the system graph, and an absence of quads using that graph IRI in the fourth column.

Right, 4store, which technically a quad store can represent empty graphs too, though 5store can't. We've never needed an empty graph, so it's not been an issue.

We don't have a problem with the way SPARQL Datasets are defined either - you can create an empty graph, but it's OK for the store to purge it immediately. It's a good pragmatic solution.

- Steve

-- 
Steve Harris, CTO
Garlik, a part of Experian
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 653331 VAT # 887 1335 93
Registered office: Landmark House, Experian Way, Nottingham, Notts, NG80 1ZZ