[GRAPHS] g-box - abstraction or concrete?

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.

Discussions?

Best,

Nathan

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