Re: interaction with a bug-tracker LDP service

> 

T

> On 20 December 2012 11:53, Roger Menday <Roger.Menday@uk.fujitsu.com> 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.
> 
> You may be interested in the way Tim's group at MIT have modelled their issue tracker running on an LDP compliant data store
> 
> http://tabulator.org/wiki/tabulator/tracker/state
> 
> Collection
> 
> http://tabulator.org/wiki/tabulator/tracker/
> 
> I tested this in opera, and I think chrome works too (Firefox was working until recently), and it should fall back to a front end, for a browser that does not understand turtle natively.  Click on 'New', for example and it should take you to a table view with UI.
> 
> There is also a complete ontology for bug tracking there.  

hi Melvin, 

That's very interesting. I wasn't aware of that. 
Actually, I choose a bug-tracker scenario only because it is in the LDP UC&R doc. 

Roger 

>  
> 
> regards,
> Roger
> 
>