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: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Thu, 08 Nov 2012 11:09:32 +0000
Message-ID: <509B92EC.3070706@epimorphics.com>
To: nathan@webr3.org
CC: Richard Cyganiak <richard@cyganiak.de>, public-ldp-wg@w3.org


On 07/11/12 22:28, Nathan wrote:
> Richard Cyganiak wrote:
>> On 7 Nov 2012, at 16:31, Andy Seaborne wrote:
>>
>>>
>>> On 05/11/12 15:39, Linked Data Platform (LDP) Working Group Issue
>>> Tracker 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
>>
>> I'm not sure that would work with the current design. If bugs and
>> features have different URI templates, then probably you also want
>> different membership properties:
>>
>>   </SomeProduct>
>>     :bug </Bugz/bug2>;
>>     :feature </Feature/request2331>.
>>
>> To get different properties, you need to POST to different containers.
>> So the client needs to decide what container to POST to, and that
>> decision will determine the URI pattern and the property to be used,
>> and not information in the payload. Which seems mostly fine to me.
>
> Is this not backwards?
>
> Consider, somebody creates a bug and the following rdf is generated by a
> client:
>
> {
>    <#> :isBugOf </SomeProduct#> ;
>        :creator </bob#me> ;
>        :description "things are way too tightly coupled"@en ;
> }
>
> then that client PUTs it to </bug/tightly-coupled>.
>
> The agent in charge of </bug/tightly-coupled> can then (easily) infer that:
> { </SomeProduct#> :hasBug </bug/tightly-coupled#> }
> and
> { </bob#me> :created </bug/tightly-coupled#> }
>
> Further, it can send a post or patch request containing the first triple
> to </SomeProduct>, and the second to </bob>. The agents in charge of the
> respective resources, can then decide whether to accept the post/patch
> request, or take some further action, or whatever.
>
> The point is, that this generic action of loosely coupled resources and
> backlinking handles so much functionality, and so many use cases.

And I take from this example, that the bug report is created (PUT) then 
associated with a container.

Seems a reference counting effect is going on - delete when the PUT'ed 
item and any container links go away.

	Andy

>
> Consider a use case of a blog post, which is associated with 12 tags, 3
> categories, and 2 editors. (simple and common). Is a client to try and
> make 17 different POSTs (18 if you consider that it's a member of a
> blog/space)? and which one of those POSTs would create it, which would
> just associate it with a weak aggregation? So complicated, when one
> simple PUT and a generic "notify linked resources" would cover the
> functional needs.
>
> Moreover, all of this in a decentralized way that works over many
> generic data servers, not just one specific application server on a
> single domain.
>
>
Received on Thursday, 8 November 2012 11:10:14 UTC

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