Re: Aggregation: simple proposal

On 17 Jan 2013, at 20:13, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Hi John, 
> 
> I was just about to say something about the need to agree on a set of terms we use consistently so I can only commend for you for making such a proposal! :-) 
> 
> Now, given that: 
> 1) the current draft uses the term container 
> 2) per resolution of issue-25 at our F2F1 the spec is to be revised to clarify that containers are about composition 
> 
> We really only need a term for the new type of container. So, I suggest: 
> 1) we use the term container when we mean to talk about composition, strong composition, etc. 
> 2) we use the term aggregation when we want to talk about aggregation. :-) 
> 3) we stop referring to all other terms and variations involving weak and strong 
> 4) if needed, we use the term collection as a higher level term to refer to both types: containers and aggregations 
> 
> I see no problem with ending up with a spec that talks about resources (LDPR), containers (LDPC), and aggregations (LDPA). 

I write that up just a little bit more formally on the wiki page

http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal#Vocabulary

@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ldp:Container a rdf:Class;
    rdfs:note "deleting a Container deletes all its members";
    rdfs:subClassOf :Collection .

ldp:Aggregation a rdf:Class;
    rdfs:note "This covers what was known as weak aggregation.  Deleting an Aggregation does not imply the deletion of its members" ;
    rdfs:subClassOf :Collection.

ldp:Collection a rdf:Class;
   rdfs:note "Thing that can have members, that has some notion of containership, to be clarified further" .

ldp:member a rdf:Property;
    rdfs:domain :Aggregation ;
    rdfs:note "the relation between an aggregation and its' members. Deleting an aggregation does not necessarily delete the members" .

ldp:contains a rdf:Property;
    rdfs:domain :Container ;
    rdfs:note "the relation between a container and its' contents. Deleting a Container deletes the container's members" .


> 
> Cheers.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> 
> John Arwe/Poughkeepsie/IBM@IBMUS wrote on 01/17/2013 05:11:35 AM:
> 
> > From: John Arwe/Poughkeepsie/IBM@IBMUS 
> > To: public-ldp-wg@w3.org, 
> > Date: 01/17/2013 05:13 AM 
> > Subject: Re: Aggregation: simple proposal 
> > 
> > Henry, some questions on the revisions. 
> > 
> > 1: "collection" seems to be used inconsistently.  We'd likely need 
> > to declare a meaning on your page and paraphrase the emails in Q&A 
> > (at least) in order to align them with its language.  I have the 
> > impression mostly that unqualified-collections is a general term 
> > used to encompass both strictly compositional collections and 
> > aggregation-al collections (sometimes also called strong and weak 
> > collections or strong and weak containers).  I propose that we 
> > consistently use collections as the general term (encompassing both 
> > composition and aggregation), consistently use a distinct single 
> > term for compositions, and do likewise for aggregations.  I care 
> > less about the terms chosen than the consistent use aspect.  I want 
> > to be sure that when term X is used that author and reader have only
> > one choice of semantic to apply to that term, even if for now that 
> > is true only within the context of each proposal.  It *probably* 
> > would be less disruptive to use Container for the compositional 
> > term, given our liberal use of ldpC in emails, although it might be 
> > more clarifying to intentionally choose an entirely different term 
> > so we're less apt to use it by accident.  Example of the existing 
> > inconsistencies: "existing container: http://localhost:9000/2012/ 
> > ... Let us start with an empty collection [JA: vs container]. ... 
> > Create a new aggregation inside the container [JA: vs collection] 
> > ... Create a aggregation container named aggregate1 inside the same 
> > collection." 
> > 
> > 2: shouldn't the aggregate1 create response be 201? 
> > 
> > 3: (delete agg) "Note that in both cases it is clear that as opposed
> > to LDPC's this does not delete any of the resources contained in the
> > Aggregation Container. "  I don't think it is clear *from what is 
> > shown".  It would be fair as an assertion of the proposal.  To be 
> > clear I think you'd need to show the before-aggregate1-state [i.e. 
> > what a subsequent GET would return, for EACH of the resources 
> > involved, perhaps by pointing to an earlier copy, but "always" 
> > clearer to be pedantic and reproduce it in full], the request 
> > [already here], and the after-aggregate1-state [i.e. what a 
> > subsequent GET would return, for EACH of the resources involved] 
> > 
> > 4: (delete alt 1) HTTP/1.1 410 OK looks... inconsistent ;-) 
> > 
> > 5: (delete alt 2) "other things inside the collection that should be
> > kept" ... by "other things inside the collection" do you mean what 
> > the spec calls "non-member properties"?  It appears so. 
> > Best Regards, John
> > 
> > Voice US 845-435-9470  BluePages 
> > Tivoli OSLC Lead - Show me the Scenario

Social Web Architect
http://bblfish.net/