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

On 19 Apr 2013, at 19:47, Cody Burleson <> wrote:

> I prefer Henry's proposal of using ldp:contains in addition to ldp:membershipPredicate or ldp:membershipPredicateInverse because it provides a clear mechanism for properly managing resources. 
> Without that, how would I be able to distinguish between resources that a container actually owns and those which it simply refers to? I would have to come up with some mechanism and this seems to be a reasonable one, so why not just go with it and make it standard?

An alternative mechanism that an LDP server _could_ use would be to create owned URIs hierarchically as 'children' of the container. The server could tell by URI inspection which members were contained and which were merely aggregated. Note that this approach is compatible with both proposals, just that it can be implemented _without_ the additional verbiage of Henry's proposal.

To my mind, this also fits much better with the prime directive  "Relative URIs are essential", because this makes container serializations much more portable.

From this perspective I'm happy with Steve's simpler proposal.


Steve Battle

Steve Battle
Semantic Engineer


Sysemia Limited
The Innovation Centre, Bristol&  Bath Science Park, Dirac Crescent, Emerson's Green, Bristol BS16 7FR
Registered in England and Wales. Company Number: 7555456


Information contained in this e-mail is intended for the use of the addressee only, and is confidential and may also be privileged. If you receive this message in error, please advise us immediately. If you are not the intended recipient(s), please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Attachments to this e-mail may contain software viruses which may damage your systems. Sysemia Ltd have taken reasonable steps to minimise this risk, but we advise that any attachments are virus checked before they are opened.

Received on Friday, 19 April 2013 19:25:35 UTC