A GSoC project idea around the Resource Description Framework

I just added an entry to the Google Summer of Code 2010 Ideas wiki page:

Resource Description Framework (RDF) is ~10 year old W3C standard. Uptake is taking off now, and it would be nice to see a Eclipse project like the Web Tools Package to provide basic RDF related functionality. This would include bundles for RDF libraries (Jena or OpenSesame) and editors for Notation3 and RDF/XML, and perhaps support for a catalog of common ontologies (RDF, RDFS, OWL, DublinCore, FOAF, ...). It could also include a Zest-based RDF graph viewer, SPARQL query editor, etc. There is existing code, for example, developed by the Bioclipse team using Jena, or the older Tripclipse. There also exist commercial offerings stressing the relevance of the RDF platform, such as Semantic Toolkit and the popular TopBraid.

For Bioclipse we have set up bundles for Jena in the bioclipse.rdf git repository, but I am sure they need some improvement. Yet, they might serve as a starting point.

RDF, Jena, Bioclipse, Eclipse, Zest: Mashups

Quite a while a go, I blogged about Zest in Bioclipse showing a bit of ONS Solubility data. I could not follow up on that until now, as I had yet to do a lot of RDF work in Bioclipse, so the screenshot back then was kind of a mockup.

Things are different now, and the Bioclipse-RDF functionality (using Jena) is released in Bioclipse 2.2 (see Semantic Web features in Bioclipse 2.2), and I got around to writing the graphical goodies for the following papers. Not submitted yet, but here's the screenshot showing a N3 file opened with a Zest-powered editor (read-only) and a plain text editor:

Semantic Web features in Bioclipse 2.2

Ola is releasing Bioclipse 2.2.0 today, and asked me to show case the semantic web functionality in Bioclipse. I realized that I do not have a nice page showing the semantic web overview. But I did blog a lot about RDF functionality, so here's a list of pointers:

• Bioclipse Manager for MyExperiment.org
• Bioclipse, RDF and defeasible reasoning (see also Samuel's blog)
  
• Bioclipse and SPARQL end points #2: MyExperiment
  
• Bioclipse and SPARQL end points
  
• Solubility Data in Bioclipse #2: handling RDF
  
• Solubility Data in Bioclipse #3: Finding ChEBI IDs
  
• Solubility Data in Bioclipse #4: Finding ChEBI IDs (Again, but better)
  
• /me is having Bioclipse/XMPP/RDF fun
  

Or check this screenshot from a Posterous post about a MyExperiment workflow:

One thing I have not blogged about yet (I think), is that the Bioclipse RDF manager also understands RDFa now. Well, sort of... it relies on a webservice, but this is what the script looks like:

model = rdf.createStore()
rdf.importRDFa(model, "http://egonw.github.com/")
rdf.saveRDFN3(model, "/Virtual/egonw.n3")

With support of SPARQL end points, and reading RDF from web resources directly (RDF/XML, N3, RDFa), Bioclipse is ready for the chemical semantic web.

Call for Collaboration: JavaDoc validation with OpenJavaDocCheck

Dear all,

while it is still very much in progress, I have made good progress with writing a new BSD-licensed replacement for Sun's DocCheck utility for testing the library's JavaDoc quality. The DocCheck's never really satisfied me, and the most recent version is ancient. Because it is closed source, no one can continue on those efforts. DocCheck is MIA.

PMD is given nice, simple overviews instead. It provides me with a quick overview of what is wrong with the CDK JavaDoc, and also provides a decent XML format which allows extraction of information, which is used by, for example, SuperNightly as showed yesterday in PMD 2.4.5 installed in the CDK 1.2.x branch.

I have been pondering about it for a long time now, but writing a JavaDoc checking library is hardly core cheminformatics research; at least, you would not get funding for it, despite everyone always complaining about good documentation. Alas.

A few weeks ago, I was reviewing some more code, and again saw the very common error of the missing period at the end of the first sentence in JavaDoc. This one is sort of important for proper JavaDoc documentation generation, but the complexity of the current DocCheck reporting, people are not familiar enough with it. Being tired of having to repeat myself, I decided to address the problen, but creating better Nightly error reporting for the CDK JavaDoc.

So, I started OpenJavaDocCheck, or ojdcheck. As mentioned, I have made quite promising progress, and the current version provides the ability to write custom tests (which I plan to use for validating content of CDK taglet content), and create XML as well as XHTML which can be saved to any file. To give you a glimps of where things are going, here's a screenshot of the current XHTML output:

This list shows a mix of tests that are now implemented in OpenJavaDocCheck itself, but the third line is actually a test that is plugged in and specific for the CDK. This is an important feature, I think, and allows users of OpenJavaDocCheck to add functionality is that is not interesting to the general public, but very interesting for the JavaDoc being analyzed. Well, at least, it is to the CDK project :)

The current list of tests is still quite small, and consists of these tests:

• test if each class and method has JavaDoc
• test for missing @return tags
• test for missing @param tags
• test for @returns instead of @return
• test @param template code, such as added by IDEs like Eclipse
• test @exception template code, such as added by IDEs like Eclipse
• test for redundant @version tags

I am now seeking feedback on the current code base, and potentially collaboration with writing more JavaDoc validation tests. There is enough to do, and I have been thinking on tests for:

• spell checking JavaDoc
• checking for 404s of web pages linked with <a href> in the JavaDoc
• well-formedness of the HTML in the webpages

And about:

• a PMD-like system to allow people to choose which testing they want or not
• an Eclipse plugin

Making Bioclipse Development easier: the New Manager Wizard

Today, Jonathan, Carl, Arvid and I made writing managers for Bioclipse a bit easier. Plug-in development Eclipse in itself is already tricky to learn, and the use of Spring by the Bioclipse managers is not helping. And because very soon two new people will be starting with writing a new manager rather soon, we thought it was time to lower the activation barrier a bit.

The basic file structure of an Bioclipse manager looks like:

net.bioclipse.foo/
|--META-INF        
|   |--MANIFEST.MF 
|   `-- spring 
|       `-- context.xml
|-- plugin.xml
|-- .classpath
|-- .project
|-- build.properties
`-- src
    `-- net
        `-- bioclipse
            `-- foo
                |-- Activator.java
                `-- business
                    |-- FooManager.java
                    |-- FooManagerFactory.java
                    |-- IFooManager.java
                    |-- IJavaFooManager.java
                    `-- IJavaScriptFooManager.java

That is twelve files which need to be just right. I used to copy/paste from an earlier (simple) manager.

But we know and understand that setting up this framework is even more challenging if you have not done this at least 10 times before. So, today we implemented a New Wizard (source available from this Git repository: bioclipse.sdk).

It just asks you a project name:

and a few other settings:



Installing the Bioclipse SDK
Installing this new plugin is fairly easy, and we have set up an Update Site at http://pele.farmbio.uu.se/sdk/. Just add this as Update site in Eclipse 3.4.x (which is still required for Bioclipse2). It depends on the JDT and PDE, which you will likely already have installed being part of the default Eclipse RCP release.

Go to the Software Updates in the Help menu:

and pick Add Site.... Enter the aforementioned update site as shown here:

Then, select the Bioclipse plugin:

After you hit Install and Eclipse install the fews tens of kBs of the plugin, the plugin should show up in your installation, like it did in mine:



Implementation Details

Writing the plugin was a challenge to me, and I am happy we were doing this in a hackaton. The Bioclipse-QSAR project already had a New Project wizard, but not for a new Plug-in Project. Some things are just slightly different then. For example, it turned out that creating a .classpath cannot be done in the regular way (it never showed up), and I had to dig up some internal code of the PDE. Actually, our current implementation is still using a few internal classes because of this:

IClasspathEntry[] entries = new IClasspathEntry[3];
String executionEnvironment = null;
ClasspathComputer.setComplianceOptions(
  project,
  ExecutionEnvironmentAnalyzer.getCompliance(executionEnvironment)
);
entries[0] = ClasspathComputer.createJREEntry(executionEnvironment);
entries[1] = ClasspathComputer.createContainerEntry();
IPath path = project.getProject().getFullPath().append("src/");
entries[2] = JavaCore.newSourceEntry(path);

Ideas are most welcome on how to clean up this code, and not make it use internal, non-exported classes. For the Java source files and even the MANIFEST.MF we are using templates, though I have seen this file being created programmatically too.

I'm sure we'll run in some needed plumbing here and there, but that's what update sites are for, not? Release soon, release often is an Open Source concept that works well in the Eclipse world.