Let me break that alphabet soup down for you:

1. SBGN: the graphics
2. LibSBGN: the software
3. SBGN-ML: the file format

Suppose you manage to procure a SBGN-ML file. You may then reasonably ask what you can do with it. Until fairly recently, the only answer that we could give to non-programmers was “not much”. That is quickly changing however. I’ll present three things you can do with an SBGN-ML file right now.

1. Open it in PathVisio

Using the following webstart link, you can open PathVisio with the SBGN-plug-in pre-installed. (More information about the state of this plug-in, see the help page). Then go to File->Import… and select SBGN-ML from the file type drop-down.

2. Convert them into an image from the Command-Line

If you want to convert a bunch of SBGN-ML files to images, it’s easier to do it from the command-line. For this purpose I created a little script. First download the sbgn-to-png tarball. Unzip it, and run it from the command line using “sh sbgn-to-png.sh “.

3. Open it in SBGN-ED

The SBGN-ED tool is an alternative to PathVisio for editting pathway diagrams. SBGN-ED has won the annual SBGN competition in the category “Best software support” twice in a row.

When comparing PathVisio and SBGN-ED, the latter is probably a bit better when it comes to editing Process Description diagrams, whereas PathVisio deals better with Entity Relationship diagrams. The only caveat is that at this time of writing, SBGN-ED only supports an older version of SBGN-ML. For this reason, files generated by SBGN-ED can be read by PathVisio, but not the other way around. An update should arrive very soon though.

Firstly, one of my goals was to find out about the current state of Cytoscape development. Cytoscape is a great tool as long as you don’t look too closely at what’s going on inside. The upcoming third version promises to fix all the minor and major problems that exist under the hood. But Cytoscape 3 has been in the making for a long time. As a plug-in developer, you have to choose between something that works right now, but will go away eventually, or something that is clearly the future, but might take a long time to materialise.

The feeling I got from the workshop is that there is light at the end of the Cytoscape 3 tunnel. For a plug-in developer with a deadline, it’s probably best to stick with the current version for now. But if you’re not under pressure to release, it’s definitely possible to write for Cytoscape 3 and make use of a nicer and more pleasant working environment.

Besides that news, I learned some cool new tricks. Using Cytoscape Commands you can write simple macros for repetitive tasks. For example, to generate the network below, first you have to import a SIF (Simple Interaction Format) file, then import a file with node attributes, then apply a layout, and then apply a visual style. If you have to do this a couple of times it gets quite tedious. But here is how all that can be automated:

Take the following SIF data, and save it using a text editor as network.sif

Here are the Node attributes, saved it as node_types.txt

For the visual style, I created one in Cytoscape and saved it as style.props, using Export->Vizmap property file. And here is the magic bit: If you save the above three files in your work directory, then you can generate that picture with the script below.

Run it from within Cytoscape with Plugins->Command Tool->Run script…, or from the command line with

We have our own logical modelling software called CellNetOptimizer (a.k.a CellNOptR). One of my current projects is to make the CellNOptR software more interoperable with popular tools such as Cytoscape. To this end, Emanuel Gonçalves, a master student in our group, has implemented a plug-in that makes CellNOptR available from Cytoscape. Work on the plug-in is progressing nicely. Below you see the video that he made, to show off some of the features of this new plug-in.

In the video, you see how you can:

• open a network
• Start the CellNOptR wizard
• Import and view experimental data
• Train the network against the data
• View the optimized network in Cytoscape

PathVisio on a tiled display

This setup gives you a lot of resolution to play with. We managed to display all major metabolic pathways from WikiPathways simultaneously, at full resolution, and map microarray data as well. When you’re standing right next to the screens, it feels like the data is all around you. That really encourages you to explore, and make connections across the pathways. That’s just much harder to do on a single screen.

So what is LibSBGN? The Systems Biology Graphical Notation (SBGN), is a standard for drawing pathways. It prescribes exactly how to draw a biochemical reaction, how one can display the effect of heat on protein degradation, or how you should present the formation of a protein complex. It’s unambiguous: no matter how complex the drawing gets, it can be interpreted in only one way. SBGN is the result of many discussions, arguments and debates, over the course of several years and it’s therefore really well thought out.

Good software support is essential to make SBGN succeed as a standard. LibSBGN was created in an attempt to encourage uptake. As the name implies, LibSBGN is a software library that should make it easy to incorporate SBGN in pathway tools.

LibSBGN is only a software component, it’s not a ready to use end-product by itself. So this announcement is probably only interesting to bioinformatics developers. Nevertheless, I hope that it will soon lead to an increased uptake of SBGN in pathway tools, which should benefit end-users of those tools as well.

LibSBGN is already supported by a few applications, including of course PathVisio. To make sure that it works exactly the same in each tool, we’ve created a comparison gallery, containing several test-cases rendered by each tool. All the diagrams should look exactly the same for each tool. This comparison page has proven tremendously useful to check for bugs and misunderstandings.

This is only the first release, there is still a lot to do. This first release only supports a part of SBGN called process description (PD). The coming months will see lots of work on the remaining parts of SBGN, entity relationships (ER), and activity flow (AF). And after that we’ve planned more features, such as validation rules and file format conversion.

This is the first tangible result from something that was set in motion at a meeting in Wittenberg. LibSBGN community: thanks for your hard work and congratulations on this first milestone.

DNA is said to contain the instructions to build an organism, just like software contains instructions for a computer. Poorly structured software is sometimes called “Spaghetti Code” because it’s such an intangible mess. What about the structure of DNA? Here is a nice quote from the linux kernel mailing list (link):

> Human communication methods are all buggy as hell  

Not to mention that they are slow, inefficient and ambiguous.

But wht did you expect? The original authors of the code are long gone and
maintenance is done by newcomers who are patching the code bit by bit. What
you get from such a development model is pretty predictable: ~1 billion years
old spaghetti DNA that no-one truly understands.

Evolution may be a “poor development model”, but at least DNA has seen billions of years of debugging

“I don’t see why Oracle won’t be able to keep MySQL open and still have a nice profitable business model.”

However, all that seems rather less likely, now that Oracle is suing Google over patent infringement in the open source Android platform.

Here is a great point of view from a Java developer on this lawsuit. Not only it explains what the suit is all about, but also gives historical perspective, how Java got into this mess in the first place.

From that link:

“Android actually *was* a great platform that supported existing Java developers and libraries incredibly well (without actually being a Java environment), and for the first time there was a serious contender to “standard” Java that Sun had absolutely no control over.”

and:

“If for nothing else, Jonathan Schwartz will be remembered as the man who broke open the Sun piñata, simultaneously releasing more open-source software than any company in history and killing Sun in the process. Either Jonathan had no “step 2″ or the inertia of a company built on closed-source products was too great to overcome. In either case, by spring of 2009 Sun was hemorrhaging”

It’s long but well worth a read if you are concerned about the future of Java.

Registration just opened, I’ve already signed up.

The SBGN community organizes regular meetings or “hackathons”, where specs are discussed and new SBGN-related software is presented. This year I was present at the meeting held at Wittenberg in Germany (where you can still find the church door where Luther pinned his 95 theses). Here is my writeup, by no means complete, just a collection of impressions.

Vanted SBGN-ED
In the category SBGN-related software, Tobias Czauderna demonstrated SBGN-ED,  a new plugin for Vanted that lets you create diagrams in SBGN format. Especially interesting is the nice validator that can tell you if you drew something that is not allowed by the SBGN specifications. A very complete SBGN editor and probably one of the nicest out there. No link yet, but there will be a publication very soon.

Vanted BridgeDb plugin
Unfortunately a few presentations had to be canceled the first day due to the volcanic ash that was plaguing the European skies. To fill the gaps in the agenda, we just started hacking on random stuff. One result of this was a Vanted BridgeDb plugin that I made together with Christian Kuklas. Christian immediately found a number of bugs and requested new features in BridgeDb. There is not yet an easy way to install the plugin, but if you’re interested you can play with the source code

SBGN Exchange format
The second and third day, most participants managed to overcome the disruption of the air traffic and join the conference. Besides discussion on the planned next release of SBGN, there was another important topic: LibSBGN.

SBGN currently only exists as a specification of glyphs and symbols and what they mean, there is no computer file format. But there are now several software packages out there that deal with SBGN, and they need a standard exchange format to work together.

The existing standard file formats for pathways, SBML and BioPAX, do not store  layout information, i.e. they do not store the position of the elements of a diagram. According to the SBGN spec, layout information does not carry any meaning. Biologically the diagram means the same thing, no matter if elements are arranged vertically, horizontally, in a circle, or in random order. So you would think there is no problem.

But as it turns out, it’s exactly the layout information that has to be exchanged between pathway software. It turns out that a good pathway layout is really hard to do automatically, so once you have painstakingly defined a layout you want to preserve it. So weirdly enough we want an SBGN file format to exchange information that is not part of the SBGN spec at all.

Because there is no standard, the current tools all defined their own ad-hoc file format out of necessity. The lack of a standard file format is really becoming an impediment to cooperation. There has been a lot of talk how this should look like, XML? DTD? GML? Object model? But in my opinion it doesn’t matter too much in the end, you just have to make a decision and stick with it. We’ve been able to turn a lot of discussion into tangible results in the form of a new SourceForge project, and uploaded some small samples and the beginnings of an XML Schema definition. Hopefully we can keep the momentum and get it mostly done by the next SBGN meeting.

jSBML
Not related to SBGN directly, but I found it interesting nontheless: A new java native library for SBML is being developed called jSBML. There already existed a library called libSBML, but it’s written in C++. Because LibSBML was considered a “good-enough” solution for java programs, the SBML community for a long time resisted the notion of a native java library. But it turned out that many SBML-based Java projects were actually developing their own native library anyway. Ironically,  the tendency to avoid duplication of work actually led to multiple incomplete projects that all duplicated each other. Sometimes it’s best to accept reality.

A big challenge for WikiPathways is to get people to take the first step, to get them over that initial hump and actually start participating. Certainly a lot of people are very interested in WikiPathways, but there is some hesitation to just start working on the content. It’s something we have to work on. Besides clearing technical hurdles, we try to gently help people, simply to get started.

As an experiment, we organized a dedicated curation jamboree, a focused effort to get together and crank through a list of curation tasks. We prepared documentation, contacted several mailing lists and harassed all our colleagues. We also put together a special chat channel where newcomers can get instantaneous contact and answers to quick questions. This event happened for two days in February.

So, was it a success? Yes, if you look at edit activity. Thomas made this graph of the number of pathways tagged with either “needs reference” (for pathways that don’t have any literature references) and “missing description” (for pathways that don’t have a nice description text). As you can see, the numbers dropped quickly during the two days of the curation event, by at least 25%. (ignore the initial jump in the blue line, that’s due to a bug in the data collection script). WikiPathways gained a lot of curated data in a short period of time.

The most active contributors were the usual suspects: Thomas, Alex, Kristina and me, the core WikiPathways team. But you can see in the graph below that other people joined in as well. Even if they did only a few curation tasks, that’s good  enough. The most important thing is to get people to take the first step. So the graph below is misleading: participating really is more important than winning.

Number of edits per user