Add RiboJ insulated versions of B00XX series of RBSs.

[ethanj801]

These are fairly well characterized http://2016.igem.org/Team:William_and_Mary/RBS and RiboJ-B0034 has been characterized with the entire Anderson promoter library https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6206723/.

[jakebeal]

Issue stems from a discussion in #138

Bringing a question over from there:

is there a structure yet for reporting quantitative measurements for parts? How do measurements get associated with parts?

We can associate measurements with parts in SBOL via the hasMeasure property on Component objects. Take a look at the Devices section in SEP 055 proposal and see what you think of the suggestions there? Adding thoughts, examples, and criticisms to the proposal discussion thread will be useful for making sure we build the right tools for supporting that association.

[eyesmo]

I propose that it would significantly increase the number of accessible insulator-RBS part combinations if, in addition to designing a few fused RiboInsulator-RBS parts, we also defined a 'ribozyme' part type that can assemble upstream of RBS parts. This part type would not be compatible with the baseline versions of MoClo or uLoop because promoters already have 3' overhangs for assembling upstream of RBSs; but this can be overcome by building a couple of part-type-switching linkers that can change the part definition of a promoter part from standard MoClo/uLoop to a 'FiveClo' assembly standard and overhang set for building more complex 5' UTRs in a standardized way (BsaI/BbsI uLoop promoter-->FiveClo promoter PTS linker example here; BsaI/mBsaI uLoop promoter-->FiveClo promoter PTS linker example here). Running a part type switching reaction on the promoter could enable more parts, like ribozymes, operators and recombinase binding sites, to be inserted between it and the RBS, without forcing a change to the (more sequence-sensitive?) RBS part definition, and while enabling baseline compatibility with the IIS assembly standard iGEM is using.

[jakebeal]

@vinoo-igem How would you feel about having a variation like that in the assembly approach?

[ethanj801]

I realize that this is somewhat of a weird place to bring this up. But I have a similar issue to bring up which is with regard to adding degrons/C-terminal tags (e.g. LVAs, PDTs, etc). Since existing CDSs have stop codons, it is somewhat difficult to add on these kinds of tags. Really I feel like the optimal solution would just be to include a stop codon in the 3' UTR/terminator and have all CDS parts not end with a stop codon. Additionally a similar issue to the one highlighted above exists for 3' UTRs (which are not particularly used right now, but could be in the future.)

[eyesmo]

More generally, there are a bunch of useful part types that don’t slot into the base-level uLoop assembly standard, and it would be very nice to have a way to interconvert parts from uLoop to a (lower-level?) assembly standard with an expanded high fidelity overhang set for building complex/composite vector backbones, 5’UTRs, CDS fusions, and 3’ UTRS. Friendzymes has been thinking through how to do this, and what part types might go in the lower-level ‘AllClo’ assembly standard. My thoughts on it as of last week are here (friendzymes/community#15 (comment)), though I’m very much open to alternative/simplifying approaches.

…

On Wed, Jan 26, 2022 at 9:21 AM Ethan Jones ***@***.***> wrote: I realize that this is somewhat of a weird place to bring this up. But I have a similar issue to bring up which is with regard to adding degrons/C-terminal tags (e.g. LVAs, PDTs, etc). Since existing CDSs have stop codons, it is somewhat difficult to add on these kinds of tags. Really I feel like the optimal solution would just be to include a stop codon in the 3' UTR/terminator and have all CDS parts not end with a stop codon. Additionally a similar issue to the one highlighted above exists for 3' UTRs (which are not particularly used right now, but could be in the future.) — Reply to this email directly, view it on GitHub <#146 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARO3EAGCVT6H2HVYT5C25LUYAGOZANCNFSM5LZ63TMQ> . You are receiving this because you commented.Message ID: ***@***.***>