Re: Another approach to containers

On 23 Nov 2013, at 05:32, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Hi all, 
> I got a new idea I'd like to propose to the WG. I believe it may provide some much needed relief by giving everyone what they want. I know, that seems impossible but have a look and let's see. :-) 
> 
> http://www.w3.org/2012/ldp/wiki/Containers 
> 
> This is relevant to all of the following issues and more: 
>  ISSUE-84 ldp:member 
>  ISSUE-85 membershipXXX rules 
>  ISSUE-86 "membership triples" misnamed 
>  ISSUE-89 Managed resources 
> 
> Regards. 
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group

Excellent. I feel we are now making real progres with this and
with the http://www.w3.org/2012/ldp/wiki/Membership wiki page.
These are really helping make the working of the spec clear which will
faciliate discussion a lot.

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 )

ldp:SimpleContainer:
  If a client sees that a resource if of type ldp:SimpleContainer, then it
can POST resources knowing that it need only be concerned about the truth
of the statements it makes. It does not need to search the LDPC for any other
statements.

ldp:ContractualContainer
If a client posts a resource of type ldp:ContractualContainer, then it 
MUST understand all ldp:creationConsequence objects, and MUST understand
and agree to the triples that are going to be created as a consequence of POSTING.

We can then make the distinctions between your DirectContainer and IndirectContainer
at a different level, namely at the level of the "rules". Here we have one Contractual
Container with two different rules ldp:DocumentConsequence, and ldp:ObjectConsequence.

[[
</shopping/cart/> a ldp:ContractualContainer;
     ldp:creationConsequence [ a ldp:DocumentConsequence;
                               ldp:subject  <#>;
                               ldp:predicate shop:agreesTo
                             ],
                             [ a ldp:ObjectConsequence; 
                               ldp:subject <#>;
                               ldp:predicate shop:buys;
                               ldp:objectSelector foaf:primaryTopic ];
     ldp:member <member1>, <member2> .         // <- it is easy to find the members

<#> order:contains <urn:isbn:0470396792> ;     
    order:wishes <urn:isbn:9781907974045> .
]]

This is an adaptation of what I wrote up here:

http://www.w3.org/2012/ldp/wiki/MembershipInferencing#Generalisation:_multiple_consequences



Social Web Architect
http://bblfish.net/

Received on Saturday, 23 November 2013 14:32:58 UTC