Re: ISSUE-26 Creation model for LDP, proposal

hi Steve, 

OK, as submitter of Issue 26, I can say that I had (still do!) a particular interest in how LDP directs the creation process (i.e. what should be provided) - and this is why I mention considering a model similar to HTML forms in the description. But, as you suggest, I am very happy to close issue 26 and clarify in an new issue, or just add some clarification to this existing issue. 

Roger

> As I read ISSUE-26, I didn't read it as Roger describes as it states:
> 
> [[
> This issue is about how creation works in LDP. An LDP container
> contain items, and a fundamental question for LDP is how items are
> created and added to a container.
> ]]
> 
> Which is covered by 5.4.1.  If the issue is being expanded to cover
> cases like which content-types are allowed, which Classes are allowed
> and additional constraints, then I'd say separate issues be created
> for that items.
> 
> So either we rewrite ISSUE-26 to more clear on what the issue is out
> the class of these kinds of issues or close it and create ones for
> these different cases.
> 
> On Fri, Jan 18, 2013 at 1:44 PM, Arnaud Le Hors <lehors@us.ibm.com> wrote:
>> IBM Rational had the same need of being able to communicate to the client
>> what the resources they can create look like. They ended up defining
>> something called Resource Shape [1].
>> 
>> "In some cases, to create resources and to query those that already exist
>> within an OSLC Service, OSLC clients needs a way to learn which properties
>> are commonly used in or required by the service. Resource Shape Resources
>> meet this need by providing a machine-readable definition of an OSLC
>> resource type."
>> 
>> This is one feature we (IBM) decided not to include in the Linked Data Basic
>> Profile submission for the sake of keeping the scope limited to a set of
>> core features but we are interested in exploring in the future. I would say
>> this is out of scope for this WG though.
>> 
>> [1]
>> http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?sortcol=table;table=up#oslc_ResourceShape_Resource
>> --
>> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>> 
>> 
>> Roger Menday <roger.menday@uk.fujitsu.com> wrote on 01/18/2013 03:02:24 AM:
>> 
>>> From: Roger Menday <roger.menday@uk.fujitsu.com>
>>> To: Steve K Speicher/Raleigh/IBM@IBMUS,
>>> Cc: "public-ldp-wg@w3.org Group" <public-ldp-wg@w3.org>
>>> Date: 01/18/2013 03:03 AM
>>> Subject: 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
>>> 
> 
> 
> 
> -- 
> - Steve