Re: Creation of Containers

>>>>>>> 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.

Nathan, 

I think on the regular web, <form>s and POST work pretty well together (?)  

> POST in LDP is exactly the same.
> 

Well, at current status of POST in LDP seems very different ... and I do agree that there is some out-of-band knowledge required. Infact, this seems to be the big Elephant in the room at the moment ... i.e. how to improve on this. 

In my opinion (previously voiced) we can do something similar to forms in LDP --- forms for robots. 

regards, 
Roger

> 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.