W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > October 2010

Re: Abstract syntax for updates

From: Pat Hayes <phayes@ihmc.us>
Date: Fri, 15 Oct 2010 12:37:16 -0500
Cc: Eric Prud'hommeaux <eric@w3.org>, "public-rdf-dawg-comments@w3.org Group Comments" <public-rdf-dawg-comments@w3.org>, rjh06r <rjh06r@ecs.soton.ac.uk>, Axel Polleres <axel.polleres@deri.org>
Message-Id: <A57FA001-05A2-4BD6-9166-7932D83C176A@ihmc.us>
To: Richard Newman <rnewman@twinql.com>

On Oct 13, 2010, at 11:53 AM, Richard Newman wrote:

>> The basic issue is that an RDF graph is defined to be a mathematical set of triples, and sets do not have state. It is impossible to modify a set, or add triples to a set or delete triples from a set, since any such additions or modifications will result in a different set. A set is defined by its members, and has no other criteria of identity. Thus it does not make sense to speak of 'adding A to {B, C}'. One can construct the set {A, B, C}, of course, but this set cannot be identical with the set {B, C} unless A is identical to one of B, C. 
> It might be worth drawing some terminology or an approach from Rich Hickey's work on separating value and identity:
>  http://clojure.org/state
>  http://www.artima.com/articles/hickey_on_time.html
> A SPARQL Update operation can, in this interpretation, be viewed as computing a new value (immutable: a set of triples) from the old value of an identity, and associating this as the new value of the identity (the "graph" or triple store that you're "modifying").

Yes, quite, although my point was that we cannot call this thing an RDF graph, because that terminology has been normatively defined to be an immutable set. So we need a new terminology. The more I think about "RDF resource", the better it gets, BTW. It is any information resource which emits RDF representations when poked; and an RDF representation is anything which is an encoding of an RDF graph. 

> Having spent quite some time programming with Clojure, the mainstream conflation of value and identity now appears intuitively ridiculous, and an obvious source of problems.

Funny how obvious these things are in hindsight, isn't it?


IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Friday, 15 October 2010 17:37:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:11 UTC