Warning:
This wiki has been archived and is now read-only.
Bug-tracker LDP service
Contents
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:
- 2013-01 threads: