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

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.

thanks and cheers,

dret.

Received on Wednesday, 29 May 2013 16:01:04 UTC