Re: Layers

On Mon, 2012-04-30 at 15:14 -0500, Pat Hayes wrote:
> Further thoughts on this.  What I called a 'surface' is a bundle of your 'layers' which share blank nodes, and which defines the scope of blank node identifiers.  Think of a bunch of layers stapled together with a sheet of paper to be the background. Blank nodes are marks on the surface, which are visible from all the layers. Two distinct surfaces can never share a bnode or a layer. Overlaying two layers on the same surface is creating their union; copying them both onto a new surface, but seperately, is merging them. 
> 
> We can take one or more layers and copy them onto a new surface, to get a new bundle isomorphic to the old one but with new blank nodes. This is what happens when a layer or bundle is transmitted from an information resource in response to an HTTP GET, for example: you get a new copy on your surface. You don't (ever) get the actual bnodes from the source itself. 
> 
> A simple layer is a singleton bundle, ie just one layer on a surface, which we could identify with the surface itself in this case. 
> 
> Make sense? Think of this as your layer idea with an added twist to handle bnode scoping (and avoid the weird situation noted recently, in which two graphs can share the same bnode. Even the old RDF WG members often get this wrong, it is very peculiar. This construction avoids it by fiat.)
> 
> We could avoid actual talk of surfaces by introducing bundling as a relation between layers, and then define a notion of 'projecting' a bundled set of layers onto a single layer. This is just RDF graph union, of course. 

This sounds just about perfect to me.   (To be clear with credit: I was
in the front row of your Surfaces talk, some years back, and the idea
has been sitting on a shelf in my mind ever since.  My main objection
was knowing that I sometimes need to share blank nodes.  So when DanBri
offered these transparent surfaces that could be layered together and
share blank nodes (that is layers), it all felt right to me.)

So, I think a bundle of layers might be a SPARQL graph store.  Or,
something very, very close.   A graph store (the concept invented for
the SPARQL Update semantics) is (in my mind, at least) a set of layers,
where one of the layers is called the "default" and all the others have
exactly one name each (ie they are named, and the UNA holds).  Maybe
that "default" layer can be the original/special/ground/base surface,
one to which transparent surfaces/layers are sometimes added.   In fact,
some people do use just the default graph in sparql, ignoring all the
named graph stuff -- that could perhaps be seen as just using opaque
surfaces.       I dunno -- I'm just trying to find a way to make the
default graph in sparql not be such an outlier.

Moving on, a dataset is the state of a graph store (like an RDF Graph is
the state of a Layer).  Put differently layers are functions from time
to RDF Graphs; graphstores are functions from time to datasets.  A
dataset is what can actually be transmitted; it's the abstract syntax
behind TriG and N-Quads.   This is a pretty good match for how we copy
one bunch of layers to another, yes?  We're copying the state, we're
making both bundles contain the same dataset.

   -- Sandro


> Pat
> 
> 
> 
> On Apr 30, 2012, at 1:50 PM, Pat Hayes 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? 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. 
> > 
> > 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. 
> > 
> > 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
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> ------------------------------------------------------------
> 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 21:12:07 UTC