README.md

title: "Data representation for combinatorial pharmacogenomics" author: "Vincent J. Carey, stvjc at channing.harvard.edu" date: "r format(Sys.time(), '%B %d, %Y')" vignette: > %\VignetteEngine{knitr::rmarkdown} %\VignetteIndexEntry{Data representation for combinatorial pharmacogenomics} %\VignetteEncoding{UTF-8} output: BiocStyle::html_document: highlight: pygments number_sections: yes theme: united toc: yes

```{r setup,echo=FALSE,results="hide"} suppressWarnings({ suppressPackageStartupMessages({ library(pharmGxComb) library(BiocStyle) library(ggplot2) library(magrittr) library(dplyr) }) })


# Introduction

Consider the following table representing
combination drug experimental design **for a given cell line**:
```{r lkd}
library(pharmGxComb)
data(dc)
table(dc$drugA_name[1:5000], 
   dc$drugB_name[1:5000])[1:5,1:5]

This is a small slice of data derivable from r nrow(dc) records in dc.

We can get an informal look at the effects on viability using a simple ggplot2 call in viabDots.

```{r lkdd} library(dplyr) library(magrittr) viabDots(dc, drugA="5-FU", drugB="ABT-888", incell_line="CAOV3")


A very naive test of interaction between 5-FU and ABT-888 concentrations
on viability in CAOV3 is given with
```{r lkreg}
summary(viabReg(dc, drugA="5-FU", drugB="ABT-888", incell_line="CAOV3"))

Thoughts on data structure and use cases

Drugs and cell lines are the main experimental factors. There is a single assay for viability. We may have genomic data as well, but the design underlying the genomic assays will determine how to think about data structure.

At this stage it does not seem clear how to reuse existing Bioc classes. Here are a few considerations, to be weighed against highest scientific priorities.

```{r ordcell,cache=TRUE} all_lines = unique(dc$cell_line) all_regs = lapply(all_lines, function(x) summary(viabReg(dc, drugA="5-FU", drugB="ABT-888", incell_line=x))$coef) names(all_regs) = all_lines all_regs_t = sapply(all_regs, function(x)x[4,3]) all_regs_p = sapply(all_regs, function(x)x[4,4]) rep = rbind(all_regs_t, all_regs_p) rep[,order(rep[2,])[1:5]]


- Assessing consistency of combination effects on **related cell lines**.
In this case some aspects of the cell line ontology might
be helpful.  How many tokens for cell line in
the test data can be mapped to CLO?

```{r lklklk}
uu = unique(dc$cell_line)
clo = ontoProc::getCellLineOnto()
ii = lapply(uu, function(x) grep(x, clo$name, ignore.case=TRUE, value=TRUE))
jj = ii[sapply(ii,length)>0]
names(jj) = uu[sapply(ii,length)>0]
jj

So r length(jj)/r length(uu) is the fraction of cell line tokens "directly mappable" to cell line ontology terms.

```{r zzz} ch = ontoProc::getChebiOnto() mm = lapply(alld, function(x) grep(x, ch$name, value=TRUE)) nn = mm[which(sapply(mm, function(x)length(x)>0))] names(nn) = alld[which(sapply(mm, function(x)length(x)>0))] nn

There are not many direct matches.  When we have a tag,
we can find out about the compound class.
```{r lklk}
ch$name[ch$parent[["CHEBI:8988"]]]

With standard naming, we can group compounds more effectively.

Summary

We need to elaborate the key use cases. The long table representation seems very useful but it does not immediately fit with the key Bioc classes.

It may be worth pointing out that there is an approach in restfulSE for lazily converting a long table layout to a "delayed" SummarizedExperiment. The back end is BigQuery so you will need to be able to authenticate to make use of the isb-cgc "project". library(restfulSE); example(BQ3_Array) and the related source spell this out. It is clumsy.



bhklab/longArray documentation built on Aug. 6, 2019, 4:11 p.m.