"
Newcastle University/12 June 2008
From 2008.igem.org
Back to Calendar
iGEM Minutes – 12/06/2008
Action Plan for next week
Group
• What it is about the DNA sequence of a promoter that makes it work the way it does? Ie. The strength of it.
• Meeting at 2pm in 601 CT with Colin Harwood to discuss safety implications of our project.
• TomCat tutorial at 10am Monday 16/06 by Matt. Three lumps of code, on three different servers must be able to communicate. Firstly this should be attempted on an example not related to iGEM. By the next meeting code related to the three projects should be communicating too.
• Come up with a tagline for the logo. If we do not come up with anything by next week, BIODIAGNOSTIC will be it.
Megan
• 15 minute presentation to go over ComC two component system in detail. Include all the parts and how the promoters work.
• Make a cellML model of three parts in the Lac operon (tutorial 1 and 2).
• List all the parts for the two component systems we shall be using.
Nina
• Meeting with Matt to fix svn on computer. Put all code so far on it.
• Write up Safety talk by Colin Harwood.
• Make a cellML model of three interacting parts in Lac operon (tutorial 3)
• Attempt to finish matrix
• Speak to JW about using B.cereus two component system.
Mark
• 15 minute presentation of how he designed and wrote up his cellML model for the Lac Operon and how he plugged it in to Java and his EA.
• Crack JSIM.
• Simulate different states of the lac operon and try to see how it will be incorporate into a java.doc
• Call that into the EA so that by next week he may have a working CellML model in his EA.
Time: 14:30 – 17:00
Attendees:
Matthew Pocock - Supervisor
Morgan Taschuk – Project 5
Mark Wappett – Project 3
Megan Aylward – Project
Nina Nielsen – Project 2
Meeting Content
Agenda 1: Simple BioBricks
Nina discussed the meeting she had with Jan-Willem Veening about producing BioBricks with just a SK and FP. He advised to use SKs and RRs with the FP. He thought it would be too ambitious to use just sensor kinase as you would not be able to recognise when the sensor has been autophosphorylated without the RR (unless going down a specific antibody avenue). In addition he thought that creating a brick for each TCS would be very expensive.
Matt suggested picking one which has been well characterised. The group decides on B. cereus since a brick for S. aureus already exists in the iGEM parts repository.
Nina then mentions that JW said that for the “simple biobrick” GFP will be used since it is the strongest. For using a combination of FPs to detect a series of outcomes; CFP, YFP and mCherry should be used. GFP would overpower them.
Matt then suggested that four individual biobricks should be made for each FP but for the same two component system in B.cereus. This would permit us to define quantitative measurements of the strength of the fluorescence.
Agenda 2: Discuss promoters and potential for using one for several genes.
Megan starts off by mentioning that in literature, promoters are rarely referred to as promoters. This makes it difficult to assemble a directory of parts when they are not actually termed “parts”.
Matt explained that to determine whether a promoter can be used for more than one gene, one needs to know the specific behaviour of that promoter with the gene. For example the strength of the promoter needs to be determined. This can be achieved in the lab by looking at time courses of a particular promoter to drive GFPs.
However the team should attempt to define the strengths by looking at literature to make reasonable estimates. The BioBricks parts repository may also provide some information. (promoter P2 used in S.aureus has been used here).
Matt suggests that one could then use this information to engineer an ideal promoter that could have a ubiquitous effect on all the genes. One could identify promoter regions by using bioinformatics tools such as TRANSFAC.
Alternatively, the team could engineer a mediocre strength promoter and use repressors to control genetic expression.
Agenda 3: Discuss individual progress this week.
Nina has been attempting to populate her matrix for all the real parts collected for S.aureus and B.cereus. She has struggled with defining the order in which different parts can occupy. She has given 1’s to parts she is certain have an effect on each other and left the others blank.
Matt says that some parts may only work with each other if other parts are also downstream/upstream of the operon.
Nina has also researched B. anthracis in detail but unfortunately not found an appropriate quorum sensing two component system with a unique peptide to exploit. The group decides that they should then just use the four organisms: S.aureus, S.pneumoniae, L.monocytogenes and B.cereus.
Nina has also been having individual Java lessons with Phil Lord and organised a safety talk for the iGEM students on Friday by Colin Harwood.
Megan has been populating her database. She thought of making two different tables rather than a different table for each part. One for different type parts and one for the different parts.
Megan has also been looking through the hibernate tutorial.
Megan has also written her architecture. She changed her arrays to collections and wrote out suitable SQL queries.
Matt suggests that she change her sorted sets to just sets too.
Mark Completed the JAVA exercise set by Morgan. He also met with Jen to discuss architecture and design of his project and how it was going to talk to the other projects. He also managed to build a cellML model of the Lac operon.
He is currently trying to get JSIM to work so that he can code up his EA.
Morgan says when he does manage can she show him how too.
All three students completed the CellML tutorial and found it very useful.
Agenda 4: T-shirts
WHSmith’s do packs of 5 screen print sets for £7 each. One available for dark and one for light backgrounds.
Matt: suggested that we buy a t-shirt of each available colour (maybe three or four contenders) to see which one is the most popular and which colour t-shirt would work best with the printing sets. We should make sure to keep the receipts!
Agenda 5: Architectures
Firstly all the architectures should be on the wiki.
Megan put up her architecture.
Matt mentioned it is important to make sure the that the architecture doesn’t over constrain.
Matt also mentioned it is ok to use numbers rather than a string for the unique ID. Megan wanted to have a P1 for promoter for example but matt thinks it is better to just have numbers.
Matt suggests that Megan should make a method for each call to have it return exactly what it should return.
Nina did not put her architecture on the wiki so writes it on the board with a huuuuuuuuuuuuuuuuuuuuge amount of help from Matt and Morgan. (See wiki).
The group runs out of time so does not manage to go over Mark’s architecture.
AOB
• Nina is away next week.
