Baetle: Bug And Enhancement Tracking LanguagE ( version 0.00001 )

So here is an absolute first draft version of a Bug ontology, just starting from information I can glean from bugs in the NetBeans repository. It really is not meant to be anything else than a place to start from, to see what the field looks like, and to try out a few ideas. There is a lot that needs to changed. If possible other ontologies should be reused. But for the moment we just need to work out if this can be of any use...

The idea is that this should end up being a solid Bug Ontology that could be used by bugzilla and other repositories to enable people to query for bugs across repositories. So if people want to join in helping out, I am currently developing it on the mailing list at, just because I have access to that repository, and so that I don't need to create another space immediately.

Before sitting down and writing out the OWL it is just a lot easier to diagram these in UML. So that's what I have done here.

Here is a description of bug 18177 from the NetBeans bug tracker, using the above outline. It is in N3.

@prefix : <> .
@prefix foaf: <> .
@prefix sioc: <> .
@prefix awol: <> .

       a :Feature;
       :status "resolved";
       :resolution "fixed";
       :qa_contact [ foaf:mbox <> ];
       :priority "P1";
       :component [ :label "openide"
                    :version "3.6";
       :bugType "looks";
       :assigned_to  <>";
       :reporter [ :nick "jtulach"];
       :interested [ :mbox <> ];
       :interested [ :mbox <> ];
       :updated "2003-12-11T06:25:15"\^\^xsd:dateTime;
       :dependsOn <>,
       :blocks <>,
       :hasDuplicate <>;
       :description <>;
       :comment <>,
       :attachment <>.

<> a :Description;
     :content [ awol:body """We need a reasonable way how to organize looks so we can easily locate them for
given representation object in a way that makes it probable that correct look
will be found. We need a way for different modules to replace (or lower
priority) of some look and provide their own. We need use to be present with
available looks (which make some sence on that object) and being able to
pernamently change the order of looks available for given object.""";
               awol:type "text/plain";
     :author [ foaf:mbox <> ];
     :created "2001-11-29T08:17:00"\^\^xsd:dateTime .     

I have hyperlinked a couple of the relations above, to show exactly how what we are doing is just describing the web. (RDF stands for Resource Description Framework after all) Click on the links and you will get a description of what that thing is about. There is already one big improvement here over the xml format provided by the service (see the xml for bug 18177 for example) and that is that we don't have to send the content of an attachment around. We just refer to it by a url (

The bugs have the #it anchor, to distinguish the bug from the page which describes it.

The URL for the code should clearly be the urls of the http repository versions. Then we should be able to link the code to packages, which should link up to libraries, which link up to products; and we can link any of those to bugs.

So what could one do with all that information available from a SPARQL endpoint?


Looking good!

Posted by Danny on March 02, 2007 at 03:38 PM CET #

This is great! I've been waiting for a “bug vocabulary”. Now I wonder how to combine this with StatCVS

This can naturally express cross-project links. For example, a bug in D2R Server might depend on a bug in D2RQ or Joseki.

One could build tools that show my assigned and reported bugs across multiple projects hosted by different organisations.

One could build a plugin that shows issues directly in the IDE. Maybe one could even update and close the bugs directly from the IDE.

If the reporting features of the issue tracker are not sufficient, one could use external reporting tools that work against the SPARQL endpoint.

One could write custom SPARQL queries to be notified about certain kinds of new bugs: “Give me all bugs that are about component X, contain the word Y in the description, and have priority > 5.” Combine this with a SPARQL-result-to-Atom converter and subscribe to the resulting feed in your RSS reader. Also: “Notify me when this bug is <em>closed</em>”—when you don't care about each and every comment that is added to the bug.

Semi-related thought: There should be RDF representations of program error reports, such as Java exceptions. Then I could SPARQL for “NullPointerException in class so-and-so of project foobar”, and possibly a solution has been filed, or at least I will find a related bug.

Posted by Richard Cyganiak on March 03, 2007 at 06:19 AM CET #

Looks good so far. I'm concerned about literals like "resolved" for the status of the bug. All the existing bug trackers have their own subtleties about those statuses, and if nothing else, they all have documentation about statuses. I think you'd do better with a URI for each status. Then I could declare separately that trac-resolved is the same as roundup-resolved (whatever those URIs turn out to be). And the trac-resolved predicate would obviously be linked to some comments and documentation; and it would be "a :Status" in n3, too, which allows for fancier grouping of statues. E.g. wontfix and resolved are both "closed" statuses, which your simple literals can't describe very easily.

As to Richard's "RDF representations of program error reports", see for one of several projects that hash up the stack trace into an error id. Those seem like they could lead to excellent automatic URLs which can be later associated with the tracking of the bug that makes that stack trace. I'd love to get an error and paste its url directly in my browser to see "this error has [n] frequency in the last few weeks; [these] other users have been experiencing it; [this] developer is working on the bug fix, and the details for that bug are [here]".

Back to the uses for your ontology. I never thought about doing more advanced queries on bug trackers (though I hear other users asking for it). What I am interested in, though, is personal/distributed bug tracking for open source projects. I might like to track local changes I make to an OSS project and then optionally publish some of my bugs+patches later. With RDF, I might just stick some n3 data right into the source files as I edit them, and then extract it my own reporting, or preserve it in the patches that I submit back to the project. It would be like a richer form of the "# drewp added this to fix crashing-- 2007-03-04" comments that I stick in modified OSS projects today.

Posted by Drew Perttula on March 04, 2007 at 01:30 AM CET #

Here is what the baetle looks like after a few extra days work and after trying to incorporate some other well known ontologies, such as and DOAP This may not be an improvement. Just trying to show a little how my thinking is evolving.
I can't incorporate images into the comments so click here to see the UML

Posted by Henry Story on March 07, 2007 at 03:36 AM CET #

I have opened a project page on google code for Baetle at
There is a mailing list/news group that goes with it
Please feel free to join, listen in, and participate.

Posted by Henry Story on March 07, 2007 at 04:59 AM CET #

Wow! That's really cool! I guess on the other close vocabulary which are needed. There is the Test Metadata one. If you had time to contribute, we could even republish the document with your schema and name through the QA IG.

There is also the need for a vocabulary for issues management. And we have already EARL as a reporting language and all of that could work very very well together.

It sounds like a possible QA Weblog article.

Posted by Karl Dubost, W3C on March 14, 2007 at 07:40 AM CET #

Post a Comment:
Comments are closed for this entry.



« July 2016