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

hello arnaud.

On 2013-05-29 10:11 , "Arnaud Le Hors" <lehors@us.ibm.com> wrote:
>>- 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.

that was my understanding, but when i get those five resources, they come
from different contexts (with part of that context being established by
the membership predicate, which can differ on a per-container basis). my
worry is how much of this external context is necessary to actually handle
these resources as LDP resources.

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

no, i don't want to link to existing ones, i really want to archive the
ones that i found, because they are of value to me. so i want to use POST,
and ideally i want to be able to POST the same resource representations
that i retrieved by GET, right? can i POST these five? if not, why can't i
freely compose LDP resources? and what would i need to do to allow me to
archive these resources?

[[ and to make this discussion more focused, let's ignore the fact if and
how i might want to keep the original URI of the resources. i am fine if
they lose their previous identity, i just want to archive them for my
future use in my personal archive LDPC. ]]

thanks and cheers,

dret.

Received on Wednesday, 29 May 2013 17:51:46 UTC