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

Re: Operations on containers

From: Roger Menday <roger.menday@uk.fujitsu.com>
Date: Fri, 19 Oct 2012 15:55:29 +0100
CC: Steve Battle <steve.battle@sysemia.co.uk>, 'Andy Seaborne' <andy.seaborne@epimorphics.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Message-ID: <D578952C-9CCE-4BA6-9092-869B66570FD7@uk.fujitsu.com>
To: Arnaud Le Hors <lehors@us.ibm.com>
> > 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, 

Received on Friday, 19 October 2012 14:56:05 UTC

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