designed by Melike Sabry

Software

  ↓  
If the document is not loading, click here to open in a new tab!

OSCAR

brought to you by Finn & Lilly
Motivation
Throughout our journey through the CAR-focused academic community, we had our eyes opened to a few problems. One of these was the difficulty of collaboration between projects, teams, and researchers (see Human Practices). Proteins are cataloged in the PDB (Protein Data Base), and nucleotide sequences are stored in the GenBank. Yet, there is no such thing specifically dedicated to the storage of CARs. After discussing with more scientists, we finalized our plans for a solution that would pose as a platform for interactions between academics.

OSCAR Logo
Figure 1: This is Oscar, and he's cool!
We came up with “OSCAR”: Open Source Chimeric Antigen Receptors, a database for cataloging and sharing CARs. By performing extensive literature research, we managed to add over 100 CARs. Our modular database schema supports the separate storage of CAR parts, for instance, the receptor, the linker, or the transmembrane domain. By breaking down the data, the creation of new CARs with new functionalities is enabled, and sharing discoveries is effortless. Due to OSCAR’s open-source nature, iGEM teams can adapt and use our tools in the future.

Since not all of us are computer science prodigies, we figured that simply creating a database and accessing data via SQL queries would not suffice. As such, we built a dynamic web app, which makes submitting and accessing research data a breeze.
Database schema

We started the development of a database by collecting and ordering everything that should be stored in OSCAR. For this, we were in close contact with scientists.

Important constraints for the database schema are:

  • A CAR comprises a linker, a transmembrane part, a receptor and an intracellular part, the linker is allowed to be NULL
  • An intracellular part consists of at least one domain and those domains can have specialized functions
  • Linker, transmembrane part, receptor, and intracellular domain each have their own sequence. However, it is allowed to store NULL values for the sequence of these components, for instance if there is a publication on a CAR but they don't make the sequences publicly available
  • Linker, transmembrane part, receptor, and intracellular part can be part of a CAR, but a NULL value for the reference to a CAR is allowed too, because several publications describe several e.g. receptors but do not test them within whole CAR

The result was the following Entity-Relationship model:

Figure 2: Entity-Relationship model for OSCAR.

Next, we converted the ER-model (Figure 2) into a relational model. For each entity and each relationship, we created one relation and marked the respective primary key by underlining it.

Paper: {[DOI: String, Journal: String, Authors: String, Year: int, Title: String]}
reviewed: {[Paper_DOI: String, CAR_ID: int]}

linker_discovered: {[Linker_ID: int, Paper_DOI: String]}
tmPart_discovered: {[TMpart_ID: int, Paper_DOI: String]}
receptor_discovered: {[Receptor_ID: int, Paper_DOI: String]}
izDomain_discovered: {[IZdomain_ID: int, Paper_DOI: String]}

CAR: {[ID: int, Function: String]}

linker_part_of: {[CAR_ID: int, Linker_ID: int]}
tmPart_part_of: {[CAR_ID: int, TMpart_ID: int]}
receptor_part_of: {[CAR_ID: int, Receptor_ID: int]}
izPart_part_of: {[CAR_ID: int, IZpart_ID: int]}
izDomain_part_of: {[IZdomain_ID: int, IZpart_ID: int]}

Linker: {[ID: int]}
TMpart: {[ID: int, Function: String]}
Receptor: {[ID: int, Function: String, needsLinker: boolean]}
IZpart: {[ID: int, Function: String]}
IZdomain: {[ID: int, Function: String]}

linker_seq: {[Linker_ID: int, Sequence_ID: int]}
tmPart_seq: {[TMpart_ID: int, Sequence_ID: int]}
receptor_seq: {[Receptor_ID: int, Sequence_ID: int]}
izDomain_seq: {[IZdomain_ID: int, Sequence_ID: int]}

Sequence: {[ID: int, Length: int, Seq: String, Annotation: String]}

In the relational model, all relations representing a 1:N relationship or a 1:1 relationship are respectively marked.

Simplification of the database schema

The relational model can be simplified by including both the 1:N relationships as well as the 1:1 relationships in the entity of the respective primary key. This leads to the following, simplified relational model:

Paper: {[DOI: String, Journal: String, Authors: String, Year: int, Title: String]}
reviewed: {[Paper_DOI: String, CAR_ID: int]}
CAR: {[ID: int, Function: String, Linker_ID: int , TMpart_ID: int , receptor_ID: int , IZpart_ID: int ]}
Linker: {[ID: int, Sequence_ID: int , Discovered_in_DOI: String ]}
TMpart: {[ID: int, Function: String, Sequence_ID: int , Discovered_in_DOI: String ]}
Receptor: {[ID: int, Function: String, needsLinker: Boolean, Sequence_ID: int , Discovered_in_DOI: String ]}
IZpart: {[ID: int, Function: String]}
IZdomain: {[ID: int, Function: String, part_of_IZpart_ID: int , Sequence_ID: int , Discovered_in_DOI: String ]}
Sequence: {[ID: int, Length: int, Seq: String, Annotation: String]}

We considered further simplification - for instance by choosing another attribute as primary key, so that no ID is needed. However, the constraints described above did not allow for this. Additionally, we investigated a possible improvement of the database scheme by transforming the schema into a high normal form. If applied, such a transformation removes redundancies from the schema. After examining all functional dependencies, we registered that the database schema described above already satisfies all conditions required to be in Boyce–Codd normal form (BCNF). We decided to not go beyond BCNF in order to avoid unnecessary complexity.

Technical setup

The bedrock of our app is made up of Django, a Python framework with an included REST API, allowing for seamless communication between our React.js frontend, and PostgreSQL, an open-source relational database that stores all our CARs. We used the Bootstrap framework to stylize the application and then bundled it all together into a small package with Webkit to provide a seamless user experience. In the end, we deployed the app to an Amazon Elastic Compute Cloud instance while the production database runs on the Amazon Relational Database Service.

Access the OSCAR database here!

The source code for OSCAR can be found on our Software GitLab.

Currently stored data
brought to you by Igor
The initial release of our database, linked above, already contains over one hundred CAR constructs identified through extensive literature research. Scientists and enthusiasts around the world can view, and in the future even reassemble, a wide variety of different receptors: from first-generation to next-generation CARs (also known as fifth-generation), from FDA-approved and commercially available to new and emerging designs, all are examples from scientific journals and patents. In addition, a large number of theoretically possible combinations could be constructed from over thirty available subsequences. We hope to use this to support future iGEM teams looking to use CAR T-cells to make the world a better place. For more details, please see our Contribution page.

View the data as an exported PDF.

Outlook

We won’t stop at just cataloging CARs and fostering academic interactions, we want to continue by building an integrated development environment where anyone can assemble CARs from already existing parts.

Let’s see where our journey takes us!

Gallery
Figure 3: On the homepage, the user can find a search field. CARs are indexed according to keywords provided by the submitter and can easily be found.

Figure 4: In the about section of our application, the user can find out more about our methods and mission.

Figure 5: If the user has access to their own CARs, they can upload them via the submit tool.

Figure 6: If the user does not know exactly what they are looking for, they can use the browse page to find an unimaginable amount of CARs.
^