Re: ContainerHierarchy again

On 03/04/2014 01:16 PM, henry.story@bblfish.net wrote:
> At the last meeting there was a resolution to move back to the 
> previous positon
> on container hierarchies, the position called "the minimal consensual 
> position"
> in
>
> https://www.w3.org/2012/ldp/wiki/ContainerHierarchy
>
> But that wiki page shows how the minimal consensual position we have 
> currently
> + the decisions we have previously come to lead to hierarchy
>
> IndirectContainer
>    DirectContainer
>       BasicContainer
>
> In RDF subclass relations DO NOT mean dependence of one subclass
> on another. You can easily deprecate classes without subclasses or
> superclasses without this leading to legacy issues.
>
> All the subclass relations mean is that you cannot have objects that 
> are in one
> class and not the superclass as shown by the picture
>
> https://www.w3.org/2012/ldp/wiki/ContainerHierarchy#LDP-BC_.3C:_LDP-DC_.3C:_LDP-IC_.3C:_LDPC
>
>
> So I think it is misleading in fact to now show the classes as having 
> no relation to each
> other when we know they do.
>
> Henry

Can we separate logic, pedagogy, and protocol?

What you're saying appears to be logically true, yes.   That was why we 
adopted the hierarchy for a while.

I'm ambivalent from a pedagogical perspective.  If we're going to 
include this hierarchy in the spec, I think we'd really need to include 
a Venn diagram with the actual features as points in the space, so that 
it's clear in what sense it's a class hierarchy.

 From a protocol perspective, I think it's important that the hierarchy 
not matter.  In particular, clients who are looking for a 
DirectContainer must be told link rel=type DirectContainer, NOT 
BasicContainer.   Logically every BasicContainer is a DirectContainer 
but we've agreed not to require clients to do that kind of inference.    
So as long as we're not going back on that, the hierarchy has no impact 
on the protocol.

        -- Sandro