- 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