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

Re: Layers

From: Pat Hayes <phayes@ihmc.us>
Date: Mon, 30 Apr 2012 15:14:50 -0500
Cc: public-rdf-wg <public-rdf-wg@w3.org>
Message-Id: <9865CE6A-1AB6-444D-909D-FBA73CD4BAE9@ihmc.us>
To: Sandro Hawke <sandro@w3.org>
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. 

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 20:15:23 UTC

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