Re: Layers

On 2 May 2012 06:12, Pat Hayes <phayes@ihmc.us> wrote:
>
> On Apr 30, 2012, at 5:00 PM, Thomas Baker wrote:
>
>> On Mon, Apr 30, 2012 at 10:01:23PM +0200, Dan Brickley wrote:
>>>> 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?
>>
>> The Layers metaphor fits very nicely with the notion of Levels in the FRBR use
>> case as described at [1]:
>>
>>    This proposal views descriptions of WEMI entities as bundles of statements
>>    made at different levels of abstraction, from the most concrete Item level
>>    to the most abstract Work level.
>
> Hmmmm. Sorry to be a bit of a pooper, but this worries me. When Sandro + Danbri came up with the "levels" terminology, I hated it because it suggested that a "vertical" dimension between layers was meaningful and even important, which it isn't. It has no semantic meaning at all: the 'layers' have no intrinsic ordering, and in fact are best thought of as constituting a set rather than a sequence or list. But Sandro calmed me down by saying, no, its just that they are transparent, like sheets of celluloid. But my worry has now reared its head again, because WEMI "levels" really do have a vertical order, and one that is semantically significant (level of abstraction).  If we endorse this kind of usage, I am afraid that others will start using the "depth" of a "layer" to mean time sequence, where deeper means older; and others to mean importance, where deeper means less trusted; and others to mean all kinds of other things. Which just re-creates the kind of confused ad-hocery that we have now.
>
> Its OK to use layers to handle levels, supported by a suitable ontology maybe, but what I DONT want us to even hint at doing is to encourage people to use some kind of ordering of layers based on an implementation accident or something meaningless like lexical ordering of the "graph names" to encode anything meaningful.

Yes, we ought to be clear that the notion of a layer isn't
intrinsically ordered.

It's hard to avoid the intuition that applications might order the
layers though; the best way I can think of making sure people don't
assume it's 'standard' is to give some different examples:

Quick primer/tutorial text -
"Layers of RDF graph data can be integrated in many different ways.
For example, you might have three graphs, A, B and C that describe a
common set of consistently identified people and their contact
information. A fourth graph ("layer") D could be composed from these
by looking for a primary contact phone number for each person
described in A (the oldest), if that fails, take it from B, if that
fails, from C. Alternatively, we could compose D by considering which
of A, B, C are from the most expensive, highly rated etc sources, and
pulling triples into D accordingly. Or we could select randomly. Or
simply take it from B and ignore the rest. Or test all the numbers in
the data to see which phone numbers seem to work. There are almost
unlimited ways of combining and recombining data graphs; the "layer"
metaphor gives us a natural way of thinking about this, but it doesn't
require any particular ordering or combination rules.

This can be compared to calendars in a desktop application; you might
have a stack of three calendars X, Y and Z in your daily calendar
tool. Nothing intrinsically orders those or determines which one shows
on the "top" when the events overlap. Similarly, in mapping tools like
Google Earth, you might have a "layer" of information P showing
current roads, another Q showing rivers, and a third R showing planned
roads. While we have the natural intuition that real-world physical
ordering (height/altitude) orders the information when comparing and
superimposing P and Q, such intuitions don't tell us whether P's layer
of "actual" versus R's "planned" roads should be ordered first, if P
and Q are overlayed. As with all metaphors for computers, it is
important to understand "layers" are a conceptual tool for helping us
understand how "graphs" of information from multiple sources can be
composed, combined and compared. As with calendars and maps, we should
always remember that not every intuition we have about physical layers
carries across to the information metaphor."

Does something like that help?

Dan

Received on Wednesday, 2 May 2012 07:13:49 UTC