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

Re: New Proposal (6.1) for GRAPHS

From: Arnaud Le Hors <lehors@us.ibm.com>
Date: Tue, 3 Apr 2012 22:09:31 -0700
To: Sandro Hawke <sandro@w3.org>
Cc: public-rdf-wg <public-rdf-wg@w3.org>
Message-ID: <OF82A71699.7131FDB6-ON882579D6.001AED1D-882579D6.001C571D@us.ibm.com>
Hi Sandro,
I have to say that my expectation was similar to Charles's. I guess it's a 
matter of deciding whether <u1> { <a> <b> <c>  } defines the <u1> graph in 
its entirety, as containing one triple, or merely states that the triple 
<a> <b> <c>  is part of graph <u1>.

I'm not saying it should be the latter rather than the former, just that 
it's not obvious.
See below for more on that.

Sandro Hawke <sandro@w3.org> wrote on 04/02/2012 05:57:13 PM:

> From: Sandro Hawke <sandro@w3.org>
> To: Charles Greer <cgreer@marklogic.com>, 
> Cc: Charles Greer <Charles.Greer@marklogic.com>, public-rdf-wg 
> <public-rdf-wg@w3.org>
> Date: 04/02/2012 05:57 PM
> Subject: Re: New Proposal (6.1) for GRAPHS
> 
> On Mon, 2012-04-02 at 14:00 -0700, Charles Greer wrote:
> > Thanks for responding Sandro.  I think that what I'm finding 
difficult, 
> > or at least a significant departure from RDF as I have understood it 
in 
> > the past, is that this TRIG document
> > 
> > <u1> { <a> <b> <c> . <d> <e> <f> }
> > 
> > is not equivalent to these n-quads:
> > 
> > <a> <b> <c> <u1>.
> > <d> <e> <f> <u1>.
> > 
> > Or rather, you now need a document structure around n-quads as well in 

> > order to provide the context in which rdf knows that these triples, 
and 
> > only these triples, constitute the graph <u1>.
> > 
> > I had previously thought that RDF was a data model that didn't need 
any 
> > notion of 'document' to work.  I'm not sure how another assertion that
> > 
> > { <u1> a rdf:Graph }
> > 
> > can assert the boundaries of <u1> unless either the { } syntax does 
more 
> > than it appears to, or the document is a harder scope boundary than I 
> > would have expected.  If the document has some relationship to scope, 
I 
> > think that should be made explicit.
> 
> Two main points:
> 
> 1.  That rdf:Graph declaration is different thing.  It changes how <u1>
> relates to the graph, but in a semantic (not syntactic) way.  It can be
> in a different document, or deduced by the use of some predicates, or
> known a priori by a data consumer.  Knowing it entitles the consumer to
> see that <u1> actually identifies the graph directly, rather than just
> being a label for the graph.     This might matter if we also know <u1>
> dc:licence ...SomeLicensingTerms....   Is it the graph that's licensed,
> or something else?     There are some use cases that suggests this
> distinction is important, but if it turns out not to be, it's not bad,
> people will just not use rdf:Graph declarations much.
> 
> 2.  Whether or not your trig example and your n-quads example are
> equivalent depends on your reading of n-quads.   This extends to your
> reading of SPARQL as well.     My understanding is people are somewhat
> informal about this, but they generally do expect that once they've seen
> the whole trig file, or the whole n-quads file, or searched the whole
> SPARQL end point, that they've seen all the triples in the graph with
> that name/label.
> 
> As a social test case, we could tell people this SPARQL query is run:
> 
>     SELECT ?s ?p ?o 
>     WHERE GRAPH <http://g1.example.org> { ?s ?p ?o }.
> 
> and that we got three result bindings back: 
> 
>     ?s  ?p  ?o
>     === === ===
>     <a> <b> 1.
>     <a> <b> 2.
>     <a> <b> 3.
> 
> Then we ask them: "According to this query, how many triples are in the
> graph known to that endpoint as 'http://g1.example.org' ?"
> 
> What do you think they'll say?
> 
> I think most folks will say, "Three", even if you ask them to think
> again and be pedantically precise.
> 

I agree that's what they would say but primarily because you said: "in the 
graph known to that endpoint"
This is a critical element which isn't apparent in a mere statement like:

<u1> { <a> <b> <c> . <d> <e> <f> }

Which doesn't say anything about where it comes from and whether it's 
complete or not.

This being said, I can get used to having it the way you suggest. 
Especially when the graph name comes first. If we had: { <a> <b> <c> . <d> 
<e> <f> } <u1> I would think differently.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group


> I think that means they're using the complete-graph semantics I'm
> suggesting.  If they were using partial-graph semantics, they'd have to
> say, "Three or more".
> 
> You see what I'm saying?   When we have a complete protocol interaction,
> via SPARQL, or transmitting a trig or n-quad files, I think the usual
> assumption is that *all* the triples in the named graph are being sent,
> not just some of them. 
> 
> I understand sometimes it would be nice to store/transmit just part of
> some named graph.   But, as I discussed in a message a couple of minutes
> ago, I think we have to pick one or the other, and I think the
> complete-graph approach is better.  It's pretty easy to convey partial
> graphs if we define the complete approach.
> 
> (I suppose if we defined the partial-graph approach we could transmit
> complete graphs by transmitting partial graphs and including a
> triple-count as metadata, so you know it's complete.   I guess that
> would work, but it seems to me to be optimizing for the much-less-common
> case.)
> 
> Coming back to:
> 
> > I had previously thought that RDF was a data model that didn't need
> any 
> > notion of 'document' to work. 
> 
> Yeah, it depends what you're doing with it.   There's a lot you can do
> with RDF without paying any attention to what documents particular bits
> of RDF were found in, but I think most of the Graphs use cases involve
> situations where you do need to pay attention to these document
> boundaries. 
> 
> > Thanks for your willingness to understand my points --- I'm sure that 
my 
> > formal language will improve over time.
> 
> It's a long process.   :-)    Interesting, it seems to be helped by
> arguing.
> 
>     -- Sandro
> 
> > 
> > Charles
> > 
> > 
> > 
> > On 04/02/2012 08:36 AM, Sandro Hawke wrote:
> > > 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 Wednesday, 4 April 2012 05:10:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:03 UTC