interaction with a bug-tracker LDP service


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. 


    :has_bug <Tracker/1/Bug/1>, <Tracker/1/Bug/2> ;
    ldp:link_collection <Tracker/1;has_bug> .

De-referencing the first Bug.  

    :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. 

    :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. 


Received on Thursday, 20 December 2012 10:54:52 UTC