W3C home > Mailing lists > Public > public-ldp-wg@w3.org > April 2013

Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior - take #2

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Sun, 28 Apr 2013 13:56:20 -0400
Message-ID: <517D62C4.2000906@openlinksw.com>
To: public-ldp-wg@w3.org
On 4/27/13 7:40 PM, Ashok Malhotra wrote:
> If we have two types of membership as in the proposal below and if the 
> container is
> deleted one type of member MUST be deleted and the other type of 
> member MAY be deleted
> then this is equivalent to members being either members which MUST get 
> deleted or links
> which get deleted but the resources they point to MAY or MAY NOT get 
> deleted.
> In such a model, resources that are included in a collection using 
> links can belong to more than one
> collection.  This solves the other issue we have re.  resources 
> belonging to more than one collection.

Yes, it does.

You have "containers" and "collections". These are old and fundamental 
patterns in computing and real life. A "container" is a kindOf 
"collection" :-)


>> 3. specify that on deleting a container LDP servers MUST delete the 
>> container and member resources listed as contained via ldp:contains, 
>> and MAY delete other member resources (typically to satisfy internal 
>> requirements).
>> So if I have:
>> <> a ldp:Container;
>>    rdfs:member <a>.
>> and I create <b> using POST to the container, I end up with:
>> <> a ldp:Container;
>>    rdfs:member <a>, <b>;
>>    ldp:contains <b>.
>> When I delete the container, both the container and <b> get deleted. 
>> <a> MAY be deleted.



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Sunday, 28 April 2013 17:56:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:47 UTC