- From: Alexandre Bertails <bertails@w3.org>
- Date: Wed, 23 Jan 2013 10:20:45 -0500
- 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