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".

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

Received on Friday, 19 October 2012 13:32:07 UTC