-
Notifications
You must be signed in to change notification settings - Fork 0
How to write your electronic labbook
The labbook is the daily diary of your research efforts. It is important for yourself, but also for others. Therefore, it is important to follow a certain standard, which is comprehensible for everyone, who may have a look at your labbook. There a different target audiences, who need to make sense out of your diary. In the RTG2416, we support the use of electronic labbooks. Currently, we use elabftw (https://www.elabftw.net/), which is an open-source solution, which does not need any third-party involvement, when you run it on your own server. Our electronic labbook can be found here:
Once you are registered at the network domain, you are able to login with your Bio2-credentials.
The electronic labbook contains different sections. They are called "Experiments", "Database" and "Search". Each one of them can help you to keep track of your work efficiently.
This is the section for your daily experiments. It is important to create at least one entry per day (at least, if you worked). This entry should contain information, which makes you and others able to understand and recreate your experiment. Following, a list with information, which should be included. Please note, that this is not an exclusive list and more information is always better
- Who was involved in the experimental session?
- To which project does the experiment belong?
- Which method/paradigm did you use?
- Was there any kind of treatment? Or was it a control experiment?
- How many mice did you use? Which mice did you use? State the animal id (internal, as well as the official one)!
- Did you use solutions? Which solutions did you use? What is the recipe of your solution? (also see "Database")
- You did not do an experiment, but analysis? Great, make an entry! State the method you used, link to a repository if possible and provide the output of your analysis
- Comment, if something unexpected happened. Any observation can help you afterwards, if you notice outliers.
To have a better overview of your projects, it is possible to create a template. This templates can contain the barely minimum of information you should provide. A template should be project-specific and aknowledged by your PI. If you have questions or need help with the templates, just contact your friendly neighborhood Data Manager.
Another important feature of the experiments section, are keywords. You should use keywords, to make your entries more findable. Mostly, the method you used (examples: "2P imaging","behavior","patch clamp") are great filters, but you can also specify this information (examples: "Whole cell patch clamp", "operant conditioning"). The more specific you are, the easier it is to find your experiment.
Last, but not least, you can lock and timestamp your experiments. By timestamping your entries, they are proofed by a decentralized certificate and you or others cannot change them anymore. German authorities expect a fraud avoidance, which we have with the timestamp.
The Database can contain information which are of a more constant nature and does not change on a daily basis, like an experimental paradigm for example or the ingredients of a solution. You can link these database objects to lab book entires, made in "experiments". If you write a database entry, make sure, that you just state constant information. If you, for example, adapt your paradigm because the first version, did not work out as expected, create a new database object and mark it as a new version instead of change the first version. This helps you, to keep track of changes in your projects and avoids confusion. So please follow this suggestion:
Old paradigm: "Name of my paradigm v1" New paradigm: "Name of my paradigm v2"
In "Search" you can look your entries. The filters are self-explanatory and if you use them wisely, you fill find the entry you are looking for