Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core]

hello arnaud.

On 2013-03-21 8:41 , "Arnaud Le Hors" <lehors@us.ibm.com> wrote:
>"Wilde, Erik" <Erik.Wilde@emc.com> wrote on 03/19/2013 12:05:39 PM:
>> 
>> as a side note, i still think that the simplest solution to all of that
>>is
>> to simply have a concept of linked vs. server-managed content and say
>>that
>> a DELETE on the container DELETEs everything managed in it. if content
>>was
>> POSTed to the server, it will get deleted. if content was linked from a
>> POSTed member, it remains unaffected. in either case, the member (the
>>LDP
>> metadata POSTed to the container) will get deleted if the container is
>> deleted. i still haven't seen any reason why we shouldn't go with the
>> simple semantics.
>I agree that the model you describe is more regular and simpler. One
>argument against it though is that it means the externally-managed
>resource isn't linked directly from the container but via an intermediary
>server-managed
> resource - similar to an atom entry.

yes, that's correct. i think that's a feature and not an argument against
it. it allows to manage and process LDP resources homogeneously, and at
the same time provides the unified interaction model that allows inline
RDF content resources or linked content resources of any kind to be
treated homogeneously.

> So, you would have something like this, assuming a container with two
>member resources, lm1 - local/server-managed, m2 -
>remote/externally-managed.
>
># http://server1.example.org/c
><> a ldp:Container;
>  rdf:member <lm1>;
>   rdf:member <lm2>.
>
><lm1> :title "a local member".
><lm2> owl:sameAs <http://server2.example.org/m2>.
>
>I chose to use owl:sameAs to link to the externally-managed resource but
>it could be anything else.

it should be something else. it should be the same relation that is
established when an inline resource is POSTed (and there i think it
wouldn't be sameAs). maybe ldp:content would be a possibility. fwiw, lm2
of course also could/should have a title, as http://server2.example.org/m2
can link to anything (such as a GIF), and thus any LDP data we'd like to
see should be managed by the LDP service.

>The point is that it is different from having this:
>
><> a ldp:Container;
>  rdf:member <lm1>;
>   rdf:member <http://server2.example.org/m2>.
>
><lm1> :title "a local member".

yes, and my point is that this is a good thing. but i guess there is no
correct answer where the difference is good or bad; it's a design choice.

>In the former, both resources are added via POST to the container, they
>both get deleted when the container gets deleted - meaning lm1 and lm2
>get created on POST and deleted on DELETE, m2 is left alone. This is
>simple and easy
> to understand. On the other hand, the client has to go through an extra
>hop (lm2 -> m2) to get to the actual resource (m2) that is meant to be
>listed as a member.

the member is actually still the thing that has been POSTed (and may have
a title, as mentioned above). only if a client wants to retrieve the
content (let's say that giant GIF), it needs to GET the content that's at
http://server2.example.org/m2

>In the latter, lm1 is created and added to the container via POST and m2
>is added via PATCH (the current draft doesn't support this today but with
>the resolution on PATCH that's an easy fix). The structure more
>accurately represents
> what is meant to be: m2 is a member of c (which is consistent with how
>the WG chose to handle binary data at the F2F: the binary blob is what
>gets linked from the container).

ok, so there may be something i need to get used to. does that mean that
when a non-RDF resource is used, it cannot have any metadata associated
with it? if no, i think that's a not-so-great design. if yes, then i need,
from REST's point of view, two resource URIs i can interact with: one to
get the metadata, one to get the content. the latter is linked from the
former. and btw, absolutely nothing prevent us from designing the
container representation in a way that the link to the content is also
included (i.e., inlined) in a container listing. that way, no additional
GETs are necessary at all.

REST gives us a lot of freedom in designing hypermedia affordances: we
decide on scenarios we want to support, and then we design representations
to guide clients effectively (using typed hyperlinks) through those
scenarios. if the WG feels that a roundtrip for GET container, GET LDP
resource, GET content is unacceptable, then we design the GET container
representation so that the content links are embedded.and btw, that's what
atom does and thus it doesn't have these additional roundtrips:
http://tools.ietf.org/html/rfc4287#section-4.1.3.2

cheers,

dret.

Received on Friday, 22 March 2013 04:57:03 UTC