Friday, June 4, 2010

Let's All Learn About iGEM Software! Yay!

This is one of those posts I wrote for my own benefit, not some hypothetical readership. This will likely be apparent. You have been warned.

I was originally planning on writing about something else and including my standard doodle with this post, but my Google search for reference images seriously grossed me out and I don't have time for that. Instead, here's a post about iGEM software which will force me to do some useful research instead of looking up eye-rending images on Google. Yay!

If you don't know me and are new to this blog here are some explanatory links about iGEM. With that out of the way, what's up with this year's Waterloo iGEM software project? Well, we're working with a BioCompiler concept that roughly translates to: take code, apply genius, extract BioBrick assembly instructions. A compiler, in a computational context, takes code and translates it into equivalent code in a much more primitive language and what we intend to do is an exact analogy of that process for biological systems.

We haven't gotten very far with this design yet, but already there seems to be a canonical example of the goal in the form of the pseudocode "if the concentration of (something) exceeds (value) and the concentration of (something else) is less than (another value) then produce [something]". I wonder how much complexity would be involved in simply translating specifications that meet the above template into assembly instructions; intuitively, I don't feel it should be too excessive, but there is already some possibility for conflicts between the signalling pathway of "something" versus "something else" and this system would already probably be pretty tricky to construct. Following this vague syntax, our working design for the main 2010 project would fit the template "if (something) is present, produce (something else); if the concentration of (something else) is above (constant), produce (yet another thing)". That's an almost trivial piece of code, but it's already pushing the limits of what we can model and what we can construct. Whether this a ringing endorsement of the BioCompiler concept or an outright condemnation, I'm not sure.

The BioCompiler concept is both really exciting and worrisome at the same time. Worrisome, because in order to pursue the BioCompiler idea we'll be discarding work done by the software team of the previous term which sets a bad precedent for continuity. Moreover, this project will definitely not be done before the end of the term, so we'll need to depend on the software team from the opposing stream to continue it. On top of the "sorry I killed you project" factor, it also bugs me that this isn't a project I could conceivably sit down and write myself given a couple weeks. I mean, I realize that it's a good thing that we have an ambitious project that will involve more than myself, and I never had any intention of literally writing the whole software project by myself, but at the same time I like being able to deliver tangible results and this project has no guarantees of delivering those results any time soon. Nonetheless, optimism run high.

Okay. That was all a long diversion because the point of this post was for me to force myself to read and talk about UC Berkeley's 2009 software project. Their project had four main components, all of which are helpfully embodied by silly characters in their documentation. Eugene, the "red-headed stepchild and language", is a formal way of describing BioBrick components. His glasses, Spectacles, are (represents? is? this is where the anthropomorphization of the software modules becomes frustrating linguistically) a tool for visualizing Eugene's data. Kepler is a "Wise Astronomer and Workflow Wizard" which is to say that it's the part of the project concerned with the assembly of parts and it/he actually guides a robot through the assembly process. That was bold and italic because it's that mindblowing. Finally, Clotho (AKA the Hot Green Chick) is a "Greek Goddess and Software Tool". Say what you will about Berkeley's documentation, at least it's memorable (and actually the rest of their documentation is decent as well, including design notes from team members and demo videos of some of the software products).

Anyway, Clotho, yeah. Clotho is an attempt to span the design hierarchy between the parts-level design that Kepler, Eugene, and Spectacles work at and the systems-level and device-level design that engineers like to think at. Actually, upon re-reading the Berkeley page, it appears they believe Kepler, Eugene, and Spectacles operate at the device-level. Huh. It also appears that despite lofty aims at hierarchy-spanning behaviour from Clotho, that module is a simple data management system. It might help you organize your thoughts at varying levels of abstraction, but it certainly won't take ideas written at one level and push them to another. That, I guess, is where we come in.

Alright folks, I'm falling asleep so this is as far as we come today. If you've read this far, I... well I don't know what to think. I'm assuming you haven't read this far. Maybe you cheated and skimmed to the end. In any case, thanks for bearing through it and hopefully everyone learned a valuable lesson about iGEM software. Yay!

4 comments:

  1. Oh dear God, that is a much longer post than I had anticipated.

    ReplyDelete
  2. Hehe, that's two of you now, blogging about iGEM since Thursday's meeting. I feel compelled to give in to nonexistent peer pressure and follow suit. (Or more like I meant to write about iGEM on Thursday, got distracted, and have now been reminded of my original intention.)

    I am also very curious about what kind of eye-rending things you were looking up on Google. :P

    ReplyDelete
  3. tl;dr, but I am charged with your enthusiasm now, thank you.

    ReplyDelete
  4. @Danielle: I look forward to your post with great enthusiasm. Consider yourself officially peer pressured. Also, I had originally posted a Buzz message about the image search, but deleted it when I realized that other people were not heeding the warning (to quote one such person: "That's not how the internet works! People click on links!"). Suffice it to say that it _was_ a "safe for work" search.

    @George: Sweet. That's all I ask for. That, and reading through all the documentation for SynBioSS, the Berkeley Software Suite, SBML, SBW, TinkerCell, EMBOSS, and GEC (in great detail). :P

    ReplyDelete