Re: Another approach to containers

On 24 Nov 2013, at 16:08, Alexandre Bertails <bertails@w3.org> wrote:

> Hi Henry,
> 
> On 11/24/2013 02:32 AM, Henry Story wrote:
>> 
>> 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.
> 
> Arnaud's proposal both recognises the potential issues when using
> ldp:containsRelation or ldp:insertedContentRelation, and gives us a
> SimpleContainer that matches our intuition and expectation. To me, it
> looks like a step in the right direction.

I agree with that.

> 
> Also, remember that we'll see at CR what features are implemented or
> not. Also time will tell us if the IndirectContainer will be adopted
> in LDP applications or not. And if not, we can always reflect that in
> LDP 1.1 :-)

I was just stepping ahead a bit to try to make those containers more flexible.
But that's probably one step too far. I'll get back to that later.

> 
> My only remark to Arnaud's proposal is the following: when the
> Container is not the containerResource (just like the first example
> for DirectContainer), then there is again an indirection. So that
> example should be for an IndirectContainer, not a DirectContainer.
> 
> The DirectContainer should only be for ldp:containsRelation being
> different from ldp:xyz. Arnaud, what do you think about that?
> 
> Alexandre.
> 
>> 
>>> 
>>> 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/

Social Web Architect
http://bblfish.net/

Received on Sunday, 24 November 2013 15:11:07 UTC