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

On 05/29/2013 11:54 AM, Wilde, Erik wrote:
> hello arnaud.
>
> On 2013-05-29 8:41 , "Arnaud Le Hors" <lehors@us.ibm.com> wrote:
>>> 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. :-)
>
> fishy or not fishy, i have been wondering about the following scenario for
> a long time and it seems to be kind of a rather simple scenario, and i am
> still wondering how this is supposed to work, given the non-fixed data
> model:
>
> - a client GETs five LDP resources because it found them by searching
> through containers, or simply because it was given five URIs that identify
> those resources.
>
> - let's assume those resources are in different containers (and/or maybe
> on different LDP servers) and all of them use different membership
> predicates (and let's say one isn't using one at all).
>
> - the client now wants to add (POST) those resources to a container where
> it keeps track of really interesting resources it found. does the client
> have to rewrite the resources? if not, how are the different membership
> predicate mappings handled by the container? if yes, what are the rules
> for this rewriting and could they have some unfortunate side effects?
>
> it seems to me that if LDP is supposed to become a standardized service,
> this kind of interoperability is fairly fundamental, and i still haven't
> quite wrapped my head around how this works with the "let's allow
> everybody to have their own data model" approach.

With the current approach, you cannot predict which membership
properties will be created, so in practice you never have full control
over the desired data model.

Maybe we need a slug-membership as well? Ohhh, that's fishy as well :-)

Alexandre.


>
> thanks and cheers,
>
> dret.
>
>

Received on Wednesday, 29 May 2013 16:08:43 UTC