Exciting times!

Currently, I’m working on Brickit. If you are interested in development, check out the quick install guide for Debian/Ubuntu or Mac OS X

Raik Gruenberg - BrickIt: An open source solution for local BioBrick management

Raik drank the BioBrick cool-aid and decided he loved it.  He ended up with hundreds of biobricks in different assemblies in his freezer - and disappointed the Registry at MIT didn’t help him keep track of their physical location.

So he built a tool to help track of local sample: BrickIt

Check it out and improve it - we sure will.  Let’s install a public version - we’ll just need to fix up some new views and perhaps implement some kind of user management & authentication system. 

Jean Peccoud - From Registries to an IDE of genetic systems

Analyzed MIT registry to try and visualize the abstraction hierarchy at work by finding inclusion of sequences in other sequences: i.e. compositions.  Lots of surprising stuff - “devices” [not sure how they categorized parts into devices] being used in compositions with basic parts, and no more than a few parts used in more than 10 compositions.

Parts Warehoue - how do you actually manage a bunch of clones?  Jean’s team sequenced the 2007 iGEM parts kit (I made all of them) and found that 471 of the wells contained undocumented DNA, 1011 contained documented DNA, and 7 contained no DNA (I’m curious how many contained the *wrong* DNA).

One business model for the Warehouse might be to have the submitter pay a submission fee for adding a part to the DNA registry to keep it maintained and to enable its reuse.

Main idea: Lack of clear understanding of what’s a part?  Basic parts / atomic parts particularly important.  IDE: develop problem-dependant design strategies, and dream of a portable and abstract description language.

Ralph Santos - PICA (part interaction and Composition Assertion)

A Composable template to describe parts in a loose way.  Abstraction vs. Models: all A are M, but not all M are A.  But let’s describe parts/devices in terms of terminals and state spaces - the terminals describe the input and output, how it interacts with the world.  See PICA

Andrew Miller - CellML for modeling Synthetic Biology

CellML is a community effort, and has a process to get people involved (with a public issue tracker).  Drafts are developed by contributors and shared and discussed early and often.  CellML is an XML language.  It’s useful for exchange b/w programs and researchers, but not a good human-computer interface.  Tools and input languages are the solution there.  CellML models can be broken into components, which themselves represent variables. The core requires all units be specified for real number variables and constants. Models can be composed by importing components from other CellML files.  This lends itself to a library or registry of models, perhaps the models associated with a collection of biobricks.

Michael Pederson LBS - Textual description language for modeling synthetic biology.

LBS is a text based description language that lets you define parallel modules of sequential processes, as reaction rates of various species.  Species have typed parameters (i.e. “is this species phosphorylated?”)  You can define typed patterns that identify specific species, with types, and then modules that relate the transition from pattern to the next.

LBS currently is defined as a language syntax and semantics, and a current project is to compile LBS to petri nets or CellML models.

Questions: is it possible to compile a high-level model (like LBS) down to specific BioBricks?  For this, we’d need a formal model of the BBs’ semantics.

9:08a: Herbert Sauro just finished his opening remarks

9:10a: Raik is explaining modularity and hierarchies in life:

• atoms > residues > domains > proteins > assemblies > organelles > cells >
• Whenever we learn to control and manipulate one of these layers, we learn a lot about the next layer.
• Natural systems have evolved into functional modules, but ones that often integrate with each other in practicality (protein domains interacting with one another)

• Standardization
• Decoupling
• Abstraction
• Free Exchange (of modules)

It’s a Party!  Go check it out!  TinySeq.com

Also, we made some awesome biobrick hero shirts to wear during our talk - pictures tomorrow!

In the meantime, check out this recently unearthed archival photo of the original BioBrick Hero himself, Tom Knight:

The main entity that Bricklet helps share, search, organize and revision is the hybrid part - device document. We tried compound names for this document, like “partvice” or “depart” or “dart”, but decided to call it a bricklet instead, to maximize confusion and our egos.  So here’s our nomenclature: Bricklet = software for managing bricklets.

Think of a bricklet as a unified view of all the information and versions and sequences that could be grouped together with a part or device.  Someday, when we have well-defined and measurable functional interfaces for connecting biological devices, it may be more appropriate to enforce a stronger dichotomy between a physical part as a piece of dna and its abstract functional identity, but for now we think the grab-bag approach will be a great intermediate until we get there.

However, a little markup goes a long way, and we’re asking users to put some general annotations on the parts’ attributes and relationships.  That lets the software help keep things organized and helps a user search for parts in a way that’s stronger than a fulltext search over wildly heterogeneous documents.

The Bricklet project consists of a Part Description Language and a Part Sharing Framework. Here are some core concepts from the Part Description Language.

Parts vs. Devices:

• Parts are expected to be structurally composed with other parts

• Devices have well defined conceptual interfaces and might be comprised of parts or devices, but they don’t require structural connection

• Structural Interfaces define physical composition standards and are strongly typed (i.e. the BBa standard)

• Conceptual Interfaces informally describe device function. Practically they are unitless words. A fluorescent device might output Light, or Photons, or Fluorescence Units, etc. We will implement features like autocomplete to help users be as consistent as possible with these. (We expect to describe device interfaces more and more strictly as measurement standards are developed)

• Plasmids are supported as composite parts, comprised of modular plasmid elements like ori, amp, and ccdb (perhaps built with a different construction interface). Part instances are contained by plasmids (usually) and also have a physical location (well coordinates, freezer, lab, institution, etc.)

Bricklet’s first success, BBa:LOLPOP1

We hope that the loosely-typed description of a device’s input and output will sidestep (for now) the fact that there are basically no measurement standards for devices yet. This will allow people to identify conceptually what the input and output of a device is without having any idea how it could be measured - i.e. BBa:F2620 AHL -> PoPS. At a minimum this should enable bricklet to suggest device combinations and lists of functionally similar devices based on the stated interfaces.

An important takeaway is that conceptual interfaces are annotated as strictly as is useful, but aren’t expected to be unrealistically strict.

This enables great features, like the ability to accurately search parts based on function. For example:

• All visible reporters.
• All parts that take AHL as an input.
• All the parts that could interact with the one I’m looking at right now.

It also helps guide you when making functional relationships, as relating A to B means that the type of A’s output is compatible with the type of B’s input.

Since people will not spontaneously decide to use the same types (units) as everyone else, types can have relationships between them, too. For example, GFP is a fluorescent protein, which is something that produces light, which is more or less the same thing as photons or lumens. As such, when you search for light-emitting parts, the search results include parts that were described as producing GFP.

We are managing our development over at the Bricklet page on Google Code, so stop on by and check out the wiki. As we draw closer to the end of April, preliminary versions of code should be available there, too.