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

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> .

Wonder whether it is a valid user case ?

Best Regards,
Nandana