Re: ISSUE-37 WAS:Proposal for containers

hello steve.

On 2013-02-01 15:20 , "Steve Battle" <steve.battle@sysemia.co.uk> wrote:
>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).

it was never my intention to say we should use atom or the atom ontology.
i was merely suggesting the use of the design pattern that atom has used.
and henry illustrated that by using his atom ontology, but i don't think
that means we should be using this ontology. at this point, we talk about
the model, not the exact representation.

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

true, but the difference is that "direct members" of a container *always*
are metadata resources following the metadata model, and thus this level
is homogeneous. one property then associates the metadata resource with
the content, and then it's up to the client to either embed the content,
or just provide a link. the LDP protocol then says that if there's just a
link, clients can GET the content there.

>The 'POSTing Binary content' example seems to be inconsistent with this
>approach as it is also referenced indirectly.

yes, that's the odd one out in this approach. however, it's just the
POSTing that works differently, and the implied semantics that the non-LDP
resource will be deleted along with the member, because both are managed
by the LDP service.

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

depends on what you mean with "consistent" ;-) what's consistent now is
that all members are LDP metadata, and that's a nice thing.

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

it's uniform in some way, and not in another. in the end, it's a matter of
taste, i guess. atom's rationale was to be able to guarantee that when you
GET a container, you GET a homogeneous set of resources in it, which you
can all treat generically. that's why there *always* is a metadata "proxy"
for these resources (apart from the fact that it is very convenient to
have a well-defined place where metadata for these often opaque formats
can be made accessible to LDP clients).

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

i think it really is a matter of taste. i am certainly used to the "expose
uniform resources that can be dealt with easily" school of thinking, and
thus prefer the "consistent" way of always exposing LDP resources. but
your argument is equally valid, you simply focus on a different aspect of
the model to argue for consistency.

cheers,

dret.

Received on Saturday, 2 February 2013 10:21:34 UTC