Re: ISSUE-26 Creation model for LDP, proposal

> This issue seems to be unnecessary in the sense that it focuses on how
> resources are created, which is covered already in the specification
> by POST'ing the representation of the resource to the container.
> 
> See 5.4.1 [1] which states:
> [[
> 5.4.1 LDPC clients should create member resources by submitting a
> representation as the entity body of the HTTP POST to a known LDPC.
> LDPCservers must respond with status code 201 (Created) and the
> Location header set to the new resource’s URL.
> ]]
> 
> Proposal: close issue as this already defined by this referenced section.
> 
> Emails associated with issues appear to be tangled in other issues,
> like actual creation of container, etc.  There is no need to tie a
> representation limitation on what is created within a container and
> this doesn't.
> 
> [1]: https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpc-5_4_1
> 


hi Steve, 

In the 5.4.1 text, how does a client know what goes inside the entity body? 
That's my concern. I'm not really happy about closing issue-26 until we can answer that (??) 




Some thoughts: 

A client could discover some information from the container about the typing (Class) of the resource making up the request. This address could be used to look up more information. The request entity body could be constructed based on this information. However, one problem with that is that autonomous nature of properties and other aspects of the RDF/OWL model means that the client may not easily work out how exactly to flesh out the request. Furthermore, a server might want to vary the properties, offer variations, etc etc. 

So, given this, I came to the conclusion that it is better for a container to list of the *properties* needed (and not the class). e.g., so it says that a Tracker;has_bug, the :content and a :related properties should be provided (multiplicity information would be useful too) - and then on successful processing, a new Bug resource is created. 

regards, 
Roger