Re: Operations on containers

>> 
>> The doc talks about the "the BPC that was used to create it [BPR]"
>> (5.6.2) and "should remove it from any other containers..."
>> 
>> This means the creating container is distinguished and needs to manage
>> the BPRs is creates separately from those it did not.
>> 
>> 	Andy
> 
> I don't think we currently have an issues open related to this point.
> 
> To support resources being members of more than one container, and also strong lifecycle dependencies between a container and a subordinate resource, the LDP should define precisely how it supports both (weak) aggregation and (strong) composition.
> 
> I believe that the semantics of RDF containers and their membership properties to be weak in the sense that (weak) membership is not the same as (strong) ownership (I can't find a reference to prove that - but would an inverse memberOf really be functional?). For this reason, I think that the following statement from ' Linked Data Platform 1.0' is ill-advised. Yes, it may delete the contents - just as it may delete everything - but that wouldn't be very intuitive.
> 
> "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."
> 
> 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.
> 
> e.g. The wording of ' Linked Data Platform 1.0' could be amended to read:
> 5.6.1 If a LDPC server supports deletion of the LDPC, the server may also delete contained resources whose hierarchical URIs begin with the URI of the container C".
> 
> No additional tracking of which containers created what resources is required.
> 
> And the example from of ' Linked Data Platform 1.0':
> # The following is the representation of
> #	 http://example.org/netWorth/nw1/assetContainer
> @prefix dcterms: <http://purl.org/dc/terms/>.
> @prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#>.
> @prefix ldp:      <http://www.w3.org/ns/ldp#>.
> @prefix o:       <http://example.org/ontology/>.
> 
> <http://example.org/netWorth/nw1/assetContainer>
>   a ldp:Container;
>   dcterms:title "The assets of JohnZSmith";
>   ldp:membershipSubject <http://example.org/netWorth/nw1>;
>   ldp:membershipPredicate o:asset.
> 
> <http://example.org/netWorth/nw1>
>   a o:NetWorth;
>   o:asset
>      <http://example.org/netWorth/nw1/assetContainer/a1>,
>      <http://example.org/netWorth/nw1/assetContainer/a3>,
>      <http://example.org/netWorth/nw1/assetContainer/a2>.


I don't think it is a good idea to rely on the structure of the URLs for working this out. 
Not least because I think a Container and its Contained items can be on separate machines.  

Generally, as you point out, I think there are lots of details in this area which need consideration, and we need some open issues for that. 

Roger