Re: interaction with a bug-tracker LDP service

Hi Roger,

 > 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. 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 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 ?
- 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. 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 ?

Just my 2 cents.

Best Regards,
Nandana