Re: Creation of Containers

Roger Menday wrote:
> On 7 Nov 2012, at 23:06, Nathan wrote:
> 
>> Richard Cyganiak wrote:
>>> On 7 Nov 2012, at 22:43, Nathan wrote:
>>>> Richard Cyganiak wrote:
>>>>> Niclas,
>>>>> Here's my (possibly flawed understanding):
>>>>> On 7 Nov 2012, at 21:38, Niclas Hoyer wrote:
>>>>>> is there a simple way to create a ldp container?
>>>>> No, the client can't tell the server to turn a resource into a container.
>>>>> The server decides what's a container, usually based on domain knowledge. A SIOC server would know that threads should be containers, and would automatically make the resource a container whenever a thread is created.
>>>>> Generic servers that don't have any domain knowledge, but are “just” “dumb” graph stores, can't really use containers.
>>>> By LDPR a client can PUT a representation which is considered an LDPC by any client doing a subsequent request on that LDPR.
>>> That's not doing any good if the server doesn't handle POST requests on that LDPR. The server can't handle POST requests unless it has some domain knowledge -- at least it needs to know what the URIs for new resources should look like.
>>>
>>>> Any "dumb" server can't stop that, can it?
>>> A dumb server can't stop a client from saying anything, whether it's true or not. What's your point?
>> My point is that I'm here in the hope that LDP will be a spec I can use 
>> for RWW, and more specifically for decentralized generic web accessible 
>> data storage providers which have some level of understanding of the 
>> data being used. As per the Socially Aware Cloud Storage and 
>> ReadWriteWeb design issues from TimBL a few years ago.
>>
>> However, the momentum of the group seems to be increasingly oriented 
>> towards providing a specification which is geared towards rather limited 
>> CRUD functionality for server side applications which expose (part of) 
>> their API as Linked Data.
> 
> Nathan, 
> 
> I share a similar opinion - sometimes the group seems to want to do WebDAV-LD - although I am sure these are early days for the work of the group. 
> 
> however, I don't quite see how your opinion above fits with your earlier statement about not wanting to use POST. 

POST is historicaly the domain of server side scripts which have some 
implementation based on magic, or out of band knowledge, rather than the 
specification of the mediatype. POST in LDP is exactly the same.

HTTP hides the implementation, mediatypes expose what can be done (in 
cases other than generic GET/HEAD/PUT/DELETE) - LDP does not have any 
mediatypes to expose this, and RDF is so generic that (without perhaps 
;profile=schema) you can't expose the information clients need to be 
able to update and control resources.

For example, how do you create a container, how does anybody know a 
container has specific functionality, what are the transfer protocol 
level indicators, where's the media indicators to drive the state?

Thus I suggest avoid POST, and anything which requires it.

Further, containers w/ POST (rather than weak aggregation w/ ontologies) 
make for a far more complex implementation, without much (if any 
benefit), and certainly no real increase in functionality. Other than 
perhaps the special use case of strong compositions which can be seen 
like foreign keys, 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 Wednesday, 7 November 2012 23:59:40 UTC