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

Hi Erik,

"Wilde, Erik" <Erik.Wilde@emc.com> wrote on 05/29/2013 08:54:54 AM:

> ...
> 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 membership predicate is defined for each container not for each 
resource.

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

The container you create to store all these resources can use whatever 
predicate you like.
I should however point out that since you want to link to existing 
resources rather than create them you wouldn't use POST.

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

Unfortunately it seems to me that a lot of this discussion is based on 
some misunderstanding. There is a single data model, which is defined by 
membershipPredicate and membershipSubject.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group