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

[GRAPHS] g-box - abstraction or concrete?

From: Nathan <nathan@webr3.org>
Date: Fri, 25 Feb 2011 19:04:10 +0000
Message-ID: <4D67FD2A.5000800@webr3.org>
To: Sandro Hawke <sandro@w3.org>
CC: public-rdf-wg <public-rdf-wg@w3.org>
Moving on to the next question that arises,

Sandro Hawke wrote:
> 1.  A "g-box" is a container, like a "set" data structure in
> programming.  It holds some RDF arcs, with their nodes. (Alternatively,
> it holds some RDF triples.).  G-boxes can overlap, sharing some of the
> same nodes and arcs.  Two g-boxes can happen to have the same contents
> (right now) while being distinct g-boxes. G-boxes contents can change:
> today a particular g-box might contain the triples { my:a my:b _:x.
> my:a my:c _:x }, and tomorrow it might instead contain { my:a my:b _:x.
> my:a my:c2 _:x }.
> * A g-box can exist without any name or persistent way of referring to
>   it; it can exist as a data structure in a running program, or I
>   suppose it can exists in someone's mind.  Long-lived g-boxes
>   probably SHOULD be given a preferred single working URL, but there
>   might be times when you do don't want to give it any, or when you
>   want to give it several URLs.

is a g-box a platonic abstraction or a concrete realisation then, as 
soon as you give a g-box a name, and duplicate it such that there are 
two copies both bearing the same name(s) that need synchronized, then 
does the g-box also become a platonic abstraction?

It appears to me that we have an idealized platonic abstraction here 
(named g-box), and then concrete realizations of those g-box's where 
their state is managed by processes via some abstract protocol which is 
(partially) materialized in various concrete protocols which manage the 
state of these abstract-g-box-shadows via messages / representations.

Real world example being a named-g-box which is replicated in two or 
more places.



Received on Friday, 25 February 2011 19:06:22 UTC

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