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

On 29 May 2013, at 16:35, Alexandre Bertails <> wrote:

> 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.
> 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.
> 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.
> I hope this is enough for discouraging people from making this a new
> entry in UC&R.


Thanks for those very good exmaples supporting the case for ISSUE-71 and 

> Alexandre.

Social Web Architect

Received on Wednesday, 29 May 2013 14:40:49 UTC