Re: Making progress on graphs

On Sun, 2012-05-13 at 23:09 +0200, Antoine Zimmermann wrote:
> +1 to the proposal and to move forward one piece at a time.

I think our decisions should be choices between complete solutions or
pieces of complete solutions.

Otherwise we risk having no solutions, or only bad solutions, because we
constrained the solution space blindly.

Richard's proposal (with some minor tweaks in how he defined dataset
[1]) happens to be in line with my proposal, but I'm rather opposed to
it as a matter of principal; I don't see how chopping up the design
space like this is going to produce better results, and I'm quite
concerned it will make things worse.

Please, just paint complete pictures, showing how to address all the use
cases, or at least some interesting ones.  Then we can look at those
pictures and decide among them.

(Antoine, you kind of did this.  We've never talked about your
proposal.  I happen to strongly prefer mine, but yours did make sense.)

What we can do -- and maybe this is would be enough for what you want,
Richard -- is make non-binding strawpolls to try to understand where
people are coming from and what design features they are likely to
support.

   -- Sandro

[1] Specifically: can the IRIs occur more than once?  I assume we'd
agree not.  More controversially, can named graphs be empty?  I'd argue
no, in order to keep compatibility with quad stores.   SPARQL 1.1 Update
struggles with this, saying EG you can create an empty graph but it
might be instantly deleted.


> 
> Le 13/05/2012 22:54, Richard Cyganiak a écrit :
> > 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.
> >
> > Best, Richard
> >
> >
> >
> >> At the moment it seems to collect all the various issues that we
> >> have discussed with a fairly clear way of moving forward.
> >>
> >> Ivan
> >>
> >>
> >> [1]
> >> http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0178.html
> >>
> >>
> >>
> >>
> On May 13, 2012, at 16:59 , Richard Cyganiak wrote:
> >>
> >>> All,
> >>>
> >>> We've been talking our way up and down the design space for
> >>> multigraphs for a year now, with not much to show for it. We
> >>> still have not settled on a basic design.
> >>>
> >>> Once we do settle on a basic design, the real work only starts
> >>> since we need to nail down the details. This will take time. Our
> >>> charter says that all documents should go to LC *this month*, and
> >>> obviously we are nowhere near ready for this.
> >>>
> >>> So I think it's time to stop exploring the design space, and
> >>> start collapsing it by making decisions.
> >>>
> >>> Obviously there is still strong disagreement on many things when
> >>> it comes to multigraphs, but it seems to me that all proposals on
> >>> the table accept a basic *abstract syntax* that is quite similar
> >>> to the RDF datasets in SPARQL, and even the most adventurous
> >>> experiments don't really stray from that forumla. Therefore:
> >>>
> >>>
> >>> 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”).
> >>>
> >>>
> >>> RATIONALE: All proposals on the table are based on an abstract
> >>> syntax very similar to SPARQL's notion of an RDF dataset,
> >>> although there is no consensus on the semantics and the
> >>> terminology. Making a decision on the basic abstract syntax would
> >>> unblock the work, and allow various strands of required detail
> >>> work to proceed independently, hopefully leading to additional
> >>> resolutions to remaining questions, such as:
> >>>
> >>> • What's the formal semantics of the abstract syntax? •
> >>> Definition of the concrete syntaxes (N-Quads, etc.) • Describing
> >>> how to work with this in the Primer • What do call the pairs?
> >>> “Named graphs” or something else? • What to call the entire
> >>> thing? “RDF dataset” or something else? • Can blank nodes be
> >>> shared among graphs? • What additional terminology (rdf:Graph
> >>> etc) needs to be defined?
> >>>
> >>> Best, Richard
> >>
> >>
> >> ---- Ivan Herman, W3C Semantic Web Activity Lead Home:
> >> http://www.w3.org/People/Ivan/ mobile: +31-641044153 FOAF:
> >> http://www.ivan-herman.net/foaf.rdf
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>

Received on Sunday, 13 May 2012 21:29:11 UTC