- From: Arnaud Le Hors <lehors@us.ibm.com>
- Date: Fri, 18 Jan 2013 13:56:14 -0800
- To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <OFF002E1D8.9BAE240F-ON88257AF7.00766868-88257AF7.007881B6@us.ibm.com>
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 >
Received on Friday, 18 January 2013 21:56:51 UTC