Re: Proposal for containers

Yes, details need to be filled in.
I thought we'd try and get agreement on the skeleton
and then add the flesh.  Feel free to create a more
detailed proposal.
All the best, Ashok

On 1/31/2013 3:51 AM, Henry Story wrote:
> 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/
>

Received on Thursday, 31 January 2013 09:29:03 UTC