Support for Crispr

[manulera]

Should be possible to add several guide RNAs and a single repair DNA (if any)

[manulera]

Probably there should be a way to indicate that they come from a plasmid ( include another input, and also say which features contain the guide RNA)

[manulera]

Hi @dgruano, just some thoughts on how this could be done:

CRISPr assembly

In the end, since we want the output to be the final product after the repair has happenned, the implementation should be the same as a regular homologous recombination, but applying a constrain that the guide RNA would cut inside the region of the genome that is replaced.

• I see two options:
  • Option 1:
  • Create another class of Assembly, that takes the RNA guides as an extra inputs, and can only return assemblies via get_insertion_assemblies.
  • In the function get_insertion_assemblies, call the parent mehtod, and then filter out the ones when the RNAs don't cut.
  • Option 2:
  • Use the usual assembly class to get all possible get_insertion_assemblies
  • Filter afterwards
  • I prefer this slightly, as it prevents adding extra classes, but I am open to either solution.

To check whether the guide RNA falls in the right place, you could use the cas9 enzyme implemented in pydna, with the usual search function. It's in pydna.crispr.cas9.

Linking guide RNAs in the source

The main question for me is how to link the guide RNAs to the source. One way would be to add them as a separate category like primers, with a unique name. In the frontend they could be added like the primers and so on.

My understanding however is that these guide RNAs typically are introduced from a plasmid, so it probably would be better to link to a sequence that contains the guide RNAs, and indicate what part of that sequence is the guide RNA. If there is a feature in the plasmid that marks the DNA, the user could select from the plasmid features those that contains the guide RNAs. What do you think?

[dgruano]

Hi @manulera!

CRISPr assembly

I think I agree with option 2! It should be easy to filter and we don't need to duplicate the whole class.

Using pydna.crispr.cas9 enzyme is a good start! We could then add support to other commonly used nucleases or support custom PAM motifs.

Linking guide RNAs in the source

As a start, we could either add the guide to the Primer section or as a manually typed source, as I think the ideal scenario would be to do as you say: clone the guide into a plasmid within SYC and then declare where it is. Two notes on that though:

1. AFAIK there are several sources for the guides (there could be more):

   • Chemically synthesized gRNA: this case would be covered with a manually typed source.
   • gRNA transformed into the genome (e.g. one mouse line expressing Cas9 and another one expressing the sgRNA): the upstream cloning process can be done in SYC, but we need to "declare" the sgRNA for the downstream CRISPR step.
   • sgRNA cloned into a plasmid: again, this can be done but we need to "declare" which part is the sgRNA.

2. Given the two last points, do you think we could implement a general case for "Feature as source", where the user can extract a piece of a previous source by selecting one of its annotations? Or do you think this should be limited to selecting an sgRNA only?

Let me know!

[manulera]

Hi @dgruano, I guess then we have a solution for the pydna/assembly class part.

As for SYC and the linking to sgRNA, I guess this is where the limitations of having all sequences related to a source as elements in input start to show (this kind of approach leads to the bug in https://github.com/manulera/ShareYourCloning_frontend/issues/124. For that, rather than having a list input where the order determines what is the template and what is the source, what would be better is to have two separate fields template and insert, and a method inputs that would return both in this type of source).

Not sure what the best way to go about this would be, I think once I get a bit more familiar with LinkML I may have a better answer.

For the record, I imagine that this type of Feature as a source will often refer to RNA or proteins (products of the DNA rather than the DNA itself).

I will have a thought about this after Easter. Happy to hear your thoughts on it as well.

[manulera]

From #118

I can add for the tests cases you mentioned, but I have some questions about specific cases and what should happen to them:

Ex1 / Ex2: Not sure what should happen here. Here the homology region would clearly be too short, perhaps if the cut falls on top the homology region, it should only be allowed if the remaining homology arm is >= minimal_homology.

EX1: Cut on the right part of HR
        ><
       GTaaaPAM
       |||||
ACGtttGGTAAAAGGACGT
|||    |||
ACG....GTA

EX2: Cut on the left part of HR
 ><
ACGttPAM  
|||||
ACGttAGGCTGCA
 |||  |||
 CGT..GGC

EX4: This would be a no for me, I would say.

EX4: Cut to the left of HR
     ><
    GTaaaPAM
    |||||PAM
TTTGGTaaaAGGACGT
      |||   |||
      AAA...ACG

EX5: I did not see the difference between this and EX4

EX5: Double target HR
        ><
       GTaaaPAM
       |||||
ACGtttGGTAAAAGGTGCA
|||   |||
ACG...GGT

[dgruano]

This should also eventually support the use of several protospacers to target the same region.