"
Team:Berkeley Software/Misc
From 2009.igem.org
(Difference between revisions)
(→Collaboration) |
(→Support for New Technical Standard) |
||
| (29 intermediate revisions not shown) | |||
| Line 5: | Line 5: | ||
__TOC__ | __TOC__ | ||
| - | This page covers a number of different topics which did not fit nicely within any of the other pages in this wiki. Here we provide a draft specification/roadmap for the next version of many of the projects here (who knows these could be a part of iGEM 2010). In addition we discuss our collaborations, efforts in standardization, | + | This page covers a number of different topics which did not fit nicely within any of the other pages in this wiki. Here we provide a draft specification/roadmap for the next version of many of the projects here (who knows these could be a part of iGEM 2010). In addition we discuss our collaborations, efforts in standardization, how our project relates to human practices, issues related to safety, and related links. |
== Draft Specification == | == Draft Specification == | ||
| Line 13: | Line 13: | ||
# Add a way to express the relationship of parts in a device to resulting transcripts - December 2009 | # Add a way to express the relationship of parts in a device to resulting transcripts - December 2009 | ||
#* Currently there is no clean way to say which parts are associated to a particular transcript after transcription. It would be ideal to have a way to do this so that rules can be applied on a transcript based level. Often interactions are on a per transcript basis. | #* Currently there is no clean way to say which parts are associated to a particular transcript after transcription. It would be ideal to have a way to do this so that rules can be applied on a transcript based level. Often interactions are on a per transcript basis. | ||
| - | # Add support for rules over part definitions (i.e. not just part instances) - December 2009 | + | # Add support for rules defined over part definitions (i.e. not just part instances) - December 2009 |
#* Current rules are constructed as such: ''Rule r1(partInstance1 WITH partInstance2)''. It would be very powerful if we could state: ''Rule r1(partDef1 WITH partDef2)''. This would remove a lot of repetition in rule creation when one wants to state something abstract regarding a whole set of parts. | #* Current rules are constructed as such: ''Rule r1(partInstance1 WITH partInstance2)''. It would be very powerful if we could state: ''Rule r1(partDef1 WITH partDef2)''. This would remove a lot of repetition in rule creation when one wants to state something abstract regarding a whole set of parts. | ||
# More completely support [http://openwetware.org/wiki/Endy:Notebook/Synthetic_Biology_Data_Transfer_Process SB/DTP (Synthetic Biology Data Transfer Process)] with XML export and import - Spring 2010 | # More completely support [http://openwetware.org/wiki/Endy:Notebook/Synthetic_Biology_Data_Transfer_Process SB/DTP (Synthetic Biology Data Transfer Process)] with XML export and import - Spring 2010 | ||
| Line 21: | Line 21: | ||
===Spectacles=== | ===Spectacles=== | ||
| - | # More advanced testing which is more integrated with the completion of | + | # More advanced testing which is more integrated with the completion of entire design flows - December 2009 |
| - | #* Spectacles | + | #* Spectacles currently exports device information to the [https://2008.igem.org/Team:UC_Berkeley_Tools/Project#Algorithm_Manager ''algorithm manager''] and the [https://2008.igem.org/Team:UC_Berkeley_Tools/Project#Sequence_View ''sequence view'']. It would be nice to more closely couple this with other tools such as the [https://2008.igem.org/Team:UC_Berkeley_Tools/Project#Parts_Manager ''parts manager'']. This would make complete design flows much more easy to create. |
# Expansion of visual cues - December 2009 | # Expansion of visual cues - December 2009 | ||
| - | #* The current Spectacles tool offers visual cues related to the status of abstract functional parts | + | #* The current Spectacles tool offers visual cues related to the status of abstract functional parts assigned to physical data as well as a part's adherence to rules. The visual cue system should be expanded and made more user flexible. |
| - | # More advanced database support | + | # More advanced database support for the assignment of physical parts - December 2009 |
| - | #* Now the user can specify what criteria they wish to use to search for parts in the database. For example one can search for all parts which say "promoter" as part of the short description or those which contain "bba" in the name. However, this system can be expanded to offer more robust search capabilities as well as more insight into the repository where the parts are located. | + | #* Now the user can specify what criteria they wish to use to search for parts in the database. For example one can search for all parts which say "promoter" as part of the "short description" or those which contain "bba" in the "name". However, this system can be expanded to offer more robust search capabilities as well as more insight into the repository where the parts are located. |
# Visual rule enforcement - Spring 2010 | # Visual rule enforcement - Spring 2010 | ||
#*Support should be added which visually enforces the rules specified by Eugene in Spectacles. This can restrict the movement of icons, the editing or property information, or the visual cues present. | #*Support should be added which visually enforces the rules specified by Eugene in Spectacles. This can restrict the movement of icons, the editing or property information, or the visual cues present. | ||
| Line 38: | Line 38: | ||
#* JBEI's parts registry is now available as web service. We should work with this registry as it is a major source of data and users. It is also a way for us to work with the larger standards community. | #* JBEI's parts registry is now available as web service. We should work with this registry as it is a major source of data and users. It is also a way for us to work with the larger standards community. | ||
# Complete the SPAM tool's oligo coverage designer and golden gate part packager - December 2009 | # Complete the SPAM tool's oligo coverage designer and golden gate part packager - December 2009 | ||
| - | #* Currently the SPAM tool is under development. There are two major pieces currently. The first is a oligo designer for sequencing which produces oligos for a sequence trading off the number of oligos produced with the confidence in the sequencing result. The second produces oligos to create parts using an alternate assembly method known as ''Golden Gate''. This work is being done with the Joint BioEnergy Institute. | + | #* Currently the SPAM tool is under development. There are two major pieces currently. The first is a oligo designer for sequencing which produces oligos for a sequence trading off the number of oligos produced with the confidence in the sequencing result. The second produces oligos to create parts using an alternate assembly method known as [http://www.plosone.org/article/info:doi%2F10.1371%2Fjournal.pone.0005553 ''Golden Gate'']. This work is being done with the [http://www.jbei.org Joint BioEnergy Institute]. |
| - | # Test data model with Davidson University's GCATalog based registry - Spring 2010 | + | # Test data model with Davidson University's [http://gcat.davidson.edu/GCATalog-r2.1/GCATalog.htm GCATalog based registry] - Spring 2010 |
#* We would like to get Clotho to work fully with other University registries. Davidson's GCATalog is one candidate and we have made contact with them to get this process started. | #* We would like to get Clotho to work fully with other University registries. Davidson's GCATalog is one candidate and we have made contact with them to get this process started. | ||
== Collaboration == | == Collaboration == | ||
| - | [[Image:BerkeleyWetTeam.png| | + | [[Image:BerkeleyWetTeam.png|150px|left|thumb|<span style="font-family: Georgia, serif;">UC Berkeley iGEM 2009 Wet Team</span>]] |
| + | [[Image:Stanford.png|150px|left|thumb|<span style="font-family: Georgia, serif;">Stanford iGEM 2009 Wet Team</span>]] | ||
| + | [[Image:synbioss.png|150px|left|thumb|<span style="font-family: Georgia, serif;">University of Minnesota's SynBioSS</span>]] | ||
| + | [[Image:jbei.png|150px|left|thumb|<span style="font-family: Georgia, serif;">Joint BioEnergy Institute</span>]] | ||
| + | [[Image:ValenciaMedal.png|150px|left|thumb|<span style="font-family: Georgia, serif;">Valencia Survey Participation Gold Medal</span>]] | ||
| + | |||
| + | <br clear="all"> | ||
For all of our projects, we worked with a number of different groups both to make our tools more visible, as well as get valuable feedback. This section discusses some of these collaborations. | For all of our projects, we worked with a number of different groups both to make our tools more visible, as well as get valuable feedback. This section discusses some of these collaborations. | ||
| - | [https://2009.igem.org/Team:Berkeley_Wetlab UC Berkeley iGEM team] - we worked very closely with our wet team counterparts to tie our Kepler based assembly workflows with the [http://www.beckman.com/products/instrument/automatedsolutions/Biomek/Biomek3000_inst_dcr.asp Beckman Coulter BioMek 3000 liquid handling robot] that they used heavily in their work. In addition we beta tested our software with them, incorporated their feedback, and ran tutorial sessions on Clotho use and how to write Clotho plug-ins. | + | *[https://2009.igem.org/Team:Berkeley_Wetlab UC Berkeley iGEM team] - we worked very closely with our wet team counterparts to tie our Kepler based assembly workflows with the [http://www.beckman.com/products/instrument/automatedsolutions/Biomek/Biomek3000_inst_dcr.asp Beckman Coulter BioMek 3000 liquid handling robot] that they used heavily in their work. In addition we beta tested our software with them, incorporated their feedback, and ran tutorial sessions on Clotho use and how to write Clotho plug-ins. |
| - | [ | + | *[https://2009.igem.org/Team:Stanford Stanford iGEM team] - we provided early versions of Spectacles to the Stanford iGEM team so that they could test it out. In addition we worked with them to incorporate new iconography as they added it to the [http://openwetware.org/wiki/Endy:Notebook/Synthetic_Biology_Open_Language SBOL Visual effort]. |
| - | [https://2009.igem.org/Team: | + | *[https://2009.igem.org/Team:Minnesota University of Minnesota] - Emma Weeding worked with us both in the development of Eugene as well as making sure the XML it exported worked with [https://2009.igem.org/Team:Minnesota/Designer SynBioSS]. |
| - | [ | + | *[http://www.jbei.org Joint BioEnergy Institute (JBEI)] - we worked with Nathan Hillson, Will Holtz, and Tim Ham at the Joint BioEnergy Institute on our SPAM tool as well as discussing ways in which design flows for synthetic biological devices should be constructed. |
| - | + | *[https://2009.igem.org/Team:Valencia Valencia iGEM Team] - In addition to many other iGEM teams, we filled out their survey and received a gold medal (100% team participation). | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | [https://2009.igem.org/Team:Valencia Valencia iGEM Team] - In addition to many other iGEM teams, we filled out their survey and received a gold medal (100% team participation). | + | |
<br clear="all"> | <br clear="all"> | ||
| Line 69: | Line 67: | ||
== Support for New Technical Standard == | == Support for New Technical Standard == | ||
This entire project is very tied to the [http://openwetware.org/wiki/The_BioBricks_Foundation:Standards/Technical/Exchange Synthetic Biology Open Language] (SBOL) effort. This is a set of three activities related to the standardization of a number of required synthetic biology concepts with the goal of facilitating software development. We contributed in the following ways. | This entire project is very tied to the [http://openwetware.org/wiki/The_BioBricks_Foundation:Standards/Technical/Exchange Synthetic Biology Open Language] (SBOL) effort. This is a set of three activities related to the standardization of a number of required synthetic biology concepts with the goal of facilitating software development. We contributed in the following ways. | ||
| + | <br clear="all"> | ||
| + | [[Image:sbolV1.png|200px|left|thumb|<span style="font-family: Georgia, serif;">SBOL Visual Promoter</span>]] | ||
| + | [[Image:sbolV2.png|200px|left|thumb|<span style="font-family: Georgia, serif;">SBOL Visual Open Reading Frame</span>]] | ||
| + | [[Image:sbolSemantic.gif|200px|left|thumb|<span style="font-family: Georgia, serif;">SBOL Semantic Proposal</span>]] | ||
| + | *[http://openwetware.org/wiki/Endy:Notebook/Synthetic_Biology_Open_Language SBOL Visual]- We worked with Suzie Bartram and Cesar Rodriquez at Stanford to make sure that Spectacles was 100% compliant with the the SBOL Visual standard. This included support to assign functional concepts to the icons as well as providing a very smooth upgrade path in the event the images evolve. | ||
| - | [ | + | *[http://openwetware.org/wiki/SBOL_Semantic SBOL Semantic] - By revamping the Clotho data model we have enabled the internal structure of Clotho to adapt to new ideas regarding the representation of biological data. Bing Xia and Douglas Densmore participated in the [http://openwetware.org/wiki/The_BioBricks_Foundation:Standards/Technical/Exchange SB Data Exchange working group meeting] at Stanford on 7/26/2009. Clotho as a project is committed to the support of this standard. |
| - | [ | + | <br clear="all"> |
| - | + | *[http://openwetware.org/wiki/The_BioBricks_Foundation:Standards/Technical/Exchange/SBOL_Script SBOL Script] - SBOL script is an effort to develop a human readable specification. Eugene has been created to be a super-set of the eventual SBOL script. A key piece that we added support for in Eugene is the exporting of Eugene as an XML description. This will lead to the manipulation of Eugene by other tools as well as translating Eugene into a more restricted form which will be SBOL script. | |
| + | <br clear="all"> | ||
| - | + | == Human Practices == | |
| - | + | Our project has the potential change the way humans interact with lab equipment via automation, how humans share information with each other, and the ways in which data is protected. We hypothesize how we can have the most impact in those three areas below: | |
| + | |||
| + | * '''Automation''' - software automation has the potential to reduce the amount of time spent in the laboratory by reducing errors, speeding up processes, and removing manual, repetitive operations. The UC Berkeley wet lab team made over '''800 parts''' which would not have been possible without automation. In addition, automation can remove human workers from potentially hazardous environments as well. Automation can reduce the stress researchers feel when manual process fail and can free them up to pursue more intellectually rewarding activities. We contributed to automation by: | ||
| + | ** Providing automation workflows for liquid handling robots in Kepler | ||
| + | ** Creating optimal assembly strategies with Clotho's ''algorithm manager'' | ||
| + | ** Allowing composite device permutations to be specified and created with Eugene | ||
| + | |||
| + | * '''Sharing''' - by enabling the use of centralize repositories of information users can share data locally and globally. Languages like Eugene allow high level specifications to be shared easily in a human readable format. Sharing allows users to be more productive as well as move research forward faster by allowing labs to build on the knowledge of other researchers. In a growing field like synthetic biology sharing is going to be vital for the growth of the field. We contributed to sharing by: | ||
| + | ** Providing ways to share high level specifications (Eugene and XML) | ||
| + | ** Allowing software to talk to centralized repositories (Clotho data API) | ||
| + | |||
| + | * '''Security''' - if software is built correctly, it can encrypt data as well as provide mechanisms for time stamping intellectual property for the legal purposes such as patenting. It can also provide checks on DNA information to prevent the construction of biologically hazardous designs. It can also track the history of biological material which can be vital in determining its origin. Specific security features are not currently the focus of our projects but we can envision the following ways we could incorporate security: | ||
| + | ** Provide a time stamp allow with verified user info along with all parts developed using Clotho | ||
| + | ** Encode rules in Eugene which prevent specific sequences from being generated during composite device development | ||
| - | |||
<br clear="all"> | <br clear="all"> | ||
| - | == | + | == Safety == |
| + | As a software project our work did not raise many of the safety issues typically associated with biological project. Nevertheless we will explicitly address four safety questions here: | ||
| + | |||
| + | # Would any of your project ideas raise safety issues in terms of: | ||
| + | #* Researcher safety? | ||
| + | #** The development of software requires many hours in front of a computer. As programmers we must guard against repetitive stress disorders and environments which are not ergonomically friendly. We made sure that we took regular breaks, worked in a comfortable lab environment, and used proper equipment. Our team rarely ventured into a wet lab environment, but when we did it was accompanied by a trained worker in the lab and we were supervised at all times. | ||
| + | #* Public safety? | ||
| + | #** We did not perform any work that put the public at any risk. | ||
| + | #* Environmental safety? | ||
| + | #** We did not perform any work that put the environment at any risk. | ||
| + | # Is there a local biosafety group, committee, or review board at your institution? | ||
| + | #* Not applicable to our work on software. | ||
| + | # What does your local biosafety group think about your project? | ||
| + | #* Not applicable to our work on software. | ||
| + | # Do any of the new BioBrick parts that you made this year raise any safety issues? | ||
| + | #* Our tools helped develop the parts built by the UC Berkeley 2009 iGEM wet team. They took the necessary steps to address safety issues raised by the parts created. | ||
| + | |||
| + | <br clear="all"> | ||
== Related Links == | == Related Links == | ||
| + | |||
| + | [http://sourceforge.net/projects/clothocad/ Clotho Sourceforge Project] | ||
| + | |||
| + | [http://sourceforge.net/projects/eugene/ Eugene Sourceforge Project] | ||
| + | |||
| + | [http://sourceforge.net/projects/keplerclotho Kepler/Clotho Integration Sourceforge Project] | ||
[https://2008.igem.org/Team:UC_Berkeley_Tools iGEM 2008 Berkeley Tools Team] | [https://2008.igem.org/Team:UC_Berkeley_Tools iGEM 2008 Berkeley Tools Team] | ||
Latest revision as of 21:51, 21 October 2009
Miscellaneous
Contents |
This page covers a number of different topics which did not fit nicely within any of the other pages in this wiki. Here we provide a draft specification/roadmap for the next version of many of the projects here (who knows these could be a part of iGEM 2010). In addition we discuss our collaborations, efforts in standardization, how our project relates to human practices, issues related to safety, and related links.
Draft Specification
This section details a draft specification for the next version of Eugene, Spectacles, and the Clotho environment. These specification descriptions assume the reader is familiar with the current state of the projects (i.e. has read the appropriate pages on this wiki). The specs involve an ordered list of tasks along with approximate dates when these should be completed by.
Eugene
- Add a way to express the relationship of parts in a device to resulting transcripts - December 2009
- Currently there is no clean way to say which parts are associated to a particular transcript after transcription. It would be ideal to have a way to do this so that rules can be applied on a transcript based level. Often interactions are on a per transcript basis.
- Add support for rules defined over part definitions (i.e. not just part instances) - December 2009
- Current rules are constructed as such: Rule r1(partInstance1 WITH partInstance2). It would be very powerful if we could state: Rule r1(partDef1 WITH partDef2). This would remove a lot of repetition in rule creation when one wants to state something abstract regarding a whole set of parts.
- More completely support [http://openwetware.org/wiki/Endy:Notebook/Synthetic_Biology_Data_Transfer_Process SB/DTP (Synthetic Biology Data Transfer Process)] with XML export and import - Spring 2010
- Current we can produce a limited XML file from Eugene's interpreter. Ideally we can make this fully compliant with the SB/DTP protocol being developed.
- Add support for a completely expressive control statement set (e.g. if, while, for) - Spring 2010
- Eugene currently only has if-statements. We will be adding the needed control statements to provide a fully expressive control flow.
Spectacles
- More advanced testing which is more integrated with the completion of entire design flows - December 2009
- Spectacles currently exports device information to the algorithm manager and the sequence view. It would be nice to more closely couple this with other tools such as the parts manager. This would make complete design flows much more easy to create.
- Expansion of visual cues - December 2009
- The current Spectacles tool offers visual cues related to the status of abstract functional parts assigned to physical data as well as a part's adherence to rules. The visual cue system should be expanded and made more user flexible.
- More advanced database support for the assignment of physical parts - December 2009
- Now the user can specify what criteria they wish to use to search for parts in the database. For example one can search for all parts which say "promoter" as part of the "short description" or those which contain "bba" in the "name". However, this system can be expanded to offer more robust search capabilities as well as more insight into the repository where the parts are located.
- Visual rule enforcement - Spring 2010
- Support should be added which visually enforces the rules specified by Eugene in Spectacles. This can restrict the movement of icons, the editing or property information, or the visual cues present.
Clotho
- Complete/Test flow for basic part creation - December 2009
- We need to complete the flow from DNA sequence capture, to part packaging, and finally to database storage. The flow is currently present but requires some manual steps and some of the user interfaces need to be made more intuitive.
- Complete/Test flow for full device creation - December 2009
- We need to complete the flow currently outlined throughout this wiki for device creation. Again, this flow works as demonstrated. However, we are sure due to the complex nature of this process bugs exist. Again ideally we also should do a complete evaluation of the user interface issues associated with this design flow to make sure that it is maximally effective and usable for bench biologists in a wide variety of settings.
- Integrate Clotho with JBEI's registry - December 2009
- JBEI's parts registry is now available as web service. We should work with this registry as it is a major source of data and users. It is also a way for us to work with the larger standards community.
- Complete the SPAM tool's oligo coverage designer and golden gate part packager - December 2009
- Currently the SPAM tool is under development. There are two major pieces currently. The first is a oligo designer for sequencing which produces oligos for a sequence trading off the number of oligos produced with the confidence in the sequencing result. The second produces oligos to create parts using an alternate assembly method known as [http://www.plosone.org/article/info:doi%2F10.1371%2Fjournal.pone.0005553 Golden Gate]. This work is being done with the [http://www.jbei.org Joint BioEnergy Institute].
- Test data model with Davidson University's [http://gcat.davidson.edu/GCATalog-r2.1/GCATalog.htm GCATalog based registry] - Spring 2010
- We would like to get Clotho to work fully with other University registries. Davidson's GCATalog is one candidate and we have made contact with them to get this process started.
Collaboration
For all of our projects, we worked with a number of different groups both to make our tools more visible, as well as get valuable feedback. This section discusses some of these collaborations.
- UC Berkeley iGEM team - we worked very closely with our wet team counterparts to tie our Kepler based assembly workflows with the [http://www.beckman.com/products/instrument/automatedsolutions/Biomek/Biomek3000_inst_dcr.asp Beckman Coulter BioMek 3000 liquid handling robot] that they used heavily in their work. In addition we beta tested our software with them, incorporated their feedback, and ran tutorial sessions on Clotho use and how to write Clotho plug-ins.
- Stanford iGEM team - we provided early versions of Spectacles to the Stanford iGEM team so that they could test it out. In addition we worked with them to incorporate new iconography as they added it to the [http://openwetware.org/wiki/Endy:Notebook/Synthetic_Biology_Open_Language SBOL Visual effort].
- University of Minnesota - Emma Weeding worked with us both in the development of Eugene as well as making sure the XML it exported worked with SynBioSS.
- [http://www.jbei.org Joint BioEnergy Institute (JBEI)] - we worked with Nathan Hillson, Will Holtz, and Tim Ham at the Joint BioEnergy Institute on our SPAM tool as well as discussing ways in which design flows for synthetic biological devices should be constructed.
- Valencia iGEM Team - In addition to many other iGEM teams, we filled out their survey and received a gold medal (100% team participation).
Support for New Technical Standard
This entire project is very tied to the [http://openwetware.org/wiki/The_BioBricks_Foundation:Standards/Technical/Exchange Synthetic Biology Open Language] (SBOL) effort. This is a set of three activities related to the standardization of a number of required synthetic biology concepts with the goal of facilitating software development. We contributed in the following ways.
- [http://openwetware.org/wiki/Endy:Notebook/Synthetic_Biology_Open_Language SBOL Visual]- We worked with Suzie Bartram and Cesar Rodriquez at Stanford to make sure that Spectacles was 100% compliant with the the SBOL Visual standard. This included support to assign functional concepts to the icons as well as providing a very smooth upgrade path in the event the images evolve.
- [http://openwetware.org/wiki/SBOL_Semantic SBOL Semantic] - By revamping the Clotho data model we have enabled the internal structure of Clotho to adapt to new ideas regarding the representation of biological data. Bing Xia and Douglas Densmore participated in the [http://openwetware.org/wiki/The_BioBricks_Foundation:Standards/Technical/Exchange SB Data Exchange working group meeting] at Stanford on 7/26/2009. Clotho as a project is committed to the support of this standard.
- [http://openwetware.org/wiki/The_BioBricks_Foundation:Standards/Technical/Exchange/SBOL_Script SBOL Script] - SBOL script is an effort to develop a human readable specification. Eugene has been created to be a super-set of the eventual SBOL script. A key piece that we added support for in Eugene is the exporting of Eugene as an XML description. This will lead to the manipulation of Eugene by other tools as well as translating Eugene into a more restricted form which will be SBOL script.
Human Practices
Our project has the potential change the way humans interact with lab equipment via automation, how humans share information with each other, and the ways in which data is protected. We hypothesize how we can have the most impact in those three areas below:
- Automation - software automation has the potential to reduce the amount of time spent in the laboratory by reducing errors, speeding up processes, and removing manual, repetitive operations. The UC Berkeley wet lab team made over 800 parts which would not have been possible without automation. In addition, automation can remove human workers from potentially hazardous environments as well. Automation can reduce the stress researchers feel when manual process fail and can free them up to pursue more intellectually rewarding activities. We contributed to automation by:
- Providing automation workflows for liquid handling robots in Kepler
- Creating optimal assembly strategies with Clotho's algorithm manager
- Allowing composite device permutations to be specified and created with Eugene
- Sharing - by enabling the use of centralize repositories of information users can share data locally and globally. Languages like Eugene allow high level specifications to be shared easily in a human readable format. Sharing allows users to be more productive as well as move research forward faster by allowing labs to build on the knowledge of other researchers. In a growing field like synthetic biology sharing is going to be vital for the growth of the field. We contributed to sharing by:
- Providing ways to share high level specifications (Eugene and XML)
- Allowing software to talk to centralized repositories (Clotho data API)
- Security - if software is built correctly, it can encrypt data as well as provide mechanisms for time stamping intellectual property for the legal purposes such as patenting. It can also provide checks on DNA information to prevent the construction of biologically hazardous designs. It can also track the history of biological material which can be vital in determining its origin. Specific security features are not currently the focus of our projects but we can envision the following ways we could incorporate security:
- Provide a time stamp allow with verified user info along with all parts developed using Clotho
- Encode rules in Eugene which prevent specific sequences from being generated during composite device development
Safety
As a software project our work did not raise many of the safety issues typically associated with biological project. Nevertheless we will explicitly address four safety questions here:
- Would any of your project ideas raise safety issues in terms of:
- Researcher safety?
- The development of software requires many hours in front of a computer. As programmers we must guard against repetitive stress disorders and environments which are not ergonomically friendly. We made sure that we took regular breaks, worked in a comfortable lab environment, and used proper equipment. Our team rarely ventured into a wet lab environment, but when we did it was accompanied by a trained worker in the lab and we were supervised at all times.
- Public safety?
- We did not perform any work that put the public at any risk.
- Environmental safety?
- We did not perform any work that put the environment at any risk.
- Researcher safety?
- Is there a local biosafety group, committee, or review board at your institution?
- Not applicable to our work on software.
- What does your local biosafety group think about your project?
- Not applicable to our work on software.
- Do any of the new BioBrick parts that you made this year raise any safety issues?
- Our tools helped develop the parts built by the UC Berkeley 2009 iGEM wet team. They took the necessary steps to address safety issues raised by the parts created.
Related Links
[http://sourceforge.net/projects/clothocad/ Clotho Sourceforge Project]
[http://sourceforge.net/projects/eugene/ Eugene Sourceforge Project]
[http://sourceforge.net/projects/keplerclotho Kepler/Clotho Integration Sourceforge Project]
iGEM 2009 Berkeley Wet Lab Team
[http://openwetware.org/wiki/The_BioBricks_Foundation:Standards/Technical/Exchange SBOL Effort]
[http://groups.google.com/group/synbiodex Synthetic Biology Data Exchange Group]
