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

On 20 Jan 2013, at 10:52, Nandana Mihindukulasooriya wrote:

> Hi,
> 
> On Sat, Jan 19, 2013 at 3:39 PM, Steve Speicher <sspeiche@gmail.com> wrote:
> forgot to reply-all
> 
> On Sat, Jan 19, 2013 at 8:57 AM, Steve Speicher <sspeiche@gmail.com> wrote:
> > On Fri, Jan 18, 2013 at 6:11 PM, Henry Story <henry.story@bblfish.net> wrote:
> >>
> >> On 18 Jan 2013, at 22:23, Steve Speicher <sspeiche@gmail.com> wrote:
> >>
> >>> 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 ?
> >>
> >> I should perhaps have chosen a different namespace for these, and not
> >> ldp. Perhaps ldpTst or something.
> >>
> >> The point of having these three classes, and these two relations,
> >> is just to help with clarity. These don't have to be adopted
> >> officially. Having a ldp:contains and an ldp:member, and having
> >> these have different rdf:domains, does not mean we cannot then make
> >> them owl:sameAs some well known vocabulary later, or adopt them for
> >> ldp.
> >>
> > One primary difference with the owl:sameAs approach is the global
> > nature of that statement.  Perhaps there are cases with my specific
> > application where the predicate is only a 'containment' predicate for
> > the current associated container, not every and all instances.  The
> > ldp:memberPredicate minimizes the scope.
> 
> I agree with Steve, it is quite useful for us to tell which is the 'containment' predicate or 'aggregation' for each instance of a container or an aggregation. I think current spec does a good job here with the ldp:memberPredicate and I think it would be nice to adapt the same for the aggregation too. However, I think this knowledge is only important to the server if it provide any additional functionality using this property like for example the current ldp:Container allows paging, getting only the non-member properties, etc. Are we planning to provide such functionalities with ldp:Aggregation ?
> 
> I tried to think of any use-cases of a hybrid collection which has to contain both 'containment' properties and 'aggregation' properties but I couldn't think of any reasonably good example from real world. In the implementation-wise, I agree with Henry that there are very good reasons to keep them disjoint such that the behavior on POST ( ldp:Container creating new resources vs ldp:Aggregation just adding new triples to the aggregation) and how the relative URIs are resolved, etc i.e. ldp:Aggregation behaves like an LDPR not LDPC. If they are disjoint, the same ldp:memberPredicate (or a better renamed one) can be used for both. I don't know whether they should have diffrent default values depending on whether the subject is an ldp:Container or an ldp:Aggregation.
> 
> When I was thinking about the use cases, One that came to my mind where it can have two 'containment' properties. For example, if I have a group where I have both admins and users and I want to make it an aggregation. e.g.
> 
> <group> a :Group; 
>    :admin <a>, <b> ;
>    :user <c>, <d> .
> 

A User (a,b,c or d) is Composed inside a System resource. Inside a Group resource, there are regular links :admin and :user, referencing the User resources.  Is that what you are saying above ?  


What about an example of mixed composition/aggregation from the Bug Tracker scenario? Usually the :has_bug relationship between a Tracker and a Bug is Composition (and one could argue that is the Tracker is deleted, all the Bugs inside are deleted too). However, it could be that a Tracker :has_bug on a separate system, i.e. Bugs are linked by composition and 'aggregation'. 

(???)  

Roger


> Wonder whether it is a valid user case ?
> 
> Best Regards,
> Nandana