Re: ISSUE-37 WAS:Proposal for containers

On 31 Jan 2013, at 22:05, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Steve Battle <steve.battle@sysemia.co.uk> wrote on 01/31/2013 12:10:06 PM:
> 
> > From: Steve Battle <steve.battle@sysemia.co.uk> 
> > To: Arnaud Le Hors/Cupertino/IBM@IBMUS, "public-ldp-wg@w3.org" 
> > <public-ldp-wg@w3.org>, 
> > Date: 01/31/2013 12:11 PM 
> > Subject: Re: ISSUE-37 WAS:Proposal for containers 
> > 
> > On 31 Jan 2013, at 19:54, Arnaud Le Hors <lehors@us.ibm.com> wrote: 
> > 
> > One argument against introducing ldp:contains or any such new 
> > predicate is that we want to encourage reuse and this doesn't. 
> > I'm not really sure this is independent of ISSUE-37. As the draft 
> > stands it only supports composition and if that's all we end up with
> > there won't be any confusion about what rdfs:member is about, will there? 
> > 
> > My understanding is that the spec being silent on aggregation only 
> > means that it places no constraints on the way that users are able 
> > to create their own RDF aggregations. 
> 
> Indeed. 
> 
> > Therefore, there is every chance that the existing composition model
> > can be confused with user aggregation unless it introduces its own 
> > vocabulary as proposed. 
> 
> Since one can choose to use different predicates to indicate membership in a container people can't - and shouldn't! - rely on the predicate being used to figure out whether they are dealing with an LDPC or not. They need to look at whether the resource is of class ldp:Container. 

I agree with you if the issue is that of determining the resource type. However, this proposal addresses a different concern, i.e. that if predicates like rdfs:member are used for composition then this makes it difficult to distinguish between a resource POSTed to the container (see Ashok's proposal item B.), and a resource linked to the container using rdfs:member (see Ashok's proposal item F.). 

I would like to propose this a way to ensure that composition and aggregation remain orthogonal.

> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> > 
> > Steve.