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

Re: interaction with a bug-tracker LDP service

From: Roger Menday <roger.menday@uk.fujitsu.com>
Date: Thu, 20 Dec 2012 13:56:24 +0000
CC: "public-ldp-wg@w3.org Working Group" <public-ldp-wg@w3.org>
Message-ID: <7704CA01-7AF0-485F-AD08-8D27D7C4C930@uk.fujitsu.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>

> Hi Roger,
> 
> A question about this part:
> 
>> POST to <Tracker/1;has_bugs> with "<> :content 'i am THIRD Bug!'. "
> 
> Could <Tracker/1> be an LDP-Container or were you avoiding that for some 
> reason?
> ------------------
> ---- <http://server/Tracker/1>
> <Tracker/1>
>     a ldp:Container;
>     ldp:membershipSubject <Tracker/1/Bugs> ;
>     ldp:membershipPredicate :has_bug .
> 
> <Tracker/1/Bugs>
>     :has_bug  <Tracker/1/Bug/1> ;
>     :has_bug  <Tracker/1/Bug/2> ;
> ------------------

hi Andy, 

One of the reasons why I don't quite like with this approach is that the <Tracker/1> resource is not very friendly to the *read-only* (say with SPARQL SELECT) consumer (?) We wanted something which is just regular LD, but then there is a secondary 'layer' which can be revealed to direct any interaction.

Roger

> 
> then
> 
>    POST to <Tracker/1> with "<> :content 'i am THIRD Bug!'. "
> 
> and get back
> 
>    Location: <Tracker/1Bug/3>
> 
> in the response.
> 
> 	Andy
> 
> 
> On 20/12/12 10:53, Roger Menday wrote:
>> hi
>> 
>> I would like the following to be considered alongside other recent proposals.
>> 
>> I will illustrate the concepts with the bug-tracker example, i.e. There is a Tracker. It contains Bugs. A Bug has content, and can also be linked to other :related Bugs.
>> 
>> eg.
>> 
>> <Tracker/1>
>>     :has_bug <Tracker/1/Bug/1>, <Tracker/1/Bug/2> ;
>>     ldp:link_collection <Tracker/1;has_bug> .
>> 
>> De-referencing the first Bug.
>> 
>> <Tracker/1/Bug/1>
>>     :related <Tracker/1/Bug/2> ;
>>     :content "i am Bug!" .
>>     ldp:link_collection <Tracker/1/Bug/1;related> <Tracker/1/Bug/1;content> .
>> 
>> The above looks like readable LD, can be queried normally, etc .. The ldp:link_collection triple is the indication that this is writable (with LDP) LD.
>> 
>> Starting with the <Tracker/1> resource, I will first create a new Bug, and then link (using :related) this Bug to another one.
>> 
>> The <Tracker/1> resource links to its "link collection" resources.
>> In this case <Tracker/1;has_bug> collection is all its :has_bug links.
>> It is an POSTable endpoint which appends to the link collection.
>> It advertises which properties should be supplied to seed this process.
>> In this case, :content and :related (optionally)
>> 
>> POST to <Tracker/1;has_bugs> with "<> :content 'i am THIRD Bug!'. "
>> 
>> In this case, the server creates a new resource and then links it.
>> Here is the new resource.
>> 
>> <Tracker/1/Bug/3>
>>     :content "i am THIRD Bug!" .
>>     ldp:collection_set <Tracker/1/Bug/3;related> <Tracker/1/Bug/3;content> .
>> 
>> Say then, I want to link <Tracker/1/Bug/3> to another (existing) resource.
>> 
>> The <Tracker/1/Bug/3;related> collection represents all the :related links.
>> I can discover that it requires a ldp:link property to seed the process.
>> 
>> POST to <Tracker/1/Bug/3;related> with "<> ldp:link <Tracker/1/Bug/1> ."
>> 
>> In this case, the server links two existing resources.
>> This is discoverable, directed update.
>> 
>> The server knows which predicates will be linking to 'progeny' resources, and which predicates are links to other, existing resources. It can direct interaction accordingly. But, the mechanism is the same for the composition or aggregation.
>> 
>> Furthermore, the link_collections, can split into pages and linked for enumeration purposes.
>> 
>> So, this is an outline of an approach to aggregation, along with ideas about creation, discovery, update, paging, etc .. I would like do a second scenario - a simple lightbulb on/off service next. I hope there is interest in that.
>> 
>> regards,
>> Roger
>> 
> 



Received on Thursday, 20 December 2012 13:57:21 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 May 2013 13:44:27 UTC