Re: Missing use case for supporting ldp:membershipPredicate/Subject

Alexandre Bertails <bertails@w3.org> wrote on 05/29/2013 09:00:55 AM:

> From: Alexandre Bertails <bertails@w3.org>
> To: Arnaud Le Hors/Cupertino/IBM@IBMUS, 
> Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
> Date: 05/29/2013 09:08 AM
> Subject: Re: Missing use case for supporting 
ldp:membershipPredicate/Subject
> 
> On 05/29/2013 11:41 AM, Arnaud Le Hors wrote:
> > Alexandre Bertails <bertails@w3.org> wrote on 05/29/2013 07:35:01 AM:
> >
> >  > You just want to be able to conflate LDPC membership with your own
> >  > domain model. I still think this is not a good idea. Several people
> >  > made the case that mixing the LDP vocabulary and the domain one is
> >  > bad.
> >
> > I hear you but clearly others think otherwise and for that matter at 
the
> > last F2F we added membershipPredicateInverse reinforcing the desire to
> > provide flexibility at the cost of some additional complexity.
> 
> The issue was stated in the context of ldp:membershipPredicate. We can
> apply the same reasoning here and use something like rdfs:memberOf.

Sorry, I don't understand this. My point is that there was agreement we 
should provide ways to accommodate existing vocabularies and in fact we 
agreed to add flexibility in this regard. If we throw away that 
flexibility and decide to force people to use a specific predicate I don't 
see any reason to allow for rdfs:memberOf.

> ...
> I mean, we're still talking about it and Steve just proposed an item
> to be added in UC&R to back it up... For these reasons, I don't think
> it's too late to reconsider this "feature".

Indeed, it's not too late. As I've repeatedly stated anything in the spec 
can be changed if we choose to. This being said, unless we quickly settle 
on these issues we're going to be in trouble delivering on our charter.

> ...
> What I meant by fishy: the requirements put on a Linked Data client or
> a SPARQL client are too high for no good reason.
> ...
> There is complexity when you offer two different ways to do the same
> thing for no demonstrated value.

I know you're passionate but please respect others needs. Because 
something is of no use to you doesn't necessarily mean it has no value. 
"no good reason" "no demonstrated value" are assertions that are 
unnecessarily adversarial.

> All the examples that we've seen so
> far can be made way more simpler by using rdf:member everywhere.

Can you please tell me how you would do Example 3 from the spec without 
membershipPredicate and membershipSubject?

By the way, I'm wondering whether this isn't really a matter of a missing 
requirement rather than a missing use case. What I mean is that it seems 
to me that the question at hand is really whether we want to accommodate 
using existing vocabularies or not.  I think this applies to various use 
cases.

Regards.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group