Team:Berkeley/Project/Construction
From 2012.igem.org
(20 intermediate revisions not shown) | |||
Line 11: | Line 11: | ||
</map> | </map> | ||
</div> | </div> | ||
- | <div class="row-end" ></div> | + | <div class="row-end" > |
+ | </div> | ||
+ | |||
<div class="row"> | <div class="row"> | ||
Line 45: | Line 47: | ||
</div> | </div> | ||
</div> | </div> | ||
+ | |||
<div class="row"> | <div class="row"> | ||
Line 61: | Line 64: | ||
<div class="col1" align="justify"> | <div class="col1" align="justify"> | ||
<p> | <p> | ||
- | We chose to use <a href="http://j5.jbei.org/j5manual/pages/23.html">Golden Gate Assembly</a> because it allowed us to | + | We chose to use <a href="http://j5.jbei.org/j5manual/pages/23.html">Golden Gate Assembly</a> because it allowed us to create libraries of multiple parts in a single cloning step. Golden Gate Assembly is powered by type IIs restriction enzymes, which have many key features that should be mentioned: |
<ol> | <ol> | ||
- | <li> They cut distal to their recognition sites. Because of this, we have full control over the resulting 4bp overhangs, giving us a theoretical choice between 4^4, or 256 different overhangs. In practice, we reduced this set, eliminating cases where | + | <li> They cut distal to their recognition sites. Because of this, we have full control over the resulting 4bp overhangs, giving us a theoretical choice between 4^4, or 256 different overhangs. In practice, we reduced this set, eliminating cases where more than two out of four bases match to minimize chances of mis-annealing. |
- | <li> They not palindromic, and thus have directionality. Because the recognition site is non-palindromic, the cutting can either happen | + | <li> They are not palindromic, and thus have directionality. Because the recognition site is non-palindromic, the cutting can either happen 5' or 3' to the recognition site. This can be modulated by reversing the sequence. |
<li>They can cut themselves out. Depending on the direction of cutting, the site can be cut out of the desired fragment so that it does not undergo digestion after it has been ligated. | <li>They can cut themselves out. Depending on the direction of cutting, the site can be cut out of the desired fragment so that it does not undergo digestion after it has been ligated. | ||
- | |||
</ol> | </ol> | ||
</p> | </p> | ||
+ | <br> | ||
<p align="center"> | <p align="center"> | ||
<img src="https://static.igem.org/mediawiki/2012/7/7b/BsmBI.jpg" width="600" class="addborder"> | <img src="https://static.igem.org/mediawiki/2012/7/7b/BsmBI.jpg" width="600" class="addborder"> | ||
Line 78: | Line 81: | ||
<p> | <p> | ||
- | In classic Golden Gate Assembly, these type IIs enzymes together with T4 DNA Ligase | + | In classic Golden Gate Assembly, these type IIs enzymes, together with T4 DNA Ligase, glue together these overhangs. We began with various part plasmids and a backbone all in a single pot. These ligate together in a single reaction that oscillates between digestion and ligation to move towards a correct product. Because type IIs endonucleases cut distal to their recognition site, once they form a connection with the correct neighbor, the product is fixed because the recognition site no longer exits in the connected result. |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
<br> | <br> | ||
Line 108: | Line 107: | ||
<div class="col1" align="justify"> | <div class="col1" align="justify"> | ||
<p> | <p> | ||
- | In our MiCode Assembly (MCA), we utilized two type IIs enzymes, BsaI and BsmBI. By alternating the usage of these two enzymes in each round of assembly and reintroducing the sites when necessary, we can | + | In our MiCode Assembly (MCA), we utilized two type IIs enzymes, BsaI and BsmBI. By alternating the usage of these two enzymes in each round of assembly and reintroducing the sites when necessary, we can iteratively build up larger constructs. We designed MCA to emphasize interchangeability that allows for iterative set expansion which enables us to efficiently build MiCodes. |
- | + | <br> | |
+ | <br> | ||
<p> | <p> | ||
The basic, fundamental unit of our GGA is the <b>part plasmid</b>, shown below. This is synonymous with the part plasmids kept in the registry, but instead of being flanked with EcoRI, XbaI, SpeI, and PstI, it is flanked by outer BsaI sites. These BsaI sites create unique overhangs when digested, which anneal with other complementary overhangs in a single-pot reaction. Conveniently, BsaI and BsmBI are compatible with T4 DNA Ligase, allowing for the two to be combined in a single pot reaction that cycles between optimal temperatures for digestion (37˚C) and ligation (16˚C). Because correct products are fixed, the system converges towards our final product. We use plasmids because they allow us to easily amplify and sequence the DNA. | The basic, fundamental unit of our GGA is the <b>part plasmid</b>, shown below. This is synonymous with the part plasmids kept in the registry, but instead of being flanked with EcoRI, XbaI, SpeI, and PstI, it is flanked by outer BsaI sites. These BsaI sites create unique overhangs when digested, which anneal with other complementary overhangs in a single-pot reaction. Conveniently, BsaI and BsmBI are compatible with T4 DNA Ligase, allowing for the two to be combined in a single pot reaction that cycles between optimal temperatures for digestion (37˚C) and ligation (16˚C). Because correct products are fixed, the system converges towards our final product. We use plasmids because they allow us to easily amplify and sequence the DNA. | ||
+ | <br> | ||
+ | <br> | ||
+ | |||
<p> | <p> | ||
+ | Each part is flanked by unique overhangs that dictate its potential neighbors, its position in the cassette, and the type of part it is (detailed below). | ||
+ | </p> | ||
- | + | <br> | |
<p align="center"> | <p align="center"> | ||
<img src="https://static.igem.org/mediawiki/2012/f/fa/GGpart.jpg" width="400" class="addborder"> | <img src="https://static.igem.org/mediawiki/2012/f/fa/GGpart.jpg" width="400" class="addborder"> | ||
- | <p align="center">A part plasmid coding for PAmCherry, our photoactivatible red fluorescent protein. | + | <p align="center">A part plasmid coding for PAmCherry, our photoactivatible red fluorescent protein. |
</p> | </p> | ||
<br> | <br> | ||
<p> | <p> | ||
- | Several part plasmids can be joined via their overhangs to produce a <b>cassette</b>. | + | Several part plasmids can be joined via their overhangs to produce a <b>cassette</b>. We break up each cassette into several parts, each which has overhangs unique to that type of part. These overhangs make sure the cassette assembles correctly, with each part being in its correct position. For MCA, we have the backbone with origin and marker, 5' upstream region, promoter, part, terminator, and 3' downstream region. |
- | + | <br> | |
- | + | <br> | |
- | < | + | |
- | <b> | + | <p> |
- | + | For each position in the cassette, there are multiple parts with compatible overhangs (each position has multiplicity), which allows us to easily interchange parts from the library of part plasmids we and the Dueber Lab have made. In this cassette assembly step, all the components of this cassette are <b>physically linked together</b>. The physical linkage retains the data about this unit of the MiCode in such a way that we can utilize it downstream. This allows us to treat the entire cassette as a single unit and enables us to build larger constructs using the cassettes with the confidence that the genotype remains stable. | |
- | + | ||
</p> | </p> | ||
+ | <br> | ||
<p align="center"> | <p align="center"> | ||
<img src="https://static.igem.org/mediawiki/2012/1/11/GGcassette.jpg" width="600" class="addborder"> | <img src="https://static.igem.org/mediawiki/2012/1/11/GGcassette.jpg" width="600" class="addborder"> | ||
- | <p align="center">A cassette coding for nucleus-localized PAmCherry with ConS and Con2 connector regions | + | <p align="center">A cassette coding for nucleus-localized PAmCherry with ConS and Con2 connector regions. |
</p> | </p> | ||
<br> | <br> | ||
<p> | <p> | ||
- | In the next round of assembly, several cassettes | + | In the next round of assembly, we combine several cassettes together to form <b>multigene cassettes</b>. Because the multigene cassettes build off of the cassettes, they retain their information in downstream usage. And because we build each multigene cassette by hand, we know exactly what the genotype and expected phenotype of each multigene cassette is. At each position between connector regions, there are multiple cassettes we can substitute in to create our desired MiCode. This modularity enables us to build a large combinatorial set of MiCodes with only a few cassettes. |
+ | </p> | ||
+ | <br> | ||
+ | <p align="center"> | ||
+ | <img src="https://static.igem.org/mediawiki/2012/9/9c/GGmultigene1.jpg" width="800" class="addborder"> | ||
+ | <p align="center">A multigene cassette coding linking various MiCode components to a <a href="https://2012.igem.org/Team:Berkeley/Project/Zippers"> leucine zipper</a>. This half codes for the bait zipper. | ||
</p> | </p> | ||
<br> | <br> | ||
+ | |||
+ | |||
+ | <br> | ||
+ | <p align="center"> | ||
+ | <img src="https://static.igem.org/mediawiki/2012/8/8f/GGmultigene2.jpg" width="800" class="addborder"> | ||
+ | <p align="center">MiCode components linked to a prey zipper. | ||
+ | </p> | ||
+ | <br> | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | <p> | ||
+ | Up until this point, we have been building one construct per reaction because we wanted to know precisely what we were building. After we build a library of bait and a separate library of prey zippers by hand, we can combine the two together in a large single-pot reaction. Because we designed the bait half-MiCode to only be compatible with the prey half-MiCode, we can ensure that the assembly links exactly one prey to one bait. Additionally, because all components on each half-code were physically linked on the plasmid in the previous round of cloning, we can link the phenotype expressed by the fluorescence to the leucine zipper. | ||
+ | </p> | ||
+ | |||
+ | |||
+ | <br> | ||
+ | <p align="center"> | ||
+ | <img src="https://static.igem.org/mediawiki/2012/b/b1/Full_MiCode.jpg" width="980" class="addborder"> | ||
+ | <p align="center">The full MiCode assembly, done in a single-pot reaction to combine the 40 bait and 40 prey zippers into a 1,600 member library. | ||
+ | </p> | ||
</div> | </div> | ||
</div> | </div> | ||
Line 148: | Line 180: | ||
+ | <div class="row-end"></div> | ||
+ | <div class="row"> | ||
+ | <div class="col12" id="spacer3"></div> | ||
+ | <div class="row-end"></div> | ||
+ | </div> | ||
+ | <br> | ||
+ | <br> | ||
+ | <br> | ||
+ | <br> | ||
+ | |||
+ | <hr align="center"> | ||
+ | |||
+ | <div class="row"> | ||
+ | <div class="col12" id="spacer"></div> | ||
+ | <div class="col3-2"> | ||
+ | <a href="https://2012.igem.org/Team:Berkeley/Project/Localization"> | ||
+ | <img src="https://static.igem.org/mediawiki/2012/e/e6/Project_nav1.jpg" | ||
+ | onmouseover="this.src='https://static.igem.org/mediawiki/2012/2/22/Project_nav1_hover.jpg'" | ||
+ | onmouseout="this.src='https://static.igem.org/mediawiki/2012/e/e6/Project_nav1.jpg'" width="230"></a> | ||
+ | </div> | ||
+ | |||
+ | <div class="col3-2"> | ||
+ | <a href="https://2012.igem.org/Team:Berkeley/Project/Construction"> | ||
+ | <img src="https://static.igem.org/mediawiki/2012/4/4d/Project_nav2.jpg" | ||
+ | onmouseover="this.src='https://static.igem.org/mediawiki/2012/b/b8/Project_nav2_hover.jpg'" | ||
+ | onmouseout="this.src='https://static.igem.org/mediawiki/2012/4/4d/Project_nav2.jpg'" width="230"> </a> | ||
+ | </div> | ||
+ | |||
+ | <div class="col3-2"> | ||
+ | <a href="https://2012.igem.org/Team:Berkeley/Project/Automation"> | ||
+ | <img src="https://static.igem.org/mediawiki/2012/0/0b/Project_nav3.jpg" | ||
+ | onmouseover="this.src='https://static.igem.org/mediawiki/2012/4/48/Project_nav3_hover.jpg'" | ||
+ | onmouseout="this.src='https://static.igem.org/mediawiki/2012/0/0b/Project_nav3.jpg'" width="230"></a> | ||
+ | </div> | ||
+ | |||
+ | <div class="col3-2"> | ||
+ | <a href="https://2012.igem.org/Team:Berkeley/Project/Zippers"> | ||
+ | <img src="https://static.igem.org/mediawiki/2012/e/eb/Project_nav4.jpg" | ||
+ | onmouseover="this.src='https://static.igem.org/mediawiki/2012/7/70/Project_nav4_hover.jpg'" | ||
+ | onmouseout="this.src='https://static.igem.org/mediawiki/2012/e/eb/Project_nav4.jpg'" width="230"></a> | ||
+ | </div> | ||
+ | <div class ="row-end"> | ||
+ | </div> | ||
+ | </div> | ||
+ | |||
+ | |||
+ | </body> | ||
</html> | </html> |
Latest revision as of 03:39, 16 October 2012
We chose to use Golden Gate Assembly because it allowed us to create libraries of multiple parts in a single cloning step. Golden Gate Assembly is powered by type IIs restriction enzymes, which have many key features that should be mentioned:
- They cut distal to their recognition sites. Because of this, we have full control over the resulting 4bp overhangs, giving us a theoretical choice between 4^4, or 256 different overhangs. In practice, we reduced this set, eliminating cases where more than two out of four bases match to minimize chances of mis-annealing.
- They are not palindromic, and thus have directionality. Because the recognition site is non-palindromic, the cutting can either happen 5' or 3' to the recognition site. This can be modulated by reversing the sequence.
- They can cut themselves out. Depending on the direction of cutting, the site can be cut out of the desired fragment so that it does not undergo digestion after it has been ligated.
An example type IIs restriction enzyme, BsmBI. In this diagram, a GACC overhang is created.
In classic Golden Gate Assembly, these type IIs enzymes, together with T4 DNA Ligase, glue together these overhangs. We began with various part plasmids and a backbone all in a single pot. These ligate together in a single reaction that oscillates between digestion and ligation to move towards a correct product. Because type IIs endonucleases cut distal to their recognition site, once they form a connection with the correct neighbor, the product is fixed because the recognition site no longer exits in the connected result.
In our MiCode Assembly (MCA), we utilized two type IIs enzymes, BsaI and BsmBI. By alternating the usage of these two enzymes in each round of assembly and reintroducing the sites when necessary, we can iteratively build up larger constructs. We designed MCA to emphasize interchangeability that allows for iterative set expansion which enables us to efficiently build MiCodes.
The basic, fundamental unit of our GGA is the part plasmid, shown below. This is synonymous with the part plasmids kept in the registry, but instead of being flanked with EcoRI, XbaI, SpeI, and PstI, it is flanked by outer BsaI sites. These BsaI sites create unique overhangs when digested, which anneal with other complementary overhangs in a single-pot reaction. Conveniently, BsaI and BsmBI are compatible with T4 DNA Ligase, allowing for the two to be combined in a single pot reaction that cycles between optimal temperatures for digestion (37˚C) and ligation (16˚C). Because correct products are fixed, the system converges towards our final product. We use plasmids because they allow us to easily amplify and sequence the DNA.
Each part is flanked by unique overhangs that dictate its potential neighbors, its position in the cassette, and the type of part it is (detailed below).
A part plasmid coding for PAmCherry, our photoactivatible red fluorescent protein.
Several part plasmids can be joined via their overhangs to produce a cassette. We break up each cassette into several parts, each which has overhangs unique to that type of part. These overhangs make sure the cassette assembles correctly, with each part being in its correct position. For MCA, we have the backbone with origin and marker, 5' upstream region, promoter, part, terminator, and 3' downstream region.
For each position in the cassette, there are multiple parts with compatible overhangs (each position has multiplicity), which allows us to easily interchange parts from the library of part plasmids we and the Dueber Lab have made. In this cassette assembly step, all the components of this cassette are physically linked together. The physical linkage retains the data about this unit of the MiCode in such a way that we can utilize it downstream. This allows us to treat the entire cassette as a single unit and enables us to build larger constructs using the cassettes with the confidence that the genotype remains stable.
A cassette coding for nucleus-localized PAmCherry with ConS and Con2 connector regions.
In the next round of assembly, we combine several cassettes together to form multigene cassettes. Because the multigene cassettes build off of the cassettes, they retain their information in downstream usage. And because we build each multigene cassette by hand, we know exactly what the genotype and expected phenotype of each multigene cassette is. At each position between connector regions, there are multiple cassettes we can substitute in to create our desired MiCode. This modularity enables us to build a large combinatorial set of MiCodes with only a few cassettes.
A multigene cassette coding linking various MiCode components to a leucine zipper. This half codes for the bait zipper.
MiCode components linked to a prey zipper.
Up until this point, we have been building one construct per reaction because we wanted to know precisely what we were building. After we build a library of bait and a separate library of prey zippers by hand, we can combine the two together in a large single-pot reaction. Because we designed the bait half-MiCode to only be compatible with the prey half-MiCode, we can ensure that the assembly links exactly one prey to one bait. Additionally, because all components on each half-code were physically linked on the plasmid in the previous round of cloning, we can link the phenotype expressed by the fluorescence to the leucine zipper.
The full MiCode assembly, done in a single-pot reaction to combine the 40 bait and 40 prey zippers into a 1,600 member library.