Re: Making progress on graphs


I'd like to return this thread to where it was started for. We seem to 
be going into corner cases quite a lot (ISSUE 22 - empty graphs -, for 
example). I think we should focus more on what we agree on. I listed the 
issues mentioned by Richard for the telecon of this week, but we didn't 
get to them, so they will be in next week's agenda. Here they are 
(slightly edited/extended version of Richard's original ones):

     ISSUE-5 Graph literals
     PROPOSED: Close ISSUE-5 ("Should we define Graph Literal datatypes?"),
     saying No, we should not.

     ISSUE-28 Syntactic nesting of g-texts
     PROPOSED: Close ISSUE-28 ("Do we need syntactic nesting of graphs 
(g-texts) as in
     N3?"), saying No, we do not -- they are useful, but we can provide 
the same
     functionality with datasets.

     ISSUE-29 Do we support SPARQL's notion of "default graph"?
     PROPOSED: Close ISSUE-29 (Do we support SPARQL's notion of "default 
     Yes, we do.

     ISSUE-30 Relation RDF Datasets with multiple graphs
     PROPOSED: Close ISSUE-30 ("How does SPARQL's notion of RDF dataset 
relate our
     notion of multiple graphs?"), saying we will use SPARQL's notion of 
RDF dataset as
     much of the foundation of our handling of multiple graphs.

     ISSUE-33 Mechanism to refer to sub-graphs and/or individual triples
     PROPOSED: Close ISSUE-33 ("Do we provide a way to refer to 
sub-graphs and/or
     individual triples?"), with the understanding that datasets can be 
used to refer to
     sub-graphs and individual triples.

Also, I would like to focus your attention to Sandro's document [1]. I 
tried to get discussion on the fact there is lot of stuff there we 
appear to agree on [2], but I miserably failed because my inadvertent 
subject line dominated the debate. Please comment on Sandro's document 
if you have time.



On 13-05-2012 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

Received on Friday, 18 May 2012 18:18:27 UTC