[Fwd: +blank node identifiers was- Re: [Graphs] Fwd: Comments on "SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs"]

cc: sandro

there's either something wrong with this (specifically the bnode 
identifiers), or something in it which could lend to our work.

do triples or statements persist over time?
do named nodes?
do blank nodes?
a <p>aragraph in an html document?
a <p>aragraph in an html document with an @id?

can these things only be seen as persisting over time if there is a 
reference to use for those things from one time or conversation to the next?

does a g-box need to be a triple container over time which you can add 
triples to and from, and a g-snap being a snapshot of it's state? what 
if a named-g-box simply provides a scope for secondary level identifiers 
(fragment identifiers), or even a name which is associated with a set of 
representations and/or identifiers over time? (where identifiers would 
be fragment identifiers).

brains ticking over with this now.. relates to webnames and computations 
mails I've been jibbering about over the past few weeks..

best,
nathan

-------- Original Message --------
Subject: +blank node identifiers was- Re: [Graphs] Fwd: Comments on 
"SPARQL  1.1 Uniform HTTP Protocol  for Managing RDF Graphs"

Nathan wrote:
> 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.

Ahh, then blank node identifiers would be a property of the g-text, and
the g-texts can be associated with a named-g-box, which would surely set
blank node identifier scoping to the named-g-box level?

Received on Friday, 18 March 2011 21:57:34 UTC