W3C home > Mailing lists > Public > public-ldp-wg@w3.org > January 2013

Re: ISSUE-26 Creation model for LDP, proposal

From: Roger Menday <Roger.Menday@uk.fujitsu.com>
Date: Sun, 20 Jan 2013 12:22:32 +0000
CC: Arnaud Le Hors <lehors@us.ibm.com>, "public-ldp-wg@w3.org Group" <public-ldp-wg@w3.org>
Message-ID: <539B519D-70AD-40D8-80B8-364C104BFB80@uk.fujitsu.com>
To: Steve Speicher <sspeiche@gmail.com>

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. 


> 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

Received on Sunday, 20 January 2013 12:23:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:36 UTC