W3C home > Mailing lists > Public > public-rdf-wg@w3.org > August 2012

Re: retronyms, Abstract/Maintained Graph

From: Nathan <nathan@webr3.org>
Date: Fri, 24 Aug 2012 09:49:13 +0100
Message-ID: <50374009.9060105@webr3.org>
To: Dan Brickley <danbri@danbri.org>
CC: Sandro Hawke <sandro@w3.org>, Richard Cyganiak <richard@cyganiak.de>, RDF Working Group WG <public-rdf-wg@w3.org>
Dan Brickley wrote:
> On 23 August 2012 17:00, Sandro Hawke <sandro@w3.org> wrote:
> 
>> You lost me here, sorry.   What's the use case for an immutable named graph?
> 
>> And it sounds like you're suggesting "mutable named graph" as the official
>> term for g-box.  Is that right?

A g-snap is immutable by nature, since it's a fixed Set of Triples, as 
soon as you add in the indirection of names the immutable property 
becomes hidden, rendering it indistinguishable in every way from a named 
g-box (mutable named graph).

A g-box emits an encoded representation (g-text) of a g-snap (distinct 
set of triples) when poked. Any time you use a name in this setup, it 
always refers to a g-box, which may or may not be mutable, you just 
don't know.

You can configure a g-box, say a REST resource, to always deliver the 
same g-text (the same encoding of the same g-snap) all the time, and 
enter in to a stable contract out side of technical scope to say it's a 
fixed resource, and give technical indicators like checksums, hashes and 
signatures to verify that it is a "fixed resource". But there's no 
technical constraint, or way to expose that it's mutable or immutable. 
Even if you do create a way to say and expose that it's immutable, then 
what you refer to is still a g-box - a "static g-box" / "fixed resource" 
- not the g-snap.

The only way to refer to a g-snap, is by it's identity, which is the set 
of triples itself, or an encoding of them, a g-text; either encoded in a 
typed literal, or as a quoted graph in N3.

Thus, an "immutable named graph" is a "static g-box", not a g-snap - the 
URI name refers to the g-box, and moreover, the immutable property of it 
is hidden by the indirection of names.

You can prove it by example with a couple of lines:

   :foo :entails <http://example.org/a> . #ref-a

   <http://example.org/a> { <s> <p> "foo" }
   <http://example.org/a> { <s> <p> "bar" }

Above you see as soon as you use names, the g-snap/g-text can change, 
and the immutable property is hidden. However with quoting / using the 
identity of the g-snap:

   :foo :entails { <s> <p> "foo" } . #ref-b

You can clearly see there's no indirection, the set of triples being 
referred to can't change.

The important detail is that in the first example #ref-a the set of 
triples being referred to can change without any change to the first 
":foo :entails ?", the graph which contains that triple can change 
meaning at any time, without any change being made to that graph itself. 
Entire datasets can change meaning massively, without the manager of 
that dataset knowing. In the second example though #ref-b, the identity 
is embedded, so you never get any surprises.

Every use case for g-snaps requires being able to refer to a distinct 
set of triples (since that's what a g-snap is), the only way to do that 
is by identity - introduce names and you're not talking about g-snaps or 
referring to them, you're referring to static g-boxes; things which are 
distinct from the fixed g-text they omit, and the g-snap that g-text 
encodes.

Without quoting it's pretty much pointless even mentioning 
mutable/immutable named graphs, as anybody looking on can only see a 
named graph.

Best,

Nathan
Received on Friday, 24 August 2012 08:50:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:06 UTC