## 2 Methods
### Metadata Extraction And Composition  
The content of an OpenGDC metadata file is obtained by taking into account:  
1. the BCR _Biospecimen_ and _Clinical Supplements_,
2. the information retrieved through the GDC APIs,
3. additional manually curated attributes computed within our standardization pipelines. Given a converted experimental data file in free-BED format, identified by an _opengdc_id_, the corresponding metadata file is generated according to the pipeline shown in Figure 1.  
Figure 1: Metadata pipeline overview. The procedure starts with the download of the _Biospecimen_ and _Clinical Supplement_ files by using the Genomic Data Commons (GDC) application programming interfaces (APIs) according to a _patient uuid_. Aliquot uuids are extracted from the Biospecimen Supplement file, whose content is split by aliquot. Based on these _aliquot uuids_ and their associated _data types_, the _GDC Data Model_ is queried through the GDC APIs, in order to obtain additional metadata information. Finally, inside a unique metadata file, we merge together: clinical data, a portion of biospecimen data, GDC Data Model metadata, and manually curated attributes (automatically generated by the pipeline). The obtained metadata attributes and their values are processed by two additional components of the pipeline: the _Data redundancy solver_, which deals with removing redundant attributes and their values, and the _Data renaming module_, which applies rules for renaming attributes. The remaining and possibly renamed attributes, along with their values, compose the final OpenGDC metadata file. On the top left corner of Figure 1, we consider **Biospecimen and Clinical Supplements**; they are organized by _patient_ (identified by the _bcr_patient_uuid_ attribute), with a patient typically related to many aliquots. Multiple OpenGDC metadata files are created, one for each aliquot reported in the patient biospecimen file. We replicate the full content of the Clinical Supplement of a patient over all metadata files regarding the aliquots of the patient. The resulting metadata attribute keys start with the _clinical_ prefix. A Biospecimen Supplement, instead, contains a unique section on the patient, but also distinct sections on multiple samples, their portions, and the resulting aliquots. In each aliquot metadata file we replicate the common parts about the patient (and, in case, about related samples/portions), while the remaining content of the biospecimen file is divided among the different metadata files according to the specific aliquot each of them refers to. The resulting metadata attribute keys start with the _biospecimen_ prefix. On the bottom left corner of Figure 1, we query **GDC Data Model elements** using the GDC RESTful APIs. We call the API services once for each aliquot listed in a Biospecimen Supplement and each data type of interest, by specifying the _aliquot uuid_ and the _data type_, and then associate with each OpenGDC data file all information retrieved in the obtained response. The extracted attributes describe a data file along different GDC Data Model conceptual areas (i.e., administrative, biological, clinical and analysis). Relevant administrative entities include the Program (i.e., the broad framework of goals to be achieved by multiple experiments, such as TCGA), the Project (i.e., the specifically defined piece of work that is undertaken or attempted to meet a single requirement, such as TCGA-LAML--which refers to Acute Myeloid Leukemia), the Case (i.e., the collection of all data related to a specific subject in the context of a specific project, such as a patient). Among biological entities there are Sample (i.e., any material sample taken from a biological entity for testing, diagnostic, propagation, treatment, or research purposes) and Aliquot (i.e., pertaining to a portion of the whole; any one of two or more samples of something, of the same volume or weight).