Re: Making progress on graphs

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

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.

In contrast, if we make make datasets-with-no-empty-named-graphs our
basic unit, then N-Quads and quadstores could conform.   Systems which
want to support empty named graphs (eg all the other SPARQL engines) are
free to do so -- we just don't force everyone to do that.

> >> In the meantime, the editors of the syntax, model and primer documents are (to slightly exaggerate) twiddling their thumbs waiting for some decisions to be made. So that they can start work on grammars, examples, and systematic reviews of other WG's related specs.
> > 
> > And your proposal clears that roadblock?  I don't see how.
> 
> It wouldn't be smart to spend time working on an N-Quads grammar before we know whether we will have to support nested graphs.

*shrug* on this one.   (having been working on it over the weekend; it was a risk I thought worthwhile.)

> It wouldn't be smart to spend time writing up multigraph examples for the Primer before we know whether we will have graph literals.

I don't think it makes sense to include GRAPH stuff in the primer until
we're a lot farther along with it, possibly after Last Call.

> It wouldn't be smart to spend time reviewing PROV-WG's work before we know whether we will have default graphs.

I think we'll need more than your proposal to really evaluate their
work, but understanding their work is helpful in any case.  (I'm feeling
bad about neglecting this, it's just been too many perspectives to put
in my head at once.)

> A considerable amount of uncertainty (although not all of it) in these areas would be removed by the proposed resolution.

I guess I'd say it removes about 30% of the uncertainty.

Anyway - if we don't require support for empty named graphs, I wont
oppose the proposal, so it may not be worth arguing more about that.

> >> This is in the month when, according to the charter, we were supposed to go to LC.
> > 
> > I'm well aware of the timing.   That's why a large part of why I've been
> > putting in very long hours on RDF-WG stuff in recent weeks.
> 
> And I appreciate it.
> 
> > I don't think it's clear to most of us how each of these
> > issues ties in with a solution. I think some issues are controversial
> > or non-controversial based on gut feelings, not good data.   I know
> > that's how it's been with me until recently.
> 
> Well, Sandro, I'll be completely honest: I have not seen you argue with data. 

The tool I've been trying to argue with is plausible solutions to the
use cases.  I'm opposed to any design that can't provide these.  If we
had several designs that had these, then there'd be more of a basis for
argument.

> And in the positions of most WG members I don't see gut feelings but concerns about compatibility with existing specifications and implementations.

That's there, too, but I don't see that providing enough insight to make
these decisions soundly.    

> > Frankly, I think the best path forward would be to close all the GRAPHs
> > issues without prejudice [1], open a few highlighted in my draft, and
> > publish it as a FPWD.  Then move forward from there, opening and closing
> > issues against that draft as a baseline.
> 
> What is the rationale for publishing this as a W3C document at all? 

As usual, to give us a stable point to work from.   Everyone can see it,
examine it, think about it, and then we can talk about what to change
about it.    A straw proposal, if you like.

Without it, it's much harder to make progress or see progress, I think.
(cf W3C Heartbeat Requirement)

> It seems to me that all the normative bits would belong into the respective syntax, model, semantics and schema documents.

I'm not sure where it best belongs long term -- it might make sense to
keep thinking about it as a separate extension.  I'm agnostic about this
for now (and that's what I put in the ED Status Box).

In any case, I think it makes sense to keep in one place for now -- with
a small number of editors willing to keep it internally consistent --
until we have rough consensus on the whole thing.   Then we can split it
up and integrate it with the other docs, if we think that's best for the
folks using our specs.   I think if we split it up now, it'll be much
harder for people to understand the proposal.

>  What's left is some stuff for the Primer and some UC&R stuff.
> 
> Assuming we take this course of action, when do you think this would yield some binding resolutions that would allow work like the items mentioned above to proceed?

Well, publishing a WD provides a kind of general resolution about the
things it covers, right?  When we agree to publish, we're agreeing that
the text of the spec represents our current thinking, and that any place
we're not feeling pretty comfortable is pointed out with an ISSUE. 

Another way to look at the with-prejudice and without-prejudice thing is
about how carefully we look at an issue, how much time we spend on it.
If we decide on something quickly, then it's easy to re-open, because
there's surely some information we didn't consider.   So my saying
"let's close all of them, and only re-open what we need for FPWD" kind
of implies "without prejudice" because we wouldn't be listing all the
arguments on either side of each one.

> How does making some binding resolutions on the non-controversial issues, before throwing out the rest with prejudice, jeopardize anything, or waste time?

I don't quite understand this question.  Perhaps it's unnecessary in
light of what I've said above.

    -- Sandro


> Thanks,
> Richard
> 
> 
> 
> 
> >    I think that will give us a
> > sense of progress and actually give us traction.
> > 
> >   -- Sandro
> > 
> > [1] Normally when issues are closed, we say they cannot be opened again
> > unless there is new information.   In this case, I suggest we simply
> > clear the slate and start again, because those issues are coming from so
> > many different directions.
> > 
> > 
> > 
> > 
> 
>

Received on Monday, 14 May 2012 23:04:09 UTC