Posts Tagged ‘pathvisio’

So I have an SBGN-ML file, what’s next?

Thursday, March 22nd, 2012

The Systems Biology Graphical Notation (SBGN) is a system for drawing pathways in a very precise and standardized way. But the problem is that the software support is spotty at best. The LibSBGN project is here to help improve that situation (For a bit of history, see here and here). As part of this project, we created a file format for SBGN files, named SBGN Markup Language or SBGN-ML.

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.

Pathway Visualization to the next level

Friday, February 25th, 2011

The laboratory of bioinformatics of Wageningen University has put together some really cool hardware. In the picture below you see their tiled display, consisting of 12 high-resolution monitors, powered by a single workstation.

PathVisio on tiled display

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.

PathVisio 2 released

Sunday, October 18th, 2009

This week we released version 2.0 of PathVisio. There has been over a year of active development since the last major release, and a ton of new features.

What is PathVisio? PathVisio is a tool for biological pathways. Stay organized! Use PathVisio as a simple notebook to collect all the various bits of information related to a biological research subject. Create images suitable for presentation or publication. Draw pathways, export them to many image formats, annotate them with links to online biological databases such as Ensembl or Entrez gene, and add comments and literature references from pubmed.

With PathVisio you draw pathways just like you would in powerpoint:
drawing_closeup

What is new? New in PathVisio 2.0 is the ability to import experimental datasets and visualize them on top of pathways. Explore large datasets in a way that is more interesting and understandable than just a huge spreadsheet. Import microarray, proteomics or metabolomics data. Microarray reporters will be automatically linked to genes and protein identifiers in pathways. You can customize the visualization, using gradients, boolean color rules, or colored icons.

Here is an example of visualized microarray data:
visualization_closeup

Perform over-representation analysis to find the pathway that was most affected by experimental conditions. This is great for hypothesis-generating experiment types, where you really don’t know anything in advance about your experiment.

Download pathway sets or share pathways on WikiPathways, a wiki where any researchers can contribute pathway knowledge. PathVisio is fully compatible.

Check our visual tour if you want to know more. Click here to Download PathVisio

For Developers: PathVisio has a plugin interface that lets users customize it to new analysis types, new visualization methods and new pathway formats. PathVisio is fully open source, and we’re always looking for Java developers who are interested in contributing, either to new plugins or to the core of the program. Contact us on our mailinglist.

Martijn’s Continuous Build System part 2

Sunday, July 19th, 2009

In part 1, I described what a continuous build system is, and what it is useful for. Now I’m going to write about another important use of the build system: testing interfaces between modules.

In a modular system, the parts evolve independently in different directions and at different speeds. This is true in programming as well as in biology. Applications with a plug-in system (plug-ins, extensions, modules and drivers are really all the same thing) can add new features while avoiding bloat, can be customized to highly specific uses without burdening the user interface for everybody, etc. In the end, every interesting program will have a need for a plug-in system of some sort.

Shackled by a stable interface

Shackled by a stable interface

In a plug-in system, you have to define an interface between the main program and the plug-ins. This interface is also called API (Application Programming Interface). It is important that this interface is well defined and doesn’t change over time. If the API unilaterally changes, all the plug-ins will stop working. So naturally, most programs strive to keep the interfaces between the program and the plug-ins stable. This is what the Cytoscape people refer to when they are talking about the “Stable Plugin API”, a holy grail that they have yet to achieve unfortunately.

For PathVisio we use an unconstrained development model where the interface between the program and plug-ins can change at any time, as needed for the improvement of the program. How is this possible?

Linux pioneered that model: they call a stable API nonsense. The interface between drivers and the kernel changes all the time. If the Linux developers think of a better, more consistent or more efficient way to interface with the drivers they go ahead and make that change.

So how is this possible? How does Linux not degrade into a stinking heap of old drivers with interface mismatches that can’t communicate with the kernel properly? The answer is simple: because Linux is completely open source, any kernel developer can update all drivers at the same time as they change the API.

This model has two consequences

  1. Linux developers are free to improve the kernel in every way they can. They do not have to keep supporting an old crufty outdated API to keep old drivers working.
  2. Drivers for Linux have to be open source, or they run the risk of getting out of date really quickly.

The fact that their hands are not tied to a stable API gives the kernel developers enormous freedom to improve their work. Compare that to Windows. Living in a closed-source world, the Windows developers are stuck, they can never improve their kernel without breaking everything. Windows developers tried to break out of this choke hold with Vista. Vista came with a fresh new driver API, different from XP. The consequence, of course, was that several months after the release of Vista people were still complaining about broken drivers.

Of course the problems with Vista did get resolved in the end, but it took a lot of time and effort. The key difference is in who updates the drivers. In the Linux world, the person who changes the API is also the person who updates the drivers. This is only possible because the drivers are open source. The Windows developers have to notify all the driver developers about the API changes. This is a huge communication burden.

Back to bioinformatics. Unfortunately, Cytoscape can’t follow the Linux model because they want to support closed-source plugins. A number of core developers of Cytoscape live in the closed source world, and are not keen to release their plug-in source code. This means that Cytoscape has to continue on its quest for that elusive Stable plugin API.

PathVisio, on the other hand, has no such tie-in. Although the PathVisio license agreement certainly permits the development of closed-source plug-ins, we strongly discourage it. PathVisio does not seek a stable plugin API. Instead, what we have is the PathVisio promise:

If you make your plug-in open source, we will update your plug-in whenever there is an API change.

And we can fulfill this promise thanks to the continuous build system. It tests interfaces between modules. It tracks modules from multiple repositories, and runs fresh tests whenever a programmer checks in new code. Even better, all modules that interact with a changed module is tested as well, so we can check that the interface between them still works. At this moment we track dozens of modules from 10 different repositories. All this testing lets us follow a development model where any interface can be changed as needed. If something breaks, the build system will tell us and we will fix it immediately.

Martijn’s Continuous Build System part 1

Thursday, June 25th, 2009

Joel said it best – Daily Builds are your friend.

A continuous build system is quality control for a program that’s being developed. It’s a computer that tests the state of the program every day. Or preferably every ten minutes. Under my desk I have a computer whose sole job it is to continuously monitor the state of PathVisio. Does it compile correctly? Are there any style problems in the source code? Are the automated tests positive? Fresh documentation is automatically generated and uploaded. The webstart version is refreshed. A fresh zip archive is created and placed in a convenient place. If there are any problems, an email is sent to our mailing list. There is an online report where you can find out everything about the current health of PathVisio.

bigstockphoto_fire_alarm_1536674The real effect of a preventive measure is always hard to tell. It’s like fire prevention measures. They are costly, yet most houses won’t need them because they’ll never burn to the ground. Setting up a good continuous build system is quite a bit of work. Is it just red tape, a lot of effort but YAGNI?

Here is an example of how it saved us. After I hooked up Helen’s summer-of-code project to the continuous build system, we soon got a ton of errors by email. It turns out that she started using GroupLayout, a java class that is only available in Java 6 and higher. However, unbeknownst to Helen, both Cytoscape and PathVisio aim to be compatible with Java 5, and I configured the build system to check for Java 5 compatibility. So we found out about this problem right away, and Helen could fix the problem immediately before going too far down a dead-end road. It would probably have taken a lot more work to fix this if we had found out later.

For PathVisio we’ve used a continuous build system since day one. But recently I’ve taken the time to make quite a few improvements. I plan to write about that in more detail in the coming days.

Edit:here is part 2