Endy:Notebook/BioBrick Open Language Specification/Doug Approach: Difference between revisions

From OpenWetWare
Jump to navigationJump to search
(New page: <pre> //Sample "Eugene" (BOL) file which illustrates the requests from SynBioSS Group //Doug Densmore //Date - 7/10/09 /* Components/Devices * BioBrick ID: To allow for the design of c...)
(No difference)

Revision as of 17:09, 11 July 2009

//Sample "Eugene" (BOL) file which illustrates the requests from SynBioSS Group
//Doug Densmore
//Date - 7/10/09

/*
 Components/Devices

	* BioBrick ID: To allow for the design of custom BioBricks, I think this property should be defined by default but not mandatory.
   * BioBrick nickname: Mandatory. For naming custom bricks, and convenience; "pTet" is more descriptive than "BBa_R0040".
   * BioBrick type: Promoter, RBS, Coding DNA, Terminator, etc. SynBioSS only cares about these four types, but obviously BOL should support every type in the Parts Registry.
   * BioBrick order: For devices and whatnot. 
*/
Property BioBrickID(txt);
Property Nickname(txt);
//Type and order will not be properties ; order can be determined by other things 

/*  
Type-Specific Characteristics
Promoters

   * Constitutively ON/OFF: That is, whether a promoter is "ON" or "OFF" when no protein is bound to it.
   * Operator Site Name(s): Such as tetO, lacO, etc....
   * Operator Site Location(s): A start/end is all we need.
   * Location of -10/-35 sites: Start/end. We are interested in this because the leakiness of a system is affected by the location of any operator site(s) relative to these sites. 
*/
Property OnOff(num); //1 will be 0; 0 will be off; maybe we could add a boolean type?
Property OperatorSiteName(txt);
Property OperatorSiteLocation(num); //0 could be start, 1 could be end
Property Negative10(num);
Property Negative35(num);

/*
Coding DNA

   * Corresponding protein: For example, BBa_E0040 codes for GFP. 
*/
Property Protein(txt);

/*
Regulatory/System Information

I do not know if the scope of BOL will eventually include entire systems, instead of just BioBrick devices. If so, the following information would be helpful to us:
Protein Properties

   * Constitutive or Non-Constitutive: Self-explanatory.
   * Protein "type": The general behavior of the protein. Currently, SynBioSS can handle activators, repressors, and reporters.
   * Binding Sites: A list of operator sites that the protein can bind do.
   * Complex: This is just an integer representing the number of protein monomers that are in an active complex. For example, TetR and LacI bind DNA as dimers(2) and tetramers(4), respectively. 
*/

Property Constitutive(num); //Again 0 and 1 can be used
Property ProteinType(txt);
Property BindingSites(txt[]);
Property Complex(num);

/*
Effector Properties

Such as aTc, IPTG, etc....

   * Binding behavior: Protein(s) that the effector binds to.
   * Act in Concert: For every protein/effector pair, this is a yes-no question. Some proteins (e.g. LuxR) will not bind to DNA until a small molecule (e.g. HSL) first binds to them. 
*/
Property BindingBehavior(txt);
Property ActInConcert(num);

/*
All properties about can be kept in a header file called SynBioSSProperties.h
*/

//Examples of components
Component Promoter(BioBrickID, Nickname, OnOff, OperatorSiteName, OperatorSiteLocation, Negative10, Negative35);
Component RBS(BioBrickID, Nickname);
Component CodingDNA(BioBrickID, Nickname, Protein);
Component Terminator(BioBrickID, Nickname);

/*
All components definintions can be in a headerfile called SynBioSSComponents.h
*/

Promoter p("BBa_R0040", "ptet", 0, "lac", 1, 0, 1);
RBS r("BBa_R0040", "rbs");
CodingDNA c("BBa_R0040", "CDS", "lasR");
Terminator t("BBa_B0010", "term");

/*
All instantiations can be in a headerfile called <x>instantiations.h
This will be created by parsing information from a database, xml file, etc
*/


//Now once all this has been captured in header files, devices can be defined

Device d = {p, r, c, t};
Device d2 = {p, d};

//sample print statements
print(d2.Nickname
print(d[0].OperatorSiteName);