BBF RFC 20 - Revision history

Austin J. Che at 18:45, 4 April 2009

2009-04-04T18:45:25Z

←Older revision		Revision as of 18:45, 4 April 2009
Line 1:		Line 1:
		+	The RFC is at http://hdl.handle.net/1721.1/44962
		+
		+	Comments are on this page
		+
	==[[Special:Emailuser/Raik\|Raik]] 03 April 2009==		==[[Special:Emailuser/Raik\|Raik]] 03 April 2009==

Austin J. Che at 18:33, 4 April 2009

2009-04-04T18:33:16Z

Austin J. Che at 15:54, 4 April 2009

2009-04-04T15:54:36Z

←Older revision		Revision as of 15:54, 4 April 2009
Line 32:		Line 32:
	'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''		'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''

-	There are ~~four~~ types of assemblies:	+	* '''[[User:Austin J. Che\|Austin Che]] 11:54, 4 April 2009 (EDT)''': I'm not sure how having more restriction enzymes reduces the benefit. This isn't a tradeoff between not having to do any mutagenesis and having to do more than one mutagenesis, but rather how many changes you have to make. If you have a PstI site in your promoter that you just can't mutate, you sure don't care if your assembly standard contains 3 restriction enzymes or 5 as long as it doesn't use PstI. Again, making construction vectors is ''really'' easy. Many people, including yourself it seems, are making construction vectors by PCR. This would simply be using a different set of primers.
		+
		+	There are five types of assemblies:
	# RFC 10 part with RFC 10 part -> RFC 10 part		# RFC 10 part with RFC 10 part -> RFC 10 part
	# RFC 10 part with RFC 20 part -> RFC 20 part		# RFC 10 part with RFC 20 part -> RFC 20 part
	# RFC 20 part with RFC 10 part -> RFC 10 part *		# RFC 20 part with RFC 10 part -> RFC 10 part *
	# RFC 20 part with RFC 20 part -> RFC 20 part		# RFC 20 part with RFC 20 part -> RFC 20 part
		+	# RFC 10 part -> RFC 20 part (explicit move)

	You bring up a good point about problems with assembly type 3 where		You bring up a good point about problems with assembly type 3 where

Raik: /* Austin Che 11:37, 3 April 2009 (EDT) */

2009-04-04T11:59:17Z

Austin Che 11:37, 3 April 2009 (EDT)

←Older revision		Revision as of 11:59, 4 April 2009
Line 168:		Line 168:
	should also provide the tools to do so. So they, first of all, will need vectors and		should also provide the tools to do so. So they, first of all, will need vectors and
	exact protocols.		exact protocols.
		+	'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''

	(5) I do not understand what you're saying here. Of course, RFC 20 is		(5) I do not understand what you're saying here. Of course, RFC 20 is
Line 176:		Line 177:
	derivatives.		derivatives.

-	~~'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''~~
	That's exactly what I am scared about: Your proposal is not only adding yet another format		That's exactly what I am scared about: Your proposal is not only adding yet another format
	to the current zoo but it actually will double the number of RFC 10 derived formats. If we		to the current zoo but it actually will double the number of RFC 10 derived formats. If we
Line 184:		Line 184:
	construction vectors. And we end up with a generation of young Synthetic Biologists that are		construction vectors. And we end up with a generation of young Synthetic Biologists that are
	going to be pretty allergic to the mentioning of the word "standard" ;-).		going to be pretty allergic to the mentioning of the word "standard" ;-).
		+	'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''

Raik: /* Austin Che 11:37, 3 April 2009 (EDT) */ Inline comments by Raik

2009-04-04T11:58:38Z

Austin Che 11:37, 3 April 2009 (EDT): Inline comments by Raik

←Older revision		Revision as of 11:58, 4 April 2009
Line 26:		Line 26:
	vectors is a one-time cost and there are less than 10 commonly used		vectors is a one-time cost and there are less than 10 commonly used
	plasmids.		plasmids.
		+
		+	On the other hand, there are still 3 other restriction enzymes to worry about
		+	(or 5 in the case of the Fusion format). So the benefit is not that big.
		+	Besides, right now, we don't have those construction vectors available, have we?
		+	'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''

	There are four types of assemblies:		There are four types of assemblies:
Line 35:		Line 40:
	You bring up a good point about problems with assembly type 3 where		You bring up a good point about problems with assembly type 3 where
	the RFC 20 part contains PstI sites because it produces a RFC 10 part.		the RFC 20 part contains PstI sites because it produces a RFC 10 part.
		+
		+	Unfortunately, if you mix several RFC 10 parts with several RFC 20 parts, then you are almost
		+	certainly going to encounter situation 3 somewhere along the chain of assembly reactions. So
		+	the problem is quite likely to occur during the assembly of larger constructs.
		+	'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''

	There are different transition plans depending on what an individual		There are different transition plans depending on what an individual
Line 107:		Line 117:
	enzyme to cut the different parts. But this is the choice of the user		enzyme to cut the different parts. But this is the choice of the user
	and the choice of the transition strategy.		and the choice of the transition strategy.
		+
		+	What I meant was that RFC 20 parts are not compatible with the RFC 10 assembly ''process''.
		+	You cannot any longer rely on RFC 20 parts to behave like RFC 10 parts during a chain of
		+	assembly reactions. RFC 20 parts can potentially poison your assembly with PstI sites,
		+	their suffix may be rejected by your automatic sequence check program, you have to verify
		+	the nature of your construction vectors, etc. pp.
		+	'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''

	(2) You can never get stuck. You are correct that if you have a PstI		(2) You can never get stuck. You are correct that if you have a PstI
Line 116:		Line 133:
	EcoRI/SpeI and transferring it into a RFC 20 plasmid. You now have		EcoRI/SpeI and transferring it into a RFC 20 plasmid. You now have
	yourself a fully compliant RFC 20 part.		yourself a fully compliant RFC 20 part.
		+
		+	OK, "stuck" is perhaps too strong a word. So there are workarounds to
		+	get out of this trap. But these workarounds require (1) that you are
		+	aware of the problem -- which is not completely trivial for iGem teams,
		+	(2) an extra cloning step and (3) may actually be required more than once
		+	during a chain of assembly reactions. Each extra cloning step throws you
		+	back by two or three extra days. Now that can be really annoying...
		+	'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''

	(3) Ordering new primers is cheap. The whole point of RFC 20 is that		(3) Ordering new primers is cheap. The whole point of RFC 20 is that
Line 122:		Line 147:
	need to be changed. They don't prime to the PstI site and thus they		need to be changed. They don't prime to the PstI site and thus they
	could be used as-is with a new destination vector.		could be used as-is with a new destination vector.
		+
		+	Point taken, in this particular case, the primers would still be valid.
		+	My concern was though that people may rely on the exact sequence for
		+	all kind of purposes. The outer part of the suffix is, so far, bullet-proof
		+	equal for all RFC 10 derived formats (BBa, Silver/BioFusion, Freiburg/Fusion).
		+	Some labs are toying with PCR and recombination-based assembly protocols and
		+	will probably not appreciate to have even more variations to worry about.
		+	'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''

	(4) Yes, you need to make new vectors. That's a one-time, easy to do		(4) Yes, you need to make new vectors. That's a one-time, easy to do
Line 130:		Line 163:
	you're making destination backbone via PCR, you may not need to do any		you're making destination backbone via PCR, you may not need to do any
	cloning other than order new primers.		cloning other than order new primers.
		+
		+	Yes, preparing the destination vector by PCR is an easy solution but, again, it may
		+	not work for everybody. If you actually recommend people to switch right now, you
		+	should also provide the tools to do so. So they, first of all, will need vectors and
		+	exact protocols.

	(5) I do not understand what you're saying here. Of course, RFC 20 is		(5) I do not understand what you're saying here. Of course, RFC 20 is
Line 137:		Line 175:
	enzymes are really "don't-cares" for RFC 10 and all its		enzymes are really "don't-cares" for RFC 10 and all its
	derivatives.		derivatives.
		+
		+	'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''
		+	That's exactly what I am scared about: Your proposal is not only adding yet another format
		+	to the current zoo but it actually will double the number of RFC 10 derived formats. If we
		+	go ahead with the transition, we end up with RFC 10 BioBricks, RFC 20 BioBricks, RFC 23 (Silver)
		+	BioBricks, RFC 25 (Freiburg) BioBricks, '''plus''' hybrid RFC 23/20 BioBricks, hybrid RFC 25/20
		+	BioBricks and odd double-hybrids where RFC 20 or RFC */20 BioBricks have ended up in RFC 10
		+	construction vectors. And we end up with a generation of young Synthetic Biologists that are
		+	going to be pretty allergic to the mentioning of the word "standard" ;-).

Austin J. Che at 15:37, 3 April 2009

2009-04-03T15:37:14Z

←Older revision		Revision as of 15:37, 3 April 2009
Line 1:		Line 1:
-	[[Special:Emailuser/Raik\|Raik]] 03 April 2009	+	==[[Special:Emailuser/Raik\|Raik]] 03 April 2009==

	RFC 20 is, in fact, NOT a relaxation of RFC 10 but rather breaks compatibility with both RFC 10 and all derived formats. Let me explain: Replacing PstI by SbfI-HF looks like a good idea because it reduces the number of cases where one has to mutate or synthesize the part DNA. SbfI-HF is chosen so that ''most'' parts adhering to RFC 10 would still be compatible with the classic PstI / EcoRI assembly. BUT, this is where the trouble starts:		RFC 20 is, in fact, NOT a relaxation of RFC 10 but rather breaks compatibility with both RFC 10 and all derived formats. Let me explain: Replacing PstI by SbfI-HF looks like a good idea because it reduces the number of cases where one has to mutate or synthesize the part DNA. SbfI-HF is chosen so that ''most'' parts adhering to RFC 10 would still be compatible with the classic PstI / EcoRI assembly. BUT, this is where the trouble starts:
Line 14:		Line 14:

	I think, in the current situation, the considerable downstream costs and complications of adopting RFC 20 would outweigh the added convenience. Right now, we should try to avoid a further degradation of the classic standard. RFC 20 would only be a temporary solution anyway, until we have settled on a next generation format that also solves the protein fusion issue. On the other hand, replacing PstI by SbfI-HF could indeed be a very useful idea for this future generation assembly standard.		I think, in the current situation, the considerable downstream costs and complications of adopting RFC 20 would outweigh the added convenience. Right now, we should try to avoid a further degradation of the classic standard. RFC 20 would only be a temporary solution anyway, until we have settled on a next generation format that also solves the protein fusion issue. On the other hand, replacing PstI by SbfI-HF could indeed be a very useful idea for this future generation assembly standard.
		+
		+	===[[User:Austin J. Che\|Austin Che]] 11:37, 3 April 2009 (EDT)===
		+	Thanks for your comments Raik. I'll respond to your different
		+	points but I'll first summarize my points.
		+
		+	I believe the adoption of RFC 20 is a good idea because it reduces
		+	experimental work and gives users more freedom in part
		+	design. Mutagenesis to remove restriction sites is one of the more
		+	time consuming steps of making a part. Adding two bases to make a SbfI
		+	site instead of a PstI when making a part is no extra work. Making new
		+	vectors is a one-time cost and there are less than 10 commonly used
		+	plasmids.
		+
		+	There are four types of assemblies:
		+	# RFC 10 part with RFC 10 part -> RFC 10 part
		+	# RFC 10 part with RFC 20 part -> RFC 20 part
		+	# RFC 20 part with RFC 10 part -> RFC 10 part *
		+	# RFC 20 part with RFC 20 part -> RFC 20 part
		+
		+	You bring up a good point about problems with assembly type 3 where
		+	the RFC 20 part contains PstI sites because it produces a RFC 10 part.
		+
		+	There are different transition plans depending on what an individual
		+	user wants. One of the advantages is that different users can choose
		+	different strategies for their sets of parts. The common elements of
		+	all the transition strategies is to always use a RFC 20 destination
		+	vector and always cut the prefix part with EcoRI/SpeI. The differences
		+	are whether to allow PstI sites in new RFC 20 parts, whether to
		+	proactively move parts into RFC 20 format, and whether to use
		+	different enzymes to digest the suffix part.
		+
		+	'''The no-brainer transition strategy''': Make no PstI containing RFC
		+	20 parts and only use RFC 10 assembly with RFC 20 vectors. You can
		+	continue to make parts that do not contain any PstI sites
		+	(i.e. compatible with RFC 10) but that contain a RFC 20 suffix
		+	(SbfI). This is really no extra work for the part maker as all you're
		+	doing is adding an extra two bases from what you would be doing
		+	anyway. For people who want to continue to use a consistent enzyme,
		+	they can continue to use PstI, but assemble into a RFC 20 destination
		+	vector. If people followed this procedure, which is identical to what
		+	they are currently doing, except that a new destination vector is
		+	being used, then more and more parts will become RFC 20 parts, with no
		+	extra work. Note that at some point, you will have to jump to a
		+	different strategy. Otherwise, you get no benefit from using RFC
		+	20. But this is the recommended initial strategy to build up the
		+	collection of RFC 20 parts.
		+
		+	'''The upgrade as needed strategy''': Whenever a RFC 10 part is needed
		+	for an assembly or when someone decides that a part is highly used,
		+	the part is moved into RFC 20 format by digesting it with EcoRI/SpeI
		+	and moving it to a RFC 20 plasmid. This is a relatively simple
		+	operation and can be done in parallel with other cloning
		+	operations. For example, anytime a RFC 10 part is used as a prefix
		+	part in an assembly (i.e. it's cut with EcoRI/SpeI), we do two
		+	ligations and transformations: one ligation with the desired suffix
		+	part and one ligation into a RFC 20 plasmid (or equivalently ligation
		+	with an XbaI/SbfI cut "empty part"). This requires minimal extra work
		+	and only moves parts as needed. Highly used parts then become in RFC
		+	20 form.
		+
		+	'''The I need some PstI sites strategy''': Make PstI containing RFC 20
		+	parts. For the users who just really want to leave a PstI site in
		+	either because it's too difficult to mutate or because it's in a
		+	region that is dangerous to mutate, they can begin to push the
		+	boundaries between the two RFCs. These RFC 20 parts must be digested
		+	with SbfI. Assembly type 3 may become a problem but can be solved by
		+	converting either the input RFC 10 part or the output RFC 10 to a RFC
		+	20 part.
		+
		+	'''The mixed approach''': Cut all RFC 20 parts with SbfI and all RFC
		+	10 parts with PstI. Clearly, this requires an extra bit of information
		+	to be maintained so that the correct enzyme can be chosen. At this
		+	point, I would assume that the majority of parts being used are in RFC
		+	20 form.
		+
		+	These transition strategies can be mixed at will and the key is that
		+	all roads lead to the majority of parts becoming RFC 20 parts, at
		+	which point you reach
		+
		+	'''The end state''': Most parts are in RFC 20 form. There are some
		+	remaining parts in RFC 10 but these have not been used much or deemed
		+	worthwhile to be made into RFC 20. Assemblies use SbfI instead of PstI
		+	and new parts are designed that can contain PstI sites.
		+
		+	My response to your points:
		+
		+	(1) It is unclear what you mean by RFC 20 parts are not compatible
		+	with RFC 10 parts. It is always possible to assemble a RFC 20 part
		+	with a RFC 10 part even if the RFC 20 part contains a PstI site. You
		+	are correct that in the transition period, you may have sets of RFC 10
		+	parts and sets of RFC 20 parts. Thus, you may have to use a different
		+	enzyme to cut the different parts. But this is the choice of the user
		+	and the choice of the transition strategy.
		+
		+	(2) You can never get stuck. You are correct that if you have a PstI
		+	containing RFC 20 prefix part and you assemble it with a RFC 10 suffix
		+	part, then you will get a RFC 10 part containing a PstI site. First,
		+	the probability of this occurring can be made arbitrarily small
		+	depending on the transition plan. But suppose you do find yourself in
		+	this situation. Then you can simply move the part by cutting with
		+	EcoRI/SpeI and transferring it into a RFC 20 plasmid. You now have
		+	yourself a fully compliant RFC 20 part.
		+
		+	(3) Ordering new primers is cheap. The whole point of RFC 20 is that
		+	you do not have to pick a destination vector. You ALWAYS use a RFC 20
		+	destination vector. Note, that the primers that you link to would not
		+	need to be changed. They don't prime to the PstI site and thus they
		+	could be used as-is with a new destination vector.
		+
		+	(4) Yes, you need to make new vectors. That's a one-time, easy to do
		+	operation. Note that the pSBXX5 series are almost compatible already
		+	as they already have a G after the PstI site. Only a C needs to be
		+	inserted before the PstI site. Thus you can make an RFC 20 insert, cut
		+	all these plasmids with EcoRI/PstI, and ligate in the insert. If
		+	you're making destination backbone via PCR, you may not need to do any
		+	cloning other than order new primers.
		+
		+	(5) I do not understand what you're saying here. Of course, RFC 20 is
		+	not intended to do anything about the protein fusion problem. All the
		+	RFC 10 derivatives for protein fusion should have no problem replacing
		+	the PstI with SbfI as it's the outermost restriction enzme. The outer
		+	enzymes are really "don't-cares" for RFC 10 and all its
		+	derivatives.

Raik: comment arguing against this replacement

2009-04-03T11:17:58Z

comment arguing against this replacement

New page

[[Special:Emailuser/Raik|Raik]] 03 April 2009

RFC 20 is, in fact, NOT a relaxation of RFC 10 but rather breaks compatibility with both RFC 10 and all derived formats. Let me explain: Replacing PstI by SbfI-HF looks like a good idea because it reduces the number of cases where one has to mutate or synthesize the part DNA. SbfI-HF is chosen so that ''most'' parts adhering to RFC 10 would still be compatible with the classic PstI / EcoRI assembly. BUT, this is where the trouble starts:

(1) ''Some'' RFC 20 parts will ''not'' be compatible with the classic assembly because they contain PstI sites. That means, users who want to assemble old (RFC 10) and new (RFC 20) parts will have to adapt their protocol and enzymes on a case-by-case basis. They cannot completely switch to the SbfI-HF because it is not working with RFC 10 (or any of the derived formats). But they cannot just use the old assembly, either.

(2) Once PstI containing Biobricks are mixed into an assembly, the resulting Biobrick is incompatible with further (RFC 10) standard assemblies. To be more exact, it can only be extended further in one direction. But it -- or anything derived from it -- cannot any longer be used as suffix part in standard assembly. Now that's a real problem. Remember, the whole point was to be able to mix RFC 10 and RFC 20 parts. In reality, there is a real danger to get stuck -- sooner or later you will end up with a Biobrick that has the classic RFC 10 prefix and suffix but nevertheless contains PstI sites. That's it, end of story.

(3) Some protocols rely on the exact RFC 10 prefix or suffix sequence which can serve, for instance, as standard priming site for PCR reactions. For example, several labs linearize the destination vector by PCR rather than by digestion: [[Prbbbb:vector_pcr]]. Again, it would disrupt the flow of these assemblies if one would need to check and pick 'correct' primers for each assembly reaction separately.

(4) RFC 20 proposes to replace one of the two 'outer' restriction enzymes. That means we need new construction vectors for this assembly. The most commonly used set of pSB1AC/K/T3 plasmids for 3A assembly will not work.

(5) RFC 20 does obviously not solve the protein fusion problem. There are two major formats out there that allow the assembly of fusion proteins: Silver/BioFusion (RFC 23) and Freiburg/Fusion (RFC 25 underway). Both are modifications of RFC 10. Both use PstI and the old set of enzymes. Both formats can mostly (RFC 23) or always (RFC 25) be combined with classic (RFC 10) Biobricks. The proposed RFC 20 Biobricks will again, in some cases, not work together with these formats. Where they do work, mixed assembly can potentially create hybrid Biobricks with a suffix that mixes RFC 25 and RFC 20, for example.

I think, in the current situation, the considerable downstream costs and complications of adopting RFC 20 would outweigh the added convenience. Right now, we should try to avoid a further degradation of the classic standard. RFC 20 would only be a temporary solution anyway, until we have settled on a next generation format that also solves the protein fusion issue. On the other hand, replacing PstI by SbfI-HF could indeed be a very useful idea for this future generation assembly standard.

←Older revision		Revision as of 18:33, 4 April 2009
Line 48:		Line 48:
	the problem is quite likely to occur during the assembly of larger constructs.		the problem is quite likely to occur during the assembly of larger constructs.
	'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''		'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''
		+
		+	* '''[[User:Austin J. Che\|Austin Che]] 14:33, 4 April 2009 (EDT)''': You're ignoring the transition plans I list below. If you want to be conservative and never think about your assemblies, you can follow the no-brainer transition strategy and not do anything different from what you are currently doing. With this approach, you will NEVER encounter situation 3. But in the process, you will be helping out everyone else who does want to standardize on SbfI.

	There are different transition plans depending on what an individual		There are different transition plans depending on what an individual
Line 144:		Line 146:
	back by two or three extra days. Now that can be really annoying...		back by two or three extra days. Now that can be really annoying...
	'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''		'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''
-		+	* '''[[User:Austin J. Che\|Austin Che]] 14:33, 4 April 2009 (EDT)''': Like I said in the transition plan above, moving to RFC 20 form takes no extra time. It's an extra parallel step done with the cloning you're already doing and needs to only be done once for a part and only for certain parts. There absolutely no case where you need to do it more than once for a chain of assembly reactions.
	(3) Ordering new primers is cheap. The whole point of RFC 20 is that		(3) Ordering new primers is cheap. The whole point of RFC 20 is that
	you do not have to pick a destination vector. You ALWAYS use a RFC 20		you do not have to pick a destination vector. You ALWAYS use a RFC 20
Line 158:		Line 160:
	will probably not appreciate to have even more variations to worry about.		will probably not appreciate to have even more variations to worry about.
	'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''		'''*[[User:Raik\|Raik]] 07:58, 4 April 2009 (EDT)'''
-		+	*'''[[User:Austin J. Che\|Austin Che]] 14:33, 4 April 2009 (EDT)''': I think I know most of the PCR based assemblies approach out there and I still cannot understand how this could possibly affect things in any dramatic way. You can just consider the PstI part of the sequence as part of the plasmid. Are you suggesting that people should stop using different plasmids because they have different sequences? Because you might not be able to use the same primers to PCR up pSB1A3 and pSB4C5, everyone should just use a single plasmid.
	(4) Yes, you need to make new vectors. That's a one-time, easy to do		(4) Yes, you need to make new vectors. That's a one-time, easy to do
	operation. Note that the pSBXX5 series are almost compatible already		operation. Note that the pSBXX5 series are almost compatible already