Re: Making progress on graphs

On Thu, 2012-05-17 at 15:27 +0100, Steve Harris wrote:
> 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.

So, what should an app developer do, if they want their code to be
portable between different sparql engines?

(answer: they should avoid using empty named graphs.  right?)

    -- Sandro

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

Received on Thursday, 17 May 2012 20:35:47 UTC