Applying LDP concepts to bug tracker

In this post I'll explore how some products that support bug tracking, such as Rational Team Concert, model their internal "Work Item" resource given W3C Linked Data Platform and OSLC concepts.  This will also highlight how various capabilities are needed to solve some key problems in a simple way.  I will be "paraphrasing" what the actual runtime resource will look like to help with human consumption of the examples (as the real-world ones can sometimes have additional concepts and capabilities that don't apply to the simple part of the model we are focused on here).

Let's take one of the most simple examples of what one might find, let's say a bug (aka "Defect") that has a few properties but no associated attachments or child bugs.

Representation of bug http://example.org/bugs/13:

@prefix dc:  <http://purl.org/dc/terms/> .
@prefix ocm: <http://open-services.net/ns/cm#> . 

<> a ocm:Defect ;
   dc:title "Bug in rendering large jpgs" ;
   dc:identifier "13" .

Now we'll explore how add a couple screen shots to the bug. Using this information I have with this resource, I'm not sure how I do that (assuming I am a Linked Data client). I could just attempt to PUT replace the contents and add a ocm:attachment statement referring to the screenshot. Depending on the server, it may reject it for a couple of reasons, such as: it doesn't known anything about ocm:attachment, or it has restrictions on the object (where the attachment is physically stored), or simply PUT updates not allowed for ocm:attachment.
To help with this problem, we can associate an ldp:Container with this bug resource to assist with this. So we expand our example, with out modifying any of the original model, just adding a few more statements.

@prefix dc:  <http://purl.org/dc/terms/> .
@prefix ldp: <http://w3.org/ns/ldp#> .
@prefix ocm: <http://open-services.net/ns/cm#> . 

<> a ocm:Defect ;
   dc:title "Bug in rendering large jpgs" ;
   dc:identifier "13" .

<attachments> a ldp:Container ;
   ldp:membershipPredicate ocm:attachment ;
   ldp:membershipSubject <>.

This tells my client now that we have an ldp:Container associated with the bug, since the ldp:membershipSubject connects this container to the bug. I can inspect also ldp:membershipPredicate to know for which same-subject and same-predicate pairing I can use this container to assist with managing and navigating them.
Now I have a URL http://examples.org/bugs/13/attachments where I can POST a screenshot to create an attachment and associate it with bug 13. Let's look at what the POST looks like:

Request:

POST http://example.com/bugs/13/attachments
Slug: screenshot1.png
Content-Type: image/png
Content-Length: 18124

[binary content]

Response:

HTTP/1.1 201 CREATED
Location: http://example.com/bugs/13/attachments/3
Content-Length: 0

Now that the attachment has been created, we can fetch bug 13 again to see what we have.

@prefix dc:  <http://purl.org/dc/terms/> .
@prefix ldp: <http://w3.org/ns/ldp#> .
@prefix ocm: <http://open-services.net/ns/cm#> . 

<> a ocm:Defect ;
   dc:title "Bug in rendering large jpgs" ;
   dc:identifier "13" ;
   ocm:attachment <attachments/3> .

<attachments> a ldp:Container ;
   ldp:membershipPredicate ocm:attachment ;
   ldp:membershipSubject <>.

We now see that there is an ocm:attachment statement associated with bug 13. This statement was added by the server when it processed the POST request to create a new resource (attachment) and then added it as a member of the attachments associated with the bug.
We can also see that this list can grow to be quite large. Experience has shown, that end users of bug trackers need to attach a number of documents, images, logs, etc. with bugs. This need also comes from a number of other capabilities such as having nested bugs or tasks. To illustrate, let's assume our bug tracking server has been upgrade or now exposes children resource within bug resources (or has had children added by other means). Let's take a look at bug 13 again:

@prefix dc:  <http://purl.org/dc/terms/> .
@prefix ldp: <http://w3.org/ns/ldp#> .
@prefix ocm: <http://open-services.net/ns/cm#> . 

<> a ocm:Defect ;
   dc:title "Bug in rendering large jpgs" ;
   dc:identifier "13" ;
   ocm:attachment <attachments/3>, <attachments/14> .
   ocm:child <../47>, <../2> .

<attachments> a ldp:Container ;
   dc:title "Attachment container for bug 13" ;
   ldp:membershipPredicate ocm:attachment ;
   ldp:membershipSubject <>.

<children> a ldp:Container ;
   dc:title "Children for bug 13" ;
   ldp:membershipPredicate ocm:child ;
   ldp:membershipSubject <>.

As you can see, the bug model stays very simple with statements about bug 13 being made directly about it using simple RDF concepts where the statements are of the form [bug13, predicate, object|literal]. We can repeat this pattern and use it in many other forms, such as a container of all the bugs the serve knows about, which I plan to illustrate in other posts.
Disclaimer: some of the predicates used in these examples show they are in the OSLC-CM namespace but have not been approved by the WG. This was done just for simple illustration.

Making progress towards an OSLC-CM 3.0

Been a while I have talked about a specific domain working group and what has been going on.  Though the work for a post-2.0 Change Management specification has been evolving for some time, it is coming along nicely.  I've been focusing much of my energy on getting the core-est part of Core (W3C Linked Data Platform and Core 3.0) rolling, while keeping an eye and hand involved with CM.

To summarize the OSLC-CM WG has looked at a number of prioritized scenarios:

• IDE Task federation and management
• Transitioning states
• Programmatically accessing and uploading attachments
• Querying across multiple states in a single request
• Additional semantics on regards to priority, severity and additional types of resources

We currently have draft specification text for most of the scenarios above.  We are planning to enter into convergence soon and start to do some implementation to validate the specifications.

Special thanks to Sam Padgett for leading the OSLC-CM efforts, planning meetings, keeping minutes, keeping track of issues and pushing forward with the draft specification.  Looking forward to getting some of these approaches implemented and specification wrapped up.