[BBF Standards] Standards Digest, Vol 5, Issue 4
J. Christopher Anderson
jcanderson2167 at gmail.com
Sun May 4 00:13:21 EDT 2008
There have been some questions about what exactly the BBb or "Biobricks
Extreme" format is, so I've added a formal definition of the standard on the
openwetware site. I describe it again at the end of this message.
I throw this out there as an observation rather than a recommendation, but
you *could* define a "sub-standard" of BBb that was a Biobricks
1.0-compatible protein fusion standard that looked like:
EcoRI-XbaI-BglII-part-BamHI-SpeI-PstI
Such parts would be fully BBb compliant, but would not be compatible with
the AgeI/NgoMIV format.
I do think it would be prudent to generally suggest that when making basic
parts by total synthesis, all restriction sites needed for known technical
standards be eliminated from parts as Reshma has done with her vector
assembly parts. As long as there aren't internal restriction sites in a
part, it's pretty trivial to convert between formats.
We are developing BBb standard assembly methods with the premise that it
will be a next-generation standard. We currently use it for many of our
projects, but we appreciate that today there is no clear motivation for
anyone to switch to it. Once our methods have matured to the point where
there are clear motivations for people to convert, we will provide a
significant number of parts in the format to encourage its use. Today,
however, it is not particularly better or worse than other methods, the
sequences cannot be easily represented in the Registry, and the scope of the
part collection is far less than Biobricks 1.0. On these practical grounds,
it seems inevitable that most projects for iGEM2008 will be done in
Biobricks 1.0-compatible formats.
Until some method, be it an idempotent assembly method, a PCR-based method,
or a total synthesis method becomes sufficiently affordable, accurate, and
fast that assembly is not the limiting step in our projects, I hope that our
field will remain open minded about different synthesis methods and embrace
iGEM projects done by alternative methods of assembly.
-Chris
=== The BBb Format ===
BBb is used by several researchers at UC Berkeley and is based on idempotent
assembly with BamHI and BglII restriction enzymes. In a nutshell, most
plasmids look like this:
GAATTCatgAGATCT-part-GGATCCtaaCTCGAG
and BBb scars are "GGATCT" encoding gly-ser when translated in frame. Note,
however, that BBb is intended as a minimal physical assembly standard, and
only those features needed for interconversion of BBb plasmids are formally
defined. Therefore, "atg" and "taa" spacers are not core definitions of the
standard.
'''Formal Definition:'''
*A BBb part is a DNA sequence flanked on the 5' end by "GATCT" and on the 3'
end by "G" lacking BglII, BamHI, EcoRI, and XhoI restriction sites
*A BBb vector is a DNA sequence flanked on its 5' end by "GATCC" and on its
3' end by "A"
*A BBb entry vector has a unique EcoRI site, no BamHI or BglII restriction
sites, and at most one XhoI site 5' to the EcoRI site
*A BBb plasmid is represented as <vector_name>-<part_name> and has the
sequence obtained by concatenating the vector and part sequences
*Further definition constraints are "sub-standards" of the BBb format
On Sat, May 3, 2008 at 4:00 PM, <standards-request at biobricks.org> wrote:
> Send Standards mailing list submissions to
> standards at biobricks.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://biobricks.org/mailman/listinfo/standards_biobricks.org
> or, via email, send a message with subject or body 'help' to
> standards-request at biobricks.org
>
> You can reach the person managing the list at
> standards-owner at biobricks.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Standards digest..."
>
>
> Today's Topics:
>
> 1. housecleaning for physical assembly (Drew Endy)
> 2. Re: housecleaning for physical assembly (Drew Endy)
> 3. Re: housecleaning for physical assembly (Raik Gruenberg)
> 4. Re: housecleaning for physical assembly (Drew Endy)
> 5. Re: housecleaning for physical assembly (Drew Endy)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 3 May 2008 14:44:36 -0400
> From: Drew Endy <endy at MIT.EDU>
> Subject: [BBF Standards] housecleaning for physical assembly
> To: standards at biobricks.org
> Message-ID: <1FEE33FC-85E0-4689-9942-21D4AABA6A6F at mit.edu>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> Folks,
>
> We need to sort out the assembly standard for physical composition of
> BioBrick parts. There are now many schemes, some of which have been
> formally described, some that have been widely adopted, and others
> that are lurking.
>
> The reason that it would be good to sort this issue out now is that
> iGEM 2008 will start next month, and the teams would benefit from
> being able to build to and use the best possible standard that
> supports reliable physical assembly of BioBrick parts.
>
> Please take a look at this website:
>
> http://openwetware.org/wiki/The_BioBricks_Foundation:Standards/Technical/Formats
>
> which summarizes the details and strengths and weaknesses of all the
> current schemes except for UCSF and UC Berkeley (this information
> needs to be added).
>
> Should we move from the classic format to the Freiburg format or to
> the Berkeley Extreme format, for example?
>
> Your thoughts please,
> Drew
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 3 May 2008 17:55:06 -0400
> From: Drew Endy <endy at MIT.EDU>
> Subject: Re: [BBF Standards] housecleaning for physical assembly
> To: "Kim de Mora" <kim.demora at gmail.com>
> Cc: standards at biobricks.org
> Message-ID: <AD4785BC-B289-4450-A83D-A442EE9CF77D at mit.edu>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> Thanks Kim,
>
> Great comments!
>
> What other thoughts or experiences do other folks have?
>
>
>
> On May 3, 2008, at 5:29 PM, Kim de Mora wrote:
>
> > Drew,
> >
> > I think it should obvious that the Biobrick 1.0 standard is not
> > what we want as it doesn't allow the construction of fusion
> > proteins. The silver Biofusion standard has its merits, but I fear
> > there may problems with the biochemistry of the scarring site. I
> > have successfully made functional fusion proteins with it. I also
> > believe that I'm having trouble with the scarring site blocking a
> > short import tag in my project. I'll know the results of this in a
> > few weeks.
> >
> > I like Raik's 3.0 Expression parts, although having longer tails
> > may lead to more difficult PCR's which could be a problem if you are
> > trying to make a yeast gene knockout construct. I also don't like
> > the incompatibility idea, although whatever we choose should be
> > implemented now before there are many more (yeast) Biobricks in the
> > registry. I'm going to make a naive suggestion: maybe an organism
> > specific Biobrick system that utilizes the least occurring sites
> > that can be made by fermentas? This would save time in one instance
> > and add much more in others...
> >
> > And finally I don't agree with the idea of suggesting an untested
> > standard. How many times have engineers said "it looks fine on
> > paper" only to discover the horrible truth out in the real world?
> > Thats my 2 cents worth. Cheers!
> >
> > Kim
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 04 May 2008 00:36:40 +0200
> From: Raik Gruenberg <raik.gruenberg at crg.es>
> Subject: Re: [BBF Standards] housecleaning for physical assembly
> To: Drew Endy <endy at MIT.EDU>
> Cc: standards at biobricks.org, Kim de Mora <kim.demora at gmail.com>
> Message-ID: <481CE8F8.5020400 at crg.es>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Drew, Hi Kim,
>
> thanks for this comment, this is indeed becoming an urgent topic!
> Obviously, I am endorsing the Freiburg Standard, not least because I have
> already ordered a set of Biobricks in this standard ;-)
>
> The main advantage over the other suggestions out there is that it
> delivers
> pretty much full compatibility to 1.0. That is, Freiburg Expression parts
> behave
> like protein coding 1.0 parts and can as such be combined with 1.0
> promoters and
> RBS etc. without any surprises.
>
> The downside is that it has so far only been used by one lab (the Freiburg
> guys)
> who however tell me that they are still using it and didn't come across
> any
> difficulties. They are not using 3A assembly though (I will try out the 3A
> assembly as soon as my order arrives, towards end of May.)
>
> Another issue is that real backwards compatibility is only given if the
> Expression part indeed does not contain neither the 3.0 *nor* the 1.0
> restriction sites -- that means we have 6 rather than 4 forbidden sites.
>
> I am less convinced of organism-specific formats. Protein biobricks can
> often be
> used unchanged in different organisms -- for example, some gene synthesis
> companies routinely offer simultaneous yeast + human codon optimization.
> The
> idea to minimize native restriction sites is attractive but (1) we don't
> have
> that many choices of enzyme pairs with compatible overhang and nice scar
> to
> start with and (2) when manipulating one organism one may often want to
> use
> (orthogonal) protein parts from another organism.
>
> A final possibility would be to produce a hybrid of the Freiburg and the
> Berkeley format -- using the Freiburg compatibility prefix/suffix but
> replacing
> NgoMIV and AgeI by the Berkeley enzymes. If Berkeley has kept the outer
> enzymes
> of 1.0, this format would have the same compatibility advantage as the
> Expression part proposal. Lacking documentation of the Berkeley format, I
> can't
> really verify this. I was told the Berkeley scar is Gly-Ser, which is a
> routine
> flexible linker for protein domains. Some may argue it is even too
> flexible
> (forcefully helix breaking) but it is indeed very commonly used.
>
> A last advantage of the Freiburg pair of inner enzymes is that there is a
> blunt
> cutting isoschizomers for one of them. This means one can excise a part
> and
> directionally transfer it into another format with minimal added spacer.
> I'll
> try to transfer some of my Biobricks into a Biofusion compatibility vector
> using
> this strategy (see last section of the WIKI).
>
> Ah, and a very last little advantage: there is a Zinc finger library out
> there
> that uses the same restriction sites because Zinc fingers turn out to have
> Thr-Gly in their natural linker. Now this is a very special-purpose
> advantage
> but two colleagues of mine are actually quite thrilled about that and want
> to
> switch their Zinc finger projects to Freiburg Biobrick cloning. (well,
> more
> generally this example rather argues for a seamless Biobrick cloning
> strategy
> like it seems to be possible with BB++).
>
> Greetings,
> Raik
>
> >> I think it should obvious that the Biobr
> ick 1.0 standard is not
> >> what we want as it doesn't allow the construction of fusion
> >> proteins. The silver Biofusion standard has its merits, but I fear
> >> there may problems with the biochemistry of the scarring site. I
> >> have successfully made functional fusion proteins with it. I also
> >> believe that I'm having trouble with the scarring site blocking a
> >> short import tag in my project. I'll know the results of this in a
> >> few weeks.
> >>
> >> I like Raik's 3.0 Expression parts, although having longer tails
> >> may lead to more difficult PCR's which could be a problem if you are
> >> trying to make a yeast gene knockout construct. I also don't like
> >> the incompatibility idea, although whatever we choose should be
> >> implemented now before there are many more (yeast) Biobricks in the
> >> registry. I'm going to make a naive suggestion: maybe an organism
> >> specific Biobrick system that utilizes the least occurring sites
> >> that can be made by fermentas? This would save time in one instance
> >> and add much more in others...
> >>
> >> And finally I don't agree with the idea of suggesting an untested
> >> standard. How many times have engineers said "it looks fine on
> >> paper" only to discover the horrible truth out in the real world?
> >> Thats my 2 cents worth. Cheers!
> >>
> >> Kim
> >
> >
> > _______________________________________________
> > Standards mailing list
> > Standards at biobricks.org
> > http://biobricks.org/mailman/listinfo/standards_biobricks.org
> >
>
> --
> ________________________________
>
> Dr. Raik Gruenberg
> http://www.raiks.de/contact.html
> ________________________________
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 3 May 2008 18:53:16 -0400
> From: Drew Endy <endy at MIT.EDU>
> Subject: Re: [BBF Standards] housecleaning for physical assembly
> To: Raik Gruenberg <raik.gruenberg at crg.es>
> Cc: standards at biobricks.org
> Message-ID: <0FA1985E-CEE5-4AF9-B4C9-BFD0A2A36E1C at MIT.EDU>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> Raik,
>
> More great comments. Note that your newly ordered set of parts aren't
> BioBrick parts (at least not yet, until we can get this standard
> issues settled).
>
> What are other people thinking? What other experiences do folks
> have? Anybody from Berkeley want to chime in? And, TK?
>
> Thanks,
> Drew
>
> On May 3, 2008, at 6:36 PM, Raik Gruenberg wrote:
>
> > Hi Drew, Hi Kim,
> >
> > thanks for this comment, this is indeed becoming an urgent topic!
> > Obviously, I am endorsing the Freiburg Standard, not least because I
> > have already ordered a set of Biobricks in this standard ;-)
> >
> > The main advantage over the other suggestions out there is that it
> > delivers pretty much full compatibility to 1.0. That is, Freiburg
> > Expression parts behave like protein coding 1.0 parts and can as
> > such be combined with 1.0 promoters and RBS etc. without any
> > surprises.
> >
> > The downside is that it has so far only been used by one lab (the
> > Freiburg guys) who however tell me that they are still using it and
> > didn't come across any difficulties. They are not using 3A assembly
> > though (I will try out the 3A assembly as soon as my order arrives,
> > towards end of May.)
> >
> > Another issue is that real backwards compatibility is only given if
> > the Expression part indeed does not contain neither the 3.0 *nor*
> > the 1.0 restriction sites -- that means we have 6 rather than 4
> > forbidden sites.
> >
> > I am less convinced of organism-specific formats. Protein biobricks
> > can often be used unchanged in different organisms -- for example,
> > some gene synthesis companies routinely offer simultaneous yeast +
> > human codon optimization. The idea to minimize native restriction
> > sites is attractive but (1) we don't have that many choices of
> > enzyme pairs with compatible overhang and nice scar to start with
> > and (2) when manipulating one organism one may often want to use
> > (orthogonal) protein parts from another organism.
> >
> > A final possibility would be to produce a hybrid of the Freiburg and
> > the Berkeley format -- using the Freiburg compatibility prefix/
> > suffix but replacing NgoMIV and AgeI by the Berkeley enzymes. If
> > Berkeley has kept the outer enzymes of 1.0, this format would have
> > the same compatibility advantage as the Expression part proposal.
> > Lacking documentation of the Berkeley format, I can't really verify
> > this. I was told the Berkeley scar is Gly-Ser, which is a routine
> > flexible linker for protein domains. Some may argue it is even too
> > flexible (forcefully helix breaking) but it is indeed very commonly
> > used.
> >
> > A last advantage of the Freiburg pair of inner enzymes is that there
> > is a blunt cutting isoschizomers for one of them. This means one can
> > excise a part and directionally transfer it into another format with
> > minimal added spacer. I'll try to transfer some of my Biobricks into
> > a Biofusion compatibility vector using this strategy (see last
> > section of the WIKI).
> >
> > Ah, and a very last little advantage: there is a Zinc finger library
> > out there that uses the same restriction sites because Zinc fingers
> > turn out to have Thr-Gly in their natural linker. Now this is a very
> > special-purpose advantage but two colleagues of mine are actually
> > quite thrilled about that and want to switch their Zinc finger
> > projects to Freiburg Biobrick cloning. (well, more generally this
> > example rather argues for a seamless Biobrick cloning strategy like
> > it seems to be possible with BB++).
> >
> > Greetings,
> > Raik
> >
> >>> I think it should obvious that the Biobr
> > ick 1.0 standard is not
> >>> what we want as it doesn't allow the construction of fusion
> >>> proteins. The silver Biofusion standard has its merits, but I
> >>> fear there may problems with the biochemistry of the scarring
> >>> site. I have successfully made functional fusion proteins with
> >>> it. I also believe that I'm having trouble with the scarring
> >>> site blocking a short import tag in my project. I'll know the
> >>> results of this in a few weeks.
> >>>
> >>> I like Raik's 3.0 Expression parts, although having longer tails
> >>> may lead to more difficult PCR's which could be a problem if you
> >>> are trying to make a yeast gene knockout construct. I also don't
> >>> like the incompatibility idea, although whatever we choose should
> >>> be implemented now before there are many more (yeast) Biobricks
> >>> in the registry. I'm going to make a naive suggestion: maybe an
> >>> organism specific Biobrick system that utilizes the least
> >>> occurring sites that can be made by fermentas? This would save
> >>> time in one instance and add much more in others...
> >>>
> >>> And finally I don't agree with the idea of suggesting an
> >>> untested standard. How many times have engineers said "it looks
> >>> fine on paper" only to discover the horrible truth out in the
> >>> real world? Thats my 2 cents worth. Cheers!
> >>>
> >>> Kim
> >> _______________________________________________
> >> Standards mailing list
> >> Standards at biobricks.org
> >> http://biobricks.org/mailman/listinfo/standards_biobricks.org
> >
> > --
> > ________________________________
> >
> > Dr. Raik Gruenberg
> > http://www.raiks.de/contact.html
> > ________________________________
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 3 May 2008 19:00:21 -0400
> From: Drew Endy <endy at MIT.EDU>
> Subject: Re: [BBF Standards] housecleaning for physical assembly
> To: standards at biobricks.org
> Message-ID: <0466007E-6B02-4C57-86E3-5B34677876B1 at mit.edu>
> Content-Type: text/plain; charset="utf-8"
>
> As background for this thread... Reshma Shetty just published a paper
> on some new BioBrick vectors (http://www.jbioleng.org/content/2/1/5).
> In designing and synthesizing the new vector parts she worked to
> remove many restriction endonuclease sites. From her article...
>
> "To adhere to the BioBrick standard for physical composition, BioBrick
> vector parts need only be free of the BioBrick restriction enzyme
> sites. However, we chose to design anew all BioBrick vector parts
> (Figure 5), so that we could completely specify their DNA sequences.
> We compiled a list of potentially useful endonuclease sites for
> removal from all new BioBrick vector parts (Table 1). We targeted each
> group of endonuclease sites for removal for a di?erent reason. We
> targeted recognition sites of enzymes that produce compatible cohesive
> ends to the BioBrick enzymes because such enzymes often prove useful
> in constructing new variants of BioBrick vectors. We targeted o?set
> cutter sites because they may be useful in alternative restriction
> enzyme-based assembly methods [57]. We targeted homing endonuclease
> sites because they are commonly used in genome engineering [58]. We
> targeted some nicking endonuclease sites because they can be useful
> for specialized cloning applications [59]. Finally, we targeted
> several additional restriction endonuclease sites to keep them
> available for use by new standards for physical composition. Our list
> of endonuclease sites constitutes a set of target sequences that
> should be considered for removal from any newly synthesized BioBrick
> part, if possible. The target sequence set will change as the
> synthetic biology community develops new standards for physical
> composition of BioBrick parts. Some of the targeted endonuclease sites
> were naturally absent from the DNA sequences encoding our new vector
> parts. For any remaining sites, we removed the recognition sequences
> from the BioBrick vector parts by introducing point mutations.
> However, the functions of the pSC101 and pUC19-derived plasmid
> replication origins were sensitive to introduced mutations, so the
> replication origins used in this work are not free of all targeted
> endonuclease sites (see Methods). Similarly, issues during synthesis
> led to an unnecessary redesign of the ccdB positive selection marker,
> so it too is not free of all targeted endonuclease sites."
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Picture 1.png
> Type: image/png
> Size: 62557 bytes
> Desc: not available
> Url :
> http://biobricks.org/pipermail/standards_biobricks.org/attachments/20080503/54b44c6c/attachment.png
> -------------- next part --------------
>
>
>
>
>
> On May 3, 2008, at 6:53 PM, Drew Endy wrote:
> > Raik,
> >
> > More great comments. Note that your newly ordered set of parts aren't
> > BioBrick parts (at least not yet, until we can get this standard
> > issues settled).
> >
> > What are other people thinking? What other experiences do folks
> > have? Anybody from Berkeley want to chime in? And, TK?
> >
> > Thanks,
> > Drew
> >
> > On May 3, 2008, at 6:36 PM, Raik Gruenberg wrote:
> >
> >> Hi Drew, Hi Kim,
> >>
> >> thanks for this comment, this is indeed becoming an urgent topic!
> >> Obviously, I am endorsing the Freiburg Standard, not least because I
> >> have already ordered a set of Biobricks in this standard ;-)
> >>
> >> The main advantage over the other suggestions out there is that it
> >> delivers pretty much full compatibility to 1.0. That is, Freiburg
> >> Expression parts behave like protein coding 1.0 parts and can as
> >> such be combined with 1.0 promoters and RBS etc. without any
> >> surprises.
> >>
> >> The downside is that it has so far only been used by one lab (the
> >> Freiburg guys) who however tell me that they are still using it and
> >> didn't come across any difficulties. They are not using 3A assembly
> >> though (I will try out the 3A assembly as soon as my order arrives,
> >> towards end of May.)
> >>
> >> Another issue is that real backwards compatibility is only given if
> >> the Expression part indeed does not contain neither the 3.0 *nor*
> >> the 1.0 restriction sites -- that means we have 6 rather than 4
> >> forbidden sites.
> >>
> >> I am less convinced of organism-specific formats. Protein biobricks
> >> can often be used unchanged in different organisms -- for example,
> >> some gene synthesis companies routinely offer simultaneous yeast +
> >> human codon optimization. The idea to minimize native restriction
> >> sites is attractive but (1) we don't have that many choices of
> >> enzyme pairs with compatible overhang and nice scar to start with
> >> and (2) when manipulating one organism one may often want to use
> >> (orthogonal) protein parts from another organism.
> >>
> >> A final possibility would be to produce a hybrid of the Freiburg and
> >> the Berkeley format -- using the Freiburg compatibility prefix/
> >> suffix but replacing NgoMIV and AgeI by the Berkeley enzymes. If
> >> Berkeley has kept the outer enzymes of 1.0, this format would have
> >> the same compatibility advantage as the Expression part proposal.
> >> Lacking documentation of the Berkeley format, I can't really verify
> >> this. I was told the Berkeley scar is Gly-Ser, which is a routine
> >> flexible linker for protein domains. Some may argue it is even too
> >> flexible (forcefully helix breaking) but it is indeed very commonly
> >> used.
> >>
> >> A last advantage of the Freiburg pair of inner enzymes is that there
> >> is a blunt cutting isoschizomers for one of them. This means one can
> >> excise a part and directionally transfer it into another format with
> >> minimal added spacer. I'll try to transfer some of my Biobricks into
> >> a Biofusion compatibility vector using this strategy (see last
> >> section of the WIKI).
> >>
> >> Ah, and a very last little advantage: there is a Zinc finger library
> >> out there that uses the same restriction sites because Zinc fingers
> >> turn out to have Thr-Gly in their natural linker. Now this is a very
> >> special-purpose advantage but two colleagues of mine are actually
> >> quite thrilled about that and want to switch their Zinc finger
> >> projects to Freiburg Biobrick cloning. (well, more generally this
> >> example rather argues for a seamless Biobrick cloning strategy like
> >> it seems to be possible with BB++).
> >>
> >> Greetings,
> >> Raik
> >>
> >>>> I think it should obvious that the Biobr
> >> ick 1.0 standard is not
> >>>> what we want as it doesn't allow the construction of fusion
> >>>> proteins. The silver Biofusion standard has its merits, but I
> >>>> fear there may problems with the biochemistry of the scarring
> >>>> site. I have successfully made functional fusion proteins with
> >>>> it. I also believe that I'm having trouble with the scarring
> >>>> site blocking a short import tag in my project. I'll know the
> >>>> results of this in a few weeks.
> >>>>
> >>>> I like Raik's 3.0 Expression parts, although having longer tails
> >>>> may lead to more difficult PCR's which could be a problem if you
> >>>> are trying to make a yeast gene knockout construct. I also don't
> >>>> like the incompatibility idea, although whatever we choose should
> >>>> be implemented now before there are many more (yeast) Biobricks
> >>>> in the registry. I'm going to make a naive suggestion: maybe an
> >>>> organism specific Biobrick system that utilizes the least
> >>>> occurring sites that can be made by fermentas? This would save
> >>>> time in one instance and add much more in others...
> >>>>
> >>>> And finally I don't agree with the idea of suggesting an
> >>>> untested standard. How many times have engineers said "it looks
> >>>> fine on paper" only to discover the horrible truth out in the
> >>>> real world? Thats my 2 cents worth. Cheers!
> >>>>
> >>>> Kim
> >>> _______________________________________________
> >>> Standards mailing list
> >>> Standards at biobricks.org
> >>> http://biobricks.org/mailman/listinfo/standards_biobricks.org
> >>
> >> --
> >> ________________________________
> >>
> >> Dr. Raik Gruenberg
> >> http://www.raiks.de/contact.html
> >> ________________________________
> >
> >
> > _______________________________________________
> > Standards mailing list
> > Standards at biobricks.org
> > http://biobricks.org/mailman/listinfo/standards_biobricks.org
>
>
> ------------------------------
>
> _______________________________________________
> Standards mailing list
> Standards at biobricks.org
> http://biobricks.org/mailman/listinfo/standards_biobricks.org
>
>
> End of Standards Digest, Vol 5, Issue 4
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://biobricks.org/pipermail/standards_biobricks.org/attachments/20080503/0643c2de/attachment-0001.html
More information about the Standards
mailing list