Re: Proposal for containers

On 30 Jan 2013, at 16:23, Ashok Malhotra <ashok.malhotra@oracle.com> wrote:

> OK.  Here goes
> 
> Container Model
> 
> A. Containers can contain containers
> Containers are LDPRs and should
> be added to contianers like any other LDPR.

yes, that follows from the minimal proposed ontology
http://www.w3.org/2012/ldp/track/issues/45
:-)

> 
> B. To add a container to a container, POST a (child) container
> representation to a (parent) container.

Though there is an issue as to whether the type of the resource should be specified or not in the HTTP Header eg:

Link: <<http://www.w3.org/ns/ldp#Container>; rel="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"

( AtomXML species these types in their content-type, which is the wrong place to do that. See:
http://www.w3.org/2012/ldp/wiki/ISSUE-37#POSTing_a_link_to_another_resource )

> 
> C. Thus, a container can contain a mix of members and containers.
> (Some of the members may be links to LDPRs.)

That is unclear. I think you mean
"(Some of the members can contain links to any resource)"

If so this follows the Simple Aggregation Proposal 
( http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal )
It turns out that at that level Atom is just a special case of that proposal:
since an Atom Entry is a special type of thing that can contain 
links to other things. An example in terms of Atom is shown here. 

http://www.w3.org/2012/ldp/wiki/ISSUE-37#POSTing_a_link_to_another_resource

The other option of having two types of links is more complex protocol wise.

> 
> D. If you GET all members of a
> container that has nested components, you get all the contents,
> members and containers at the top level.  That is, you do not get nested
> components.

That is also very vague. I assume you mean "If you GET an LDPC resource"..
yes, that is how one expects containers to behave, but

I think that is somewhat beyond the scope of what needs to be defined. 
When you GET a LDPC you get information about its contents (LDPRs and LDPCs, 
and other). Minimally, you could get just a link to the members. Of course
the risk is that in order to work out what these are pointing to
a client would have to download each resource to find out.  So it is a 
pragmatic thing to do to give some of the metadata needed for each resource.

Atom specifies a strict set of what is necessary. That is in atom every
resource MUST have a title, a summary or a content, an author... That is just
forced by the structure of the XML on them. This is sometimes awkward, such
as when one posts an image, and the server has to create an atom entry
but the server has to invent the title and the summary.

In any case this is why Atom People are very keen on profiles, that is specified
what a graph contains. One cannot really do this in the way they like because
owl will just allow you to reason on missing data. Here the data has to always
be fully specified. So one needs to have bound SPARQL queries on the data
to get what they want. 
Some more on profiles here, but it needs elaboration.
http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0339.html


> 
> Composition and Aggregation
> 
> E. If you delete a container you delete everything it contains.
> For nested containers this leads to a cascaded delete.

yes.

> 
> F. If you do not want a member to be deleted when the container is deleted,
> do not include the member in the containers but rather include a link to the
> member in the container.

very vague since this can also be mistaken with the ldp:contains proposal
someone needs to officially put forward.

What the Atom and the Simple Aggregation Proposal say is: put the link in 
the LDPR created by the container. That is move your link out by one.

> 
> E and F follow the AtomPub model.  

And the simple aggregation proposal. 


> There are other proposals
> -- distinct containers and aggregators, an attribute to distinguish
> between containers and aggregators.  We can debate these separately
> from A, B, C, D

yes, someone needs to put forward the proposal I had at one point 
mixed up wit Simple Aggregation, and which makes use of the ldp:contains
relation.

> 
> 
> All the best, Ashok
> 
> On 1/30/2013 4:06 AM, Steve Battle wrote:
>> Thanks for the clarification Ashok.
>> 
>> Given past confusion, I think it would be clearer if proposals about (container) composition and (RDF) aggregation were kept entirely separate.
>> Is it possible to disentangle them?
>> 
>> Steve.
>> 
>> On 30 Jan 2013, at 00:50, Ashok Malhotra<ashok.malhotra@oracle.com>  wrote:
>> 
>>> Steve:
>>> My bad -- I used the word collection when I should have used container.
>>> 
>>> It is about both composition and aggregation.  E and F address that.
>>> 
>>> All the best, Ashok
>>> 
>>> On 1/29/2013 7:25 PM, Steve Battle wrote:
>>>> Ashok,
>>>> I'm just seeking clarification here (no relevant issues are referenced in the subject line or body text).
>>>> 
>>>> 1) Is this proposal about composition (the model), or aggregation?
>>>> 2) Is a collection the same thing as a LDP container?
>>>> 
>>>> Steve.
>>>> 
>>>> On 29 Jan 2013, at 21:14, Ashok Malhotra<ashok.malhotra@oracle.com>   wrote:
>>>> 
>>>>> I think we are converging, so I'm writing this up as a proposal for collection
>>>>> handling.
>>>>> 
>>>>> 3. Can collections contain collections?
>>>>> 
>>>>> A. Yes, collections contain collections
>>>>> Collections are LDPRs and should
>>>>> be added to collections like any other LDPR.
>>>>> 
>>>>> B. To add a collection to a collections, POST a (child) collection
>>>>> representation to a (parent) collection.
>>>>> 
>>>>> C. Thus, a collection can contain a mix of members and collections.
>>>>> Some of the members may be links to LDPRs
>>>>> 
>>>>> D. If you GET all members of a
>>>>> collection that is nested, you get all the contents, members and collections
>>>>> at the top level.  That is, you do not get nested members.
>>>>> 
>>>>> E. If you delete a collection you delete everything it contains.  For nested collections
>>>>> this leads to a cascaded delete.
>>>>> 
>>>>> F. If you do not want a member to be deleted when the collection is deleted,
>>>>> do not include the member in the collection but rather include a link to the
>>>>> member in the collection.
>>>>> 
>>>>> I realize that E and F are controversial.  If you disagree.  Please indicate which
>>>>> parts of the proposal you disagree with.
>>>>> 
>>>>> -- 
>>>>> All the best, Ashok
>>>>> 
>> 
> 

Social Web Architect
http://bblfish.net/