Customizing dccvalidator

dccvalidator is intended customizable for different settings, however the built-in Shiny application is designed to ensure that data conforms to a specific project organization structure in which data is organized into studies that are described with a combination of metadata files. These metadata files document the individuals, specimens, and assay(s) that were performed in the study. Documenting the data in this way allows researchers to describe the study at different levels while minimizing repetition. These metadata files can later be joined on the individualID and specimenID columns to create a table of all of the metadata for the study.

For projects like AMP-AD, PsychENCODE, and others that follow the same structure, see the next section (“Customizing the Shiny application”) for how configure an instance of the application for the project.

For projects that do not follow the same structure but wish to use some elements of dccvalidator’s data validation capabilities, see “Extending dccvalidator” below.

Customizing the Shiny application

The Shiny app uses a configuration file to set details such as where to store uploaded files, which metadata templates to validate against, whom to contact with questions, etc.

To create a custom version of the app, you’ll need to follow these steps:

  1. Create a Synapse project or folder with the appropriate permissions to store uploaded files. In AMP-AD, we created a folder to which consortium members have permissions to read and write, but not download. Only the curation team has the ability to download files (in order to assist with debugging). See this example of how to create a project with appropriate permissions.
  2. Fork the dccvalidator GitHub repository.
  3. Create a new configuration in the config.yml file. Note that any values you do not customize will be inherited from the default configuration. The configuration file must have a default configuration.
  4. (Optional): create a pull request with your configuration back to the upstream dccvalidator repository.
  5. Within the file app.R, replace the "default" configuration with the name of your new configuration.
  6. Deploy the application as described in the Deploying dccvalidator vignette.

To install the dccvalidator instead of forking the repository:

  1. Create an app.R file containing the following:

    library("dccvalidator")
    run_app()
  2. Create a config.yml file using the configuration options specified below and name the parameters “default”.

    default:
    parent: "syn20400157"
  3. Create a Synapse project or folder with the appropriate permissions to store uploaded files. In AMP-AD, we created a folder to which consortium members have permissions to read and write, but not download. Only the curation team has the ability to download files (in order to assist with debugging). See this example of how to create a project with appropriate permissions.

Configuration options

Extending dccvalidator

Users who wish to use dccvalidator for projects that do not follow the same structure as AMP-AD and PsychENCODE can do so by reusing the existing validation functions in their own R code, implementing new checks as needed, and reusing Shiny modules from dccvalidator.

Using validation functions in scripts

Functions to check data for common quality issues are at the core of dccvalidator. These functions in dccvalidator are all named with the pattern check_*(): check_annotation_keys(), check_annotation_values(), check_cols_empty(), etc. See the function reference for a complete list.

These functions are used in the dccvalidator Shiny app, but they can also be used in scripts or reports. Each function takes data as input and returns results in the form of custom condition objects. The condition objects inherit from R’s "message", "warning", and "error" classes. However, rather than raising a message/warning/error, the check functions in dccvalidator return the condition objects themselves.

The condition objects contain several useful pieces of information. There is a message describing the result of the check, as well as a message describing the expected outcome. For warnings and errors, the data that caused the warning or error is included.

Creating new validation functions

While we have functions for many data validation tasks, users may wish to create their own custom checking functions. The functions check_pass(), check_warn(), and check_fail() will create condition objects from the provided arguments. Here is an example of how one could write a custom function that checks if pH values are within an appropriate range.

The check_condition() function can make the above a little more concise:

Reusing app modules

The Shiny app that dccvalidator provides allows users to see the results of data validation. This module (results_boxes_server()/results_boxes_ui()) is exported from dccvalidator and can be reused in other Shiny applications like so: