Re: Another approach to containers

Henry Story <henry.story@bblfish.net> wrote on 11/23/2013 06:32:27 AM:

> Now I think we only really need two distinctions. 
> 1. A Simple LDP Container -- your ldp:SimpleContainer
> 2. A Contractual LDP Container -- both your ldp:DirectContainer and 
> your ldp:IndirectContainer
> 
> Why this difference?
> 
> Because we want:
> - something that can be placed in the HTTP header as a type
> - the client to be able very quickly to work out if there are any 
consequences
> beyond the basic creation of ldp:member ( a.k.a ldp:xyz or 
> ldp:manages ) to the 
> creation of a resource.
> - something that can evolve more easily ( as new rule languages develop 
)
> 

Sorry, that doesn't work for me. If anything it's the IndirectContainer 
that is the most unique and should be segregated from the other two. This 
is because both with SimpleContainer and DirectContainer the resource that 
gets POSTed is the resource that gets listed as the member. 
IndirectContainer has that unique behavior of not doing so, which is why 
ldp:memberResource/ldp:created is needed.

I know you like your view of a basic membership relation on top of which 
some additional relation can be built that is merely a consequence but as 
Ashok pointed out this fails to address the use case of leveraging 
existing domain specific vocabulary.

Understand that the point is not to be able to infer the domain specific 
relationship. The point is to be able to leverage that domain specific 
relationship which already exists by allowing to define a container around 
it.

For this reason, I don't want to get into trying to group any of these 
containers. Let's just have the three of them in their own rights and not 
fight over which is the true one, please.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group