Re: ISSUE-36: Summary of ways of making containers

On Wed, 23 Jan 2013, Steve Speicher wrote:

> On Wed, Jan 23, 2013 at 4:41 AM, Henry Story <henry.story@bblfish.net> wrote:
>> In summary here are the proposed ways of allowing applications to make
>> containers:
>>
>> 1. Using the MKCOL HTTP Method from WebDAV
>> ------------------------------------------
>>
>>   - Works like GET/PUT/POST/DELETE .
>>   - Implemented in 100s of millions of clients on MS-Windows, OSX, Linux, and other Unixes for WebDAV
>>   - RFC: http://tools.ietf.org/html/rfc4918#section-9.3
>>
>
> Seeing the value in this.  If we want to tunneling the MKCOL through
> POST we could do that as well, something like X-HTTP-Method-Override:
> MKCOL.

That kind of tunneling is a hack that we should not recommend in the LDP 
spec.

> Note: we could do something similar for PATCH.
>
>> 2. POST + server looks at content of graph
>> ------------------------------------------
>>
>>    if graph posted to ldp:Container </satellite/x4354/> contains the triple
>>
>>       <> a ldp:Container .
>>
>>    the server makes a container.
>>
>
> Makes sense.  Of course, client could add some non-member triples as
> this point as well.
>
>> 3. Link from LDPC to factory
>> ----------------------------
>>
>>    The container </satellite/y500/> contains a link to a factory <makeAnotherContainer> .
>>
>>    <> a ldp:Container;
>>       ldp:containerFactory <makeAnotherContainer> .
>>
>> <makeAnotherContainer> would then be something else besides an LDPR or an LDPC.
>> It  would need to describe itself as a factory and tell you for which collection it was a
>> factory for. One can then POST something into the <makeAnotherContainer> factory in
>> order to create a collection inside the original </satellite/y500/> .
>>
>
> I guess I don't fully understand why adding this overhead helps.
>
> This seems to set us up to need a "Factory" predicate for any kind of
> thing that can be created.  Perhaps we could instead say way kind of
> thing can be created in this container.
>
> For example,
>
> <> a ldp:Container;
>       ldp:canCreate ldp:Container, oslc:ChangeRequest .
>
> Then one could look up these Classes to see what they look like.  This
> may be something better for LDP 2.0 (for lack of better name).  I have
> a need for something like this anyway, knowing what kinds of things
> the container accepts.  Disclaimer, the name ldp:canCreate is nothing
> I'm emotionally attached to.
>
>> 4. Link from LDPC to home document that links to factory
>> --------------------------------------------------------
>>
>>    The container contains a link to the home document
>>
>>    <> a ldp:Container;
>>       ldp:homeDocument <http://nasa.gov/satellite/y500/homeSweetHome/> .
>>
>>    The home document contains a link to the containerFactory
>>
>>    <http://nasa.gov/satellite/y500/homeSweetHome/> a ldp:HomeDocument;
>>       ldp:containerFactory <makeContainersFor> .
>>
>>    Sending a POST to the containerFactory can create a container, but requires
>> telling the container factory which container one wishes to create the container
>> in. The containerFactory needs to describe also which containers it can create
>> a factory for.
>>
>
> I'm not sure why the home document is needed or anything special.
> Isn't it just a ldp:Container ?  Couldn't another application
> somewhere create a ldp:Container which then includes the first ?
>
>> Henry
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>
> Thanks for putting this out there, really helps move the discussion
> along with such good proposals.
>
> --
> - Steve
>
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Wednesday, 23 January 2013 15:44:49 UTC