RE: Operations on containers

"Steve Battle" <steve.battle@sysemia.co.uk> wrote on 10/19/2012 06:31:34 
AM:

> From: "Steve Battle" <steve.battle@sysemia.co.uk>
> To: "'Andy Seaborne'" <andy.seaborne@epimorphics.com>, <public-ldp-
> wg@w3.org>, 
> Date: 10/19/2012 06:32 AM
> Subject: RE: Operations on containers
> 
> > -----Original Message-----
> > From: Andy Seaborne [mailto:andy.seaborne@epimorphics.com]
> > Sent: 24 September 2012 11:18
> > To: public-ldp-wg@w3.org
> > Subject: 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".

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.

> 
> No additional tracking of which containers created what resources 
isrequired.
> 
> 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>.
> 
> 


--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group