Team:Purdue/Project/Background

From 2013.igem.org

Revision as of 02:42, 22 September 2013 by CThompson (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


PurdueLogo2013.png

Background

The Basics

Robustness Design

One of the overwhelming problems that synthetic biologists face on a daily basis is the variability in genetic constructs. With our ever persistent drive to find a way to develop a standard set of parts for synthetic biology, it is often overlooked that these “standard” parts do not interact the same way that a nut and a bolt do. Sure the threads of each must match for compatibility, but you are guaranteed that a matching set of nuts and bolts will hold together a table just as well as they will hold together a chair, or a piece of metal machinery, or the engine of your car.

When we place together a promoter with a new gene of interest we do not yet have these compatibility rules to know how a promoter will work with this gene of interest. We, as synthetic biologists, still don’t know that one promoter/gene will work the same way in one strain of E. coli as they will in another E. coli. For synthetic biology to truly emerge as a field that can capitalize in industry, we must find novel ways of engineering biological systems reliably using our own standard parts.

Standardized Datasheets

As everyone in iGEM already knows, using the Registry of Standardized Parts can be a very frustrating endeavor. Searching through the registry with ease takes practice, and even then it can be difficult to find good parts to use. Many of the parts in the registry have little to no characterization data present on their registry pages. And some parts in the registry have been very well characterized, but all with different assays and techniques. So it can be very difficult to compare multiple parts that have good data because the data is so different.


After weeks of traversing the registry and igem.org, we finally came to the conclusion that the main, underlying issue is that there is currently no standard for characterization data in the registry. Teams have no definitive guideline to follow to characterize their parts.

So to solve this problem, we had to figure out where to start. As a group we discussed some of the protocols iGEM teams had tried to write over the years, and how most of them never went past the team that created it. We were also having trouble deciding how to design a system that every iGEM team would hopefully use. We realized that the best way to design a system that everyone would use and also find a way to keep the idea alive after this year was to talk to as many iGEM teams as possible and get their help and input.