Re: proposal for refactoring Containers

On February 23, 2014 11:50:57 AM EST, Ashok Malhotra <ashok.malhotra@oracle.com> wrote:
>If a ldp:Container is deleted are all its contained resources deleted
>as well?

This proposal is agnostic on that.  

I think it would help people if we explained that servers might transfer the contained Resources to another container, or leave them orphaned in no container.

At some point I'd like to see this made explicit to clients, and thus give clients a way to request a particular behaviour.

The design that comes to my mind is:

<> a ldp:DeleteContainedOnDeleteContainer.

And

<> a ldp:TransferContainedOnDeleteContainer;
   ldp:onContainerDeleteTransferTo <other container>

And

<> a ldp: leaves orphans on delete container.

But I haven't thought about it a lot.


>We have discussed containment vs. membership (what you call selection)
>before and I have maintained that this is a fundamental dichotomy that
>should
>be formally supported.

Understood.

    - Sandro

>All the best, Ashok
>
>On 2/23/2014 11:01 AM, Sandro Hawke wrote:
>> Thinking more about weak aggregation vs strong containment, I find my
>preference would be to think of them as two separate things: containers
>(which manage the lifecycle of the things in them) and selections
>(which manage views of information about multiple things). Mostly I'd
>expect to use one or the other. Often I'd want something that was both,
>because I want unified access to selected information about the managed
>resources.
>>
>> It would be quite a stretch, however, to imagine I'd want something
>that combined them both independently. That would be what's in the spec
>today: a thing that isn't a collection but rather holds two different
>collections at once, neither of which has its own identity. You don't
>iterate over an ldp:container, you iterate over either its
>containedResources or its members.
>>
>> Still, I can live with that. It works. It's like a pen that's also a
>screwdriver. You can use it as a pen. You can use it as a screwdriver.
>Ontological it's a bit confusing, and one might prefer to think of it
>as a new kind of tool that has a pen part and a screwdriver part. But
>if I need to write something, I can use it, and if I need to open up my
>computer, I can use it for that, too.
>>
>> The problem with this combined tool, beyond a few mental gymnastics,
>is that it's going to make it harder to make it a good pen and a good
>screwdriver. Right now, you kind of get ink on the screws sometimes.
>That is, it's not clear how post and delete (containment operations)
>interact with the membership triples outside of a BasicContainer. We
>can clear that up, but I'm sure as we add more features in the future,
>this mashup design will keep making it harder. (I see how it probably
>complicates paging, access control, and subscribing to changes, just to
>name my three favorites.)
>>
>> I've sketched out how I think it should probably look:
>https://www.w3.org/2012/ldp/wiki/Collection_Types
>>
>> With enough encouragement, I can figure out the exact spec changes.  
>I think they're mostly editorial, but a few ldp: terms would probably
>change.
>>
>>      -- Sandro
>>
>>

Received on Sunday, 23 February 2014 17:19:11 UTC