Storing Base Editor Data in MaveDB

[bencap]

Base editor data is a type of functional assay data that is similar to MAVE data in many respects. In these experiments, engineered CRISPR base editors are used to convert target bases without creating double strand breaks, introducing mutations in a given window based on their proximity to the CRISPR guide RNA binding location.

One important difference is that in a typical analysis, only the guide RNAs are quantified and used to calculate variant scores. The actual mutations introduced are inferred based on the guide location, relative position of the editing window, and the base editor's conversion profile. This is typically done by assuming all bases of the appropriate type in the window are converted with 100% efficiency and calculating the variant DNA sequence (and variant amino acid sequence, if relevant) that way. Because of this, it is possible that two different guide RNAs could introduce the same sequence variant if they bind near each other.]

To address this and more faithfully represent the way the data was generated and analyzed, we should add a new score set type in MaveDB specifically for base editor data. Key features and implementation notes are outlined below:

• Base editors should be able to use existing experiment and experiment set records with no changes.
• Instead of an hgvs_ index column, base editor score sets use a new column guide_sequence as the index column.
  • Guides should be validated to ensure that they are unique, like all index columns.
  • Guides should be validated to ensure that they contain only ACGT.
• hgvs_nt is required but does not need to be unique.
• hgvs_pro is optional.
• Base editor score sets do not have a target sequence. All hgvs_ columns should be specified with a versioned chromosome scaffold, transcript, or protein identifier from RefSeq as was introduced for the SGE data.
  • Many base editor experiments hit multiple functional elements (many genes) so this should be supported.
• Base editor experiments may have multiple score sets, with each score set describing the variants with a different editing window width.
• Many base editor variants will be multi-nucleotide variants, since the assumption is that all nucleotides in the editing window have been changed.
• It will be useful to generate VRS objects for the base editor variants, but this can wait if the mapping service will struggle with this type of multi-nucleotide and multi-amino acid data.
• The most extensive changes will be required in the validator code to accept this new type of uploaded data table.
• We may be able to auto-detect whether a score set is a base editor score set simply by the presence of the guide_sequence column, but it is probably better to not do this and force an explicit choice. We may want to use the same column name for CRISPR-based technologies like SGE where including the guide is valuable metadata but not an index value.

[bencap]

Related to #312

[afrubin]

@ldrepano @Reintg here's the proposed base editor implementation for MaveDB. We're eager to have your feedback, and if you have a few lines of example data to look at that would also be quite helpful.

[bencap]

This might represent a good opportunity to refactor some of the validation code to better support MaveTools.

[bencap]

Hi @ldrepano @Reintg, I just finished up a draft of the base editor data validation logic and was wondering if there was any example data you had I could test with.

Everything looked good with the test data I generated, but it would be useful to have some of the data as you would want to submit so that I can make sure it's compatible with real world data. For more information on formats and how uploaded data should look, we have some documentation available here: https://mavedb.org/docs/mavedb/upload_guide.html. Thanks!

[ldrepano]

Hello! Sorry that I missed the earlier comment for revision of the text. I have no concerns/suggestions about the implementation notes, although it would be helpful for me to see the actual implementation to be more certain! Attached are the score sets for a parallel experiments with an editor that generates C>T vs. A>G that target TP53. I will follow up with the rest of the metadata (assuming that is helpful as well?) but just sending this over now so that it does not hold up your work!
Best,
Laura

TP53_activity_based_selection_Etoposide_CBE_MaveDB_scoreset.csv
TP53_activity_based_selection_Etoposide_ABE_MaveDB_scoreset.csv

[bencap]

No worries @ldrepano and thanks for those files.

I have the staging site in use for something until Wednesday afternoon, but I can deploy the draft of these changes tomorrow evening after that is done and that would be a place to test how the data upload would actually look (staging.mavedb.org). The metadata would also be useful, but having the actual changes on the site might be easier than going back and forth here, so if you'd rather do that we could just wait for Thursday.

Linking the changes as well: Support for Base Editor Data #352, although the actual PR probably isn't very useful.

[bencap]

Hi @ldrepano, I just deployed the base editor draft changes to staging.mavedb.org, so they should be available to test now.

A couple notes on the files from above at a glance, since as of right now there would be a few parsing errors:

• You'll want to add prefixes to your variant strings, depending on the column (protein variants are expected to be prefixed p., while nucleotide variants might be c., n., g., etc. depending on your methods.
• You'll also want to add the transcript accession you used to these variants. When reported against an accession, we expect variants to be fully qualified with respect to the transcript identifier.
• We expect different variants to be space separated. Is there a semantic HGVS meaning to the space following the commas in these files, or was that just how the data was generated?
• There's an NC entry for some variants that I'm not familiar with. What does that entry represent?

Putting it all together, the second line of the TP53 file from above might look like

AAAACATCTTGTTGAGGGCA,"<TP53_nucleotide_transcript.version>:c.['396G>A','399G>A']","<TP53_protein_transcript.version>:c.['Lys132Lys','Met133Ile']",-0.6764895163253973