Re: Operations on containers

> 
> > 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". 
> 
> Isn't one supposed to treat URIs as opaque and not parse them? 
> 
> This may indeed be a very simple and pragmatic way of dealing with this problem though. 
> 
> A logical consequence would then be to allow creating a resource within a container using PUT in the same way. 


well, from what I can tell from the group is that we are already doing something a bit like a "POSTed PUT". But, is this a consequence we want to chase ? 

many regards, 
Roger