RE: ISSUE-37 WAS:Proposal for containers

> -----Original Message-----
> From: Henry Story [mailto:henry.story@bblfish.net]
...
> On 1 Feb 2013, at 11:08, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:
> > to avoid confusion, what's the problem of using rdfs:member to always
> > represent membership, ldp:content to always represent member content,
and
> > then to distinguish between containment and aggregation simply by
letting
> > the user decide whether they embed the content or not when creating
new
> > members?
...
> - The Atom-Pub solution does not require this distinction since it
creates
>   an indirection from Container to entry, and places the links in the
Entry.
>   See the examples "Posting a link to another resource"
>
http://www.w3.org/2012/ldp/wiki/ISSUE-37#POSTing_a_link_to_another_resourc
e

So, is the difference you're pointing out above that the use of
atom:content is merely contingent to the example (ie. you're not mandating
use of atom),
and there's no requirement to define ldp:content (any indirection will
do).

What seems to be identical in both your positions is that all direct
members of the container are deleted on deletion of the container
(containers only do composition).
So, If we need aggregation then we can do it with indirection (e.g.
atom:content or ldp:content).

I agree that this approach would obviate the need for ldp:contains, as no
such distinction would be necessary.

The 'POSTing Binary content' example seems to be inconsistent with this
approach as it is also referenced indirectly.
Could it be made consistent with your approach if the <mouse.gif> content
were the direct member of the container, and the subject of the metadata
about it.
In the excerpt below, <mouse.gif> will definitely be deleted along with
the container, as it is a direct member (of the composition).
This seems to be much more uniform:

<> a ldp:Container;
   rdfs:member [ owl:sameAs <entry1>;
                 a :Entry;
                 :author  <http://joe.example/#i>;
                 :title "Atom Powered Robots Run Amok";
                 :id
"urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"^^xsd:anyURI;
                 :updated "2013-01-13T18:30:02Z"^^xsd:dateTime;
                 :summary "Some text." ],

               [ owl:sameAs <entry2>;
                 a :Entry;
                 :author <http://joe.example/#i>;
                 :id "http://atom.example/entry2";
                 :title "picture of a cat";
                 :updated "2013-01-13T18:30:02Z"^^xsd:dateTime;
                 :summary "Cat with a funny hat made of bread";
                 :content <http://cat.example/cat1.jpg> ],

	<mouse.gif> .

<mouse.gif>;
                 a :Entry;
                 :author <http://joe.example/#i>;
                 :id "http://atom.example/entry3";
                 :title "mouse";
                 :updated "2013-01-13T19:10:02Z"^^xsd:dateTime .

The naming of the gif honours the slug; the important point is that the
gif is named by the container, and it isn't an indirect link.
I guess you could also add the content type to the gif metadata.
I recall some conversation earlier on about whether the binary should be
the subject of the metadata, or the object of a :content link, but doesn't
this way round make more sense in the context of your proposal?


Steve.

Received on Friday, 1 February 2013 14:21:27 UTC