W3C home > Mailing lists > Public > public-rdf-wg@w3.org > May 2012

Re: Making progress on graphs

From: Richard Cyganiak <richard@cyganiak.de>
Date: Mon, 14 May 2012 22:14:47 +0100
Cc: RDF Working Group WG <public-rdf-wg@w3.org>, W3C Chairs of the RDF WG <team-rdf-chairs@w3.org>
Message-Id: <A2A99AF4-95E3-4B73-9F8D-B0C730C605E7@cyganiak.de>
To: Sandro Hawke <sandro@w3.org>
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 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?

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

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

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

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

>> 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. And in the positions of most WG members I don't see gut feelings but concerns about compatibility with existing specifications and implementations.

> 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? It seems to me that all the normative bits would belong into the respective syntax, model, semantics and schema documents. 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?

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

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 21:15:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:48 GMT