The National Cancer Institute (NCI) has established the Genomic Data Commons (GDC). The GDC provides the cancer research community with an open and unified repository for sharing and accessing data across numerous cancer studies and projects via a high-performance data transfer and query infrastructure. The GenomicDataCommons Bioconductor package provides basic infrastructure for querying, accessing, and mining genomic datasets available from the GDC. We expect that the Bioconductor developer and the larger bioinformatics communities will build on the GenomicDataCommons package to add higher-level functionality and expose cancer genomics data to the plethora of state-of-the-art bioinformatics methods available in Bioconductor.
From the Genomic Data Commons (GDC) website:
The National Cancer Institute’s (NCI’s) Genomic Data Commons (GDC) is a data sharing platform that promotes precision medicine in oncology. It is not just a database or a tool; it is an expandable knowledge network supporting the import and standardization of genomic and clinical data from cancer research programs. The GDC contains NCI-generated data from some of the largest and most comprehensive cancer genomic datasets, including The Cancer Genome Atlas (TCGA) and Therapeutically Applicable Research to Generate Effective Therapies (TARGET). For the first time, these datasets have been harmonized using a common set of bioinformatics pipelines, so that the data can be directly compared. As a growing knowledge system for cancer, the GDC also enables researchers to submit data, and harmonizes these data for import into the GDC. As more researchers add clinical and genomic data to the GDC, it will become an even more powerful tool for making discoveries about the molecular basis of cancer that may lead to better care for patients.
The data model for the GDC is complex, but it worth a quick overview and a graphical representation is included here.
The GDC API exposes these nodes and edges in a somewhat simplified set of RESTful endpoints.
This quickstart section is just meant to show basic functionality. More details of functionality are included further on in this vignette and in function-specific help.
This software is available at Bioconductor.org and can be downloaded via
BiocManager::install
.
To report bugs or problems, either
submit a new issue
or submit a bug.report(package='GenomicDataCommons')
from within R (which
will redirect you to the new issue on GitHub).
Installation can be achieved via Bioconductor’s BiocManager
package.
if (!require("BiocManager"))
install.packages("BiocManager")
BiocManager::install('GenomicDataCommons')
library(GenomicDataCommons)
The GenomicDataCommons package relies on having network
connectivity. In addition, the NCI GDC API must also be operational
and not under maintenance. Checking status
can be used to check this
connectivity and functionality.
GenomicDataCommons::status()
## $commit
## [1] "3d0c5b1fd25804e51093b02b870742d9042e75bd"
##
## $data_release
## [1] "Data Release 38.0 - August 31, 2023"
##
## $status
## [1] "OK"
##
## $tag
## [1] "4.0.1"
##
## $version
## [1] 1
And to check the status in code:
stopifnot(GenomicDataCommons::status()$status=="OK")
The following code builds a manifest
that can be used to guide the
download of raw data. Here, filtering finds gene expression files
quantified as raw counts using STAR
from ovarian cancer patients.
ge_manifest <- files() %>%
filter( cases.project.project_id == 'TCGA-OV') %>%
filter( type == 'gene_expression' ) %>%
filter( analysis.workflow_type == 'STAR - Counts') %>%
manifest()
head(ge_manifest)
After the 858 gene expression files
specified in the query above. Using multiple processes to do the download very
significantly speeds up the transfer in many cases. On a standard 1Gb
connection, the following completes in about 30 seconds. The first time the
data are downloaded, R will ask to create a cache directory (see ?gdc_cache
for details of setting and interacting with the cache). Resulting
downloaded files will be stored in the cache directory. Future access to
the same files will be directly from the cache, alleviating multiple downloads.
fnames <- lapply(ge_manifest$id[1:20], gdcdata)
If the download had included controlled-access data, the download above would
have needed to include a token
. Details are available in
the authentication section below.
Accessing clinical data is a very common task. Given a set of case_ids
,
the gdc_clinical()
function will return a list of four tibble
s.
case_ids = cases() %>% results(size=10) %>% ids()
clindat = gdc_clinical(case_ids)
names(clindat)
## [1] "demographic" "diagnoses" "exposures" "main"
head(clindat[["main"]])
head(clindat[["diagnoses"]])
The GenomicDataCommons package can access the significant
clinical, demographic, biospecimen, and annotation information
contained in the NCI GDC. The gdc_clinical()
function will often
be all that is needed, but the API and GenomicDataCommons package
make much flexibility if fine-tuning is required.
expands = c("diagnoses","annotations",
"demographic","exposures")
clinResults = cases() %>%
GenomicDataCommons::select(NULL) %>%
GenomicDataCommons::expand(expands) %>%
results(size=50)
str(clinResults[[1]],list.len=6)
## chr [1:50] "935ca1d3-2445-4f59-95a6-19f3311c1900" ...
# or listviewer::jsonedit(clinResults)
This package design is meant to have some similarities to the “hadleyverse” approach of dplyr. Roughly, the functionality for finding and accessing files and metadata can be divided into:
In addition, there are exhiliary functions for asking the GDC API for information about available and default fields, slicing BAM files, and downloading actual data files. Here is an overview of functionality1 See individual function and methods documentation for specific details..
projects()
cases()
files()
annotations()
filter()
facet()
select()
mapping()
available_fields()
default_fields()
grep_fields()
available_values()
available_expand()
results()
count()
response()
gdcdata()
transfer()
gdc_client()
aggregations()
gdc_token()
slicing()
There are two main classes of operations when working with the NCI GDC.
Both classes of operation are reviewed in detail in the following sections.
Vast amounts of metadata about cases (patients, basically), files, projects, and
so-called annotations are available via the NCI GDC API. Typically, one will
want to query metadata to either focus in on a set of files for download or
transfer or to perform so-called aggregations (pivot-tables, facets, similar
to the R table()
functionality).
Querying metadata starts with creating a “blank” query. One
will often then want to filter
the query to limit results prior
to retrieving results. The GenomicDataCommons package has
helper functions for listing fields that are available for
filtering.
In addition to fetching results, the GDC API allows faceting, or aggregating,, useful for compiling reports, generating dashboards, or building user interfaces to GDC data (see GDC web query interface for a non-R-based example).
A query of the GDC starts its life in R. Queries follow the four metadata
endpoints available at the GDC. In particular, there are four convenience
functions that each create GDCQuery
objects (actually, specific subclasses of
GDCQuery
):
projects()
cases()
files()
annotations()
pquery = projects()
The pquery
object is now an object of (S3) class, GDCQuery
(and
gdc_projects
and list
). The object contains the following elements:
projects()
function, the default fields from the GDC are used
(see default_fields()
)filter()
method and will be used to filter results on
retrieval.aggregations()
.Looking at the actual object (get used to using str()
!), note that the query
contains no results.
str(pquery)
## List of 5
## $ fields : chr [1:10] "dbgap_accession_number" "disease_type" "intended_release_date" "name" ...
## $ filters: NULL
## $ facets : NULL
## $ legacy : logi FALSE
## $ expand : NULL
## - attr(*, "class")= chr [1:3] "gdc_projects" "GDCQuery" "list"
[ GDC pagination documentation ]
With a query object available, the next step is to retrieve results from the
GDC. The GenomicDataCommons package. The most basic type of results we can get
is a simple count()
of records available that satisfy the filter criteria.
Note that we have not set any filters, so a count()
here will represent all
the project records publicly available at the GDC in the “default” archive"
pcount = count(pquery)
# or
pcount = pquery %>% count()
pcount
## [1] 82
The results()
method will fetch actual results.
presults = pquery %>% results()
These results are
returned from the GDC in JSON format and
converted into a (potentially nested) list in R. The str()
method is useful
for taking a quick glimpse of the data.
str(presults)
## List of 9
## $ id : chr [1:10] "CGCI-HTMCP-CC" "TARGET-AML" "GENIE-JHU" "GENIE-MSK" ...
## $ primary_site :List of 10
## ..$ CGCI-HTMCP-CC: chr "Cervix uteri"
## ..$ TARGET-AML : chr [1:2] "Hematopoietic and reticuloendothelial systems" "Unknown"
## ..$ GENIE-JHU : chr [1:33] "Spinal cord, cranial nerves, and other parts of central nervous system" "Small intestine" "Brain" "Skin" ...
## ..$ GENIE-MSK : chr [1:49] "Testis" "Spinal cord, cranial nerves, and other parts of central nervous system" "Small intestine" "Brain" ...
## ..$ GENIE-VICC : chr [1:46] "Spinal cord, cranial nerves, and other parts of central nervous system" "Testis" "Small intestine" "Other and unspecified major salivary glands" ...
## ..$ GENIE-MDA : chr [1:42] "Testis" "Spinal cord, cranial nerves, and other parts of central nervous system" "Small intestine" "Brain" ...
## ..$ TCGA-MESO : chr [1:2] "Bronchus and lung" "Heart, mediastinum, and pleura"
## ..$ TARGET-ALL-P3: chr [1:2] "Hematopoietic and reticuloendothelial systems" "Unknown"
## ..$ TCGA-UVM : chr "Eye and adnexa"
## ..$ TCGA-KICH : chr "Kidney"
## $ dbgap_accession_number: chr [1:10] "phs000528" "phs000465" NA NA ...
## $ project_id : chr [1:10] "CGCI-HTMCP-CC" "TARGET-AML" "GENIE-JHU" "GENIE-MSK" ...
## $ disease_type :List of 10
## ..$ CGCI-HTMCP-CC: chr [1:4] "Epithelial Neoplasms, NOS" "Complex Epithelial Neoplasms" "Adenomas and Adenocarcinomas" "Squamous Cell Neoplasms"
## ..$ TARGET-AML : chr [1:2] "Myeloid Leukemias" "Not Applicable"
## ..$ GENIE-JHU : chr [1:33] "Neoplasms of Histiocytes and Accessory Lymphoid Cells" "Mast Cell Tumors" "Chronic Myeloproliferative Disorders" "Osseous and Chondromatous Neoplasms" ...
## ..$ GENIE-MSK : chr [1:49] "Neoplasms of Histiocytes and Accessory Lymphoid Cells" "Mast Cell Tumors" "Osseous and Chondromatous Neoplasms" "Hodgkin Lymphoma" ...
## ..$ GENIE-VICC : chr [1:43] "Neoplasms of Histiocytes and Accessory Lymphoid Cells" "Mast Cell Tumors" "Chronic Myeloproliferative Disorders" "Precursor Cell Lymphoblastic Lymphoma" ...
## ..$ GENIE-MDA : chr [1:34] "Osseous and Chondromatous Neoplasms" "Hodgkin Lymphoma" "Adenomas and Adenocarcinomas" "Trophoblastic neoplasms" ...
## ..$ TCGA-MESO : chr "Mesothelial Neoplasms"
## ..$ TARGET-ALL-P3: chr [1:4] "Not Applicable" "Lymphoid Leukemias" "Leukemias, NOS" "Myeloid Leukemias"
## ..$ TCGA-UVM : chr "Nevi and Melanomas"
## ..$ TCGA-KICH : chr "Adenomas and Adenocarcinomas"
## $ name : chr [1:10] "HIV+ Tumor Molecular Characterization Project - Cervical Cancer" "Acute Myeloid Leukemia" "AACR Project GENIE - Contributed by Johns Hopkins Sidney Kimmel Comprehensive Cancer Center" "AACR Project GENIE - Contributed by Memorial Sloan Kettering Cancer Center" ...
## $ releasable : logi [1:10] TRUE TRUE TRUE TRUE TRUE TRUE ...
## $ state : chr [1:10] "open" "open" "open" "open" ...
## $ released : logi [1:10] TRUE TRUE TRUE TRUE TRUE TRUE ...
## - attr(*, "row.names")= int [1:10] 1 2 3 4 5 6 7 8 9 10
## - attr(*, "class")= chr [1:3] "GDCprojectsResults" "GDCResults" "list"
A default of only 10 records are returned. We can use the size
and from
arguments to results()
to either page through results or to change the number
of results. Finally, there is a convenience method, results_all()
that will
simply fetch all the available results given a query. Note that results_all()
may take a long time and return HUGE result sets if not used carefully. Use of a
combination of count()
and results()
to get a sense of the expected data
size is probably warranted before calling results_all()
length(ids(presults))
## [1] 10
presults = pquery %>% results_all()
length(ids(presults))
## [1] 82
# includes all records
length(ids(presults)) == count(pquery)
## [1] TRUE
Extracting subsets of results or manipulating the results into a more conventional R data structure is not easily generalizable. However, the purrr, rlist, and data.tree packages are all potentially of interest for manipulating complex, nested list structures. For viewing the results in an interactive viewer, consider the listviewer package.
Central to querying and retrieving data from the GDC is the ability to specify
which fields to return, filtering by fields and values, and faceting or
aggregating. The GenomicDataCommons package includes two simple functions,
available_fields()
and default_fields()
. Each can operate on a character(1)
endpoint name (“cases”, “files”, “annotations”, or “projects”) or a GDCQuery
object.
default_fields('files')
## [1] "access" "acl"
## [3] "average_base_quality" "average_insert_size"
## [5] "average_read_length" "channel"
## [7] "chip_id" "chip_position"
## [9] "contamination" "contamination_error"
## [11] "created_datetime" "data_category"
## [13] "data_format" "data_type"
## [15] "error_type" "experimental_strategy"
## [17] "file_autocomplete" "file_id"
## [19] "file_name" "file_size"
## [21] "imaging_date" "magnification"
## [23] "md5sum" "mean_coverage"
## [25] "msi_score" "msi_status"
## [27] "pairs_on_diff_chr" "plate_name"
## [29] "plate_well" "platform"
## [31] "proc_internal" "proportion_base_mismatch"
## [33] "proportion_coverage_10X" "proportion_coverage_10x"
## [35] "proportion_coverage_30X" "proportion_coverage_30x"
## [37] "proportion_reads_duplicated" "proportion_reads_mapped"
## [39] "proportion_targets_no_coverage" "read_pair_number"
## [41] "revision" "stain_type"
## [43] "state" "state_comment"
## [45] "submitter_id" "tags"
## [47] "total_reads" "tumor_ploidy"
## [49] "tumor_purity" "type"
## [51] "updated_datetime" "wgs_coverage"
# The number of fields available for files endpoint
length(available_fields('files'))
## [1] 1021
# The first few fields available for files endpoint
head(available_fields('files'))
## [1] "access" "acl"
## [3] "analysis.analysis_id" "analysis.analysis_type"
## [5] "analysis.created_datetime" "analysis.input_files.access"
The fields to be returned by a query can be specified following a similar
paradigm to that of the dplyr package. The select()
function is a verb that
resets the fields slot of a GDCQuery
; note that this is not quite analogous to
the dplyr select()
verb that limits from already-present fields. We
completely replace the fields when using select()
on a GDCQuery
.
# Default fields here
qcases = cases()
qcases$fields
## [1] "aliquot_ids" "analyte_ids"
## [3] "case_autocomplete" "case_id"
## [5] "consent_type" "created_datetime"
## [7] "days_to_consent" "days_to_lost_to_followup"
## [9] "diagnosis_ids" "disease_type"
## [11] "index_date" "lost_to_followup"
## [13] "portion_ids" "primary_site"
## [15] "sample_ids" "slide_ids"
## [17] "state" "submitter_aliquot_ids"
## [19] "submitter_analyte_ids" "submitter_diagnosis_ids"
## [21] "submitter_id" "submitter_portion_ids"
## [23] "submitter_sample_ids" "submitter_slide_ids"
## [25] "updated_datetime"
# set up query to use ALL available fields
# Note that checking of fields is done by select()
qcases = cases() %>% GenomicDataCommons::select(available_fields('cases'))
head(qcases$fields)
## [1] "case_id" "aliquot_ids"
## [3] "analyte_ids" "annotations.annotation_id"
## [5] "annotations.case_id" "annotations.case_submitter_id"
Finding fields of interest is such a common operation that the
GenomicDataCommons includes the grep_fields()
function.
See the appropriate help pages for details.
The GDC API offers a feature known as aggregation or faceting. By
specifying one or more fields (of appropriate type), the GDC can
return to us a count of the number of records matching each potential
value. This is similar to the R table
method. Multiple fields can be
returned at once, but the GDC API does not have a cross-tabulation
feature; all aggregations are only on one field at a time. Results of
aggregation()
calls come back as a list of data.frames (actually,
tibbles).
# total number of files of a specific type
res = files() %>% facet(c('type','data_type')) %>% aggregations()
res$type
Using aggregations()
is an also easy way to learn the contents of individual
fields and forms the basis for faceted search pages.
[ GDC filtering
documentation ]
The GenomicDataCommons package uses a form of non-standard evaluation to specify R-like queries that are then translated into an R list. That R list is, upon calling a method that fetches results from the GDC API, translated into the appropriate JSON string. The R expression uses the formula interface as suggested by Hadley Wickham in his vignette on non-standard evaluation
It’s best to use a formula because a formula captures both the expression to evaluate and the environment where the evaluation occurs. This is important if the expression is a mixture of variables in a data frame and objects in the local environment [for example].
For the user, these details will not be too important except to note that a filter expression must begin with a “~”.
qfiles = files()
qfiles %>% count() # all files
## [1] 1003747
To limit the file type, we can refer back to the section on faceting to see the possible values for the file field “type”. For example, to filter file results to only “gene_expression” files, we simply specify a filter.
qfiles = files() %>% filter( type == 'gene_expression')
# here is what the filter looks like after translation
str(get_filter(qfiles))
## List of 2
## $ op : 'scalar' chr "="
## $ content:List of 2
## ..$ field: chr "type"
## ..$ value: chr "gene_expression"
What if we want to create a filter based on the project (‘TCGA-OVCA’, for example)? Well, we have a couple of possible ways to discover available fields. The first is based on base R functionality and some intuition.
grep('pro',available_fields('files'),value=TRUE) %>%
head()
## [1] "analysis.input_files.proc_internal"
## [2] "analysis.input_files.proportion_base_mismatch"
## [3] "analysis.input_files.proportion_coverage_10X"
## [4] "analysis.input_files.proportion_coverage_10x"
## [5] "analysis.input_files.proportion_coverage_30X"
## [6] "analysis.input_files.proportion_coverage_30x"
Interestingly, the project information is “nested” inside the case. We don’t need to know that detail other than to know that we now have a few potential guesses for where our information might be in the files records. We need to know where because we need to construct the appropriate filter.
files() %>%
facet('cases.project.project_id') %>%
aggregations() %>%
head()
## $cases.project.project_id
## doc_count key
## 1 54096 FM-AD
## 2 58776 TCGA-BRCA
## 3 66476 CPTAC-3
## 4 38590 TARGET-AML
## 5 31298 TCGA-LUAD
## 6 28343 TCGA-UCEC
## 7 29249 TCGA-HNSC
## 8 27881 TCGA-OV
## 9 28166 TCGA-THCA
## 10 29137 TCGA-KIRC
## 11 28589 TCGA-LUSC
## 12 28375 TCGA-LGG
## 13 36470 GENIE-MSK
## 14 27615 TCGA-PRAD
## 15 24991 TCGA-COAD
## 16 22719 TCGA-GBM
## 17 24808 TCGA-STAD
## 18 24437 TCGA-SKCM
## 19 22697 TCGA-BLCA
## 20 28464 GENIE-DFCI
## 21 27014 MMRF-COMMPASS
## 22 20162 TCGA-LIHC
## 23 17584 TARGET-ALL-P2
## 24 15890 TCGA-CESC
## 25 15921 TCGA-KIRP
## 26 14184 TCGA-SARC
## 27 18052 HCMI-CMDC
## 28 11973 MP2PRT-ALL
## 29 10645 CGCI-BLGSP
## 30 14968 BEATAML1.0-COHORT
## 31 9996 TCGA-ESCA
## 32 9981 TCGA-PAAD
## 33 9623 TCGA-PCPG
## 34 8631 TCGA-READ
## 35 11553 REBC-THYR
## 36 8786 TCGA-TGCT
## 37 8656 TCGA-LAML
## 38 9244 CPTAC-2
## 39 6576 TCGA-THYM
## 40 5705 TARGET-NBL
## 41 5856 CGCI-HTMCP-CC
## 42 4746 TCGA-ACC
## 43 4345 TCGA-KICH
## 44 4484 TCGA-MESO
## 45 4257 TCGA-UVM
## 46 5454 CMI-MBC
## 47 5286 NCICCR-DLBCL
## 48 2532 TARGET-WT
## 49 2972 TARGET-OS
## 50 3095 TCGA-UCS
## 51 3625 TARGET-ALL-P3
## 52 3857 GENIE-MDA
## 53 3833 GENIE-VICC
## 54 2528 TCGA-DLBC
## 55 2486 TCGA-CHOL
## 56 3320 GENIE-JHU
## 57 2632 GENIE-UHN
## 58 1712 CGCI-HTMCP-DLBCL
## 59 1826 EXCEPTIONAL_RESPONDERS-ER
## 60 1747 CDDP_EAGLE-1
## 61 1571 MP2PRT-WT
## 62 1455 APOLLO-LUAD
## 63 1036 TARGET-RT
## 64 1305 CMI-MPC
## 65 1093 WCDT-MCRPC
## 66 896 CGCI-HTMCP-LC
## 67 1038 GENIE-GRCC
## 68 878 OHSU-CNL
## 69 875 MATCH-Z1D
## 70 806 CMI-ASC
## 71 832 MATCH-Q
## 72 801 GENIE-NKI
## 73 798 MATCH-B
## 74 775 MATCH-Y
## 75 758 ORGANOID-PANCREATIC
## 76 553 CTSP-DLBCL1
## 77 495 MATCH-N
## 78 339 TRIO-CRU
## 79 185 TARGET-CCSK
## 80 222 BEATAML1.0-CRENOLANIB
## 81 101 TARGET-ALL-P1
## 82 21 VAREPOP-APOLLO
We note that cases.project.project_id
looks like it is a good fit. We also
note that TCGA-OV
is the correct project_id, not TCGA-OVCA
. Note that
unlike with dplyr and friends, the filter()
method here replaces the
filter and does not build on any previous filters.
qfiles = files() %>%
filter( cases.project.project_id == 'TCGA-OV' & type == 'gene_expression')
str(get_filter(qfiles))
## List of 2
## $ op : 'scalar' chr "and"
## $ content:List of 2
## ..$ :List of 2
## .. ..$ op : 'scalar' chr "="
## .. ..$ content:List of 2
## .. .. ..$ field: chr "cases.project.project_id"
## .. .. ..$ value: chr "TCGA-OV"
## ..$ :List of 2
## .. ..$ op : 'scalar' chr "="
## .. ..$ content:List of 2
## .. .. ..$ field: chr "type"
## .. .. ..$ value: chr "gene_expression"
qfiles %>% count()
## [1] 858
Asking for a count()
of results given these new filter criteria gives r qfiles %>% count()
results. Filters can be chained (or nested) to
accomplish the same effect as multiple &
conditionals. The count()
below is equivalent to the &
filtering done above.
qfiles2 = files() %>%
filter( cases.project.project_id == 'TCGA-OV') %>%
filter( type == 'gene_expression')
qfiles2 %>% count()
## [1] 858
(qfiles %>% count()) == (qfiles2 %>% count()) #TRUE
## [1] TRUE
Generating a manifest for bulk downloads is as simple as asking for the manifest from the current query.
manifest_df = qfiles %>% manifest()
head(manifest_df)
Note that we might still not be quite there. Looking at filenames, there are
suspiciously named files that might include “FPKM”, “FPKM-UQ”, or “counts”.
Another round of grep
and available_fields
, looking for “type” turned up
that the field “analysis.workflow_type” has the appropriate filter criteria.
qfiles = files() %>% filter( ~ cases.project.project_id == 'TCGA-OV' &
type == 'gene_expression' &
access == "open" &
analysis.workflow_type == 'STAR - Counts')
manifest_df = qfiles %>% manifest()
nrow(manifest_df)
## [1] 429
The GDC Data Transfer Tool can be used (from R, transfer()
or from the
command-line) to orchestrate high-performance, restartable transfers of all the
files in the manifest. See the bulk downloads section for
details.
[ GDC authentication documentation ]
The GDC offers both “controlled-access” and “open” data. As of this writing, only data stored as files is “controlled-access”; that is, metadata accessible via the GDC is all “open” data and some files are “open” and some are “controlled-access”. Controlled-access data are only available after going through the process of obtaining access.
After controlled-access to one or more datasets has been granted, logging into the GDC web portal will allow you to access a GDC authentication token, which can be downloaded and then used to access available controlled-access data via the GenomicDataCommons package.
The GenomicDataCommons uses authentication tokens only for downloading
data (see transfer
and gdcdata
documentation). The package
includes a helper function, gdc_token
, that looks for the token to
be stored in one of three ways (resolved in this order):
GDC_TOKEN
GDC_TOKEN_FILE
.gdc_token
As a concrete example:
token = gdc_token()
transfer(...,token=token)
# or
transfer(...,token=get_token())
The gdcdata
function takes a character vector of one or more file
ids. A simple way of producing such a vector is to produce a
manifest
data frame and then pass in the first column, which will
contain file ids.
fnames = gdcdata(manifest_df$id[1:2],progress=FALSE)
Note that for controlled-access data, a
GDC authentication token is required. Using the
BiocParallel
package may be useful for downloading in parallel,
particularly for large numbers of smallish files.
The bulk download functionality is only efficient (as of v1.2.0 of the GDC Data Transfer Tool) for relatively large files, so use this approach only when transferring BAM files or larger VCF files, for example. Otherwise, consider using the approach shown above, perhaps in parallel.
# Requires gcd_client command-line utility to be isntalled
# separately.
fnames = gdcdata(manifest_df$id[3:10], access_method = 'client')
res = cases() %>% facet("project.project_id") %>% aggregations()
head(res)
## $project.project_id
## doc_count key
## 1 18004 FM-AD
## 2 16824 GENIE-MSK
## 3 14232 GENIE-DFCI
## 4 3857 GENIE-MDA
## 5 3320 GENIE-JHU
## 6 2632 GENIE-UHN
## 7 2492 TARGET-AML
## 8 2052 GENIE-VICC
## 9 1587 TARGET-ALL-P2
## 10 1507 MP2PRT-ALL
## 11 1235 CPTAC-3
## 12 1132 TARGET-NBL
## 13 1098 TCGA-BRCA
## 14 1038 GENIE-GRCC
## 15 995 MMRF-COMMPASS
## 16 826 BEATAML1.0-COHORT
## 17 801 GENIE-NKI
## 18 652 TARGET-WT
## 19 617 TCGA-GBM
## 20 608 TCGA-OV
## 21 585 TCGA-LUAD
## 22 560 TCGA-UCEC
## 23 537 TCGA-KIRC
## 24 528 TCGA-HNSC
## 25 516 TCGA-LGG
## 26 507 TCGA-THCA
## 27 504 TCGA-LUSC
## 28 500 TCGA-PRAD
## 29 489 NCICCR-DLBCL
## 30 470 TCGA-SKCM
## 31 461 TCGA-COAD
## 32 443 TCGA-STAD
## 33 440 REBC-THYR
## 34 412 TCGA-BLCA
## 35 383 TARGET-OS
## 36 377 TCGA-LIHC
## 37 342 CPTAC-2
## 38 339 TRIO-CRU
## 39 324 CGCI-BLGSP
## 40 307 TCGA-CESC
## 41 291 TCGA-KIRP
## 42 263 TCGA-TGCT
## 43 261 TCGA-SARC
## 44 259 HCMI-CMDC
## 45 212 CGCI-HTMCP-CC
## 46 200 CMI-MBC
## 47 200 TCGA-LAML
## 48 191 TARGET-ALL-P3
## 49 185 TCGA-ESCA
## 50 185 TCGA-PAAD
## 51 179 TCGA-PCPG
## 52 176 OHSU-CNL
## 53 172 TCGA-READ
## 54 124 TCGA-THYM
## 55 113 TCGA-KICH
## 56 101 WCDT-MCRPC
## 57 92 TCGA-ACC
## 58 87 APOLLO-LUAD
## 59 87 TCGA-MESO
## 60 84 EXCEPTIONAL_RESPONDERS-ER
## 61 80 TCGA-UVM
## 62 70 CGCI-HTMCP-DLBCL
## 63 70 ORGANOID-PANCREATIC
## 64 69 TARGET-RT
## 65 63 CMI-MPC
## 66 58 TCGA-DLBC
## 67 57 TCGA-UCS
## 68 56 BEATAML1.0-CRENOLANIB
## 69 52 MP2PRT-WT
## 70 51 TCGA-CHOL
## 71 50 CDDP_EAGLE-1
## 72 45 CTSP-DLBCL1
## 73 39 CGCI-HTMCP-LC
## 74 36 CMI-ASC
## 75 36 MATCH-Z1D
## 76 35 MATCH-Q
## 77 33 MATCH-B
## 78 31 MATCH-Y
## 79 24 TARGET-ALL-P1
## 80 21 MATCH-N
## 81 13 TARGET-CCSK
## 82 7 VAREPOP-APOLLO
library(ggplot2)
ggplot(res$project.project_id,aes(x = key, y = doc_count)) +
geom_bar(stat='identity') +
theme(axis.text.x = element_text(angle = 45, hjust = 1))
cases() %>% filter(~ project.program.name=='TARGET') %>% count()
## [1] 6543
cases() %>% filter(~ project.program.name=='TCGA') %>% count()
## [1] 11428
# The need to do the "&" here is a requirement of the
# current version of the GDC API. I have filed a feature
# request to remove this requirement.
resp = cases() %>% filter(~ project.project_id=='TCGA-BRCA' &
project.project_id=='TCGA-BRCA' ) %>%
facet('samples.sample_type') %>% aggregations()
resp$samples.sample_type
# The need to do the "&" here is a requirement of the
# current version of the GDC API. I have filed a feature
# request to remove this requirement.
resp = cases() %>% filter(~ project.project_id=='TCGA-BRCA' &
samples.sample_type=='Solid Tissue Normal') %>%
GenomicDataCommons::select(c(default_fields(cases()),'samples.sample_type')) %>%
response_all()
count(resp)
## [1] 162
res = resp %>% results()
str(res[1],list.len=6)
## List of 1
## $ id: chr [1:162] "17baef7c-d97d-4b98-ab53-503ef856523d" "ef4cbd38-bc79-4d60-a715-647edd2ebe9e" "f06f09f3-8133-4a92-ac86-fbe64295e0d8" "f2bbfa9d-9a9d-4f46-9fde-378e4c44e2ad" ...
head(ids(resp))
## [1] "17baef7c-d97d-4b98-ab53-503ef856523d"
## [2] "ef4cbd38-bc79-4d60-a715-647edd2ebe9e"
## [3] "f06f09f3-8133-4a92-ac86-fbe64295e0d8"
## [4] "f2bbfa9d-9a9d-4f46-9fde-378e4c44e2ad"
## [5] "7875018b-91dc-4ab1-83b0-ee3883e2816e"
## [6] "7b892055-c59d-4550-8688-ad039790af3d"
cases() %>%
GenomicDataCommons::filter(~ project.program.name == 'TCGA' &
"cases.demographic.gender" %in% "female") %>%
GenomicDataCommons::results(size = 4) %>%
ids()
## [1] "0030a28c-81aa-44b0-8be0-b35e1dcbf98c"
## [2] "14213209-2217-4812-9a19-d9b2b6718467"
## [3] "15850852-5979-419d-ae38-76ffd0e9d7e8"
## [4] "0775583e-c0a0-4f18-9ca2-8f89cedce3d6"
cases() %>%
GenomicDataCommons::filter(~ project.project_id == 'TCGA-COAD' &
"cases.demographic.gender" %exclude% "female") %>%
GenomicDataCommons::results(size = 4) %>%
ids()
## [1] "01ad5016-f691-4bca-82a0-910429d8d25b"
## [2] "022f39e9-57ee-4b2b-8b3a-8929e3d69a37"
## [3] "03efbc94-a43d-4db0-9377-e397348430a6"
## [4] "04d7a52f-a89b-4114-a608-a6254b4d604f"
cases() %>%
GenomicDataCommons::filter(~ project.program.name == 'TCGA' &
missing("cases.demographic.gender")) %>%
GenomicDataCommons::results(size = 4) %>%
ids()
## [1] "91544f6b-90b6-45df-a501-3097fe0c74be"
## [2] "d495fa6d-8dbb-46ab-8743-b3d42c06b7a3"
## [3] "d682d35c-0ec5-4e6e-8349-ac2e39bec86f"
## [4] "24506980-2857-4069-9af3-79ce4527eb00"
cases() %>%
GenomicDataCommons::filter(~ project.program.name == 'TCGA' &
!missing("cases.demographic.gender")) %>%
GenomicDataCommons::results(size = 4) %>%
ids()
## [1] "0030a28c-81aa-44b0-8be0-b35e1dcbf98c"
## [2] "14213209-2217-4812-9a19-d9b2b6718467"
## [3] "15850852-5979-419d-ae38-76ffd0e9d7e8"
## [4] "0775583e-c0a0-4f18-9ca2-8f89cedce3d6"
res = files() %>% facet('type') %>% aggregations()
res$type
ggplot(res$type,aes(x = key,y = doc_count)) + geom_bar(stat='identity') +
theme(axis.text.x = element_text(angle = 45, hjust = 1))
q = files() %>%
GenomicDataCommons::select(available_fields('files')) %>%
filter(~ cases.project.project_id=='TCGA-GBM' &
data_type=='Gene Expression Quantification')
q %>% facet('analysis.workflow_type') %>% aggregations()
## list()
# so need to add another filter
file_ids = q %>% filter(~ cases.project.project_id=='TCGA-GBM' &
data_type=='Gene Expression Quantification' &
analysis.workflow_type == 'STAR - Counts') %>%
GenomicDataCommons::select('file_id') %>%
response_all() %>%
ids()
I need to figure out how to do slicing reproducibly in a testing environment and for vignette building.
q = files() %>%
GenomicDataCommons::select(available_fields('files')) %>%
filter(~ cases.project.project_id == 'TCGA-GBM' &
data_type == 'Aligned Reads' &
experimental_strategy == 'RNA-Seq' &
data_format == 'BAM')
file_ids = q %>% response_all() %>% ids()
bamfile = slicing(file_ids[1],regions="chr12:6534405-6538375",token=gdc_token())
library(GenomicAlignments)
aligns = readGAlignments(bamfile)
Error in curl::curl_fetch_memory(url, handle = handle) :
SSL connect error
openssl
to version
1.0.1 or later.
openssl
, reinstall the R curl
and httr
packages.sessionInfo()
## R version 4.3.1 (2023-06-16)
## Platform: x86_64-pc-linux-gnu (64-bit)
## Running under: Ubuntu 22.04.3 LTS
##
## Matrix products: default
## BLAS: /home/biocbuild/bbs-3.17-bioc/R/lib/libRblas.so
## LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.10.0
##
## locale:
## [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
## [3] LC_TIME=en_GB LC_COLLATE=C
## [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
## [7] LC_PAPER=en_US.UTF-8 LC_NAME=C
## [9] LC_ADDRESS=C LC_TELEPHONE=C
## [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
##
## time zone: America/New_York
## tzcode source: system (glibc)
##
## attached base packages:
## [1] stats graphics grDevices utils datasets methods base
##
## other attached packages:
## [1] ggplot2_3.4.3 GenomicDataCommons_1.24.3
## [3] magrittr_2.0.3 knitr_1.43
## [5] BiocStyle_2.28.0
##
## loaded via a namespace (and not attached):
## [1] rappdirs_0.3.3 sass_0.4.7 utf8_1.2.3
## [4] generics_0.1.3 tidyr_1.3.0 bitops_1.0-7
## [7] xml2_1.3.5 hms_1.1.3 digest_0.6.33
## [10] grid_4.3.1 evaluate_0.21 bookdown_0.35
## [13] fastmap_1.1.1 jsonlite_1.8.7 GenomeInfoDb_1.36.2
## [16] BiocManager_1.30.22 httr_1.4.7 purrr_1.0.2
## [19] fansi_1.0.4 scales_1.2.1 jquerylib_0.1.4
## [22] cli_3.6.1 rlang_1.1.1 crayon_1.5.2
## [25] XVector_0.40.0 munsell_0.5.0 withr_2.5.0
## [28] cachem_1.0.8 yaml_2.3.7 tools_4.3.1
## [31] tzdb_0.4.0 dplyr_1.1.3 colorspace_2.1-0
## [34] GenomeInfoDbData_1.2.10 BiocGenerics_0.46.0 curl_5.0.2
## [37] vctrs_0.6.3 R6_2.5.1 magick_2.7.5
## [40] stats4_4.3.1 lifecycle_1.0.3 zlibbioc_1.46.0
## [43] S4Vectors_0.38.1 IRanges_2.34.1 pkgconfig_2.0.3
## [46] gtable_0.3.4 pillar_1.9.0 bslib_0.5.1
## [49] Rcpp_1.0.11 glue_1.6.2 highr_0.10
## [52] xfun_0.40 tibble_3.2.1 GenomicRanges_1.52.0
## [55] tidyselect_1.2.0 farver_2.1.1 htmltools_0.5.6
## [58] labeling_0.4.3 rmarkdown_2.24 readr_2.1.4
## [61] compiler_4.3.1 RCurl_1.98-1.12
S3
object-oriented programming paradigm is used.