W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: ldp-ISSUE-30 (bugtrack): Hierarchical bugtracking service [Use Cases and Requirements]

From: Richard Cyganiak <richard@cyganiak.de>
Date: Wed, 7 Nov 2012 23:31:31 +0000
Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, Linked Data Platform Working Group <public-ldp-wg@w3.org>
Message-Id: <E3FD0F83-8B8F-49F7-9EAC-339CBD8B1F7F@cyganiak.de>
To: Roger Menday <roger.menday@uk.fujitsu.com>
On 7 Nov 2012, at 23:02, Roger Menday wrote:
>>>> POST /SomeProduct { <> a :Bug } yields { /Bugz/bug2 a :Bug }
>>> 
>>> I read that as a response of 201/"Location: /Bugz/bug2" and
>>> content { /Bugz/bug2 a :Bug } at /Bugz/bug2.
>>> 
>>> Presumably POSTing { <> a :FeatureRequest } causes a different template for the URI allocated:
>>> 
>>> Location: /Feature/request2331
<snip>
>>> This is a great example - the data has driven the server's decisions on the response.
>> 
>> Right, and if it works this way, then the client doesn't need to know that :Bugs go into the one container and :Features into the other; the server can sort this out by looking at the request. That's an advantage.
> 
> Unfortunately, in my opinion, it doesn't work this way ... 
> 
> e.g. if there are two properties with range :Bug then it wouldn't work.
> 
> So, either the intended property name has to be inside the POSTed entity, or the client has to be *directed* to a (subject+property) collection, and this is the endpoint they POST to. we did it the second way ... 

Good point. The second way sounds better to me too. Less ways in which it can break, and the server can express its intent more clearly as it enumerates the properties that are available for POSTing to.

Best,
Richard
Received on Wednesday, 7 November 2012 23:31:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:42 UTC