Re: composition and aggregation

hello henry.

On 2013-01-29 17:28 , "Henry Story" <henry.story@bblfish.net> wrote:
>When I do an HTTP GET on your Container I need to be able to distinguish
>which things are contained in the container and which things are linked
>from it. So assuming your http://my.example/wilde/ container returns
>G1 = {
>      <> a ldp:Container;
>         rdfs:member <friends>, </joe> .
>}
>Then how would an agent know which of <member> or </joe> was
>a contained element, and which one was linked?

it wouldn't, but why would that be a problem? notice that in the proposal
i have made, <friends> probably wouldn't be in there, because members
always would be managed by the server. so you would get something like
this:

<> a ldp:Container;
   rdfs:member </jim>, </joe> .


and then when GETting /jim, the content about jim would be embedded in
jim, whereas when GETting /joe, the content would be linked, and you would
need to GET /joe's content with an additional GET. we could of course, and
we probably should, expose the content triples in the collection listing
already, so that we would reduce the number of required GETs.

>Now a client can tell which of those resources if deleted from
><http://my.example/wilde/> would in fact be removed. The answer
>is <friends> would be removed. Also you know that if you send
>a DELETE to <friends> it will be removed from the ldp:Container.

in my proposal, both /jim and /joe get deleted, so there's no need to make
any statements about who gets deleted. everybody gets deleted. the only
thing that will not get deleted is /joe's content, but it will lose its
status as being /joe's content anyway and simply will continue to happily
live as a web resource.

>So perhaps you POST
>P1 = {
>   <> ldp:content <http://bblfish.net/> .
>}

that, plus all the other metadata that's required by the LDP protocol,
plus all the optional metadata i am planning to store.

>to  <http://my.example/wilde/> then a new GET on
>that resource will return
>G3 = { 
>    <> a ldp:Container;
>        ldp:contains <friends>;
>        ldp:link </joe>, <http://my.example/wilde/> .
>}

now i am very confused. http://my.example/wilde/ is the container, right,
because you POSTed an entry to it. upon success, you will get a new
resource, maybe http://my.example/wilde/42, that will contain the graph
(maybe with whatever our protocol says we want to add, such as a link to
the container) you POSTed.

have you made an error here when adding ldp:link
<http://my.example/wilde/>? i really don't understand why you would GET
this when GETting the container.

>Ok so for an embedding example now:
>Perhaps you post (forgetting namespaces for the moment )
>
>P2 = {
><> ldp:content [ a animal:Cat;
>                 foaf:name "kittykitty"
>                 foaf:depiction <img/kity.jpeg> ]  .
>}
>So now because there is additional information on the blank node that
>represents an animal,
>Your idea is that a new GET on <http://my.example/wilde/> will return
>G3 = {
>    <> a ldp:Container;
>        ldp:contains <friends>, <kitty>;
>        ldp:link </joe>, <http://my.example/wilde/> .
>}

you're assuming the server assigned "kitty" as the entry URI? then yes for
that part, but again i don't understand the container resource linking to
itself.

>Where a GET on <http://my.example/wilde/kitty> will return perhaps
>K1 = {
>  [] foaf:name "kittykitty";
>     foaf:depiction <img/kitty.jpeg> .
>}

nope, we GET an entry, so we GET the entry's metadata (since you created
none, maybe just whatever the server assigned, let's say a creation date),
plus the content still represented in the same way as you POSTed it. K1 is
an invalid LDP entry, because each LDP entry MUST contain exactly one <>
ldp:content triple.

>Anyway, is this what you are getting at or am I misunderstanding what you
>are thinking of? 

i cannot really tell because i am not fully following the examples you
have included. but it seems you have a fairly different model in mind from
the one i am trying to explain.

cheers,

dret.

Received on Tuesday, 29 January 2013 17:23:58 UTC