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.

>
>  >
>  > Let's say I have a Linked Data client, which is just allowed to follow
>  > links and dereference URLs. Now, I have to search for
>  > ldp:membershipPredicate -- if it exists... -- before I know how to
>  > find the members. That's some extra logic, I would prefer not having
>  > to do that. That would simplify everything.
>
> There is no doubt that limiting the membership predicate to rdf:member
> would be simpler.
> But as always there is a trade-off between simplicity and flexibility.
> We appear to have people on both sides of the fence on this particular
> issue and I note that removing these features is going against the
> direction the WG has been going, as noted above.

I'll be honest: I hadn't paid attention to the use of
ldp:membershipPredicate at the time and I've realized the implications
only recently. I may be alone there (I'm not) but I wouldn't assume
that people really wanted to conflate the LDP vocabulary with the
domain one.

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

>
>  >
>  > Also, what happens if there is both rdfs:member and
>  > ldp:membershipPredicate? The problem is that we cannot make a choice
>  > easily. We have to be ready to change the state of the client
>  > depending on some property, which may happens at any moment (the
>  > content could be streamed). This is an extra constraint on the client
>  > that seems not necessary.
>  >
>  > Here is another argument. Let's say you want to extend an LDPC with
>  > some SPARQL capabilities (that's very natural), where the LDPC is the
>  > default graph and its members are named graphs. Now try to think about
>  > the query that would give you these members and you'll see that there
>  > is something wrong, as you need to handle two cases: with and without
>  > ldp:membershipPredicate. For me this is really fishy.
>
> There is nothing fishy about it. If the spec provides an indirection you
> have to deal with it and it's more complicated than if it doesn't. There
> is nothing new here. :-)

What I meant by fishy: the requirements put on a Linked Data client or
a SPARQL client are too high for no good reason.

>
>  >
>  > I hope this is enough for discouraging people from making this a new
>  > entry in UC&R.
>  >
>  > Alexandre.
>
> I can certainly see how one might find this is an unnecessary complexity
> if they have no use for it. What we need to figure out is whether
> simplifying the spec the way you suggest makes it useless to some. The
> simplest spec is an empty one but it isn't very useful. :-)

There is complexity when you offer two different ways to do the same
thing for no demonstrated value. All the examples that we've seen so
far can be made way more simpler by using rdf:member everywhere.

Alexandre.

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

Received on Wednesday, 29 May 2013 16:02:13 UTC