Re: ISSUE-26 Creation model for LDP, proposal

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

I disagree. I think it is really important. If we want a generic client (like Tabulator) it is essential. 
I don't think we can honestly say we have satisfied our charter either. 

And, there seems to be lots of similarities between OSLC and our (Fujitsu) approach, so, why not we start from that ?

regards 
Roger

> [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
> >