Team:Purdue/Project/Background

From 2013.igem.org

Revision as of 18:59, 21 September 2013 by CThompson (Talk | contribs)


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 our first thought was to actually create this characterization standard. Meaning we would write a series of recommended protocols and steps for teams to fully characterize a part. We thought the best way to start would be to talk to as many other iGEM teams as possible to get a good grasp on what teams are looking for