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

Re: New Proposal (6.1) for GRAPHS

From: Charles Greer <cgreer@marklogic.com>
Date: Mon, 02 Apr 2012 14:00:48 -0700
Message-ID: <4F7A1380.1080701@marklogic.com>
To: Sandro Hawke <sandro@w3.org>
CC: Charles Greer <Charles.Greer@marklogic.com>, public-rdf-wg <public-rdf-wg@w3.org>
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.

Thanks for your willingness to understand my points --- I'm sure that my 
formal language will improve over time.


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


-- 
Charles Greer
Senior Engineer
MarkLogic Corporation
charles.greer@marklogic.com
Phone: +1 707 408 3277
www.marklogic.com

This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. Thank you for your cooperation.
Received on Monday, 2 April 2012 21:01:14 UTC

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