- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Sun, 25 Oct 2015 18:34:15 +0100
- To: Tom Johnson <tom@dp.la>
- Cc: Robert Sanderson <azaroth42@gmail.com>, public-ldpnext@w3.org
- Message-ID: <CAKaEYhLKUPKCdKafqCEJfmCb0cER74NczJhqK8uH_5=YiWjCjQ@mail.gmail.com>
On 25 October 2015 at 18:09, Tom Johnson <tom@dp.la> wrote: > Hi Rob, > > Your reading aligns with mine. > > In Lamprey[0], the default behavior is to create a new, uncontained > resource with the specified interaction model at the PUT target. This makes > it easy to create new "root" containers, or free-floating direct/indirect > containers. > > I know that Marmotta takes a different tack where, in your example, > /foo/bar would be contained in /foo. I believe it errors if you try to use > PUT to create, e.g., /foo/not-a-container/bar. > > Are there other behaviors in existing implementations? What are the > trade-offs? > " An alternative, though not standard way of creating new resources is to use HTTP PUT. Although HTTP PUT is commonly used to overwrite resources, this way is usually preferred when creating new non-RDF resources (i.e. using a mime type different than *text/turtle*). REQUEST: PUT /picture.jpg HTTP/1.1 Host: example.org Content-Type: image/jpeg ... RESPONSE : HTTP/1.1 201 Created " Read more at: https://github.com/solid/solid-spec > > [0] https://github.com/ruby-rdf/rdf-ldp/ > > On Sun, Oct 25, 2015 at 1:07 AM, Robert Sanderson <azaroth42@gmail.com> > wrote: > >> >> Am I correct in my reading that if there is a container /foo and I use >> PUT rather than POST to create a resource /foo/bar, then it is undefined in >> the specification whether that new resource is ldp:contained by the >> container? >> >> Justification: >> >> 5.2.4 does not mention using PUT to create new resources, just specifies >> behavior for updating resources. >> 5.2.3 only talks about POST in terms of adding new ldp:contains triples >> 4.2.4.6 specifically allows creation of resources via PUT >> >> Bug, or intentional loophole? >> >> Rob >> >> -- >> Rob Sanderson >> Information Standards Advocate >> Digital Library Systems and Services >> Stanford, CA 94305 >> > >
Received on Sunday, 25 October 2015 17:34:44 UTC