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 21:20:35 +0000
Message-ID: <4D83CCA3.2050001@webr3.org>
To: Sandro Hawke <sandro@w3.org>
CC: Andy Seaborne <andy.seaborne@epimorphics.com>, Pat Hayes <phayes@ihmc.us>, RDF Working Group <public-rdf-wg@w3.org>
Sandro Hawke wrote:
> On Fri, 2011-03-18 at 19:22 +0000, Andy Seaborne wrote:
>> Is g-snap->g-text is just a function of the content type?
> Well, probably, for our purposes, I think so.  
> There's a trivial case where it's not: the  arbitrary non-semantic
> variability in serialization, eg whitespace.  So, some notion of
> equivalence class of g-texts may be important.
> There's a related problem I don't know if we can or should address,
> which is how to deal with websites which use cookies or other
> information (IP address, browser sniffing, etc) to customize content.

I was going to raise that, it's where the "resource state" http/rest 
story and the rdf "snapshot" story both breaks down.

Perhaps we should just scrap that story early on and have Named-G-Box = 
( <u>, GB ) where GB = { gt1, gt2, gt3, ... }

Where gt* are g-texts, and GB is a g-box. A g-box being a set of g-texts 
over time. And of course a named-g-box is just a GB associated with a URI.

If we need g-snap, which I'm sure we do, then perhaps each g-text 
encodes/serializes a g-snap, and several g-texts may all 
encode/serialize equivalent g-snaps, but that requires g-snap equality 
to be determined.

O, actually I quite like that, then all g-snap's are anonymous abstract 
sets of rdf triples, and it's the set of g-texts (g-box) that is 
associated with a name.



Received on Friday, 18 March 2011 21:21:50 UTC

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