Re: composition and aggregation

On 29 Jan 2013, at 15:24, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:

> hello ashok.
> 
> On 2013-01-29 2:21 , "Ashok Malhotra" <ashok.malhotra@oracle.com> wrote:
>> We agree that both composition and aggregation are needed but we
>> don't have agreement on mechanisms.
>> http://www.w3.org/2012/ldp/track/issues/34
>> covers a part of it.
>> 
>> There seem to be three proposals:
>> A.  Use an attribute on the collection to indicate composition or
>> aggregation
>> B.  Use two separate classes for composition and aggregation
>> C.  Delete all members when a collection is deleted.  Use links to cover
>> the
>> aggregation case.
> 
> i don't see the simple proposal i made a while ago in here (or maybe it's
> C?): there is no difference between aggregation or composition on the
> collection level. the difference is simply in the entries: if content is
> embedded, they are using "composition", if content is linked, they are
> using "aggregation". members are deleted when the collection is deleted,
> and depending on how clients created members, the content is deleted as
> well, or it remains unaffected.
> 
> to summarize: i think we're getting on the wrong track if we start
> discussions by "how do we create composition collections" and "how to we
> create aggregation collections". by using the webby way of giving people
> the choice to embed or link, we can elegantly cover both concepts. and the
> best thing is that on the server side, we don't need to do anything. it's
> all up to the client to decide how they are creating their members.

You are saying that you need two relation

ldp:contains a rdf:Property;
   rdfs:domain ldp:Container;
   rdfs:comment """
  deleting this relation requires deletion of the resource that is the object 
  of this relation.
  """

ldp:link a rdf:Property;
   rdfs:comment """
  a relation to another resource, that like a symbolic link on a unix file system 
  does not entail the deletion of the object of the relation if removed. "
 

Mind you that ldp:link is so general you may wonder why not just use the top level
property of rdf. Is there anything special about this link property at all?

Now my proposal "Aggregation: Simple Proposal"  on the wiki 
  http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal
shows how one can indeed do this with any non LDPC resource.
We don't really need an ldp:Aggregation class for this to work, it just helps
a bit.

My guess is though that you want ldp:Containers to be also 
able to contain ldp:link relations right? I think that is the
jist of your proposal. In such a case you need to explain how
you add those relations to a container. Currently POSTing a 
graph to a container creates an rdf:member which in fact implies
an ldp:contains relation as defined above. Because currently 
the implicit rule we have is that 

 { ?c a ldp:Container ;
      rdfs:member ?x } <=> { ?c ldp:contains ?x } 

So you need to tell a story about how you add an arbitrary non 
ldp:contains relation to a container. 

My suggestion is that you can use the PATCH method
that still needs defining to do this if you really
need it:

PATCH /container HTTP/1.1
...
ADD { <> ldp:link <http://someother.server.com/resource> . }

Since PATCH is in any case useful for:
  - intelligent and quick deletion of LDPC members
  - updating any resource efficiently
  - the above

We might as well proceed and get that part of the work done.

Henry

PS. In the interest of fairness and openess I must disclose a
potential conflict of interest here. Being an Apache member I 
have a potentially strong intellectual interest in PATCH being a 
strong member of the LDP protocol. 

> 
> cheers,
> 
> dret.
> 
> 

Social Web Architect
http://bblfish.net/