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

On 05/29/2013 01:01 PM, Arnaud Le Hors wrote:
> 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.

What I meant is that people were already assuming that this was part
of the spec (it was in the Submission) and that we had to deal with
it. Most of us (me included) didn't imagined the consequences of
keeping it and we kept specifying on top of it.

But we now have a better understanding of the consequences for this
approach.

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

Agreed. Do you see what I meant with taking some distance? :-)

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

In the light of the recent threads and examples, I'd be interested in
knowing if people would considerer dropping the support for "existing
vocabularies". I would even go further with adding some text stating
the goal of not mixing the LDP vocabulary with domain-based ones.

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

You're right. Please accept my excuses if I've offended anyone with
these words.

But it's not only about passion. We have work in progress for the
Linked Data client, and I see no good way to be implement it without
having a state in it, and with no guaranty to be correct [1].

[1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0277.html

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

I wouldn't.

For the very same reasons, I wouldn't use any feature that relies on
the domain model. And with this approach, note that you wouldn't be
able to distinguish the membership if you had chosen the same
membershipPredicate, which is another serious drawback.

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

Existing vocabularies were not thought with LDP in mind as LDP didn't
exist. So I'm not sure what it means to accommodate the use of these
existing vocabularies.

Alexandre.

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

Received on Wednesday, 29 May 2013 18:09:30 UTC