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

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.

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

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

> 
> 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. :-)
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group