- From: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>
- Date: Tue, 22 Jan 2013 19:04:40 +0100
- To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <CAAOEr1k+oUWB=+_=FEgjmu-A3bHKg8e-oY6MSUFsqNqK7BeNeA@mail.gmail.com>
Hi, > >If is something you POST to to create a collection, then is it not > >an ldp:Container? But if it is an ldp:Container then it's a bit odd > >that you are POSTing to another ldp:Container, in order to create a > >new container in your collection. > > it's what i called "collection factory" in my earlier email. i agree that > it would be rather odd to POST a request to create a new container to a > container, which is why i mentioned the übercontainer concept some people > have invented. we also could define that this resource does not support > GET at all (like mentioned above), and then we don't have this problem to > begin with. it's a container factory and nothing else. > This might not be the general case but when we map LDP applications in some domains, hierarchical collections are not odd I guess. In one concrete case that we are implementing we have, Products, Components, Bugs. Products contain Components and Components contain Bugs. So if I could just post to a collection and if the server is clever to know the one that is being created is a collection not a resource, I can POST a Component to a Product, and later on POST bugs to that created Component to create bugs on that. So the server allows clients to create new containers in controlled manner based on a pre-defined domain model. <p> a ldp:Container; a :Product; rdfs:memeber <p/c1>; rdfs:memeber <p/c2>. <p/c1> a ldp:Container; a :Component; rdfs:memeber <p/c1/bug1>; rdfs:memeber <p/c1/bug2>. <p/c1/bug1> a :Bug . However, I think this can be designed in alternative ways using either collection factories or using MKCOL. Best Regards, Nandana
Received on Tuesday, 22 January 2013 18:05:26 UTC