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);