W3C home > Mailing lists > Public > public-ldp-wg@w3.org > January 2013

Re: ISSUE-37 WAS:Proposal for containers

From: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>
Date: Fri, 1 Feb 2013 00:48:15 +0100
Message-ID: <CAAOEr1nOjdJvUeYrffawz-5RaWi_JaxyLDpcwD4UJN4xp3LMbw@mail.gmail.com>
To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Hi,

On Thu, Jan 31, 2013 at 8:54 PM, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> One argument against introducing ldp:contains or any such new predicate is
> that we want to encourage reuse and this doesn't.
> I'm not really sure this is independent of ISSUE-37. As the draft stands
> it only supports composition and if that's all we end up with there won't
> be any confusion about what rdfs:member is about, will there?
>

I thought this is independent because effectively this proposal won't
change anything in the current spec regarding both data and interaction
models and it's just changing the default value of the membershipPredicate.
With the flexibility given by the membershipPredicate property of a
container I can still represent my containers the way I want even
using rdfs:member
predicate. Only advantage I see is this might help a bit to clearly
distinguish composition as discussed in [1,2] . But I agree with you,
whether it is necessary or not might depend of ISSUE-37.

I also agree with the argument about reuse but I think we use ldp:Container
and ldp:membershipPredicate instead of reusing rdfs:Container
and rdfs:ContainerMembershipProperty because their semantics might not be
exactly the same as the ones defined in the RDF Schema. So I personally
don't see a big issue if we have to introduce a default predicate if
necessary. But whether it is necessary or not is an open question.

Best Regards,
Nandana

[1] - http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0000.html
[2] - http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0004.html
Received on Thursday, 31 January 2013 23:49:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:44 UTC