Re: interaction with a bug-tracker LDP service

hi Nandana, 

> > My understanding is that POST is a mechanism to create _new_ resources
> > within containers.
> 
> The collections contain *links*, and so, POST is actually creating a (additional) link.
> So this is consistent.
> 
> I think how you create *links* and retrieve links is one of the main differences between your proposal and the simple proposal (and also the current spec.).  The way I think (it might be wrong) is that arc between two nodes in a graph is a link.  So in RDF, any triple that connects two resources is a link. However, in the web that triple (*link*) is represented by the state of a resource with a URI but not a resource itself.

Yes! And, it order to manage it (the link), it is made a resource - not a resource in the primary LD layer, but in a secondary layer of LDP LD (which can be revealed). When the link is a resource then the link between two resources can be removed without removing the resources themselves. And for creating the link, the normal container mechanism is used - the container represents *all* links of a given type, and append to the container therefore creates a new link with that type. 

> So adding a link is rather changing the state of a resource than creating a resource (with a new identity or a URI). Anyways I don't know whether anything wrong with that and I looked at RFC 2616 9.5 POST to double check, it says POST can be used to 'Annotation of existing resources' too.  
> 
> Actually, the current mechanism used by the spec to retrieve / update large LDPC has some similarities with your approach despite of the difference that while you use this special link:collection URLs to manage large collections of properties within weak containers, LDPC uses it to manage non-members. Eg. <containerURL>?non-member-properties can be used to get all non-member properties of a LDPC

If we take ?non-member-properties, and break down into further into the constituent non-member properties, I can see why you make your observations above (and the member properties can also be broken-down too). 

> and  PUT to <containerURL>?non-member-properties to update non-member properties. However, LDPC still uses PUT to update the non-members assuming it is the smaller portion of the state. But it your case, it could be a larger portion (a collection with many links) so updating the collection (or creating a new link as you say) by POSTing to a collection URI provides a practical and quite a genius solution. 
> 
> Another difference I see between your proposal and simple proposal is that you allow different types of link collections within the same weak container. I think that is why you say a weak container has-a collection* and not is-a collection. You also explicitly show that links can be to both resources and literals i.e. that link property can be both an object property or a data property.

> I think simple proposal should be an object property as it only has one membership property for aggregation. It is also the same of LDPC in the current spec with respect composition. As a consequence of the fact that it only has a single membership property,  LDPC can have a fixed URL as mentioned in the previous paragraph without having to let the clients know the available collection URLs via 'ldp:link_collection' property. 
> 
> I just wrote this to see whether I understood your proposal correctly. I know this might be too early to send any questions as you have not revised the wiki yet but I will just put the questions that came to mind while reading the proposal. If those are answered when you refine the wiki just ignore them.
> 
> - So the server has a pre-defined set of properties for collections (depending on the type of the weak container, like say Product[hasBug], Bug[related, content]) and whenever a weak container (which can have collections) is created, the server automatically populates the ldp:link_collection properties as a set of server managed properties ?

Yes.
(for me it reads better when "weak container" is replaced with "resource" in the above paragraph.)

> - If a client does GET on http://example.com/Tracker/1, it can discover using the ldp:link_collection property that <Tracker/1;has_bug> is a, say *writable collection* inside a weak container.

(again, I think the weak container is'nt necessary)

> But a client do a GET on <Tracker/1;has_bug>, it's representation does not contain any server managed properties saying it is a *writable collection*. Is that right ?

So, as we know that <Tracker/1;has_bug> is a collection, we next need to know *how* to write to the collection. So the server managed properties on <Tracker/1;has_bug>, advertise what must be POSTed to create a new Bug, (i.e. related, content), and maybe say something about the multiplicity of these properties. 

regards, 
Roger

> 
> Just my 2 cents.
> 
> Best Regards,
> Nandana