- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Thu, 8 Nov 2012 00:48:17 +0000
- To: nathan@webr3.org
- Cc: Roger Menday <roger.menday@uk.fujitsu.com>, Niclas Hoyer <niclas@verbugt.de>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Nathan, On 7 Nov 2012, at 23:58, Nathan wrote: > For example, how do you create a container, You don't. The server decides what becomes a container. > how does anybody know a container has specific functionality, The only specific functionality of a container is that you can POST to it in order to create a new resource with a server-assigned URI that will be connected to the container (or its “subject resource”) via a specified property. Clients know this because the resource is typed as an ldp:Container, and the property (and optionally, the “subject resource”) are listed with well-known properties in the ldp: namespace in the container's description. (There's paging, which is an open issue. It can be indicated by a hyperlink with a specific property in the ldp: namespace that has the semantics, “go here to fetch the next page”. Clients know about the paging functionality because the property is present in the resource's description.) > what are the transfer protocol level indicators, What does that mean? > where's the media indicators to drive the state? What indicators beyond those listed above are necessary? > Thus I suggest avoid POST, and anything which requires it. Isn't this circular reasoning? “RDF is too generic. Therefore, it can't properly describe how to control resources via POST. Therefore, we should avoid POST and anything that requires it. Therefore, we shouldn't define the LDP vocabulary that solves the problem of RDF being too generic.” > Further, containers w/ POST (rather than weak aggregation w/ ontologies) make for a far more complex implementation, It's an implementation that every kid can cobble together in two hours with PHP. > without much (if any benefit), and certainly no real increase in functionality. How do let the server assign URIs without the use of POST? This may not be a use case that you have, but it's a use case that others have. > Other than perhaps the special use case of strong compositions which can be seen like foreign keys, I don't understand the analogy with foreign keys. I also note that the only thing that POST *is* used for in LDP (post F2F resolutions) is for creating resources in strong composition, so I'm not really sure any more what you're actually arguing against. Best, Richard > or as using transactions to keep things neat and tidy. > > I'm sure dret will be able to explain that better than I can. >
Received on Thursday, 8 November 2012 00:48:42 UTC