Skip to main content

One Health VBD Hub Training 2026

2 Pre-Work

We are excited to welcome you to the One Health VBD Hub Training Event on 11th-13th November at Silwood Park.

Before the event, we would like you to complete this pre-work. This will help ensure everyone has a foundation understanding of the topics, and will be prepared to fully participate in the workshops.

The pre-work covers three sections:

  1. Navigating the VBD Hub
  2. Understanding Data Curation Standards
  3. Data Wrangling Principles

We ask that you complete these three sections, and ensure R, RStudio, and the relevant packages are installed on your device BEFORE the event.

The packages you will need for the workshops are:

  • ohvbd
  • tidyverse
  • dplyr
  • ggplot2

We will be using the VBD Hub Forum for additional support before and during the training, as well as informal chats and coordination. Please have it set up in advance, and follow this link to join. If you need help navigating the Forum, please see the video under 2.1.1 The VBD Hub Forum.

You will need to bring your own laptop to participate in the event. Make sure it is updated, and remember to bring your charger.

2.2 Understanding Data Curation and Standards

Throughout the Training Event, we will be using Hub curated datasets to practice the skills learnt. Although users cannot upload data directly through the VBD Hub at this time, understanding this process is helpful for interpreting the datasets you retrieve using tools such as the Hub Search and the ohvbd package.

Watch this short video outlining standard operating procedures when curating VBD data.

Video transcript

In this video, we will explore how data is shared, curated, and made available through the VBD Hub. Although users cannot upload data directly through the VBD Hub at this time, understanding this process is helpful for interpreting the datasets you retrieve using tools such as the Hub Search and the ohvbd package.

The VBD Hub resources bring together data from multiple sources, including databases such as VecDyn, VecTraits, and GBIF. Before being uploaded to these databases, datasets go through a process of curation, formatting, and standardisation to ensure the data is structured consistently. This consistency is what allows us to search across datasets, combine data from different sources, and use the VBD Hub data retrieval tools effectively. Understanding this process helps you to interpret the datasets you download, including:

  • Why the datasets follow a particular structure
  • How the variables are defined
  • How data from different sources is combined in a consistent way

Before any dataset is shared, the VBD Hub follows a structured Data Management Plan, which outlines how data should be handled from collection through to publication. This process begins when a new dataset is identified, either by a researcher or through community contribution.

  1. The first step is to determine whether the data are sensitive, for example, whether they include identifiable human data. Sensitive datasets may require additional data protection measures or working with the Hub curator before submitting to an appropriate repository.
  2. Next, the Hub assesses whether the data are ready for release. This includes checking whether the dataset meets publication requirements, or funder specifications.
  3. If the data are not yet ready for release, the Hub curator works with the data provider to prepare the dataset for release.
  4. If the data are ready for release the next step is to ensure ethical considerations are addressed, including data protection, and to apply appropriate metadata standards.
  5. Finally, the Hub determines whether the dataset should be hosted directly, or deposited into an external repository.

When sharing VBD data, it is important to consider the type of data being collected as different data types require different structures and standards. Data types might include:

  • Occurrence data
  • Abundance data
  • Trait data
  • Genomic data
  • Proteomic data
  • Microarray data
  • Transcriptomic data
  • Epidemiological data
  • Environmental data

Each of these data types follows specific standard operating procedures (or SOPs), which define how the data should be formatted and described. These SOPs help to ensure that datasets from different sources can be combined and compared within the database.

Occurrence data record where and when a species has been observed. For this data type, the VBD Hub recommends using standards based on Darwin Core, which is widely used for biodiversity data. This means datasets should include:

  • A confirmed species name using a recognised taxonomy
  • Geographic coordinates
  • A date of observation

Occurrence data are typically shared through platforms such as GBIF, which collate biodiversity records from around the world. Using Darwin Core ensures that your data can be integrated with these global systems and used in large-scale analyses of species distributions. Additional details, such as how the observation was made or who recorded it, are often included as metadata.

Abundance data describe how many individuals were collected at a given place and time. The VBD Hub formats these datasets for VecDyn, which focuses on vector population dynamics. To support this, datasets must clearly define:

  • Sampling start and end dates
  • Location identifiers
  • Sampling method, such as trap type
  • Sampling effort, such as number of traps
  • The units of abundance

These requirements ensure that abundance data can be interpreted clearly and used reliably with other datasets.

Trait data describe biological or ecological characteristics of a species. The VBD Hub recommends structuring these datasets for VecTraits, which is designed specifically for biological trait data. To ensure consistency, each record must include:

  • A clearly defined trait
  • Standardised units of measurement
  • The species the trait applies to
  • Context such as life stage, sex, or environmental conditions

Standardising trait definitions allows researchers to compare characteristics across species and studies.

Genomic data describe DNA sequences and genetic information. The VBD Hub recommends depositing these data in established repositories such as GenBank, with links available through the Hub. These datasets must include:

  • Sequence data in standard formats
  • Metadata describing the organism, sampling location, and methods
  • Links to associated publications or projects

Using established genomic repositories ensures long-term storage, accessibility, and integration with other molecular datasets.

Proteomic data describe the proteins expressed by an organism, helping us to understand biological function and response. These datasets are typically include:

  • Protein identifiers or names
  • Measurements of protein presence or abundance
  • Details of the experimental design

The VBD Hub recommends uploading proteomic data to ProteomeXchange, and provides links to the appropriate data submission guidelines.

Microarray data measure gene expression across many genes simultaneously. To be reusable, these datasets must include:

  • Raw and processed expression data
  • Clear descriptors of the experimental design
  • Information about the platform used

These datasets are often deposited in public gene expression repositories, ensuring they can be accessed and reanalysed by other researchers.

Transcriptomic data describe RNA expression, showing which genes are active under specific conditions. The VBD Hub recommends submitting these datasets to repositories such as the Sequence Read Archive (SRA), with guidelines linked through the Hub. The requirements for these repositories include:

  • RNA sequence data
  • Expression measurements
  • Experimental conditions and protocols

This information allows other researchers to interpret gene expression patterns and reuse the data in new analyses.

Epidemiological data describe disease occurrence and transmission in populations. These datasets often do not fit into a single external repository, so they may be hosted directly by the VBD Hub. They must clearly define:

  • Case definitions
  • Time and location of observations
  • The population being studied

These data may involve sensitive information, therefore ethical considerations and data protection are especially important.

Environmental data describe conditions such as climate, habitat, or land use. These datasets may be linked to external environmental databases or hosted within the Hub, depending on their structure. They must include:

  • The variables measured, such as temperature or rainfall
  • Units and measurement methods
  • Spatial and temporal resolution

These details are essential for linking environmental data with biological or epidemiological datasets in later analyses.

In this video, we have explored how data is shared, curated, and structured within the VBD Hub. Understanding these concepts provides important context for working with VBD data and helps you make better use of the resources available through the VBD Hub.

2.3 Data Wrangling Principles

Data wrangling is the process of cleaning, transforming, and organising raw data into a format that is suitable for analysis.

Throughout the Training Event, we will be using datasets retrieved from different sources. These sources might use inconsistent formats or unclear variable names, and therefore need to be wrangled before analysis.

Understanding data wrangling principles will help you organise your data into a usable format, making further analysis smoother and more reliable.

Before we start working with data in R, it is important to understand that data wrangling is not just a set of steps, but a process of making your data fit for your specific research question.

The choices you make when cleaning and transforming your data will directly influence your results, so it is important to apply consistent and thoughtful approaches.

Let’s have a look at some basic data wrangling techniques commonly applied to VBD datasets:

1. Understand Your Data First

Do: Explore your data before making any changes. We can look at the first few rows of our dataset using head(), which allows us to better understand our data, including checking the column names and data types.

Don’t: Jump straight into cleaning the data without fully understanding how it is formatted. Without understanding the data, you risk misinterpreting variables and accidentally removing useful data.

2. Save Your Raw Data

Do: Keep an unchanged version of the raw dataset so you can access a previous version if something goes wrong, reproduce your work, and verify your results.

Don’t: Overwrite your original data. When wrangling your data in R, assign your cleaned data to a new object: clean_data <- raw_data.

3. Use Clear & Consistent Naming

Do: Use informative column, model, and object names so you know what your object is explicitly. Clear naming makes your R workflow easier for others (and yourself) to understand. You can rename columns using the dplyr function rename():

clean_aedes_data <- clean_data |>
  rename(
    latitude = decimalLatitude,
    longitude = decimalLongitude
  )

In this function, the syntax works as: new_name = old_name.

Don’t: Use unclear names or names with messy formatting. Try to avoid spaces, special characters, or specific abbreviations.

4. Reformat Your Data

Do: Convert your data to long format for analysis, using the tidyr function pivot_longer().

clean_data <- clean_data |>
    pivot_longer(
      cols = starts_with("year"),
      names_to = "year",
      values_to = "abundance"
    )

We can break this down and have a look at what each part of this function is doing:

  • cols = starts_with("year") - This selects the columns we want to reshape. In this case, we are selecting any column that starts with “year”, (for example, year_2010, year_2011).
  • names_to = "year" - This creates a new column called year, which will store the names of the original columns. Instead of having separate columns like year_2010 and year_2011, those labels will now appear as values in a single column called year.
  • values_to = "abundance" - This creates a new column called abundance, which will store the data values that were previously spread across those year columns.

So instead of having one row with many year columns, we now have multiple rows where each row represents a single year-abundance observation.

In this format, each row represents a single observation, which can make the data easier to filter and analyse.

Don’t: Use data in wide format, where values are spread across multiple columns. This can limit data wrangling and processing, such as grouping across different years and generating effective visualisations.

Tip: Dealing with NAs after pivoting

When you convert data to long format, any empty cells in the wide data become rows with NA in the new values column. You can remove these rows by adding the argument values_drop_na = TRUE to your pivot_longer() code:

clean_aedes_data <- clean_aedes_data |>
    pivot_longer(
    cols = starts_with("year"),
    names_to = "year",
    values_to = "abundance",
    values_drop_na = TRUE
  )

Before using this argument, check what the NAs in your dataset actually mean:

  • The NAs come from the data’s wide format - If the empty cells only exist because of how the data was spread across columns, for example, a site that was not sampled in a particular year, the rows hold no information and it is safe to remove them.

  • The NAs are genuine missing data - If a value should exist but was not recorded, for example, a site was sampled but the count was missing, keep these rows. Removing them hides gaps in your data, which may affect your analysis and results.

Remember that NA is not the same as zero. A zero means no mosquitoes were found, but an NA means there is no information. Always look at your data after pivoting before deciding whether to remove NAs.

5. Record What You Do

Do: Keep track of your progress by recording what changes you made and why you used that approach. It is good practice to note these changes as comments in your code:

# Rename columns for clarity
# Convert data to long format for easier analysis

Don’t: Rely on memory alone. It is easy to forget what analytical methods you used, why you chose that approach, and what order you processed your data in. Keeping clear records of your workflow contributes to better reproducibility.

Frequent Mistake:

Try to avoid spaces, special characters, or specific abbreviations when naming objects in R.

There are a few options for alternative syntax, we would recommend: - Using camelCase where letters are capitalised to indicate new words (e.g. specificModelName). - Or using an underscore to connect words (e.g. specific_model_name).

If using camelCase, remember that R is case sensitive - if your object is named specificModelName, but you call specificmodelname, R will show an error:

Error: object ‘specificmodelname’ not found

Task: Applying Data Wrangling Principles to a Tick Dataset

Open the dataset ticktools_task.csv in RStudio. This is a VecDyn dataset containing counts of ticks collected at sites across England as part of the TickTools project, and is available through the VBD Hub. We have made some changes to the original dataset to give you the opportunity to practise these data wrangling skills.

Work through the following points:

  1. Inspect the dataset using head(). Notice what the columns represent, what the data types are, and whether there are any missing values.

  2. Rename your data as a new object. Any changes you make will use this new object, rather than the raw data.

  3. Rename at least two columns using rename().

  4. Check whether your dataset is in wide or long format. Use pivot_longer() if required.

  5. After pivoting, look at your data again and check for NAs. Think about what these values represent, and decide whether they should be removed.

  6. Add comments to your code explaining what changes you made and why.

The original VecDyn dataset, ticktools_original.csv, is already in long format, with clear and consistent column names. Each abundance count is stored in a single column, sample_value, rather than being spread across separate year columns. This is one of the benefits of using data from a curated repository - the data has already been standardised.

The original dataset also has many more columns than the task version, including information on taxonomy, sampling methods, and who collected the data. Some of these additional columns are empty, as not every study records every type of information. We will look at these columns in more detail during the Training Event.

You will now be familiar with some core data wrangling principles, which will prepare you for the Wrangling VBD Data workshop during the Training Event. In this workshop, we will cover a handful of essential wrangling techniques for VBD data.