Team:Berkeley Software/Eugene
From 2009.igem.org
Line 5: | Line 5: | ||
|rightSideBox= | |rightSideBox= | ||
- | <center>[[Image:Eugene.png| | + | <center>[[Image:Eugene.png|200px]]</center> |
|title= | |title= |
Revision as of 23:59, 11 October 2009
- Eugene
- Spectacles
- Kepler
- Data Model
Eugene
Introduction
With the rise of partification in synthetic biology, there needs to be a formal specification to describe standard biological parts, especially when designing complex devices. The specification needs to be both human-writable and human-readable, a language that raises the level of abstraction where bioengineers can work. Eugene is such a language. Engineering at the part level requires both flexibility and rigidity. Eugene allows the user to mix custom parts with predefined parts from established databases. Parts can encapsulate an arbitrary amount of information, anything from a DNA sequence to experimental history. When designing a device in Eugene, parts can be freely stitched together on a whim, or strictly joined together based on rules. The design process is meant to be systematic yet intuitive. The user considers what information parts include, constructs parts to be used in the design, enforces restrictions on how parts can interact, and creates devices that are composites of the parts or other devices. Being a textual design, a device specified in Eugene is portable and easily lends itself to being translated into other formats, such as XML. In synthetic biology, the notion of part changes regularly and is debated tirelessly. Thus, Eugene tries to be adaptable and expressive in any climate. This page goes into the language specification in detail.
Some content goes here.