Re: Another approach to containers

On 24 Nov 2013, at 02:43, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> 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. 

From the protocol perspective though ldp:SimpleContainer and the other two work in very different ways.
All LDP clients will know the meaning of ldp:created ( a.k.a ldp:member, ldp:manages, ldp:xyz ) and
therefore as soon as they see that a resource is an ldp:SimpleContainer they can act in the knowledge
that it is just the truth of what they POST that they need to be responsible for.

On the other hand with the other two containers ( your ldp:DirectContainer and ldp:IndirectContainer )
the client needs to know what the consequences of his POSTing is. So the client MUST understand the 
ldp:containerResource, ldp:containsRelation, and ldp:insertedContentRelation objects. Since those can
be any type of object or relations and since this could bind the client to something, ( eg my "Volunteering for the Army post" http://lists.w3.org/Archives/Public/public-ldp-wg/2013Nov/0022.html )
this requires a much more sophisticated client. Certainly not a vanilla one.

> 
> 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. 

Can you clarify the use case? I am not sure what you are talking about.

> 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. 

That exist where? Can you specify this in terms of protocol?

> 
> 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. 

They all exist in conceptual space for sure. I don't see any of them having a fundamental contradiction inherent that would blow them out of the water.


> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 

Social Web Architect
http://bblfish.net/

Received on Sunday, 24 November 2013 07:33:21 UTC