Re: Generic "Graph" Use Cases

On 7 Mar 2011, at 15:05, Nathan wrote:
> Nathan wrote:
>> Richard Cyganiak wrote:
>>> How about this: Let's assume I have a g-box that for whatever reason has been “sealed” and made immutable. Is there any RDF statement that you'd possibly like to make about this immutable g-box that you wouldn't want to make about the g-snap sealed therein, or vice versa?
>> no :) a sealed g-box is perfect
>> now all we need is a way to seal the state of a g-box yesterday, which is in a different state today.
> 
> and of course, pass by value rather than reference (so to speak) - which is the primary g-snap case, so you don't have to go looking something up, only to find it's either gone or changed, or because it's entirely impractical to mint x many URIs and host x many persistent docs, when you could just quote, annotate and send.

Thanks, that helped.

I like the way how an analogous case is handled on the Web: You can't really name representations on the Web, but you can set up an immutable single-representation resource and name that. Then you use information outside of the protocol -- e.g., links in the representations -- to organize the different resources in a way that allows clients to understand how they relate. This is how you can have versioning on the Web without stepping outside of the basic URI/resource/representation schema. And if you like, then you can still standardize some extension that makes the relationships explicit on the protocol level, cf. Memento.

Immutable graphs and pass-by-value can be done in the same way with named-g-boxes -- after all, it's up to the g-box owner to decide whether updates are possible, and they can communicate information about immutability etc as RDF statements.

Best,
Richard

Received on Monday, 7 March 2011 15:50:35 UTC