Re: Aggregation: simple proposal

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

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