- From: Wilde, Erik <Erik.Wilde@emc.com>
- Date: Tue, 22 Jan 2013 11:21:52 -0500
- To: Henry Story <henry.story@bblfish.net>, "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>
- CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
hello henry. On 2013-01-22 15:03 , "Henry Story" <henry.story@bblfish.net> wrote: >On 22 Jan 2013, at 14:34, Ashok Malhotra <ashok.malhotra@oracle.com> >wrote: >>Erik's solution will work. >> You either POST to a collection which will create the LDPR >You POST a Graph or a binary to a collection, right? Those are pretty >much complementary classes of things. let's not mix the three cases we may want to clearly specify: 1. how to POST a self-contained entry. 2. how to POST an entry that's only protocol metadata and links to the entry's content. 3. how to POST something that's not RDF. for me, the simplest model is to treat 1 and 2 the same and simply distinguish them by what you're POSTing. like i said, the server doesn't even need to care, it behaves in exactly the same way. the only difference is in what you POST, and how the "complete entry" (LDP protocol data plus content) has to be retrieved by a client (one GET in the self-contained case, two GETs in the linked case). 3 is different because we're POSTing something that's a non-RDF media type. i still think atompub is a good model to look at: POST it to a special collection which handles non-RDF things (and advertises its supported media types through the LDP protocol), let the LDP server store the blob, and generate an RDF entry as a proxy. from then on, manage both concurrently, i.e. DELETEing one will DELETE the other. cheers, dret.
Received on Tuesday, 22 January 2013 16:22:49 UTC