- From: Steve Speicher <sspeiche@gmail.com>
- Date: Fri, 18 Jan 2013 16:23:01 -0500
- To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
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:23:27 UTC