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

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.

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 Wednesday, 7 November 2012 22:30:10 UTC