<p>SBOL 3 is well suited for an application like this, though you may wish to consider some of the specifics (e.g., whether to use a conventional database or an RDF triple store), and has been used for similar (though not exactly the same) workflows in other projects.</p>
<p>To some of your specific questions:</p>
<ul>
<li>In addition to tracking the provenance relationships, SubComponent relations can be used to track the inclusion of parts within your final build. The sourceLocation field can be used to express the difference between the original part and a post-assembly trimmed version when there are changes in the reaction.</li>
<li>The assembly plans and reactions can be represented not just with activities, but using SBOL Interaction objects.</li>
<li>SBOL Implementation objects can be used for tracking specific aliquots as well as the designs that are intended to be included in them.</li>
<li>If you still need to enhance Activity records, you can either use the base extension capabilities in pySBOL3 or (better) use <a href="https://github.com/SynBioDex/sbol_factory/" rel="nofollow noreferrer">SBOL Factory</a> to create extension classes via an ontology.</li>
<li>With regards to serialization format, since SBOL 3 is pure RDF, you can use any RDF serialization you want, including <a href="https://json-ld.org/" rel="nofollow noreferrer">JSON-LD</a>.</li>
</ul>
<p>There's a lot to unpack here, so I would suggest that if you want to dig deeper into any of these specific responses that you ask new questions focused on individual aspects.</p>
<p>Here is an example in prototype work on protocols:</p>
<p><a href="https://github.com/SD2E/paml/blob/main/paml/paml.ttl" rel="nofollow noreferrer">https://github.com/SD2E/paml/blob/main/paml/paml.ttl</a></p>

CC BY-SA 4.0
2021-09-23T15:22:08.903Z
2021-09-29T04:17:25.750Z
2021-09-29T04:17:25.750Z
jakebeal
<p>I wonder about using The Synthetic Biology Open Language (SBOL) for a project involving the development of a web application to track the lineage of recombinant DNA molecules in a laboratory collection. I am wondering whether SBOL can support this use case, and I could really use some help from community members.</p>
<h3>Use case</h3>
<p>The ultimate goal is to develop a web application to keep an audit trail of recombinant DNA in a laboratory collection, where sequences are traceable through cloning steps up to their entry point into the collection.</p>
<p>For instance, we can imagine we want to document the generation of a new plasmid by combining fragments of two existing plasmids by restriction and ligation. The web application would provide an interface where you can select the input sequences, select the restriction sites and the assembly, and would generate the child sequence. This information would then be stored in a relational database, and would also be exportable to a text file. Essentially, something like the history of a sequence in SnapGene, but using a relational database instead of the file system, and having an open standard to export the information.</p>
<h3>Implementation (roughly)</h3>
<p>This requires the following steps:</p>
<ol>
<li><p><strong>Generating a schema to document genetic engineering steps:</strong> The most abstract version of a step would just have inputs and output, but there would have to be a specific implementation for each operation. For the restriction and ligation described above, there would be three steps</p>
<ul>
<li>Digestion plasmid A: which enzyme was used, and where it cut.</li>
<li>Digestion of plasmid B: which enzyme was used, and where it cut.</li>
<li>Ligation of pieces: Order of the pieces of the assembly</li>
</ul>
<pre><code>Plasmid A -[restriction]-&gt; Restriction Fragment A
                                                |-[Ligation]-&gt;Final product
Plasmid B -[restriction]-&gt; Restriction Fragment B

</code></pre>
</li>
<li><p><strong>Building an API that reads the inputs and description of a step and returns the output:</strong> For this, I had thought of using the library <a href="https://pydna.readthedocs.io/" rel="nofollow noreferrer">pydna</a>, since it seems to cover the initial use cases I could think of.</p>
</li>
<li><p><strong>Building a visual interface to generate this documentation:</strong> A mockup with minimal functionality can be found <a href="https://www.genestorian.org/html/web_interface/index.html" rel="nofollow noreferrer">here</a></p>
</li>
<li><p><strong>Developing a web application managing a database based on the schema mentioned above</strong></p>
</li>
</ol>
<h3>Will SBOL ever cover this use case?</h3>
<p>As far as I understand it, SBOL currently provides the most abstract layer of the schema described in the previous section, supported by the <code>&lt;prov:&gt;</code> tags, so each entity could be related to its ancestors through an <code>Activity</code> that represents the ligation, the restriction. etc. However, from looking at the documentation there seems to be no schema for any concrete implementation of <code>Activity</code>. For example, to describe a restriction operation. Restriction is relatively simple, but for PCR there would be the need to also define a schema for the alignment of primers, with potential missmatches etc. Provenances should also support importing entries from public resources (such as genome databases). These concrete <code>Activity</code> schemas should be readable by an API that would take the inputs and return the output. For cloning steps, this would be performed with <a href="https://pydna.readthedocs.io/" rel="nofollow noreferrer">pydna</a> or something similar. For sequences imported from public resources, the provenance would have the url of a web request, and the API would request the sequence, and parse it.</p>
<p>From the documentation of <code>prov:Activity</code>: <em>to capture how an entity was derived, it is expected that any additional information needed will be attached as annotations</em>. From this, I wanted to ask whether specific schemas representing the cloning steps will ever be part of the SBOL, or should be provided as external files.</p>
<h3>How to approach implementation?</h3>
<p>My original plan (before realising about <code>&lt;prov&gt;</code> tags in SBOL) was to do the schema in json, since it's the easiest way to go for a web application. I suppose that the json schema would be easily convertible into xml to eventually be used in SBOL.</p>
<p>I still think it would be best to start with json, since I don't think for the nature of this task I can leverage any of the features of SBOL beyond the <code>&lt;prov&gt;</code> tag. The sequences themselves will be stored in the original import format, and the only new aspect that I will introduce would be the schemas for cloning steps. Once I have a minimal prototype of the schemas and I have tested the application with users, I could come back to these forums and discuss the schema and potential changes that can be made to it, if it is to be included in SBOL.</p>
<p>If you have some thoughts in any of these points, I would really appreciate any feedback.</p>

<sbol>
Using SBOL for lineages of recombinant DNA molecules and strains
# Using SBOL for lineages of recombinant DNA molecules and strains

(Asked by: username_0 on 2021-09-23)

I wonder about using The Synthetic Biology Open Language (SBOL) for a project involving the development of a web application to track the lineage of recombinant DNA molecules in a laboratory collection. I am wondering whether SBOL can support this use case, and I could really use some help from community members.
Use case
The ultimate goal is to develop a web application to keep an audit trail of recombinant DNA in a laboratory collection, where sequences are traceable through cloning steps up to their entry point into the collection.
For instance, we can imagine we want to document the generation of a new plasmid by combining fragments of two existing plasmids by restriction and ligation. The web application would provide an interface where you can select the input sequences, select the restriction sites and the assembly, and would generate the child sequence. This information would then be stored in a relational database, and would also be exportable to a text file. Essentially, something like the history of a sequence in SnapGene, but using a relational database instead of the file system, and having an open standard to export the information.
Implementation (roughly)
This requires the following steps:

Generating a schema to document genetic engineering steps: The most abstract version of a step would just have inputs and output, but there would have to be a specific implementation for each operation. For the restriction and ligation described above, there would be three steps

Digestion plasmid A: which enzyme was used, and where it cut.
Digestion of plasmid B: which enzyme was used, and where it cut.
Ligation of pieces: Order of the pieces of the assembly

Plasmid A -[restriction]-> Restriction Fragment A
                                                |-[Ligation]->Final product
Plasmid B -[restriction]-> Restriction Fragment B



Building an API that reads the inputs and description of a step and returns the output: For this, I had thought of using the library pydna, since it seems to cover the initial use cases I could think of.

Building a visual interface to generate this documentation: A mockup with minimal functionality can be found here

Developing a web application managing a database based on the schema mentioned above


Will SBOL ever cover this use case?
As far as I understand it, SBOL currently provides the most abstract layer of the schema described in the previous section, supported by the  tags, so each entity could be related to its ancestors through an Activity that represents the ligation, the restriction. etc. However, from looking at the documentation there seems to be no schema for any concrete implementation of Activity. For example, to describe a restriction operation. Restriction is relatively simple, but for PCR there would be the need to also define a schema for the alignment of primers, with potential missmatches etc. Provenances should also support importing entries from public resources (such as genome databases). These concrete Activity schemas should be readable by an API that would take the inputs and return the output. For cloning steps, this would be performed with pydna or something similar. For sequences imported from public resources, the provenance would have the url of a web request, and the API would request the sequence, and parse it.
From the documentation of prov:Activity: to capture how an entity was derived, it is expected that any additional information needed will be attached as annotations. From this, I wanted to ask whether specific schemas representing the cloning steps will ever be part of the SBOL, or should be provided as external files.
How to approach implementation?
My original plan (before realising about  tags in SBOL) was to do the schema in json, since it's the easiest way to go for a web application. I suppose that the json schema would be easily convertible into xml to eventually be used in SBOL.
I still think it would be best to start with json, since I don't think for the nature of this task I can leverage any of the features of SBOL beyond the  tag. The sequences themselves will be stored in the original import format, and the only new aspect that I will introduce would be the schemas for cloning steps. Once I have a minimal prototype of the schemas and I have tested the application with users, I could come back to these forums and discuss the schema and potential changes that can be made to it, if it is to be included in SBOL.
If you have some thoughts in any of these points, I would really appreciate any feedback.

**Tags:** sbol

---

## 1 answers

### Answer by username_1 on 2021-09-23. Score: 1

SBOL 3 is well suited for an application like this, though you may wish to consider some of the specifics (e.g., whether to use a conventional database or an RDF triple store), and has been used for similar (though not exactly the same) workflows in other projects.

To some of your specific questions:

* In addition to tracking the provenance relationships, SubComponent relations can be used to track the inclusion of parts within your final build. The sourceLocation field can be used to express the difference between the original part and a post-assembly trimmed version when there are changes in the reaction.
* The assembly plans and reactions can be represented not just with activities, but using SBOL Interaction objects.
* SBOL Implementation objects can be used for tracking specific aliquots as well as the designs that are intended to be included in them.
* If you still need to enhance Activity records, you can either use the base extension capabilities in pySBOL3 or (better) use [SBOL Factory](https://github.com/SynBioDex/sbol_factory/) to create extension classes via an ontology.
* With regards to serialization format, since SBOL 3 is pure RDF, you can use any RDF serialization you want, including [JSON-LD](https://json-ld.org/).

There's a lot to unpack here, so I would suggest that if you want to dig deeper into any of these specific responses that you ask new questions focused on individual aspects.

Here is an example in prototype work on protocols:

<https://github.com/SD2E/paml/blob/main/paml/paml.ttl>


---

