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

"Wilde, Erik" <Erik.Wilde@emc.com> wrote on 05/29/2013 10:51:01 AM:

> From: "Wilde, Erik" <Erik.Wilde@emc.com>
> To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, 
> Cc: Arnaud Le Hors/Cupertino/IBM@IBMUS
> Date: 05/29/2013 10:53 AM
> Subject: 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.

I agree that the container in which you find each resource provides a 
context but I don't see how using membershipPredicate makes a difference 
in this regard.

If all you do is archive the resource rather than the container you find 
it in you lose whatever context comes from the container. This is true for 
the membership predicate used as well as any other information the 
container may have about the 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.
> 
> 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?

Ok then. Just do what you said. POST to your archive container what you 
GET for each resource. There is no problem.

Consider the following example from the spec:

# The following is an elaborated representation of
#   http://example.org/netWorth/nw1
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology/>.
<>
   a o:NetWorth;
   o:netWorthOf <http://example.org/users/JohnZSmith>;
   o:asset 
      <assetContainer/a1>,
      <assetContainer/a2>;
   o:liability 
      <liabilityContainer/l1>,
      <liabilityContainer/l2>,
      <liabilityContainer/l3>.

<assetContainer/>
   a ldp:Container;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipSubject <.>;
   ldp:membershipPredicate o:asset.

<liabilityContainer/>
   a ldp:Container;
   dcterms:title "The liabilities of JohnZSmith";
   ldp:membershipSubject <.>;
   ldp:membershipPredicate o:liability.

If you GET any of the resources a1, a2, l1, l2, and l3 and add them to 
your own container you would have the exact same result as if the above 
was structured to use rdf:member only.

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

Yeah, that's why I was talking about linking rather than creating.

> thanks and cheers,
> 
> dret.
> 

--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group