Send DNA Design TemplateActors: Sean as the sender; Bryan as the recipient. Goal: To send the design template for it to be filled in with DNA sequence. Overview and scope: Representation of a composite DNA design independent of sequence. The design is the specification of an ordered set of template DNA components which are required. For this use case the identifiers for the constituent DNA components and types are specified, but their DNA sequence and coordinate based positions are not. Diagrams representing structural information such as this, are published as the genetic level design layout in most synthetic biology primary literature. Successful Scenario: Main
Precondition: Diagram as in Figure 1 drawn in TinkerCell. Post condition: A Eugene input script file (String) as specified below. Device T9002_J61048 (Promoter BBa_ R0040, BBa_B0034, ORF BBa_C0062, Terminator BBa_B0010, Terminator BBa_B0012, Promoter BBa_R0062, BBa_B0032, ORF BBa_E0040, Terminator BBa_ J61048);
Description of Scenario: Sean, a synthetic biologist, sets out to improve evolutionary stability of BBa_T9002. He sketches a design using TinkerCell (example drawn from Sleight 2010). The new circuit design (Figure 1) calls for the use of DnaComponents in the following order: R0040 (pTetR), B0034, C0062(luxR), B0010, B0012, R0062 (pLuxR), B0032, E0040 (gfp), and J61048 (replacing B0015). After completing the design, Sean would like Bryan, the student working on the project with him, to fill in the sequence information and then send it to get additional annotations needed for the assembly process. Sean does not specify which software tool Bryan should use. The choice of tools is Bryan’s responsibility so he should be able to take one file type and choose an appropriate tool for his task. Currently, Clotho apps (Eugene, MatchMaker) and GenoCAD offer automated or semi-automated solutions, but both are capable of assisting the process. Also a sequence editor such as ApE, VectorNTI, etc can be used to manually do so. Alternatively, Sean could perform this sequence annotation himself, but for the purpose of this case, he would not pre-plan which tool to use, therefore would like to save his design in a generic file before choosing the downstream tool. Note: Other software, such as BioCompiler in the TASBE tool chain, GenoCAD, iBioSim, and the JBEI DeviceEditor, can create similar DesignTemplates. When trivially small (such as this example) they can be easily typed in by hand using Eugene script or generated by Eugene. Alternatively, the WikiDust plugin for TinkerCell also offers a simple mechanism to retrieve DNA sequences within TinkerCell, the exchange of sequence designs with results after WikiDust pulls in the sequence information will be a separate case. Implementation Note: In the diagram the IDs and names are actually concatenated strings as TinkerCell only displays one label per DNA component, these labels on the diagram will have to be corrected and the ID fields populated. Also, the order of DnaComponents will have to be determined by TinkerCell API methods. This case lists the specific IDs for components, but it does not specify the sequence, nor position coordinates. Technically unspecified sequences, could be inserted between the components, without invalidating the design. ie the components are specified to be in relative order (using partial order). BBa_ IDs imply and mean BioBrick Parts from the PartsRegistry are to be used, but the assembly choices, therefore choices of scar sequence are left to the user in use case #02. A generalization of this use case is to not specify IDs and instead to specify “other” required parameters for the design specification. SBOL Structure to be used: Generic Composite DNA Design Template DCØ → (SArp1 (DCt1), SArp2 (DCt2), …, SArpØ (DCt)) Send Annotated DNA SequenceActors: Bryan as the sender; Jane as the recipient. Goal: To send the annotated DNA sequence for assembly planning. Overview and scope: Representation of an annotated DNA sequence as a DNA component with sequence annotations. The DNA sequence is annotated by position with sub-components and other features. The position is specified using the base pair coordinates along the 5’ to 3’ direction. For this use case the constituent DNA components and their types are specified, but their relative position (order) on the DNA sequence is not specified explicitly. Annotated DNA sequence such as this is, are often found in the familiar GenBank flatfile format. Precondition: SBOL structure Design Template: DCØ (SArp1 (DCt1), SArp2 (DCt2), …, SAØ (DCt)). and Collection of DNA Components Col(DCst1, DCst2, … DCstN)
Post condition: Annotated DNA sequence DCst → SArp1 (DCst1) → SApos2 (DCst2), … → SAposN (DCst) output containing information as specified below T9002_J61048 1929bp of DNA sequence 1..54 = R0040 63..74 = B0034 81..836 = C0062 870..949 = B0010 958..998 = B0012 1007..1061 = R0062 1070..1082 = B0032 1089..1808 = E0040 1817..1929 = J61048 Successful Scenario: Main
Description of Scenario: Bryan, a synthetic biology PhD student, sets out to build T9002_J61048. He will fill in the sequence of the design using Eugene. His result will be a compilation of the DNA components fulfilling the design that Sean specified. To do this Eugene will need a collection of DNA components retrieved from partsregistry.org . Therefore, Bryan will retrieve this collection and translate it into Eugene Part files (see Use Case #03). Once Bryan is finished running Eugene, he will export the results and send them to Jane, an undergraduate student in the lab, who will plan, assemble, and sequence-verify the new circuit. The example used is the transfer of a design from TinkerCell to Eugene, but other tools could serve as alternatives. The analogous process in the TASBE tool chain is from BioCompiler to MatchMaker. iBioSim could generate the design and feed into any of these downstream tools. GenoCAD could be used to make the Design Template or to read one generated elsewhere and when given the collection of components GenoCAD automates the process of assigning sequence to the design. [SynBioSS could be considered as well.] Alternatively, Spectacles or Eugene Scripter can be used to read the output directly into Clotho, and use its assembly algorithms to plan the assembly. At this stage the annotated sequence could also be sent for direct synthesis if Bryan so chooses. SBOL Structure: Generic Annotated DNA Sequence DCs → (SApos1 (DCts1), SApos2 (DCts2), …, SAposN (DCtsN)) Publish Collection of DNA ComponentsActors: Mike as the publisher; Bryan as the consumer. Goal: To publish a collection of DNA components to be re-used for design of novel DNA circuits. Overview and scope: Representation of a collection of DNA components annotated and typed. The collection is an unordered set of DNA components. For the first iteration of this use case the set of DNA components are basic, meaning they do not have sub-components specified, other DNA component structures can be used to extend this case as a set of alternatives. Successful Scenario: Main
Precondition: Sequence information for BBa_R0040, BBa_B0034, BBa_C0062, BBa_B0010, BBa_B0012, BBa_R0062, BBa_B0032, BBa_E0040, BBa_J61048. Post condition: Eugene Part files as specified below. Promoter BBa_ J61048 (.ID("BBa_ J61048"), .Sequence("GATCTttgacagctagctcagtcctagggactatgctagcG"), .Orientation("Forward")); etc Description of Scenario: Mike, a bioinformatics PhD student, wants to make the Parts Registry available in SBOL format for others to re-use. He transforms the PartsRegistry XML format (ie rsbpml) into SBOL and publishes them on the web as a service to the community. To make the Parts files available to Eugene in Use Case #02 Bryan retrieves the information he needs in Clotho’s Hermes app. Note: The example used in this use case can be completed without this step as Clotho offers a Parts Registry importer tool. However, the generalized case requires a standardized format. Implementation Note: The PartsRegistry in SBOL format can both be retrieved directly as a file and queried using a RESTful API query format, whichever suits the user best. SBOL Structure to be used: Generic basic DNA Component Collection Col(DCst1, DCst2, … DCstN) Multi-Step Exchange of Annotated Plasmid DNA SequenceGoal: To retrieve and send annotated plasmid DNA sequence information between multiple software packages. Overview and scope: Information exchange mediated by the Clotho platform between web-based resources GD-ICE, PartRegistry via SBPkb, BIOFAB to TinkerCell, Gene Designer, VectorNTI , back to Clotho. Description of Scenario: A Clotho user imports a plasmid from GD-ICE, a part from SPBkb, and a part from BIOFAB Emeryville. She includes the parts and plasmid in an emerging design. She exports the design in a SBOL formatted file. She emails the SBOL file to a TinkerCell, Gene Designer, and VectorNTI user. The TinkerCell, Gene Designer, and VectorNTI users view the design, make changes, and email the modified design back to the Clotho user. She views the modifications with Clotho. --Cesar Rodriguez Discussed during Version 1.0 design
I want to exchange the relevant data about this experiment with someone. At least the information on S1' and P1' has to be transmitted. It would be desirable to have info in S1' and P1' to "point to" their parents.
T9002  Sufficient Basic Unit Composite Part Composite Annotated Part Multi-tiered Composite Part Use case overview: Use cases for SBOL break down into categories described by the included information. Categorization based on the differentia are then grouped by intent. An example use case is as follows: A Clotho user imports a plasmid from GD-ICE, a part from SPBkb, and a part from BIOFAB Emeryville. She includes the parts and plasmid in an emerging design. She exports the design in a SBOL-formatted file. She emails the SBOL file to a TinkerCell user and a VectorNTI user. The TinkerCell and VectorNTI users view the design, make changes, and email the modified design back to the Clotho user. She views the modifications with Clotho. Another example: A Clotho user imports a plasmid from GD-ICE, a set of parts from SPBkb, and a set of parts from BIOFAB Emeryville. She specifies a high-level design in Proto that will make use of these parts, and runs the Proto BioCompiler to generate an abstract GRN design, which is exported in an SBOL formatted file. She then imports the design into Clotho and uses the MatchMaker application to create the design using parts and plasmids selected from the set that she just imported. And another: A user uses iBioSim to design an abstract genetic circuit. She simulates it with iBioSim to explore design trade-offs. Once confident that the behavior is roughly what she wants, she imports parts from SBOL part databases (i.e., SPBkb, BIOFAB, and GenoCAD). These parts come with characterizations which get incorporated into our analysis models. She can then resimulate designs for this concrete implementation to see if she is satisfied that it still behaves as expected. If so, she can then export the SBOL for a DNA component which is the composition of these parts. She could then send this component to Clotho for assembly. we often initially test designs using cotransfection with one plasmid per functional unit before we serialize the functional units onto a single plasmid. Thus, we may have a design with five DNAComponents and no precedence constraints between them. This same design gets turned into 5 plasmids in one instantiation and 1 plasmid (which will pick up precedence and then start/stop locations) in another instantiation.
-note: It's not sensible to try to distinguish between having no Relative Position Data and having no precedence constraints. Thus, I would changes the first MUST to a MAY. - Jake A use case: Consider a situation where the synthetic biologist wants to test various promoters but keep the rest of the design constant. In this case, the promoter component has a relative position, but the rest of the components will have start positions and sequences. Lets call this SBOL file the "template" design, because the engineer plans to use it to generate various other DNAComponents, each with a specific promoter. I'm not sure how the original "template" DNAComponent will get addressed in each of these complete designs -- I don't think it is possible in the current Core model, because the size of the template is not known and it defines regions upstream and downstream of the promoter component. A use case: I'm interested in clearly representing our design. One constraint on my example design is that the location of the 5' primer precedes the location of the 3' primer on my DC. A second and independent constraint is that the location of the promoter precedes the location of the CDS on my DC. It is not a constraint of my design that the location of my promoter precedes the location of my 3' primer or that the location of my 5' primer precedes the location of my CDS, although this may be a natural inference to draw from the combination of asserted constraints. To loose this useful and explicit knowledge because of the implementation artifact that the 5'primer and promoter are co-located so we must pool all precedes and subComponent relations seems like a real shame. We've lost the ability to state things about *the location of the 5' primer* and independently state things about *the location of the promoter*. It puts us in the paradoxical position that by being more concrete about the details, we actually loose information about the design. This same argument holds true when ever there is information directly associated with the SequenceAnnotation that relates specifically to only one of the subComponents. Take the example of running a simple alignment of short query sequences against some DNA to find canonical RBSs. You may have 5 similar short query sequences. These may happen to have alignment hits to the same region of DNA. However, the score for each alignment is unique to the combination of the location and the query sequence. It would be natural to store that score on the SequenceAnnotation stating the location, but there's no way to do that if we're forced to use the same SequenceAnnotation for all of the hits. You can't associate one score with one specific query sequence at that place if you're forced to re-use the same SA instance for all the hits at that place. DC: name = "My Construct" SAhit1: start=20, end=30, strand=+ alignmentScore=12 subComponent [ DCqueryRBS1 ] SAhit2: start=20, end=30, strand=+ alignmentScore=15 subComponent [ DCqueryRBS2 ] SAhit3: start=20, end=30, strand=+ alignmentScore=3 subComponent [ DCqueryRBS3 ] |
*