- From: Nathan <nathan@webr3.org>
- Date: Fri, 24 Aug 2012 09:49:13 +0100
- 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