Endy:Notebook/BioBrick Open Language Specification/Doug Approach

Response to Emma's Requirements

//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(boolean); //we added a boolean type, "true" or "false" are possible values (without quotes)
Property OperatorSiteName(txt[]); //changed to reflex Emma's comments
Property OperatorSiteLocation(num[]); //changed to reflex Emma's comments
Property Negative10Negative35(num[]); //changed to reflex Emma's comments

/*
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(boolean); //Changed to boolean
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 part
Part Promoter(BioBrickID, Nickname, OnOff, OperatorSiteName, OperatorSiteLocation, Negative10Negative35);
Part RBS(BioBrickID, Nickname);
Part CodingDNA(BioBrickID, Nickname, Protein);
Part Terminator(BioBrickID, Nickname);

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

Promoter p("BBa_R0040", "ptet", true, ["TetR1", "TetR2"] , [1, 19, 26, 44], [19,44]); //reflects Emma's comments
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);