Re: Making progress on graphs

On Tue, 2012-05-15 at 11:13 +0100, Andy Seaborne wrote:
> 
> On 15/05/12 00:04, Sandro Hawke wrote:
> > On Mon, 2012-05-14 at 22:14 +0100, Richard Cyganiak wrote:
> >> Hi Sandro,
> >>
> >> On 14 May 2012, at 16:11, Sandro Hawke wrote:
> >>>> Your position is that you object as a matter of principle to resolving about half of the open issues, except if they're all resolved as a package. This is even though the proposed partial resolution supports your position and appears to have WG consensus.
> >>>
> >>> I'm not objecting _formally_, I just think it's unwise to approach our
> >>> work this way likely to lead to more wasted time.
> >>
> >> Whose time exactly?
> >
> > I guess that's a rhetorical question?  Any/all of us...
> >
> >>> I would object formally to it as phrased, because I think we need to use
> >>> a notion of datasets that's compatible with quads.     That is, Issue-22
> >>> should be No, not Yes.   CF the semantics of creating an empty named
> >>> graph in SPARQL 1.1.
> >>
> >> This confuses me. Both SPARQL 1.1 and SPARQL 1.1 Update support empty graphs (optionally in the latter), so allowing empty graphs both in the abstract syntax and in the concrete syntaxes surely is a requirement? Meaning ISSUE-22 should be Yes?
> >
> > Not really - that "optional" is key.  As I recall, this optionality was
> > put in because some SPARQL engines actually store quads, not datasets.
> > So SPARQL has the notion of empty name graphs, but implementations never
> > have to deal with them.  (eg, "An implementation MAY remove graphs that
> > are left empty after triples are removed from them.")
> 
> Empty named spaces can happen -- RDF allows the empty graph.

Of course.

> SPARQL Update still covers loading empty graphs or setting a named slot 
> to the empty graph.

Yes, that's fine.  It does not disagree with what I'm saying.

> The fact that SPARQL Update introduces a variation in empty graph 
> handling (empty named graphs can be dropped) is much more of an 
> implementation matter.   This is a much weaker statement than "no 
> support for".

Yes, indeed.   But it is also different from "MUST support".

> > If we followed your proposal and made datasets (with possibly-empty
> > named graphs) our basic unit, then people would no longer be able to use
> > quad-stores or quad syntaxes (like N-Quads) while conforming to our
> > specs.
> 
> The reality is that such systems are in use today.

Right, that's what I said.  Richard's proposal would make them
non-conformant RDF systems, or something like that, depending how we
define GRAPHs conformance.    

I'm strongly opposed to doing that.   I think it should remain okay
(standards-conformant) for people to use quad-based systems for doing
their GRAPHs work.

   -- Sandro

>  Andy
> 
>

Received on Tuesday, 15 May 2012 11:58:43 UTC