- From: Ashok Malhotra <ashok.malhotra@oracle.com>
- Date: Wed, 30 Jan 2013 16:52:11 -0500
- To: public-ldp-wg@w3.org
Hi Steve: These are good questions. I am not an RDF expert. Perhaps some of the others can fill in the blanks. All the best, Ashok On 1/30/2013 2:18 PM, Steve Battle wrote: > 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 21:52:44 UTC