W3C home > Mailing lists > Public > public-ldp-wg@w3.org > October 2012

ldp-ISSUE-25 (Aggregation): Strict aggregation and strong composition in containers [Linked Data Platform core]

From: Linked Data Platform (LDP) Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Fri, 19 Oct 2012 16:28:14 +0000
Message-Id: <E1TPFQk-00071Y-TJ@nelson.w3.org>
To: public-ldp-wg@w3.org
ldp-ISSUE-25 (Aggregation): Strict aggregation and strong composition in containers [Linked Data Platform core]

http://www.w3.org/2012/ldp/track/issues/25

Raised by: Steve Battle
On product: Linked Data Platform core

This issue pertains to questions raised by AndyS, namely how do we:

 > 1/ Place an existing BPR in a container
 > 2/ Place a BPR in more than one container
 > 3/ Remove a BPR from a container but not delete it from the system 
(c.f. 5.6.1, 5.6.2) -- this may be part of a move operation.
 > 4/ Create a container under another container? Move a BPC under 
another BPC?

Specifically, this raises the issue that we must be clear about how the LDP supports both strict aggregation and strong composition in containers.

The lifecycle of a composed resource is tied to the container; if the container is deleted any composed resource MAY be deleted. Weakly aggregated resources should not be deleted.

stevebattle argues that rdfs:member (and this is not atypical) defines only weak aggregation, and as such it would be incorrect to treat members as though they have a strong lifecycle dependency on the container as in: "5.6.1 If a LDPC server supports deletion of the LDPC, the server may also delete the resources that are referenced as its contents." (Linked Data Platform 1.0).

stevebattle proposes that a resource is only (strictly) composed under a container if its URI can be hierarchically relativized to the URI of the container (and without using '..' in the relativized path). Intuitively, the URI of the subordinate resource begins with that of the container.

objections include:
* URIs should be opaque
* Composition of resources in different authorities would not be possible
* Very hard to move composed resources between containers
* It would be possible to add composed resources to a container using PUT
* It would even be possible to create the container after the subordinate resource
Received on Friday, 19 October 2012 16:28:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:32 UTC