When I initially saw The MIT Registry of Standard Biological Parts, I just fell in love with the idea. However, after closer inspection I realized that it’s not what I hoped to find. The Registry collects an interchangeable functional modules that can be assembled into novel biological systems. And it does it as good as it sounds, but to a certain extent. Pedro wrote some time ago about unavoidable complexity and potential issues with collected parts. I completely agree with his arguments but I have even more doubts about the Registry’s current approach.
First of all, my feeling is that DNA-centric view of life starts to limit us in understanding what is happening at a molecular level. It moved forward science a lot and it is still extremely useful, but with genetics we are not going to understand and avoid emergent properties of biological systems. DNA, RNA, proteins at a sequence and structure level are all interacting with each other. This properties are encoded in DNA, I agree. However, as Pedro pointed out, we have no way to predict what happens after transferring a part to other organism. It is possible to select for mutations that will render this part usable in the other organism, but I don’t think this approach would be of much use if we deal with organisms that are hard to grow (imagine you want to insert a specific system into extremophile organism). And what is more, it’s not necessarily practical if we transfer the part to an organism which already has a similar element encoded in the genome.
In my humble opinion, the Registry can be extended in two directions, transforming parts into a containers that have a specific functional role and include sub-gene elements, like domains or tectons. Let me describe both in more detail.
Currently a BioBrick is assigned a function and a sequence. I would rather see a functional role, that can be fulfilled by many different sequences. For example, if we have an enzymatic function the BioBrick would include not only single DNA sequence from a single organism, but also a protein sequence, domains, sequence motifs and a structure (whatever is available), and all these should be available for all organisms for which we can assign reliably this information. To clarify, I’m far from populating the Registry with BLAST results. I would rather have it done manually, or at least in the way The SEED allows experts to create subsystems and assign a functional roles to proteins. In this way we could just take a gene from a target organism instead of mutating the original one. Having a container would mean that we could include there different flavors of the same gene (for example, after optimization).
For the second thing, I’m a big fan of creating novel functions out of existing elements. That’s a reason why I believe the Registry should include building blocks of proteins as well as other fancy things, like riboswitches. One of the obvious example would be a signal transduction element, where one can attach different receptor domains to the same membrane component. This has been done already thousands of times – why not to standardize it?
Maybe with these two changes maybe we could finally connects some dots and make a complexity of biological systems more understandable or at least traceable. Future directions of the Registry are not very well defined, so I believe there’s a space for at least discussion about such ideas.
Freelancing science 
Bryan Bishop
April 5, 2008 at 02:14
In a sense, this is what we are doing when we are making transcriptional switches and DNA/RNA logic circuits in vitro in synthetic biology; what you have to do is make sure that the various biomolecules (ribo/deoxyribo) only hybridize where you want them to, where you want their sequences to match up, what to match/not-match, and basically it all looks like a nasty regular expression from a late night of perl programming. Then, you use Seeman code and other stuff relating to nucleic acid physics (or just the RNAinverse server from Vienna) to come up with the complementary strands and to make sure you don’t accidentally step on your own toe, which is ironic since we call them toeholds anyway. This sounds close to what you are suggesting: instead of specifying one and only one sequence, write a program that can work within a certain domain and generate alternatives that still match the functional specifications, as wrestled from experimentation, computational simulations via molecular dynamics and DNA physics, or from the literature as the case may be. A few friends and I have started a database for this in general for any sort of project, trying to mimic the success of apt and CPAN over here (in the context of a material science project to make a kinematic self-replicating machine, but this is another subject for another time).
– Bryan
Pawel Szczesny
April 5, 2008 at 19:47
Bryan, if I understood you correctly, your idea for a biobricks is to have a set of sequences, that fullfil a certain functional role, and while this is what I mean here, it’s only part of the story. Between a function of some gene, and its DNA sequence there’s a whole spectrum of information defining interactions of all its levels (DNA/RNA/protein sequence and structure) with other elements at all their levels. This information should be for example semantically included in the definition of a biobrick, so it is more like multiinput/multioutput device, instead of single input/ouput one. Without addressing in some way the complexity of these elements, we are unlikely to scale up (which mean we wouldn’t even enter the roadmap you have written).
Raik
April 6, 2008 at 19:35
On a first glance, the MIT Registry may seem to only contain “transcription logic” parts but there is, actually, also an increasing number of protein (domain) Biobricks. Your plug ‘n play receptor idea,for example, was already put into practice by the 2007 iGem team from Slovenia: See BBa_I712006!
Two more teams were working with protein parts during the 2007 iGem. Check out the projects from Freiburg and UCSF! BTW, out of those only 3 protein teams, 2 made it to the final. So working with proteins is a clear winning strategy. Ah, and there are also 2 Riboswitch Biobricks on their way to the registry: e.g. BBa_I752000
You have a good point that we ultimately want to get away from the strict DNA-centric view and this discussion is already in full swing. On the other hand, we absolutely need to have a single exact sequence for each actual Biobrick. We couldn’t do any reproducible engineering otherwise. The more abstract information you are describing could then be layered on top of this basic Biobrick description.
Pawel Szczesny
April 6, 2008 at 20:09
Thanks Raik, but obviously my limited English skills made this post not so easy to understand. I don’t recomment just working with proteins. I have seen many protein parts in the Registry and all of them, inluding BBa_I712006, share the same feature – in practice, they are nothing else than pieces of DNA. There’s no protein sequence, no functional annotation, no domain breakdown. And to be clear, I don’t propose to overlay this DNA sequence with all this information – I want to put this piece into a container that has a function written over it. Such sequence should have all its protein-derived information attached to it, but should be identified by its functional role, not some out-of-nowhere DNA. In this way we can have more than one sequence fullfiling this role – and we should. In the current version of the Registry, two enzymes performing exactly the same function but one normal and one thermostable will be two independent biobricks, with no data shared between. For me it doesn’t make sense, as they differ only in stability and sequence – the rest is essentially identical. Both have defined sequence and defined outcome. Why to completely separate them?
Plug ‘n play receptor concept as you call it is again the same story – instead of having bunch of different biobricks that differ lets say by receptor domain, I want to have buckets with receptor domains, membrane parts, and reporting domains and ability to mix them in novel ways. These combinations if done, should be reported if they work – that’s clear. But we don’t gain any knowledge if signal transduction component is in the same container with GFP based reporter device.