Notes from june 2nd

Goal of the assembly method algorithms:

Take a string of DNA, and chain it up in this form:

[Prefix][Complimentary Sequence of DNA (to the original string)][Original string of DNA][Suffix][Complimentary Sequence of DNA (to the original string)]

(The [][] notation means two strings concatenated with nothing between)

The [*fix][Complimentary] form a Primer.

The length of the complimentary sequence is related to the temperature: the temperature will be given and the number of base pairs calculated accordingly; there's still a minimum of 15bp required. Some sites are considered restricted; these are elaborated on in the guidelines in Dropbox.

The prefix and suffix are given based on the assembly method and seem to be standard. The original string will be a BioBrick's DNA sequence: we could have many of these to piece together, and we would want to link up all the sequences as much as possible.

We've also identified that we're going to need a UI that incorporates:

• A search view to find the parts (plugs into the CGI file on iGEM's website that handles searches)
• A "brickbucket" to hold the requested parts (acquired from the official XML API, possibly through another API if applicable). Should be possible to easily go from search view to brickbucket.
• A review page, which should then allow the users to confirm which pieces they want to submit for analysis (and ideally we would find the optimal assembly methods for those selected components, and also take care of calculating the requirements for all 5 if possible)(so we're weeding out assembly methods that won't work and pieces that are incompatible).
• A bricklaying and cementing process where each piece is looked at by each of the 5 algorithms, and the process repeated for each of the pieces that are being stringed together. (not sure if the algorithms can do a micro-shitton (10) of these at once, or if we should be taking each biobrick one at a time. Will have to inquire with Wilson, Dylan, Yara, etc.). There's some restricted sites that will throw up errors and toss the user back to the previous stage with their brickbucket intact.
• Once that's done, the user is prompted with any additional information (eg warnings, advisories), and the final sequence(s) displayed. Furthermore, the segments that were added in by our program should be cleanly identified: I propose simply highlighting each component.
• From there, the program should allow a text dump (or whatever is the standard for DNA work).

A client-server model might be possible, allowing the server to do the bulk of the work. If it's not terribly intensive, it can be kept entire client-side, which would be ideal if it can hit our target platform(s). If it is a client-server program, an API should be exposed that sends off the final sequence as JSON, XML, or plaintext (depending on what is needed).

The actual algorithms are better described in the documentation that was given and those should be referred to first: I am just proposing these as design guidelines based on what we discussed in the meeting on Sunday, June 2nd.