Re: New Proposal (6.1) for GRAPHS

On Thu, 2012-03-29 at 09:25 -0700, Charles Greer wrote:
> I really like this solution and it seems to satisfy the use cases 
> familiar to me from when I actually worked a lot with RDF in the wild.
> 
> One thing I'm tripping over though --  The scope of a TRIG document or 
> RDF dataset in effect 'closes the world.'  Is the idea of "merge" only 
> within a TRIG document/dataset?
> 
> I can only see two ways to really assert a graph literal -- either by 
> sanctifying the boundaries of  a dataset, thereby making merges with 
> external data problematic, or by signing bytes.  Am I missing something, 
> as usual?

There's some misunderstanding here, yes.   Maybe you can talk through
some particular thing you imagine doing, involving merging and TriG, and
I'll be able to pick it up.   From what you've written, I'm confused.

Maybe I can clarifying by translating this TriG document:

        <u1>  { <a>  <b>  <c> }
        
into this English declaration:

        The URI 'u1' denotes something, and that thing has exactly one
        associated RDF Graph.   That associated RDF graph consists of
        one RDF triple, which we can write in turtle as "<a> <b> <c>".

So, perhaps it's more clear, now.  If you merged that with another TriG
document:

        <u1>  { <a>  <b>  <d> }
        
Then, trying to accept both documents at onces, you'd be saying:

        The URI 'u1' denotes something, and that thing has exactly one
        associated RDF graph.  In one document that associated graph is
        claimed to be the RDF triple "<a> <b> <c>", but in another
        document that graph is claimed to be the RDF triple "<a> <b>
        <d>". 
        
So, in this case, you can try to merge the documents, but when you do,
you find there is a contradiction, since there is only allowed to be one
associated graph, but in this case there are two different ones.

       -- Sandro

> Charles
> 
> 
> On 03/27/2012 07:23 PM, Sandro Hawke wrote:
> > I've written up design 6 (originally suggested by Andy) in more
> > detail.  I've called in 6.1 since I've change/added a few details that
> > Andy might not agree with.  Eric has started writing up how the use
> > cases are addressed by this proposal.
> >
> > This proposal addresses all 15 of our old open issues concerning graphs.
> > (I'm sure it will have its own issues, though.)
> >
> > The basic idea is to use trig syntax, and to support the different
> > desired relationships between labels and their graphs via class
> > information on the labels.  In particular, according to this proposal,
> > in this trig document:
> >
> >     <u1>  {<a>  <b>  <c>  }
> >
> > ... we only know that<u1>  is some kind of label for the RDF Graph<a>
> > <b>  <c>, like today.  However, in his trig document:
> >
> >     {<u2>  a rdf:Graph }
> >     <u2>  {<a>  <b>  <c>  }
> >
> > we know that<u2>  is an rdf:Graph and, what's more, we know that<u2>
> > actually is the RDF Graph {<a>  <b>  <c>  }.  That is, in this case, we
> > know that URL "u2" is a name we can use in RDF to refer to that g-snap.
> >
> > Details are here: http://www.w3.org/2011/rdf-wg/wiki/Graphs_Design_6.1
> >
> > That page includes answers to all the current GRAPHS issues, including
> > ISSUE-5, ISSUE-14, etc.
> >
> > Eric has started going through Why Graphs and adding the examples as
> > addressed by Proposal 6.1:
> > http://www.w3.org/2011/rdf-wg/wiki/Why_Graphs_6.1
> >
> >       -- Sandro (with Eric nearby)
> >
> >
> 
>

Received on Monday, 2 April 2012 15:36:43 UTC