Team:Wisconsin-Madison/humanpractice

From 2011.igem.org

(Difference between revisions)
 
(24 intermediate revisions not shown)
Line 157: Line 157:
<a href="https://2011.igem.org/Team:Wisconsin-Madison">Main</a>
<a href="https://2011.igem.org/Team:Wisconsin-Madison">Main</a>
<a href="https://2011.igem.org/Team:Wisconsin-Madison/whatisigem">What is iGEM?</a>
<a href="https://2011.igem.org/Team:Wisconsin-Madison/whatisigem">What is iGEM?</a>
 +
<a href="https://2011.igem.org/Team:Wisconsin-Madison/ca">Contributions & Attributions</a>
</div>
</div>
</li>
</li>
Line 180: Line 181:
<div id="m4" onmouseover="mcancelclosetime()" onmouseout="mclosetime()">
<div id="m4" onmouseover="mcancelclosetime()" onmouseout="mclosetime()">
<a href="https://2011.igem.org/Team:Wisconsin-Madison/protocols">Protocols</a>
<a href="https://2011.igem.org/Team:Wisconsin-Madison/protocols">Protocols</a>
-
<a href="https://2011.igem.org/Team:Wisconsin-Madison/calender">Calender</a>
+
<a href="https://2011.igem.org/Team:Wisconsin-Madison/calender">Calendar</a>
<a href="https://2011.igem.org/Team:Wisconsin-Madison/references">References</a>
<a href="https://2011.igem.org/Team:Wisconsin-Madison/references">References</a>
</div>
</div>
Line 198: Line 199:
</ul>
</ul>
</center>
</center>
-
 
+
<center>
<center>
Line 219: Line 220:
This year, the UW-Madison iGEM team has strived to produce a modular directed evolution system for one- and two-component sensor systems. While the goal of improving biosensors to optimize the biofuel discovery process has motivated our work, our methods have led us to some more fundamental questions. These all stem from the following: when a BioBrick undergoes directed evolution, what functions can the source, the intermediates, and the end product serve in the registry? <p>
This year, the UW-Madison iGEM team has strived to produce a modular directed evolution system for one- and two-component sensor systems. While the goal of improving biosensors to optimize the biofuel discovery process has motivated our work, our methods have led us to some more fundamental questions. These all stem from the following: when a BioBrick undergoes directed evolution, what functions can the source, the intermediates, and the end product serve in the registry? <p>
-
Upon consideration, we saw two ways the current registry could support this sort of small-scale tinkering. The new product could either be listed as a new part or be an informational addition to the source part. While creating new parts for each mutant with a desired phenotype would fit the current one-part-one-genotype dogma of the registry, it would also produce a litany of similar parts. By adding knowledge about the phenotypes conferred by small mutations to the page itself, we would be able to see a part and the effects of mutations upon it on a single page. However, pages could become unwieldy if multiple mutageneses were performed upon the same target part or device and the mutants would not be readily available for interested teams to test. In the interest of providing users with an easy to use system for understanding, referring to, and using members of BioBrick mutant libraries, we propose a new registry feature: mutant families. <p>
+
Upon consideration, we saw two ways the current registry could support this sort of small-scale tinkering. The new product could either be listed as a new part or be an informational addition to the source part. While creating new parts for each mutant with a desired phenotype would fit the current one-part-one-genotype dogma of the registry, it would also produce a litany of similar parts. By adding knowledge about the phenotypes conferred by small mutations to the page itself, we would be able to see a part and the effects of mutations upon it on a single page. However, pages could become unwieldy if multiple mutageneses were performed upon the same target part or device and the mutants would not be readily available for interested teams to test. In the interest of providing users with an easy to use system for understanding, referring to, and using members of BioBrick mutant libraries, we propose a new registry feature: mutant families.
 +
<p><br>
-
The central premise of mutant families is the creation of mutant libraries containing “children” mutants of a desired phenotype from “parent” BioBrick parts. By introducing the possibility of a new section on parts pages for mutated derivatives, iGEM teams could more easily access interesting intermediates or libraries shared by other teams. The format is perhaps easiest to imagine as a tree. Through this visual analogy, users can see the extent by which a phenotypically interesting child is mutated from its BioBrick parent. By submitting mutants as children under a parent part, a single page could display the extent of a mutation as well as identify and provide individuals with interesting phenotypes. The comparison of mutant families to existing options is further laid out in the design matrix below. <p>
+
The central premise of mutant families is the creation of mutant libraries containing “children” mutants of a desired phenotype from “parent” BioBrick parts. By introducing the possibility of a new section on parts pages for mutated derivatives, iGEM teams could more easily access interesting intermediates or libraries shared by other teams. The format is perhaps easiest to imagine as a tree. Through this visual analogy, users can see the extent by which a phenotypically interesting child is mutated from its BioBrick parent. By submitting mutants as children under a parent part, a single page could display the extent of a mutation as well as identify and provide individuals with interesting phenotypes. The comparison of mutant families to existing options is further laid out in the design matrix below. <p><p>
<center>
<center>
Line 227: Line 229:
<p>
<p>
 +
To better understand how mutant families would affect how users access the registry, we made a series of mock-ups of how we pictured mutant families could be implemented.
 +
<p>
 +
A separate tab could appear for parts which contained mutant children parts: <br>
 +
<img src="http://i53.tinypic.com/2ldjegx.jpg" align="right" style="border:1px solid black;">
 +
<p>
 +
&nbsp;
 +
<p>
 +
Upon hovering over the link, users could see the available actions for that mutant family, and either access mutants or contribute newly created ones: <br>
 +
<img src="http://i56.tinypic.com/2ninmo8.jpg" align="right" style="border:1px solid black;">
 +
<p>
 +
&nbsp;
 +
<p>
 +
Clicking through to view the library, users would see phenotypically interesting mutants from the first generation of mutagenesis. <br>
 +
<img src="http://i52.tinypic.com/24bvt6a.jpg" align="right" style="border:1px solid black;">
 +
<p>
 +
&nbsp;
 +
<p>
 +
Information would be provided for users about each mutant, such as mutation parameters and phenotypic characteristics. Each of these mutant child parts could then be moused over to show available related parts in the family: <br>
 +
<img src="http://i51.tinypic.com/2pyvvpf.jpg" align="right" style="border:1px solid black;">
 +
<p>
 +
&nbsp;
 +
<p>
 +
Clicking through, users could access individual pages for each notable mutant child. Each such child would get its own sub-page to the parent (see arrow in previous image), allowing for information to be consolidated without the parent part page becoming bogged down with too much data. We feel that this system is intuitive, implementable, and would greatly increase the parts registry experience for future teams either working with existing mutant libraries of BioBricks or creating their own.
 +
<img src="http://i54.tinypic.com/2e0pme0.jpg" align="right" style="border:1px solid black;">
 +
 +
<p>&nbsp;
 +
<p>
We believe that mutagenesis is a powerful tool for directed evolution, characterization, and fine-tuning of parts and devices in the registry. We hope that establishing mutant families as part of the registry will encourage further use and discussions of rationally mutated gene products, and most importantly it will improve the user experience for teams working with mutant libraries. Inevitably questions will arise about guidelines for when highly-mutated children will become new parts of their own; we don’t have a concrete answer for this and think it is an important conversation to have. The topic is particularly interesting when applied to intellectual property in synthetic biology. Can a parent protein be mutagenized to the point it is no longer legally protected? Can a mutated protein be patented, and the ownership not extend to the immediate precursor to it? These questions underline the difficulty in applying firm laws to the dynamic field of synthetic biology, and we look forward to their discussion. <p>
We believe that mutagenesis is a powerful tool for directed evolution, characterization, and fine-tuning of parts and devices in the registry. We hope that establishing mutant families as part of the registry will encourage further use and discussions of rationally mutated gene products, and most importantly it will improve the user experience for teams working with mutant libraries. Inevitably questions will arise about guidelines for when highly-mutated children will become new parts of their own; we don’t have a concrete answer for this and think it is an important conversation to have. The topic is particularly interesting when applied to intellectual property in synthetic biology. Can a parent protein be mutagenized to the point it is no longer legally protected? Can a mutated protein be patented, and the ownership not extend to the immediate precursor to it? These questions underline the difficulty in applying firm laws to the dynamic field of synthetic biology, and we look forward to their discussion. <p>

Latest revision as of 03:54, 29 September 2011









Mutants and Registry Users: A Happy Family

This year, the UW-Madison iGEM team has strived to produce a modular directed evolution system for one- and two-component sensor systems. While the goal of improving biosensors to optimize the biofuel discovery process has motivated our work, our methods have led us to some more fundamental questions. These all stem from the following: when a BioBrick undergoes directed evolution, what functions can the source, the intermediates, and the end product serve in the registry?

Upon consideration, we saw two ways the current registry could support this sort of small-scale tinkering. The new product could either be listed as a new part or be an informational addition to the source part. While creating new parts for each mutant with a desired phenotype would fit the current one-part-one-genotype dogma of the registry, it would also produce a litany of similar parts. By adding knowledge about the phenotypes conferred by small mutations to the page itself, we would be able to see a part and the effects of mutations upon it on a single page. However, pages could become unwieldy if multiple mutageneses were performed upon the same target part or device and the mutants would not be readily available for interested teams to test. In the interest of providing users with an easy to use system for understanding, referring to, and using members of BioBrick mutant libraries, we propose a new registry feature: mutant families.


The central premise of mutant families is the creation of mutant libraries containing “children” mutants of a desired phenotype from “parent” BioBrick parts. By introducing the possibility of a new section on parts pages for mutated derivatives, iGEM teams could more easily access interesting intermediates or libraries shared by other teams. The format is perhaps easiest to imagine as a tree. Through this visual analogy, users can see the extent by which a phenotypically interesting child is mutated from its BioBrick parent. By submitting mutants as children under a parent part, a single page could display the extent of a mutation as well as identify and provide individuals with interesting phenotypes. The comparison of mutant families to existing options is further laid out in the design matrix below.

To better understand how mutant families would affect how users access the registry, we made a series of mock-ups of how we pictured mutant families could be implemented.

A separate tab could appear for parts which contained mutant children parts:

 

Upon hovering over the link, users could see the available actions for that mutant family, and either access mutants or contribute newly created ones:

 

Clicking through to view the library, users would see phenotypically interesting mutants from the first generation of mutagenesis.

 

Information would be provided for users about each mutant, such as mutation parameters and phenotypic characteristics. Each of these mutant child parts could then be moused over to show available related parts in the family:

 

Clicking through, users could access individual pages for each notable mutant child. Each such child would get its own sub-page to the parent (see arrow in previous image), allowing for information to be consolidated without the parent part page becoming bogged down with too much data. We feel that this system is intuitive, implementable, and would greatly increase the parts registry experience for future teams either working with existing mutant libraries of BioBricks or creating their own.

 

We believe that mutagenesis is a powerful tool for directed evolution, characterization, and fine-tuning of parts and devices in the registry. We hope that establishing mutant families as part of the registry will encourage further use and discussions of rationally mutated gene products, and most importantly it will improve the user experience for teams working with mutant libraries. Inevitably questions will arise about guidelines for when highly-mutated children will become new parts of their own; we don’t have a concrete answer for this and think it is an important conversation to have. The topic is particularly interesting when applied to intellectual property in synthetic biology. Can a parent protein be mutagenized to the point it is no longer legally protected? Can a mutated protein be patented, and the ownership not extend to the immediate precursor to it? These questions underline the difficulty in applying firm laws to the dynamic field of synthetic biology, and we look forward to their discussion.