Re: Proposal for containers

Ashok,

LDP resources (including containers) are defined as "web resources that describe their state using RDF".
What are your thoughts on how the relationship between the container and the contained is represented in RDF? This being part of it's state.

My concern, as always, is that if predicates like rdfs:member are allowed for composition then this makes it difficult to distinguish between a resource POSTed to the container (as in B.), and a resource _linked_ to the container using rdfs:member (as in F.). I advocate use of a distinct composition property (eg. ldp:contains, or ldp:owns, or ldp:manages) to avoid this confusion between composition and aggregation.

This is an extension of your proposal below, NOT an alternative proposal.

Steve.

On 30 Jan 2013, at 15:23, Ashok Malhotra <ashok.malhotra@oracle.com> wrote:

> OK.  Here goes
> 
> Container Model
> 
> A. Containers can contain containers
> Containers are LDPRs and should
> be added to contianers like any other LDPR.
> 
> B. To add a container to a container, POST a (child) container
> representation to a (parent) container.
> 
> C. Thus, a contianer can contain a mix of members and comtainers.
> (Some of the members may be links to LDPRs.)
> 
> D. If you GET all members of a
> container that has nested components, you get all the contents,
> members and containers at the top level.  That is, you do not get nested
> components.
> 
> Composition and Aggregation
> 
> E. If you delete a container you delete everything it contains.
> For nested containers this leads to a cascaded delete.
> 
> F. If you do not want a member to be deleted when the container is deleted,
> do not include the member in the containers but rather include a link to the
> member in the container.
> 
> E and F follow the AtomPub model.  There are other proposals
> -- distinct containers and aggregators, an attribute to distinguish
> between containers and aggregators.  We can debate these separately
> from A, B, C, D
> 
> 
> All the best, Ashok

Received on Wednesday, 30 January 2013 19:19:22 UTC