Re: Creation of Containers

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.

I wish I could explain this further in a way that made sense to people 
here, after all many of the people here fostered my own passion for the 
semantic web, and the web of data.

Best,

Nathan

Received on Wednesday, 7 November 2012 23:07:28 UTC