W3C home > Mailing lists > Public > public-ldp-wg@w3.org > January 2013

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

From: Alexandre Bertails <bertails@w3.org>
Date: Wed, 23 Jan 2013 10:20:45 -0500
Message-ID: <50FFFFCD.9030206@w3.org>
To: Steve Speicher <sspeiche@gmail.com>
CC: Henry Story <henry.story@bblfish.net>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
On 01/23/2013 10:00 AM, 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.
>
> Note: we could do something similar for PATCH.

Sadly, some http clients in old browsers won't let you add custom
headers either. We may have to consider the URL hack as a fall-back
(this is a common problem in the web apis world).

>
>> 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.

These "non-member triples" could also be part of the request-body of
the MKCOL. This is actually much more important than it looks at first
sight. For example, Andrei and I have a use-case where we need to add
other triples to "configure" the container.

I can live with either 1.+fallback or 2., but I have a slight
preference for 1.+fallback as it makes the operation very clear, and
we can make decisions before looking at the body.

>
>> 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 ?

+1 to your 2 previous comments. I don't see any added value in 3. and
4., it's just more complicated for both the server and the client.

Alexandre.

>
>> Henry
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>
> Thanks for putting this out there, really helps move the discussion
> along with such good proposals.
>
> --
> - Steve
>
>
Received on Wednesday, 23 January 2013 15:20:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:44 UTC