W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2011

Re: [Graphs] Fwd: Comments on "SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs"

From: Nathan <nathan@webr3.org>
Date: Fri, 18 Mar 2011 19:35:59 +0000
Message-ID: <4D83B41F.9010307@webr3.org>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
CC: Pat Hayes <phayes@ihmc.us>, RDF Working Group <public-rdf-wg@w3.org>
Andy Seaborne wrote:
> In g-box/g-snap/g-text, there is third concept which is g-snap and the 
> word "respresents" is used for g-box->g-snap (inc in Gavin's diagram) 
> but in AWWW a representation is the bits (g-text) returned.

If it helps any, there's a little noticed nuance in REST and the HTTP 
spec which speaks of two different things:


"resource representation"
   content+meta associated with a URI

Likewise we have a "g-box" and then a "named g-box", which gives us 
another layer of terms:

a "named g-box"
a "g-snap of named g-box"
a "g-text representation of a (g-snap of a named g-box)"

> Is g-snap->g-text is just a function of the content type?

It depends, and is more complex, on one level then yes a g-snap is 1-* 
with g-text. Many g-text's can encode the same g-snap, the bytes in each 
g-text will be different, likewise the content-type, encoding pattern 
different ways of writing the same graph), content-length etc.

However, when you add in the named dimension, then two identical g-texts 
  can differ only in the named-gbox they are associated with. That is to 
say, the association between g-text and the name of the g-box is 
critical, just as with http resources and their representations.

More about this here:



Received on Friday, 18 March 2011 19:37:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:04 UTC