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

Re: Operations on containers

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Fri, 19 Oct 2012 15:14:09 +0100
Message-ID: <50816031.2070509@epimorphics.com>
To: Steve Battle <steve.battle@sysemia.co.uk>
CC: public-ldp-wg@w3.org


On 19/10/12 14:31, Steve Battle wrote:
 > I don't think we currently have an issues open related to this point.

Do raise anything you see as missing - the message might have been 
before we started raising issues in earnest.

> Do we have to record additional information about which "BPC that was
> used to create it [BPR]". The state of the container must be
> expressible in RDF, should we record strong ownership relationships
> in addition to weak aggregation relationships?
>
> Actually, I don't think so. There's a much simpler and more intuitive
> mechanism already apparent in the example below, based on the
> hierarchical organization of the URI. The URI for a subordinate
> resource<http://example.org/netWorth/nw1/assetContainer/a1>  can be
> simply relativized (ie. not using '..') against the membership
> subject<http://example.org/netWorth/nw1>. In other words, the URI for
> the subordinate resource begins with the URI of the container -
> simple as that. Resources that are members but not composed as
> defined here would not fall under strong lifecycle management of the
> container.

That could be where we end up, strong and weak lifecycles.

We don't want to over burden the implementation with tracking.

The naming form has an implication that a LPD-R (né BPR) is permanently 
the responsibility of the creating container.  It can't be moved to 
another container, along with the strong responsibility for it, without 
renaming.  A moved LPD-R has to go from strong to weak lifecycle if the 
URI is to be stable.

User Story:
Imagine creating a new portfolio container and wanting to reorganise the 
existing assets between the two containers.



We need to account for the usual create, mv, cp, rm with the extra 
consideration of stable/cool URIs for external naming making rename.

("account for" means know its possible, not that it must be a specific 
operation of an LDP.)

A complicated case is moving a container ...

	Andy


Summary of original message:

 > 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?


	Andy
Received on Friday, 19 October 2012 14:14:39 UTC

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