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

On Wed, Jan 23, 2013 at 4:41 AM, Henry Story <> 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:

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:

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 <> .
>    The home document contains a link to the containerFactory
>    <> 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

Thanks for putting this out there, really helps move the discussion
along with such good proposals.

- Steve

Received on Wednesday, 23 January 2013 15:00:46 UTC