Re: Feedback on Henry's proposal for ISSUE-34

I agree with Steve. In particular, I don't see why we need to introduce 
new predicates to indicate membership.

The spec currently defines ldp:membershipPredicate which you can use to 
specify which predicate you use with a default to rdfs:member.

Unless we want to support a mix bag type of collection in which some 
members are contained and others are aggregated (i.e., some are deleted 
and others aren't when the collection is deleted) we don't need to add 
anything else than what we have. I'd say let's simply reuse 
ldp:membershipPredicate for Aggregations.

In general, I think we should try and minimize the number of things we 
invent.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group


Steve Speicher <sspeiche@gmail.com> wrote on 01/18/2013 01:23:01 PM:

> From: Steve Speicher <sspeiche@gmail.com>
> To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, 
> Date: 01/18/2013 01:23 PM
> Subject: Feedback on Henry's proposal for ISSUE-34
> 
> Henry's simple aggregation proposal [1] is close to the model I have
> in mind.  I have a few comments:
> 
> 1) ldp:Collection - this seems unnecessary in vocabulary.  We now need
> to define semantics of it.  For talking/terminology it is ok.  it
> would be simpler to just have ldp:Container and ldp:Aggregation.  I
> don't really see one as a subclass as the other.
> 
> 2) Why do we need ldp:member and ldp:contains?  What if my model
> already has terms defined like foaf:knows?  Do I need to insert
> another triple for each entry of the container vs. just using
> ldp:containerMemberPredicate?  If I did have my foaf:knows, would it
> be expected that I would link to ldp:member?  If so simply use
> owl:SubPropertyOf ?
> 
> 3) What are the semantics of these collections?
> 
> <1> a :Collection;
>    :contains <a>;
>    :member <b>.
> 
> <2> a :Container;
>    :member <c>, <d>.
> 
> <3> a :Aggregation;
>    :contains <e>, <f>.
> 
> <4> a :Container, :Aggregation;
>    :contains <g>, <h>.
> 
> I'd recommend that if there is a conflict, then aggregation is the
> default.  Though I don't feel strongly about it.
> 
> 4) Can I convert a Container to an Aggregation (or vice versa)?  It
> would seem that it might make sense to go from Container->Aggregation
> but not the other way, otherwise we'd have to define a bunch of rules.
> 
> 5) Interaction model for resource creation: I would assume the way to
> create a resource and add it to a collection would not change for
> Aggregation, POST representation to collection, resource created and
> added to collection.  Right?
> 
> [1] - 
http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal
> 
> --
> - Steve Speicher
>