Team:Heidelberg/Software/MidnightDoc
From 2014.igem.org
m |
|||
Line 14: | Line 14: | ||
subtitle= Documentation made easy | subtitle= Documentation made easy | ||
| | | | ||
+ | container-style=background-color:white; | ||
+ | | | ||
+ | titles={{:Team:Heidelberg/templates/title|Introduction}}{{:Team:Heidelberg/templates/title|Project Components|Project_Components}}{{:Team:Heidelberg/templates/title|Conclusions}}{{:Team:Heidelberg/templates/title|References}} | ||
+ | | | ||
+ | abstract= Here we introduce MidnightDoc. | ||
content= | content= |
Revision as of 22:58, 17 October 2014
– Documentation made easy
ABSTRACT
Here we introduce MidnightDoc.content=
Contents |
Introduction
Documentation is one of the most important aspects of any scientific project. Nevertheless, maintaining a detailed log of all experiments performed can often be a daunting task, especially when consistency and standardization across multiple persons is required. This consistency is particularly important in the context of iGEM, where group work is of paramount importance. Also, as many iGEM projects build upon results of preceding teams, a standardized way of documenting would further enhance this interaction. Reproducibility of projects would also be increased. Thus, a consistent, semi-automated, documentation method could help solve many of the problems faced by iGEM teams, but also researchers in general.
For these reasons, we created a software which does just that. Our MidnightDoc enables reproducibility by making sure that documenting experimental methods becomes a fun activity; a natural extension of normal lab routine. In the following, we will describe the main design principles behind this fine piece of software.
Lay out your plan, then record what you did
The most important design principle behind MidnightDoc is the fact that it accompanies lab work and in fact makes it easier. In order to illustrate this, consider the simple example of a restriction or ligation experiment: The user will first look up for the concentrations of his fragments, as measured for example by a spectrophotometer. Then, based on these concentration measurements and the manufacturer guidelines, which might specify the required amount of each fragment (e.g. in micromol or nanograms) or the ratio between them, the user will calculate the necessary volumina. Only after these calculation have been done, will the user be able to mix these components and then start the reactions. Once this has been done, he will document some of the aforementioned numbers (e.g. the volumina used) in his labbook for future reference.
Now, notice that there are several ways in which a software tool can assist in the previous process. First of all, an integrated database with information on all available plasmid, PCR amplified DNA fragments, etc. would make the retrieval of the concentration information a lot easier. Then, this can be immediately used for subsequent calculations, which also should be done by the software.
To achieve this, you have to pre-specify your plan: the experimental guidelines and procedures which you want to follow. The rules, such as ratios of fragments, will then be integrated in order to automate calculations. Thus, MidnightDoc, will help with your calculations, but at the same time document what you did. Also, once you have created the protocol for an experimental procedure, such as a ligation with different fragments, you will be able to reuse it with new details, such as the new fragments or the different concentrations.
Propagation and Backtracking
Of course, storing all details in the software also has many other advantages, such as "Propagation" and "Backtracking". Already in a previous design principle, we touched on the idea of propagation: Details about biological samples, which have already been entered into the database, can then be used for calculations in subsequent experiments. But it also helps with error analysis: Assume you repeat a concentration measurement of a DNA sample and determine that the originally measured value was incorrect. Now also assume that you have already used this DNA for downstream work. If you were to update this value now, all values depending on it will be updated. For example, the MidnightDoc will automatically reflect the change by showing the true amount (e.g. in nanomols), which was used downstream. Thus, the user will be able to determine, if the wrong measurement of concentration has had implications for the other experiments.
By "backtracking", we describe the other side of the same coin: You should be able to follow the complete history of any sample in your lab. For example, for a plasmid, you should be able to trace back the components out of which it was assembled. In turn, you should be able to trace the history of these components. In turn, if these were amplified by PCR, you should also be able to access the primers that were used, the template DNA (or host species), as well as the reaction conditions. In this way, "backtracking" also assists with possible error analysis and makes a task, which is very hard and time-consuming in the classical labbook setting, very easy.
You decide the level of detail
When starting to use MidnightDoc, the user will first need to describe the protocols they wish to perform. These protocols can be entered in a very flexible way and allow to specify whatever parameters the user may want to record for this type of experiment. While it is certainly possible to add a multitude of possible value inputs to each and every method, filling in all the information might become too much of a burden for day-to-day lab work. The user may therefore choose to record only few values for standard (e. g. cloning) protocols, and more for complex assays for meaningful statistical analysis.
This applies likewise to the source materials of experiments which can be backtracked: it would certainly be possible to document every bottle of lysis buffer or even every flask of growth medium ever produced. Generally, however, the user might not want to have to check which database entry corresponds to the flask of medium used for their miniprep cultures; it may therefore not be advisable to include this as a traceable source material, whereas it would be of greater importance to be able to relate the lot of a manually purified protein used in an assay.
This abstraction principle also makes MidnightDoc conform to the different requirements of different labs and even the different sciences.
Version control
The biostatistics community has recently embraced the idea of [http://cran.r-project.org/web/views/ReproducibleResearch.html Reproducible research], by introducing standards which should be followed when reporting any computational task. Thus, other researchers will be able to verify methods used in diverse publications, but also modify and improve upon them. We believe, that documentation of wet lab work, should also try to make use some of these concepts (and vice versa!).
The main concept of the reproducible research community which inspired us for MidnightDoc are the version control systems, such as [http://git-scm.com/ git]. In computational tasks and programming in general, the basic idea is that you should be able to look at the code you had previously written, which over many iterations lead to the final production code. Similarly, in the context of wet lab documentation, you should be able to easily revert to the state of the documentation at a particular date. This would allow one to explore protocols that were used by the lab previously and got replaced or modified over time. In addition, it would allow to explore PCR fragments, plasmids, etc. which were available at a particular point in time.
In summary, version control, is very exciting indeed, even if it is not distributed, as MidnightDoc will take care of it!
It's on the web
MidnightDoc is implemented as a standard web application. Therefore, there is no need to install any software on many client computers -- just open up your browser and point it to the copy deployed on your lab's IT infrastructure. Of course, MidnightDoc is designed as a multi-user system with a shared database, so the propagation and backtracking features also are continuous when basing your work upon previous experiments of others -- and all of the aforementioned features make it astonishingly easy to understand every aspect of how they were performed. This makes it ideal for team work like in an iGEM setting.
Outlook
Conceptually, MidnightDoc could also harness the plethora of available web resources. It goes without saying that accessing all documentation details from everywhere is a big advantage already. But we also envisage other applications by this web-integration, such as the following: The MidnightDoc tool will be tightly linked in the future to synthetic biology registries, such as the iGEM/BBF parts registry, but also other ones, such as the JBEI registry. Thus, information about different parts used will be easily coupled to experimental methods. Another application would be the integrated design of primers, e.g. by use of Gibthon, an automated tool for the design of primers for Gibson assembly developed by the Cambridge iGEM teams of 2010 and 2011.
Right now, MidnightDoc is still in pre-beta stage, but the source code is available on GitHub!