There has been a lot of discussion about how OpenWetWare can best get involved with scientific publishing. One of the ideas that has been tossed around is to develop OWW as a place to publish supplementary material. In the spirit of my ongoing experiment with OWW as a publication platform (see other posts one, two, three,four, five), I’ve played around with using OWW as a repository of supplemental material.

The idea is simple - there is a lot of extra information gleaned in the course of an investigation that just doesn’t make it into the final paper. We all know of it under the blanket term ‘Supplementary Material’, but what it consists of can vary quite a bit from paper to paper. Most of the time it contains tables and figures that describe some technicalities that don’t fit in with the story line of the article, but are required if anyone wanted to reproduce the results of the investigation. There is no reason it couldn’t be more, which is where OWW could step in to revolutionize the supplementary material business.

Being wiki based, OWW has a unique opportunity to offer the most up-to-date version of supplementary material possible. Even though articles and papers are fixed time snapshots of a work, research has a life of its own and is often on-going. What’s to say that a regularly updated supplemental material section of an article wouldn’t be useful? Furthermore, since wikis support almost any kind of content imaginable, why not explore alternative supplementary materials such as videos that don’t fit in with the current pdf-based supplementary material model?

The problem is that we haven’t figured out how best to get OWW plugged into the mainstream publishing venues. Luckily some journals - namely the Public Library of Science (PLoS) journals - have created a way we can play around with some of these ideas.

Here’s the setup: I recently published a comparative genomics study in PLoS Computational Biology (link (trackback)). During this study, I used python to do ALL of the computations in the work. I thought it would be a good idea to write a small companion paper on how I did this so that other scientists could learn how great python is as a complete scientific programming environment. You can see this article through OWW here. This little companion article can easily be viewed as supplementary material to my original article. I contacted the PLoS people and asked them if I could add a link to this OWW article from the original article and they said ‘Sure, you can even do it yourself!’ You see, PLoS has a commenting system, much like the one on this blog - all I had to do is to create a comment linking to my OWW article (see image below) and voila, we have the first OWW supplementary material! What is even more interesting is that the supplementary article was written AFTER the original article was published - a great example of how OWW facilitates the evolution of supplementary materials over time.

The conclusion is that we actually don’t have to do much at all to start using OWW as a supplementary material repository - just start using it, and figure out a way to link your OWW pages to your official journal article. If you have published in a PLoS journal, then do the above. I encourage you to write other journals and request that they manually place a link to your content if they don’t offer a commenting system.

Please, let me know what you think and share your experiences in using OWW for developing supplementary materials by leaving a comment below.

Posted: April 14th, 2008 under Publishing.
Comments: 7

This is the fifth report of the ‘Publishing on OpenWetWare’ series. In brief, I am writing an article on OWW from start to finish: initial writing -> collecting comments -> publishing on arXiv.org -> presenting at a conference. For other articles, see one, two, three,four. In this report, I’ll share my experiences in presenting the work at Pycon 2008.

Creating the Presentation

Creating the presentation was not too difficult, especially since I used the general outline for the article as the outline of the talk. I could also use the same code snippets in the talk, with some minor modifications. You can see the talk slides here.

The Presentation

The talk was well attended (about 200 people), and there were questions about other tools that one could also use in python for science. It looks like there is a small community of scientists using python that come to Pycon regularly.

There is also a group of people interested in bringing some of the good coding practices offered by python to more scientists. There are also a lot of general software development tools such as unit testing and source code management that not only make the scientific programming task easier, but also promote good scientific practice. I am hoping that Python - All A Scientist Needs will be the first of a series of articles on good programming practices for scientists. I’m also hoping that we can write these articles with the same process (OWW -> arXiv), and make OWW into a respected publishing platform.

Please leave a comment!

Posted: March 15th, 2008 under Publishing.
Comments: none

This is the fourth report of the ‘Publishing on OpenWetWare’ series. In brief, I am writing an article on OWW from start to finish: initial writing -> collecting comments -> publishing on arXiv.org -> presenting at a conference. For other articles, see one, two, and three. In this report, I’ll share my experiences in how easy it was to convert the wiki text into latex and publish the paper on the arXiv.

The Setup

The article, ‘Python - All A Scientist Needs’ can be seen here. Once the article was in its final form, I wanted to formalize its publication by submitting a copy of it to the arXiv. The arXiv takes PDF submissions, so all I really had to do was to print the OWW page to PDF and submit that. However, I wanted things to look a bit nicer so I chose to convert the wiki text into latex, and submit a pdf generated by latex. This way I could also use the latex hyperref package to put clickable links within the PDF.

Wiki -> Latex

The final latex source of the article can be found here. To convert the wiki text into latex, I had to perform the following steps:

1. Create the base latex file.
2. Input the wiki text: To do this, I juts selected edit on the wiki page and copied and pasted the whole article into the latex document. Initially, I commented out the code examples and figures to deal with them later.
3. Replace the wiki markup with latex markup:
   • Make single quotes into latex quotes (” -> `’)
   • Make italic quotes into emph (”” -> \emph{})
   • Make bold quotes into \bf (””” -> {\bf})
   • Replace tags with \cite (regexp (.*?) -> \cite{$1})
   • Replace tags with $ (regexp (.*?) -> \$$1\$)
   • Replace # lists with enumerate environments
   • Replace * lists with itemize environments
4. Added references: Here I had to manually convert the biblio package references into \bibitem’s in the latex source. I used the hyperref package and the \href command to link to resources on the web.
5. Added the code examples: I chose the listings package, although it was a bit confusing to customize. In fact, the inadequacy of the package necessitated a code restructuring.
6. Added the figure.

Overall, this was a pretty painful process, even for someone with a lot of experience with wikis and latex. It was hard to keep the wiki version and the latex version’s synced together as well. Overall the final PDF does not look as good as the wiki page. In total, the latexing took about 6 hours of work.

Publishing on the arXiv

Publishing the paper on the arXiv was very straight-forward. I simply filled out a form with the article metadata (title, abstract, etc.), uploaded my latex and figure files, and it was posted on the arXiv within a couple of days. You can see the article here.

There was a minor issue with copyright licensing that should be mentioned. OWW uses a Creative Commons Attribution-ShareAlike license. The arXiv offers a couple of license choices (CC-Attribution and CC-NonCommercial-Attribution-ShareAlike), but neither of them matched OWW’s license exactly. In the end I chose CC-Attribution, because I did not want to have the NonCommercial issue. We should probably sort this matter out if we want to create a lot of arXiv papers from OWW.

Conclusions

In the end, the process was worth it because there is now a referenceable copy of the article on the arXiv. (Referenceable in the sense that journals will accept a reference to an arXiv paper.) It took a little while to convert the wiki text into latex, but a lot of that can be facilitated by an automatic conversion tool.

Please let me know what you think by leaving a comment on this post!

Posted: March 15th, 2008 under Publishing.
Comments: none

This is the third report of the ‘Publishing on OpenWetWare’ series. In brief, I am writing an article on OWW from start to finish: initial writing -> collecting comments -> publishing on arXiv.org -> presenting at a conference. For other articles, see one, and two. In this report, I’ll share my experiences in gathering comments from the community.

The Setup

The first draft of ‘Python - All A Scientist Needs’ can be seen here. After finishing the draft, I posted a link at the top of the page asking anyone who wanted to comment to leave a comment on the talk page. I also sent emails to 6 friends, giving them a link to the OWW page, and asking them to either email me comments, or to type them directly in the wiki page. In addition, the second report in this series (two) invited anyone who wanted to comment on the paper to leave a comment on the wiki, or a comment on the blog post.

All the comments received can be seen on the talk page.

Results

I received a total of 2 comments and criticisms, and 2 notes of encouragement. Neither set of the criticisms were that critical, and every note I received was very positive. All of these responses were from the email solicitations. The breakdown of the method of delivery is as follows:

• 3 comments by email. (One of these was typed in manually into the talk page by myself.)
• 1 comment from the wiki talk page. (In this case I actually forced my friend to get an OWW account to do this.)
• 0 comments from the blog post (about the article itself).

This is all despite the 4,163 times (as of this writing) that the article has been viewed.

Conclusions

Something is wrong with the way OWW is thinking about users contributing to the wiki. This experiment seems to demonstrate that users are hesitant to edit pages - even talk pages - even when they are explicitly asked to. Over 4,000 page hits is an awful lot for at least some of those to not leave comments.

I’m not sure why this is the case, but I would sure like to find out. If anyone has any ideas, please don’t hesitate to leave a comment on this blog post, or the talk page for the article.

On the other hand, this 4,000 number could reflect a lot of non-OWW users accessing the page. (Googling ‘Python Scientist’ gives the page as the 8th result as of this writing.) I have no way of knowing how many of those people might have wanted to leave a comment, but couldn’t because they are not OWW users. (To avoid spam, I only put a link to emailing me through OWW, not explicitly through my email address. However, there are links to the blog posts which allow public comments, but those are presumably found only by the most diligent readers.)

The main reason why OWW does not allow anonymous comments is that science is not anonymous, and OWW in the end is a resource for professional-quality scientific material. OWW might consider opening up to blog-like comments however, where authors of the page can accept or reject anonymous comments as they appear. It might allow for a lot more community participation, and it would be nice for the authors to know how people viewed their material.

If you have any thoughts/questions/opinions, once again, please don’t hesitate to leave a comment on this blog post, or the talk page for the article.

Posted: March 10th, 2008 under Publishing.
Comments: none

Previously I wrote about my plan to try out OWW as an authoring platform. I have now completed the first phase of this little experiment, and I thought I would share my experiences.

The first draft of ‘Python - All A Scientist Needs’ can be seen here. I wrote the article completely on OWW, but developed and tested the code examples on my laptop, since OWW doesn’t provide a way to test and run code. The wiki worked out pretty great until the document got too long to manage easily. Below are the pros and cons of my experience.

Wiki As An Authoring Tool: Pros

• I really enjoyed having a copy of the document that I could work on from anywhere (my laptop at home, computer on the bench in the lab).
• The formatting looks nice, especially the code example highlighting.
• The biblio plugin makes citations very easy to work with (with some manual typing).
• The versioning through the article history made it very easy to see past versions.
• Having the wiki host the source code zip file is a great way to share supplementary data.

Wiki As An Authoring Tool: Cons

• The article got a little unwieldy to deal with when it got to its full length. When adding citations, I needed to edit the whole document to be able to see where the citation goes as well as plug it into the References section.
• The wiki auto-time-out could be very frustrating causing me to lose changes if I didn’t save often enough. (You can see where I got a little annoyed if you look at the history comments.)
• I had to use a web browser to do my edits, instead of a client-side text editor, which is my method of choice.

It’s now time for phase 2 - collecting comments. I have sent out an email to a few friends to collect their comments. Hopefully they will use the talk page to write their comments down. I would be very grateful if any of you would like to leave comments, either on the talk page, or at the bottom of this post.

Thanks!

Posted: February 20th, 2008 under Publishing.
Comments: 5

The Steering Committee has been talking about developing an alternative publishing system/model through openwetware. I wish I could give a more concrete definition of what we are trying to achieve, but we are still in a pretty active debate and nothing clear has emerged.

My personal opinion about it, is that the first thing to do is for OWW to build a publishing community by creating a free, open-access, moderated system to publish Synthetic Biology papers. These papers would not have to be strictly the same as traditional peer-reviewed papers, and could include descriptions of protocols, part characterizations/designs, etc. In addition these papers could use OWW url’s as citations, thus establishing a legitimate credit system for OWW contributions. Both of these are a little hard to achieve with current publishers, hence the need for our own channel. We would only start with synthetic biology because it is a small, young and vibrant crowd, and of course this would apply to all disciplines eventually - we just need to get on our feet.

Specifically, I am a strong advocate of trying out a model in which people write their papers/publishable bits on the OWW wiki. Once they are done (revised, commented on, etc.) we publish them to arXiv.org where the work is moderated and if accepted is then hosted there and in effect given a doi which is more citeable in conventional publication. From there it can be submitted wherever the author wishes.

To be specific, my particular reasons for wanting to use the arXiv are as follows:

• The arXiv would be open to having an ‘oww’ or ’synthetic biology’ section, much like it has condensed matter physics, high energy phyciscs sections. In fact it already has a section called ‘quantitative biology’ that we could submit to. The sections are weakly moderated for suitable content by people in the field.

• The arXiv is an e-print system, and is often used as an intermediate step between research and publishing in a more peer-reviewed journal. There are also cases where the arXiv is the final resting place for a paper, including those in the PLoS One model where the science is good, but it is not ‘hot’ enough to get into a journal.

• The arXiv is completely electronically based, and offers many services including ingest and digest APIs to create automatic submission tools, and include arXiv content inside websites (rss) and tools (like pubmed searching).

• An arXiv article is assigned a unique identifier (not a standard doi though), that is citeable.

• The arXiv has a flexible enough system so that we could have an arXiv-hosted OWW journal with essentially no backend cost. In fact, certain astro-physics and mathematics societies already do create their own ‘overlay’ journals on the arXiv.

• OWW can easily create an arXiv ’skin’ that contains a commenting system overlaid on the backend content hosted by the arXiv, or whatever else we want to do.

To that end, I am trying out a little experiment. I am going to write a paper on the arXiv on a topic that would not normally be publishable in a peer-reviewed journal: about how I used the python programming language to perform all the computational work in a recent comparative genomics study. I will write the paper on OWW, send out the link to it for comments, and when I have revised it, I will submit it to the quantitative biology section of the arXiv.

Anyone that is interested, please see: Python - All a Scientist Needs. Leave a comment there, or here, and let me know what you think!

Posted: February 7th, 2008 under Publishing.
Comments: 11

The past month or so I have been moving from Ithaca, NY to Berkeley, CA, and I am happy to have arrived at my new home in the Arkin Lab. I’m still in the process of settling in, but I have managed to start experiments thanks to John Dueber and Weston Whitaker, who have generously agreed to teach me the ropes of molecular biology. (Given that I have almost no lab experience, this should be a lot of fun for me, and hopefully not too much pain for Wes and John.)

While spending some time getting introduced to the bench, I’m also brainstorming project ideas in the general area of biocomputing. If anyone is in the area and wants to chat about biocomputing, OpenWetWare, or anything else, please drop me a line.

Posted: January 15th, 2008 under Uncategorized.
Comments: 2

I owe another thanks to Bill Flanagan for installing the WordPress markdown pluggin, which enables me to format my posts in markdown rather than in HTML. This really makes writing blog entries much more fun and convenient since now I can easily use TextMate to write my entries offline at my leisure, and post them when I am online.

Strictly speaking, markdown support and TextMate offline editing are separate issues, but their combination really makes things pleasant. I am not a big fan of the WordPress online editor - it is really just too slow, and I also have to be online to write or edit posts. While this is not usually a problem, there are certain times like when I am on a plane that I would like the ability to write and edit posts. The WordPress editor also makes you use HTML, which I find to be a bit unwieldy. Ok, one at a time.

First markdown. Markdown is a simple markup language that lets you write things like [this link to the original markdown site](http://daringfireball.net/projects/markdown/) (this link to the original markdown site), instead of HTML <a> tags. In this way, markdown is very similar to mediawiki syntax.

Second is TextMate’s ability to interact with the WordPress API. I really can’t put it any better than this TextMate blogging screencast, but the gist of it goes something like this: Every WordPress blog has a special url that can receive what are called XMLRPC requests. XMLRPC stands for ‘XML Remote Procedure Call’, and it essentially means that you can write a client to send specific pieces of XML to the WordPress blog to ask it to return information such as a list of posts. You can also send whole blog posts formatted appropriately, and the WordPress blog, via this API, will post them for you.

You can then write any client you want to take advantage of this system, and this is what the TextMate people have done. Since you only need to interact with the WordPress blog to get a list of posts, or while posting content, you can do the majority of your writing and editing offline! And what is more, you can write any client to do this - it doesn’t have to be TextMate.

And this brings me to my ideas about where OWW should go technologically to help foster Open Lab Notebooks. One of my biggest complaints that I have about the OWW wiki is that I have to be online to to write a wiki entry. Not only that, but you have to deal with the whims of your connection to OWW - it is really frustrating to lose a post because your connection to OWW timed out, or you accidentally closed that browser window before you hit save. I can imagine a system where the OWW wiki has an API that allows me to write a TextMate pluggin to interact with it much like TextMate can now interact with WordPress. I can then take notes in the lab during the day, and not worry about my internet connection. I can edit a paper on the plane, and post my update to OWW when I have an internet connection again. What is more, I can easily write TextMate templates to auto-fill in information that is particular to my experiment, or article.

And that is just the start of it. By exposing an OWW API, I can then write code that automatically posts the results of my latest calculations on my OWW wiki pages. Or I can get my favorite lab instrument X to automatically upload a data file containing the data from the latest run. The possibilities are endless.

I should say that things like this can be done right now, but mostly through some hacks that don’t expose the full power of the OWW mediawiki software. I think with a little tweaks, we’ll have everything we need to let client developers have a hey-day.

Links

• OWW’s Bill Flanagan
• The Markdown Syntax
• Mediawiki Syntax
• The WordPress API
• TextMate
• Blogging with TextMate Screencast
• Cameron Neylon discusses Open Lab Notebooks

Posted: November 4th, 2007 under Uncategorized.
Comments: none

I cannot resist mentioning something that I think will really add another huge boost to the open science movement. arXiv.org has now opened up its massive troves of open access articles via an Application Programming Interface, or API.

You might think that you have never heard of arXiv.org before, nor do you have any connection to it whatsoever. But more than likely you do have a connection to it, especially if you have ever visited a journal’s website, read a table of contents online, looked at an online abstract, or downloaded a PDF of a paper.

What was to eventually become arXiv.org was started by Paul Ginsparg in 1991 as an electronic means of continuing a practice already common among high-energy physicists: sharing pre-prints before they came out in the journals. At that time, high-energy physicists already recognized that the long delay’s associated with print publication actually hurt the pace of research, so they went ahead and sent pre-prints of all their papers to their friends. Realizing that this could 1) be done much better using the then increasingly popular email, and 2) that the current buddy list prevented those not in-the-know from ever being in-the-know, Ginsparg decided to digitalize this culture in the form of a centralized repository of digital pre-prints that anyone could access. The word ‘e-print’ was born.

Ginsparg’s original creation was based on SMTP, the protocol that enables email. (Remember the ‘web’ did not yet exist in 1991.) Eventually HTTP took the world by storm and in 1994 Ginsparg and co made the repository accessible via an HTML interface that eventually evolved into the present day arXiv.org.

From the very start, the arXiv project has provided full and open access to all of its e-prints. While it was inspired by and initially used by theoretical high-energy physicists, it quickly spread to all sub-disciplines of physics, and now serves the communities of physics, math, and computer science and most recently quantitative biology and statistics. For the most part, the arXiv allows anyone in these disciplines to post their work with only a smidgeon of peer review. Despite not having a rigorous peer review process, the arXiv has articles of astonishingly high quality, mainly because the common practice is for everyone to post their articles to the arXiv as well as submit to a regular journal.

Needless to say, it was the first of its kind, and it has done much to promote both the digitalization of scientific journals, and open access.

The arXiv has been going strong all this time, but the interface has centered around HTML web pages meant to be accessed by humans. That means that while it is easy to type in http://www.arxiv.org and click around to search and retrieve the articles that you are interested in, it is not easy to write a program to do this. (Unless you want to screen scrape, and no one wants to do that.) Well this has just changed with the release of the arXiv API.

But why would you want to write programs to do this stuff. The first thing that comes to mind is to relieve your self from the tedium of all those clicks, especially if you want to do things in bulk. But once you realize this, you immediately begin to think of all sorts of other uses, and herein lies the beauty of the API - once you have a way to program against all that information, you can do anything you want. More importantly you can convince your local nerd herd to program what you want. It’s probably a good time to make friends again.

Despite the API being only a few days old, there have already been some people that have stepped up to develop clients, including OpenWetWare’s Bill Flanagan. Pretty soon you will be able to use the extremely convenient biblio plugin on OpenWetWare to create bibliographies using arXiv articles. Given that there is a growing number of arXiv posts about quantitative biology, I suspect that there will be a growing number of OWW users that use this feature.

But I should mention, the arXiv is not the first scientific literature source to open up their information via an API. To my knowledge, this milestone was achieved by the National Center for Biotechnology Information with their entrez e-utils system. This system allows programmatic access to all of PubMed, PubMed central, and the data wharehouses at NCBI such as Genbank. In fact, the current biblio pluggin uses this API.

But the arXiv API puts the physics, math and computer sciences community in the mix, so that someone can really make a mashup with all of that open access content. I tried to do this a while ago before the arXiv API, and let me tell you that I sorely missed it. The arXiv API is a much needed addition to the open science infrastructure. As arXiv has done in the past, I hope this inspires a wave of API building by journal publishers and others with valuable data so that we can have the tools necessary to creatively combine all these knowledge sources to improve the way science is done.

For more details on the arXiv API, you can go to the arXiv API homepage, where you will find information on how to participate in the lively developer community, as well as info on how to get started using the API for your purposes.

Links

• The arXiv homepage
• arXiv API homepage
• Wikipedia: Paul Ginspary
• Grisha Perelman wins Fields medal for articles exclusively on arXiv.org
• Bill Flanagan
• The Biblio Pluggin
• Quantitative Biology at the arXiv
• NCBI
• The entrez e-utils API system

Posted: October 25th, 2007 under Open Science.
Comments: 8

Topic

Whole-cell biocomputing, by M. L. Simpson, G. S. Sayler, J. T. Fleming and B. Applegate out of Oak Ridge National Lab, University of Tennessee and Purdue University.

Open Access Journals

This paper is published in Trends in Biotechnology by the scientific megapublisher Elsevier. It is a shame that this article is not available for everyone to read. My comments here, and on my OpenWetware notes page, are open for anyone to read, and I encourage you to add a comment to this post, or edit the notes yourself. By participating in OpenWetWare, you promote the open sharing of scientific knowledge, and send the message to traditional publishers that you promote this cause.

Idea

This is a review article that covers recent progress (up to 2001) in using whole-cell genetic systems as biocomputing platforms. Rather than emphasize the role of one particular genetic subsystem (a single switch for example), the authors promote the view of the complex genetic machinery of the entire cell as a computational system.

The paper draws analogy between the ideas behind silicon-based integrated circuits and modern understanding of biochemical-based genetic circuits. The authors include a discussion of several natural cellular phenomena that can be viewed as complex computations:

1. Directed motility such as chemotaxis, phototaxis and magnetotaxis viewed as an input-reasoning-actuation system.
2. Symbiotic colonization as a complex computational communication system.
3. Group formation (such as biofilm formation) as a complex computational system.

This discussion leads the authors to consider engineering the cells genetic machinery to perform computations. Rather than focus on a particular domain-specific problem, the authors discuss the ’silicon mimetic’ approach to biocomputational engineering, in which the primary aim is to build the analog of modern silicon-based integrated circuits as genetic circuits inside cells.

The keystone of the silicon-based computing architectures is the transistor . A transistor can be viewed as a three terminal device where the transport of signal between two of the terminals is controlled by the third (the gate). Combinations of transistors can be put together to perform logic operations and other control structures, which is indeed what is done to build up the modern day processor.

The authors suggest an biological analogy to the transistor whereby a substrate-enzyme-product circuit is controlled by some effector acting on the enzyme, such as an enzyme inhibitor, or some transcription factor controlling the concentration of the enzyme. Such an analogy can be used to construct simple logic gates such as AND, OR, and XOR, which the authors suggest.

The authors mention several weaknesses of the synthetic mimetic approach, as discussed below, but remain optimistic about further engineering of this paradigm, and discuss further avenues of this work.

Discussion

I think the analogy of cells as naturally performing computations is a rich and productive one to pursue, and in this I think the authors do a good job by describing several common biological phenomenon as ‘computational’. In fact, the authors present a very interesting comparison between the information storage capacity between the DNA-based memory and logic units of cells, and that of modern silicon-based computers, suggesting that even the most modern silicon processing techniques don’t come anywhere near the volume-capacity for information storage and processing that a cell already has.

However, I think the analogy between cellular and silicon-based computing can go too far, and I think the authors have done just that. The authors seem to put all their eggs in the basket of the silicon mimetic approach. Before I discuss why I think this is a bad idea, I must first say a couple of words about why it might be a good idea. There are two main reasons:

1. We know a lot about silicon-based computing. There is a lot of infrastructure devoted to designing digital circuits to perform a slew of computations efficiently. If we could somehow figure out how to manufacture these circuits inside cells, all of the theoretical work on circuit design (that is not hardware-implementation specific), should be able to be ported over relatively quickly. Given the sheer volume of knowledge we have in this area, this is a good goal.

2. All silicon-based circuits are built upon one single idea - the transistor. In turn, transistors can be combined to form simple logic gates, such as AND, XOR, and OR. In turn, as the authors point out, any combinatorial logic function can be implemented as a series of these three gates. The idea is that if you get one thing right, you can build up arbitrary complexity by putting it together in complex ways. We already know how to do that (see 1. right above), so all we have to do is get this transistor thing right, and we are home free.

Unfortunately this is not true, and the authors even admit there are problems. While the problems are many, I’ll list just a few:

1. Digital circuits require low noise levels to have deterministic states. These boolean functions we are talking about implementing take two inputs, and return an output. Each of the inputs and outputs are boolean, meaning that they are one of two things - true or false (or 1 or 0). In silicon you have techniques to manufacture a system that has well defined states defined by the amount of electric charge in a certain region - if there is no charge in the region, the state is false, if there is above a certain threshold of charge, the state is true. Ideally you would have the same thresholding system inside a cell, but instead of charge, you would measure molecular concentration. The problem is, molecular concentrations in cells can fluctuate with much more noise that electric charge in silicon circuits. Noise is rampant in cells. The problem is, if you can’t rely on well-defined inputs, you can’t expect deterministic outputs, and your boolean logic functions turn into some probabilistic system. I don’t know, but you might be able to compute with such a system, but you certainly cannot compute with it in the same way as a deterministic silicon system.

2. Digital circuits are insulated from each other. There has been a lot of effort to cram more and more transistors into a smaller and smaller area of silicon. Much of the work to do this requires better insulation techniques so that an input of true on one transistor does not affect the inputs on its neighboring transistor. A central problem in biocomputing is how to insulate biochemical networks from each other. After all, the cell is just a bag of chemicals. I discussed this problem in my previous journal club about Programmable Cells, and mentioned that if you implement a computational unit as a network of a few molecules, you cannot have multiple copies of that unit in a single cell without the units interfering with each other. In other words, you won’t be able to put together multiple AND’s, XOR’s and OR’s together inside a single cell to make something more complicated, at least with the current biotechnology. However, the authors do suggest using multiple cells in a computation, where the cell wall acts as the insulation. This is a neat idea and should be explored more, but it might mean that traditional silicon-based computational architectures might need to be abandoned in biocomputing. Even if you could pack multiple non-interfering circuits in one cell, it is not clear that the cell has enough excess DNA capacity to contain all these circuits.

3. These simple logic operations are not adequate for computations requiring memory, and syncing to a clock. Many computations in silicon processing architectures require retrieving past computations from memory, and pipelining many computations together that are synchronized by a system clock. The authors mention these inadequacies, and cite relevant literature on work towards these goals.

The analogy of cells as computational systems is fantastic. However, we need to start thinking outside of the box, and start to consider general computational paradigms that are more aligned to what the cell actually does. It would be interesting to try to model a complex genetic regulatory network as a serial array of logic gates, just to compare the two. I suspect that the cells way of doing things is much more efficient in terms of the space required to encode it and the time required to execute the logic of the network. We should be looking to the paradigms of cellular computation for inspiration to make a programmable cellular biocomputing architecture.

As always, please add a comment to continue this discussion, or edit the my OpenWetWare notes yourself.

Links

• My OpenWetWare Bibliography
• OpenWetWare Notes on this poper
• OpenWetWare
• This paper on PubMed
• Trends in Biotechnology
• Elsevier
• Field Effect Transistor (Wikipedia)
• Central Processing Unit (Wikipedia)
• Programmable Cells Journal Club

Posted: October 4th, 2007 under Journal Club.
Comments: 2