- From: Sergio Fernández <sergio.fernandez@salzburgresearch.at>
- Date: Thu, 31 Jan 2013 09:45:27 +0100
- To: Steve Battle <steve.battle@sysemia.co.uk>
- CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Also we may need to discuss what kind of membership hierarchical relationships would be considered for LDPCs. On 30/01/13 20:18, 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 > > -- Sergio Fernández Salzburg Research +43 662 2288 318 Jakob-Haringer Strasse 5/II A-5020 Salzburg (Austria) http://www.salzburgresearch.at
Received on Thursday, 31 January 2013 08:46:17 UTC