Posts Tagged ‘meeting’

Going to COMBINE 2010

Saturday, July 31st, 2010

COMBINE 2010 is a meeting about all systems biology standards: SBML, SBGN, BioPAX, … etc. It’s from October 6 to 9 in Edinburgh, just before the ICSB conference.

Registration just opened, I’ve already signed up.

SBGN 5.5 Hackathon writeup

Sunday, April 25th, 2010

The goal of Systems Biology Graphical Notation or SBGN is to define a set of standard shapes for things like reactions, enzymes, genes, metabolites, compartments etc. For example, here is the reaction that takes place in your body after an alcoholic beverage, using SBGN notation.

Alcohol dehydrogenase as SBGN diagram

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.

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.