Bug-tracker LDP service

1 Assumptions

• There is a Tracker at http://example.com/Tracker/1.
• The Tracker contains Bugs.
• A Bug has content.
• A Bug can be linked to other :related Bugs.
• The ldp:link_collection triple is the indication that its subject is an LDP-R, otherwise it is regular LD.

We would like to be able to:

• X
• Y

2 Known differences from an LDPC

3 Run Through

3.1 Original State

This is what "just exists" already. How it came to be this way is outside the proposal's scope. It corresponds to what one would receive in response to an HTTP GET request with the subject Request-URI.

The Tracker's content, i.e. what a GET http://example.com/Tracker/1 HTTP/1.1 would be expected to return:

@base http://example.com/ .
<Tracker/1> 
    :has_bug <Tracker/1/Bug/1>, <Tracker/1/Bug/2> ;
    ldp:link_collection <Tracker/1;has_bug> .

• The <Tracker/1> resource links to its "link collection" (LDP-LC) resources.
• In this case the <Tracker/1;has_bug> collection is all its :has_bug links, and it is addressable with HTTP independently of the Tracker resource. One could say the Tracker has-a bug link collection, not is-a bug collection.
• <Tracker/1;has_bug> is a POSTable endpoint which appends to the link collection.
• <Tracker/1;has_bug> advertises which properties should be supplied to seed this process. In this case, :content and :related (optionally). This information is published as data on the LDP-LC resource. This allows dynamic introspection, and including varying the parameter lists, and cardinality information can also be included (e.g. to express that :related is optional).

The Tracker's :has-bug LDP-LC content, i.e. what a GET http://example.com/Tracker/1;has_bug HTTP/1.1 would be expected to return:

@base http://example.com/ .
<Tracker/1;has_bug> 
    ldp:property :has_bug ; 
    ldp:element <Tracker/1;has_bug.1>, <Tracker/1;has_bug.27> ;
    ldp:parameterSet [ 
        ldp:action <Tracker/1;has_bug> ;
        ldp:parameter [ 
            ldp:property :content ;
            ldp:type <http://www.w3.org/2001/XMLSchema#String>
        ] ;
        ldp:parameter [ 
            ldp:link :related ;
            rdfs:range :Bug
        ]
    ] .
<Tracker/1;has_bug.1> ldp:link <Tracker/1/Bug/1> . 
<Tracker/1;has_bug.27> ldp:link <Tracker/1/Bug/2> . 

The first bug's content, i.e. what a GET http://example.com/Tracker/1/Bug/1 HTTP/1.1 would be expected to return:

@base http://example.com/ .
<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> .

Bug 1 has two LDP-LC resources: one of :related bugs, and one for :content.

Bug 1's LDP-LC for the :related property, i.e. what a GET http://example.com/Tracker/1;related HTTP/1.1 would be expected to return:

@base http://example.com/ .
<Tracker/1/Bug/1;related> 
    ldp:property :related ; 
    ldp:element <Tracker/1;related.32> .
    ldp:parameterSet [ 
        ldp:action <Tracker/1;related> ;
        ldp:parameter [ 
            ldp:link :related ;
            rdfs:range :Bug
        ]
    ] .
<Tracker/1;related.32> ldp:link <Tracker/1/Bug/2> . 

Bug 1's LDP-LC for the :content property, i.e. what a GET http://example.com/Tracker/1;content HTTP/1.1 would be expected to return:

@base http://example.com/ .
<Tracker/1/Bug/1;content> 
    ldp:property :content ; 
    ldp:element <Tracker/1/Bug/1;content.36> .
    ldp:parameterSet [ 
        ldp:action <Tracker/1/Bug/1;content> ;
        ldp:parameter [ 
            ldp:property :content ;
            rdfs:range :Bug
        ]
    ] .
<Tracker/1;content.36> ldp:content "i am Bug!" . 

In the above, the LDP-R's look like normal LD, can be queried normally, etc.

The LDP-LC resources exist for the management of the links emanating from the LDP-R.

3.2 Creating a new bug

Based on the parameters described in the representation of the LDP-LC, a request entity can be constructed and POSTed to the endpoint indicated by the action property.

Request:

POST http://example.com/Tracker/1;has_bug HTTP/1.1

<> :content 'i am THIRD Bug!'. 

Response:

HTTP/1.1 201 Created
Location: http://example.com/Tracker/1/Bug/3

<Tracker/1/Bug/3> 
    :content "i am THIRD Bug!" .
    ldp:collection_set <Tracker/1/Bug/3;related> <Tracker/1/Bug/3;content> .

In this case, the server creates a new resource GET http://example.com/Tracker/1/Bug/3 HTTP/1.1 and then links it. The representation of the new resource is included in the response body for convenience. Here is the new resource, i.e. what a subsequent would be expected to return

A subsequent GET http://example.com/Tracker/1 HTTP/1.1 would be expected to return the following, assuming that it started in the #Original State.

@base http://example.com/ .
<Tracker/1> 
    :has_bug <Tracker/1/Bug/1>, <Tracker/1/Bug/2>, <Tracker/1/Bug/3> ;
    ldp:link_collection <Tracker/1;has_bug> .

3.3 Link an existing bug to another existing resource

Let's say I want to link <Tracker/1/Bug/3> to another (existing) resource. The <Tracker/1/Bug/3;related> LDP-LC represents all the :related links. Furthermore, it can be discovered that it requires a ldp:link property to seed the process. From this information a POST request can be constructed.

Request:

POST http://example.com/Tracker/1/Bug/3;related HTTP/1.1

<> ldp:link <Tracker/1/Bug/1> .

Response:

HTTP/1.1 201 Created
Location: http://example.com/Tracker/1/Bug/3;related.1

<Tracker/1/Bug/3;related.1> ldp:link <Tracker/1/Bug/1> .

In this case, the result is a link between two existing resources. This was discoverable, directed update. i.e. the main Bug resource is updated (in this case, by adding a new link). The client was made ware of how to do the update, i.e. directed.

Furthermore, the LDP-LC, can split into pages and linked for enumeration purposes.

3.4 Summary

3.5 Placeholder empty section

Request:

verb URL HTTP/1.1

Response:

4 Representing containment and/or aggregation links

5 Email threads that have been incorporated above

• 2012-12 Threads:
  • Roger's
• 2013-01 threads:
  • Steve Battle's continuation