W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: Creation of Containers

From: Niclas Hoyer <niclas@verbugt.de>
Date: Wed, 07 Nov 2012 23:45:00 +0100
Message-ID: <509AE46C.6070700@verbugt.de>
To: Richard Cyganiak <richard@cyganiak.de>
CC: public-ldp-wg@w3.org
Richard, thank you for your fast reply.

> Generic servers that don't have any domain knowledge, but are “just” “dumb” graph stores, can't really use containers.

Why not? I thought about a more "general" implementation of a container 
that could be used in many, possibly nearly all use cases where a ldp 
container could be useful.

> The problem with this is that it doesn't tell the server where it's supposed to create new resources. A container can be POSTed to in order to create new resources, and the server needs to assign URIs to the new resources.

A simple implementation could just create new resources as subordinate 
of the container URI. With a URI template a user could tell the server 
more fine grained where to create new resources.

> A question though: Can't you solve it by having a sioc:Forum that is an ldp:Container that creates threads?

I think this just displaces the problem, because a client program maybe 
wants to create a new sioc:Forum and that needs to be created somehow.

> The very first container on the site perhaps has to be initialized by the server administrator when setting up the LDP server. Then, everything else can be created through that container. It's a bit like in a filesystem; the root already has to exist for you to be able to create new files or directories.

That is exactly what I understand by a "general" implementation. For 
example one could setup such a resource for a group like the ldp working 
group. This resource could then be turned into a container. If we e.g. 
want to add mailinglist functionality, one could create a new 
subresource, turn that into a container which is also a sioc:Forum and 
start messaging.
Received on Wednesday, 7 November 2012 22:45:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:33 UTC