Wilms tumor annotation (SCPCP000014)

[UTSouthwesternDSSR]

Proposed analysis

We plan to annotate cell types for the Wilms tumor samples (n=10) in SCPCP000014. Our analysis involves data clean-up for low quality nuclei and doublets, cell type annotation, and tumor cell identification.

Scientific goals

The goal of this analysis is to curate a validated cell type annotation for Wilms tumor samples in the portal (SCPCP000014). Specifically, we aim to generate following outcomes: (i) Lists of marker genes to identify cell types in Wilms tumor; (ii) Identification of tumor cells from normal cells; (iii) Refined annotation of cell types among normal cells; (iv) Annotation of sub-groups among tumor cells, if applicable.

Methods or approach

1. We will start with the processed count matrices provided by ALSF.

2. We will remove doublets if there is any in each sample, using available tools like DoubletFinder.

3. We will first perform an automated cell type annotation using SingleR with public references, including datasets from literatures. Then we will run PCA, clustering, and UMAP visualization, where we expect same cell types cluster together.

4. The annotation generated in step 3 will then be complemented with manually curated marker gene lists, using tools like enrichr or cellassign.

5. We will use CNV-based tools like CopyKat to classify tumor and normal cells. Those cells with absence of inferred copy number alterations will be annotated as normal cells.

6. Finally, we will merge the whole cohort together, and perform PCA, clustering, and UMAP visualization. We expect normal cell type to cluster together, and tumor cells to be separated by inter-sample heterogeneity. We will finetune the cell type annotation, if any cell groups with other cell types.

Existing modules

This module is based on the existing annotation workflow of Ewing sarcoma samples in #292, with some modification.

Input data

This analysis will use processed count matrices in SingleCellExperiment object from SCPCP000014.

Scientific literature

The following datasets might be useful when curating marker gene lists and/or cell type references:
https://pubmed.ncbi.nlm.nih.gov/36718830/
https://pubmed.ncbi.nlm.nih.gov/30093597/

Other details

This analysis will be performed on our local machine and HPC, and will be conducted in R. We plan to share the annotation within two months.

[Jen-OMalley]

Hi @UTSouthwesternDSSR. I'm Jen, the Scientific Community Manager at the Data Lab. Thank you for sharing your proposed analysis!

Have you filled out the contributor form yet? On this form, you will provide the name and email address that will be associated with the AWS account that we'll create for you. We also need this form returned to ensure you have agreed to the OpenScPCA terms and conditions and other policies. Once we receive this, our team will review your proposed analyses and get back to you with next steps within 3 business days!

In the meantime, please let us know if you have any questions about OpenScPCA. We look forward to discussing more with you soon!

[UTSouthwesternDSSR]

We have submitted the contributor form. Looking forward to contributing the community!

[Jen-OMalley]

Excellent @UTSouthwesternDSSR! Your AWS account has been created and you should receive an email to complete setup. Here are instructions for setting up AWS!

[UTSouthwesternDSSR]

Thank you!

[sjspielman]

Hi @UTSouthwesternDSSR! I'm Stephanie, one of the Data Scientists in the Data Lab. We're looking forward to having you on board as an OpenScPCA contributor!

Before you get started, I wanted to provide some additional guidance.

---

First, we very much appreciate your interest in performing cell type annotation on multiple projects (this discussion, #629, and #630)!

Given that you are proposing similar analysis pipelines across each project, we recommend that you begin your OpenScPCA contribution with only one ScPCA project. You can feel free to choose which project you'd like to start with. After code for your first analysis module has been developed, reviewed/approved, and added to the repository, you can begin to apply that code to the other projects you'd like to annotate. Once we reach that stage, we can also check in further to discuss how your module(s) and shared code will be organized.

---

Next, I'll offer some specific feedback about your proposed approach:

We will start with the processed count matrices provided by ALSF.

We indeed do recommend starting with the ScPCA processed count matrices (_processed.rds or _processed_rna.h5ad), because it ensures that all analyses in OpenScPCA have the same starting point.
These objects have already undergone removal of empty droplets, filtering of low quality cells, and normalization.
See the documentation on the ScPCA Portal for more information about how these objects were processed.

We will remove doublets if there is any in each sample, using available tools like DoubletFinder.

We are actually right now in the process of running scDblFinder on all samples, and the results will be made available to you via S3 shortly.
These results will include a TSV file with the output from scDblFinder.
If you plan to annotate and remove doublets, please use these results.
If you would like to use these results before they are available, you may also run the available script in the doublet-detection module.

We will first perform an automated cell type annotation using SingleR with public references, including datasets from literatures. Then we will run PCA, clustering, and UMAP visualization, where we expect same cell types cluster together.

Note that PCA and UMAP coordinates are already calculated in the processed objects you'll be using, but we recommend you re-calculate clusters rather than relying on those in the processed object.

---

Once you are ready to start your analysis, please follow the below steps to start contributing to the project:

• Follow the technical setup instructions found in the OpenScPCA documentation.
• File an issue to track the initiation of your analysis module.
• Initiate your module and file a pull request to establish the module (without any analysis code yet; for example see this PR which was made solely to initialize a new module).

After this PR has been reviewed and accepted, you will be ready to continue with the rest of the analysis that you proposed. A key part of your analysis will involve scoping your work to ensure slow-and-steady modular progress towards the final cell type annotations.

I would recommend that you break up your work into the following steps, where each bullet point would be an issue and at least one subsequent pull request (PR).

1. Add documentation and, if the files are small enough, the actual files containing the reference datasets you plan to use for SingleR annotation.

   • An important step to pay attention to here are terms of reference data reuse; does the data you are using as a reference have licensing terms that permit dissemination and reuse, or are there any terms that might conflict with our open licensing? E.g., if there's an embargo still on any of that data, it can't be used here yet. I see you linked some papers that may contain references, so embargo may not be relevant, but other terms may be.
   • If the files cannot be added directly to the repository (this would happen if they are too large and/or the terms do not permit), then we may need to discuss further how this information can be communicated and integrated into the module to ensure reproducibility. Please let us know if you have any questions here!

2. Add the code to perform cell type annotation with SingleR.

3. Add documentation for and any additional files with marker gene information that will be used to refine annotations. You'll use these additional metadata files in your next issue/PR.

4. Add the code used to refine annotations, including documentation and code to add manual annotations where relevant.

   • Generally speaking, it will be important to ensure that manual changes you make to automated cell type labels are clearly documented (e.g., what evidence or information was used to make the manual call? why do you think a given manual call is better than an automated one?) and reproducible as well.
   • In other words, manual cell typing should still be part of a reproducible script, not a fully manual overwrite of a result file.

5. Add the code for inferCNV (or similar tools) for calling tumor vs. normal cells.

6. Add code to merge all samples together and perform validation

   • This analysis will likely be something we'll want to come back to and discuss. For example, for visualization, you will probably want to perform batch correction/integration, but this may not be necessary for all downstream applications. To the extent you want to integrate the data, you'll need to pick a suitable tool, and we're definitely glad to discuss this more once you get to this analysis stage!

7. Add code to refine cell type annotations based on results from the previous step

---

Finally, I just want to add some clarification to some of your opening discussion comments:

This analysis will be performed on our local machine and HPC, and will be conducted in R. We plan to share the annotation within two months.

First, just an FYI that as an OpenScPCA contributor, you will have access to virtual computers which may be helpful for running analyses you can't run on a laptop. Depending on your HPC setup and what kinds of permissions you have to install dependencies and software environments, you might find it more convenient to work on a virtual computer that we offer.

We plan to share the annotation within two months.

Please bear in mind that, as an OpenScPCA contributor, your work will be conducted openly and iteratively. This means that, although the final results will of course take some time to fully establish, your analysis code will be openly available the entire time you are working. A two month timeline to complete cell type annotation is perfectly fine; I just want to highlight that we'll be heavily engaging throughout this process, rather than you working independently for 2 months and then sending over results.

You can find more information about this in our policies, notably this one:

Code and other materials you commit to your fork and push to GitHub will be publicly available and licensed under the same license as the AlexsLemonade repository (Creative Commons Attribution 4.0 International and 3-Clause BSD licenses).

---

Let us know if you have any questions or comments, or want to generally discuss anything else! We're happy to have you on board!

[UTSouthwesternDSSR]

Hi Stephanie, our team has two people working on T-ALL and Wilms tumor respectively. In general, the approach for annotation should be similar, but T-ALL studies have CITE-seq data, which could be useful for annotation.
I also have some questions regarding the processed data for [#630], and I will post it there.

[sjspielman]

Hi Stephanie, our team has two people working on T-ALL and Wilms tumor respectively. In general, the approach for annotation should be similar, but T-ALL studies have CITE-seq data, which could be useful for annotation.

Got it, this makes sense if you're spreading the work around the team! I'll have a look at your question in #630 and provide some insight over in that discussion as well.