Andrew Hessel

Hi!

I'm Andrew Hessel. I am one of the ambassadors with the iGEM program, working with Randy Rettberg.

iGEM Ambassador Information

Randy has created the iGEM ambassador program to help support the growing number of iGEM teams. While there's no fixed job description, our goal is to assist the participating groups in any way we can, keep information flowing, and help behind the scenes.

My immediate goals are to:

• absorb the current iGEM philosophies and goals
• master the wiki (it's fun!)
• review previous iGEM teams and projects
• determine which teams I will be responsible for and contact with them
• improve documentation
• improve the registry
• help streamline backend workflow
• think about ways to grow and enhance everything iGEM related!

Contact Information

Here's how to reach me:

email : ahessel (at) gmail (dot) com

IM: sailingandrew (at) hotmail (dot) com or google chat.

Skype: search for ahessel (at) gmail (dot) com or 'beakerandrew' (24 hours)

home: 416.848.1725 (not after 11 pm EST)

cell: 416.834.8310 (24 hours)

Personal Blurb

My interest in synthetic biology stems from work I did in the early 1990's. I studied the genomes of and collated the available sequence information for various Salmonella species, creating genomic maps. But I wanted to do more than just decipher genomes. I wanted to create them, yet there was no practical way to write DNA code. I've had an eye on developments leading to this ever since.

The technology for writing DNA is growing more reliable and affordable every day. As genetic work shifts to being synthesized de novo we can expect to the appearance of a different sort of biology, and a different biological scientist. iGEM is important because it plants the seeds for this new field. And that's very cool.

Comments on the Registry

(Initial thoughts... Comments welcome!)

Overall objective:

Make the iGEM registry logical, intuitive, and a useful resource to reseachers wanting to build GEMs or visitors wanting to explore the documentation, data, and tools.

Note: These comments are not meant to address the data collected for parts, devices, or systems in the iGEM registry. I have been reviewing the GO (gene ontology) site and considering how an ontology might be created for iGEM. These comments address some relatively straightforward reorganizations of the current data and website.

Registries in General:

A registry is only valuable if it organizes the material it contains. The registry must be kept clean and organized, have useful and easy-to-understand assembly tools, and high quality documentation and data.

The registry should:

• Organize data intuitively
• Make it easy for users or guests to "play", designing parts, devices, and systems
• Automatically clean up designs that are not promoted to synthesis or assembly (orphan sweep)
• Flag items stalled in synthesis or assembly, or that have not been physically received
• Prompt part owners to provide test, measurement, and other scoring data for completed items

Site Visitors:

Most visitors are presumed to be curious, first-time visitors not well versed in the ideas or tools of synthetic biology. (Is this true?) General information about the registry, including:

• What is this synthetic biology stuff?
• What is the registry about?
• What can it be used for?

is very important to seed interest and support for iGEM and SB. The registry documentation should be clear and assume a minimum of biological knowledge.

Login and Registration:

After reading this introductory material, new users may want to expore the tools and data further. Most users today may be part of an MIT-affiliated lab or an iGEM team but the site should not reinforce these constraints. The registration page should collect the necessary information required to keep accurate construction records about the parts, systems, and devices the users create. Physical, real-world address information is important for all users that wish to request synthesis or assemblies, since these will require shipping labels. Guest accounts should not have the ability to promote projects beyond the design stage; only minimal guest user information, eg. a verified email address, would be collected.

Parts, Devices, and Systems:

The abstraction hierarchy outlined in Parts, Devices, and Systems is important, yet the registry does not clearly subscribe to this architecture. The icon menu at the top of the page lists various parts categories (eg. RBS) then confusingly jumps to composites, projects, or unrelated heading like "cell" or "plasmid". More thought that goes into the organization of the registry and the icon bar. Perhaps Parts, Designs, and Systems could be made more fundamental in how the data is presented to users.

Parts (discrete, non-reducible components)

Categories:

a. Designs only

b. Designed and synthesized

c. Designed, synthesized, and used in at least 1 assembly (RE sites work, etc)

d. Designed, synthesized, used in assembly, and tested/measured

e. Intermediates stages (used for tracking purposes)

Comments

1. 'Designs only' should be regularly swept (no need to delete permanently, just make them away).
2. Designed and synthesized should be linked to a physical location of the part. If no part can be found in the registry freezer, the record should be swept.
3. Intermediates should be flagged if stalled.
4. Parts that are synthesized but not assembled should be QC'd by the registry (test assembly).
5. Wherever possible, test and measurement data should be recorded for the part. Users should also be asked to score the part so that ranking data can be generated.

Devices (combinations of 2 or more parts):

Categories:

a. Designs only

b. Designed and assembled

c. Designed, assembled, and tested/measured

d. Intermediates

Comments

1. In process categories should be reviewed regularly.
2. Designs and intermediates should be swept or reviewed regularly, as necessary.
3. Test and measurement data should include scoring system for ranking
4. Devices made but not tested should generate email prompts to the owner of record or subsequent users for accurate record keeping.

Systems (combinations of 2 or more devices) Similar to Device categories

Misc. stylistic comments:

• The 'About the registry' page needs to be updated
• The page headers are inconsistent in the different menus
• The references, glossary, FAQ and Links all need revision or enhancement
• Why is parts2.mit.edu and parts.mit.edu both maintained? The assembly tool in parts.mit.edu has an error message -- not ideal since this is the primary site
• The registration page should be updated and expanded to collect more data