Re: Aggregate/Container

On Fri, Mar 8, 2013 at 6:38 AM, Henry Story <henry.story@bblfish.net> wrote:
> Changing the subject line, as this topic does not affect the intuitive
> requirement.
>
> On 7 Mar 2013, at 22:09, Roger Menday <Roger.Menday@uk.fujitsu.com> wrote:
>
>
> On 4 Mar 2013, at 09:24, Henry Story wrote:
>
>
> On 1 Mar 2013, at 19:40, Arnaud Le Hors <lehors@us.ibm.com> wrote:
>
>> From: Henry Story <henry.story@bblfish.net>
>> To: Raúl García Castro <rgarcia@fi.upm.es>,
>> Cc: public-ldp-wg@w3.org
>> Date: 03/01/2013 05:41 AM
>> Subject: Re: The Intuitive/ Requirement
>>
>>
>> On 27 Feb 2013, at 17:22, Raúl García Castro <rgarcia@fi.upm.es> wrote:
>>
>> ...
>> >> yes, but I think this could just as well lead one to the opposite
>> >> conclusion, namely that the aggregation model presented recently is
>> >> not intuitive.
>> >
>> > Well, but aggregation is what we already have in the current
>> version of the specification (Editor's Draft 27 February 2013).
>>
>> Oh, I am surprised that was put in, with so little support. I'll need to
>> look at that closer. But I am not sure it is incompatible with the
>> prosposition
>> put forward here as argued below...
>>
>> ...
>
> Hi Henry,
> Aggregation was added to the spec as a follow up to the decision to close
> Issue 34 on February 11. I see no evidence of having "little support". What
> are you referring to?
>
> http://www.w3.org/2012/ldp/meeting/2013-02-11#resolution_3
>
>
> I was thinking about the vote at
> http://www.w3.org/2012/ldp/meeting/2013-02-25#line0222
>
> "use John's proposed ontology with Aggregation renamed as
> AggregateContainer, Composition as CompositeContainer, and better
> documentation"
>
> which had 3 +1 and 8 +0 s
>
> which I don't consider to be anywhere close to overwhelming support.
>
> I think this made its way into the section 5.1here:
>
> [[
> The model for containers follow that of two distinct types: composition and
> aggregation. Due to composition constraints, the lifespan of the member
> resource must match that of its container and it a member resource can not
> be a member of more than one container. For both types of containers,
> members are o
>
> nly added by using POST, which both creates the resource and inserts a
> membership triple. A request to delete a composite container that has
> members, will result in all the members and the container itself will be
> deleted. A member resource is removed from a composite container by deleting
> the resource directly, which removes the membership triple from the
> container.
> ]]
>
>
>
> I some how had a feeling that what was being voted for at that point was
> for it be adopted as a point of discussion to focus on. I did not think that
> it was
> going into the spec as is.
>
>
> My understanding:  going forward with John's proposal was a way of breaking
> the issue-34 deadlock. It's not like we really agreed to it - It was just a
> new way of talking about it. As I see it, now that the text is written up in
> the draft, it is time to do as Arnaud said and review the text and raise new
> issues, etc.
>
>
> This seems to me to raise a few questions. If I look at the ontology I see
> that
>
> ldp:AggregateContainer     a :Class;
>               :subClassOf ldp:Container .
> ldp:CompositeContainer     a :Class;
>                :subClassOf ldp:Container .
>
> Some questions that occur to me:
>
> Are there containers that can be both AggregateContainer and
> CompositeContainer or are
> these non overlapping classes? Ie: is it true or false that
>
>    ldp:AggregateContainer owl:disjoingWith ldp:CompositeContainer .

For delete semantics, yes they are disjoint.

> (1) If false, then how would one know when deleting one of these containers,
> which of the members was also going to be deleted?

When deleting a ldp:CompositeContainer, all the members would be deleted.
When deleting a ldp:AggregrateContainer, a server may or may not
delete members.  We have not defined the needs around communicating
with the client what had been deleted.  David Wood had pointed out how
he is doing this today.
See 5.6 HTTP DELETE [1].

I could imagine that once we have a PATCH model in LDP, or some way to
affect membership of containers, that there would be restrictions on
modifying (addition) membership of ldp:CompositeContainers.

> (2) Can one transform an ldp:AggregateContainer into an
> ldp:CompositeContainer?

Spec doesn't say anything about this, so it is left open to
implementers I would think.  If it were me, I'd would allow some
ldp:CompositeContainers to be morphed into ldp:AggregateContainers by
simply allowing the type to be modified.  I guess the question is: do
we need to specify anything here? And if we did, what would be want it
to say?

> If so the question the question (1) becomes even more pressing
>
> Henry
>
>
> Roger
>
>
> Anyway, I don't think this is incompatible with the point I am putting
> forward here.
>
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>
>

[1] - https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#http-delete-1

--
- Steve

Received on Friday, 8 March 2013 13:41:26 UTC