Team:DTU-Denmark/Software
The Wiki Wizard
Creating and designing an iGEM wiki can be a difficult and timeconsuming task. We believe an easier way to create wikis can help many teams. Therefore we created the Wiki Wizard.
The Wiki Wizard takes care of namespacing pages and files, and can automatically generate a referene list for a page, while editing the pages, a preview of the wiki can be seen by clicking on the ’Team main page’ link in the menu.
You can find it at GitHub
Wiki creation
With our wiki wizard, you can choose an existing theme, upload a theme made by someone else, or create your own. The tool is based on Flask and uses the Jinja engine for templates. By default the Wiki Wizard sets a theme and creates pages corresponding to the ones set by default on the iGEM wiki.
Content
Page
In the Wiki Wizard a page is a container for one or more sections, in which the page content is written. A page can also be given an image, template, position, name and url.
- The template determines the overall layout of the page.
- The image is a setting, that themes can use for page specific images.
- Position determines the order pages in the menu, unless the menu is specified in menu(see below)
- The name is shown in the menu and
- The URL is the link to the page – e.g. blank for front page, or Team for team page
Section
Sections are where the content is stored. These can be edited either in the page editor or separately in the section editor. To make writing easier, the section content is written in a CKEDITOR frame, which allows you to write HTML as you would write a page in Word. Sections can also be given an image, template, position and name.
- The image is a setting, that themes can use for section specific images.
- The template determines which and how content is rendered
- Position determines the order of the sections on a page and
- The name is used for section headers, and themes can use it to create section links.
Entities
Besides keeping track of your pages, the Wiki Wizard can also store your teams members, advisors, sponsors etc as Entities. Section templates can be designed to show (some of) these, thus adding members to your members section can be done with a few clicks. Again these can be edited in a CKEDITOR frame (see above) and have some settings. They are, image, position name, role and link.
- Images are used to for e.g. member section images.
- Position determines the order
- Role is used to filter e.g. members for the member section.
- Name is the name of the entity.
- Link can be used to make links to e.g. sponsor websites
Menu
The menu can be used to create a nested menu or add external links to the menu. Each item in the menu can have page, parent, position, name url and children.
- Page is used to make a link to a page
- Position determines order
- Name and url can be used to make external links, these are ignored if page is assigned.
- Parent/Children can be used to create dropdowns. Items with a parent, will be listed under the parent, and children are the items listed under the current item. How many levels of the menu may be limited by the selected theme.
Timeline
Timeline entries can be used to quickly generate a timeline/journal. These entries have a date, title and content, which again is edited with a CKEDITOR. The timeline can be inserted in a specific section by selecting a template that shows timeline entries.
References
Keeping track of reference order is tedious. Therefore references can be added here. They should have the reference text, and a reference id.
- The id is used to insert citations in the content, similar to LaTeX, they can be inserted as [-1]
- Reference text, is the text that will be shown in the reference list
These settings can be grabbed automatically by supplying a doi. And the theme should include a reference section template used to display the generated reference list.
Files
Files can be uploaded to the Wiki Wizard here. No need to worry about namespacing, as the Wizard will rename files to the correct namespace when uploading to the wiki (see below).
Settings
The settings tab can be used to select the base url, that the wiki should upload to. This year it is 2015.igem.org, next year it should be 2016.igem.org. This is also the page where the team name is entered, so that the Wizard can upload and rename files correctly. The last setting, is used to determine whether or not, it should be possible for new users to register on the Wizard, this option should be ticked off, once the desired users have been created. Users can be also created and deleted under the Advanced -> Users tab.
Theme
This section can be used to edit/upload files for the current theme under theme files. And themes can be selected under Select theme.
Wiki Upload
The Wiki Wizard can upload the files and content to the iGEM servers and automatically rename files to the correct namespace. No need to individually upload the files and edit pages, just select what you want to upload, and the Wizard takes care of the rest.
Writing themes
The theme system utilises Flask-Themes2 for theme selection, more on how to write themes can be seen here
NOD Nrps Oligo Designer
In order to fully utilise high throughput methods, you must be able to do high throughput design.
We developed a prototype oligo designer for NRPS library production and screening in python (NOD).
You can find it at GitHub
Usage
NOD is a commandline program, that takes a fasta file with one or more dna sequences encoding a NRPS and prints oligos that can be used to alter the specifity of each module. Also shipped with the tool is a simple UI, that can be run instead.
Requirements
NOD requires a few extra programs. It uses HMMSEARCH of HMMER to identify the adenylation domains and MUSCLE to identify the stachelhaus code, it is written in python and requires BioPython. To run the UI, wxPython must also be installed.
Development
The code for identification of adenylation domains and stachelhaus is based on antiSMASH, but has been slightly modified in order to not only identify the stachelhaus code, but also keep track on the positions in the unaligned sequence.
After identifying the stachelhaus residues, the stachelhaus code is compared to the stachelhaus code of different specificities. By comparing the degenerate sequence of the new stachelhaus code to the sequence of the native code, the changes are scored based on the amount of oligos required to incorporate all changes followed by the number of required mismatches. More than one oligo may be necessary, if changes are too far apart. The oligos are designed to be 90 nucleotides long with homologous ends of atleast 15 nucleotides in each end.
Perspectives
The developed tool is only a prototype and several improvements could be added.
- Currently the program randomly selects a codon from a degenerate codon if more than have the same required mismatches to incorporate. An improvement to this, could be to score codons according to codon usage.
- The oligo folding is not optimised, but this could be added by using ViennaRNA.
- With more data on incorporation efficiencies, it would be possible to calculate the allelic replacement of each oligo set, in order to select the stachelhaus code with highest allelic replacement
Department of Systems Biology
Søltofts Plads 221
2800 Kgs. Lyngby
Denmark
P: +45 45 25 25 25
M: dtu-igem-2015@googlegroups.com