Re: MKCOL for making collections

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