- From: Dan Brickley <danbri@danbri.org>
- Date: Mon, 30 Apr 2012 22:01:23 +0200
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Sandro Hawke <sandro@w3.org>, public-rdf-wg <public-rdf-wg@w3.org>
On 30 April 2012 20:50, Pat Hayes <phayes@ihmc.us> wrote: > This is VERY like the 'surfaces' proposal in http://www.slideshare.net/PatHayes/rdf-redux (see especially slides 7-10), but with one very important difference: surfaces cannot share bnodes with other surfaces. As this aspect of the surfaces design was critical to making bnodes work more rationally and providing a notion of bnode scoping, I wonder if it is worth debating this point in more depth. Can we combine these ideas in some way? (Maybe you missed in my mail where I tried to credit you for that -> http://lists.w3.org/Archives/Public/public-rdf-wg/2012Apr/0232.html though it's mostly lifted from Guha's old mcf and mozilla stuff.) Regarding "A surface is something like a bundle of overlaid layers, like a movie still made up from overlaid cels", -- yes, that metaphor works for me, maybe because I've been spending enough time learning visual compositing tools (Blender etc, e.g. http://www.blender.org/development/release-logs/blender-242/blender-composite-nodes/ ) that it no longer really feels like a metaphor. [offtopic but hey] In that kind of tool, while there is a layered compositing of images, the 'programming' model is handled in terms of a nodes-and-connectors flow from inputs to outputs. I think it's important that we be clear that any talk of "layers" isn't to discourage other useful metaphors within tools and supporting languages. For example, something like Apache Pig (not RDF, but not a million miles away...) is also very flow oriented, while Tinkerpop/Gremlin works in terms of graph traversal instructions. I think we're all the richer for having different styles of talking about managing and navigating this sort of data, but there is something quite unifying in the layers+surfaces metaphor that can help people understand the data, without dictating exactly how people work with it. > A surface is something like a bundle of overlaid layers, like a movie still made up from overlaid cels. Or, put the other way, a layer is part of a suface which has been peeled off and raised above the surface. (Danbri's pictures work either way.) Think of the surface as the opaque background of the transparent layers: bnodes are marks on this surface. We could copy a layer onto another surface, for example, and then the suface idea of conjunction (replacing unions and merges) works here also: to conjoin A and B, just copy them both onto a new surface. That's quite interesting. It's refreshing to be able to start to articulate operations that work with larger units than triples. I wonder what other kinds of operations between graphs/layers/surfaces are useful in everyday rdf (/owl) life? > It is worth trying to get this right, as we are tantalisingly close to making RDF have full first-order expressiveness here. The 'codices' idea (later slides) is very much like layers sitting on top of a surface, but beause of the bnode scoping, it effectively provides for nested quantification, which layers wouldnt be able to do by themselves. BUt the closeness of the intuitions is striking. > > Even if this is beyond charter for this WG, I would like to think about it, if only to make sure we don't accidentally do something that would accidentally block this as a future extension for some trivial careless reason. It feels quite in-scope to me, if you think the maths might work out... Dan > Pat > > On Apr 29, 2012, at 2:41 PM, Sandro Hawke wrote: > >> It all makes sense to me now. It's so simple: >> >> http://www.w3.org/2011/rdf-wg/wiki/Layers >> >> Dan Brickley's suggestion of the term "layer" instead of "named graph" >> fit so well for me, it made this all flow nicely. I suspect this is >> what many people think of when they say "named graph" -- I just couldn't >> get past all the other meanings of that term. >> >> Hopefully you'll all like my three examples, which I think cover the >> territory of use cases pretty well. >> >> -- Sandro >> >> >> >> > > ------------------------------------------------------------ > IHMC (850)434 8903 or (650)494 3973 > 40 South Alcaniz St. (850)202 4416 office > Pensacola (850)202 4440 fax > FL 32502 (850)291 0667 mobile > phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes > > > > > >
Received on Monday, 30 April 2012 20:01:47 UTC