ouladFormat: Preprocessing OULAD Data in R

• ouladFormat is an R package that prepares the Open University Learning Analytics Dataset (OULAD) by cleaning, merging, and reshaping multi-file data into a flat tibble.
• It standardizes preprocessing steps—filtering, joining, and transforming demographics, assessment, and VLE data—to support reproducible and comparable educational analysis.
• The toolkit offers various transformation options, such as VLE click scaling and learning classifications, to facilitate workflows like early identification of at-risk students.

Searching arXiv for the ouladFormat paper and closely related OULAD preprocessing work to ground the article with current metadata. ouladFormat is an R package for preparing the Open University Learning Analytics Dataset (OULAD) for analysis. It was introduced to reduce the preprocessing burden associated with OULAD, which contains anonymized data on 32,593 students across 22 module presentations from 7 modules at the Open University, and to return cleaner, analysis-ready outputs, typically as a single flat tibble where each row is a student (Howard, 14 Jan 2025). The package is positioned as data-wrangling infrastructure rather than a modeling framework: it loads and formats the OULAD for data analysis, cleans and reformats the original source tables, merges multiple OULAD tables, produces analysis-ready tibbles, and supports reproducibility and comparability across studies (Howard, 14 Jan 2025).

1. Definition and scope

ouladFormat addresses a practical obstacle in educational analytics: large real-world datasets are complex and can require intensive preprocessing. In the case of OULAD, that obstacle is especially visible because the dataset is publicly available and valuable for learning analytics and educational data mining, yet its complexity is itself a barrier (Howard, 14 Jan 2025). The package was therefore developed to make OULAD easier to use for research, teaching, and practical educational analytics, while leaving modeling and statistical analysis to downstream R workflows.

The package does not perform modeling or statistical analysis itself. Its role is data preparation. After preprocessing, its outputs can be used with other R packages for descriptive statistics, visualization, machine learning, or prediction (Howard, 14 Jan 2025). In that sense, ouladFormat is best understood as an infrastructure layer for educational analytics, analogous in function to packages that standardize access to other complex platform datasets.

The package is available on CRAN and can be installed with:

install.packages("ouladFormat")

All outputs are returned as tibbles, that is, tidyverse-style data frames (Howard, 14 Jan 2025).

2. OULAD schema and the preprocessing problem

As described for ouladFormat, OULAD is organized as a database schema across seven files, with information spanning four broad categories: Demographics, Registration, Assessment, and VLE (Virtual Learning Environment) (Howard, 14 Jan 2025). The package discussion focuses on the following source tables/files:

• studentInfo
• studentRegistration
• assessments
• studentAssessment
• studentVle
• vle

The demographic component is drawn from studentInfo and includes variables such as id_student, code_module, code_presentation, gender, region, highest_education, imd_band, age_band, num_of_prev_attempts, studied_credits, disability, and final_result. The paper highlights imd_band as “the index of multiple deprivation band of the place where the student lived during a module-presentation” (Howard, 14 Jan 2025).

The registration component is drawn from studentRegistration and includes id_student, code_module, code_presentation, registration timing, and unregistration timing, notably date_unregistration. The assessment component is built from assessments and studentAssessment, with fields including id_assessment, assessment_type, due date, weight, date_submitted, score, is_banked, derived week, and derived reactivity. The VLE component is built from studentVle and optionally enriched using vle, with variables such as id_student, id_site, date, and sum_click; the vle file provides activity classifications such as homepage, oucontent, and forumng (Howard, 14 Jan 2025).

The preprocessing challenge is not only the multiplicity of files but also the substantive irregularities of educational records. OULAD is spread across multiple related files rather than a single analysis table; VLE data are especially large and time-indexed; assessment data must be joined and filtered carefully; students may repeat modules or withdraw partway through a presentation; and not every student appears in every file, so sample size changes depending on what data are requested (Howard, 14 Jan 2025). A concrete example is given for the DDD-2013J module presentation: there are 1,938 students with registration data, 1,507 students with assessment data, and 1,503 students with data across all four categories. One student, 3733, unregistered on day -8, that is, eight days before teaching began, so no assessment data exist for that student; if assessment-inclusive data are requested, that student disappears from the output (Howard, 14 Jan 2025).

A plausible implication is that ouladFormat is as much about analytical consistency as convenience. Standardizing recurrent preprocessing decisions—such as filtering by module and presentation, resolving repeated students, handling withdrawn students, selecting a time window for assessment or VLE data, reshaping long event data into wide student-level features, and combining categories into one flat dataset—directly affects reproducibility (Howard, 14 Jan 2025).

3. Package architecture and function taxonomy

The package contains ten functions, grouped into four purposes (Howard, 14 Jan 2025).

Purpose	Functions
Loading support	load_github_modified(), path_to_file()
Load specific data	dataset_demographics(), dataset_registration(), dataset_assessment(), dataset_VLE_time(), dataset_VLE_activity()
VLE format conversion	convert_VLE(), VLE_learning_classification()
Combine datasets	combined_dataset()

The paper stresses a hierarchical architecture in which the main function combined_dataset() calls the others. A substantial number of workflows can therefore be expressed through a single high-level call, although the lower-level functions remain useful when one wishes to inspect one source category in isolation (Howard, 14 Jan 2025).

The package does not store the full OULAD internally. Instead, for use with the package, OULAD is stored as a series of .RData files on GitHub, organized according to the OULAD schema. The function load_github_modified() loads .RData files directly from GitHub into a specified environment; the paper notes that it was modified so the user can choose the environment, allowing package functions to load data into the local function environment rather than polluting the global workspace (Howard, 14 Jan 2025). The function path_to_file() provides access to a bundled sample of student VLE data—5,000 rows from the AAA-2013J presentation—included because the full VLE data are too large for lightweight CRAN examples (Howard, 14 Jan 2025).

The five “specific data” functions share three core parameters: module, presentation, and repeat_students. Modules are listed as Social Sciences: AAA, BBB, GGG; and STEM: CCC, DDD, EEE, FFF. Presentations are 2013B, 2013J, 2014B, and 2014J, where B indicates a February start and J indicates an October start. Both module and presentation can take "All" in many functions, and the package errors if the requested presentation does not exist for the selected module. The repeat_students argument controls whether students who repeated a module are "remove" or "keep"; the paper notes that in combined_dataset(), if presentation = "All", repeat students are always removed (Howard, 14 Jan 2025).

4. Category-specific dataset construction

dataset_demographics() loads and formats the OULAD studentInfo file, with minimal changes. It returns the demographic subset matching the requested module, presentation, and repeat-student filter. dataset_registration() performs the corresponding operation for studentRegistration, again with minimal modification (Howard, 14 Jan 2025). These two functions preserve the original student-level covariate structure while making it directly accessible for downstream analysis.

dataset_assessment() performs the most extensive restructuring. In addition to the three core parameters, it accepts week_begin, week_end, and na.rm, which define the period of the semester to include in the returned assessment outputs (Howard, 14 Jan 2025). The function returns a list containing:

• assessment_data
• assessments
• assessment_performance
• assessment_reactivity
• plus the selected module, presentation, and repeat_students

assessment_data is the merged long-form data from studentAssessment and assessments, filtered to the requested time window. assessments returns the full assessment schedule for the chosen module-presentation, including derived week. For DDD-2013J, the paper notes six continuous assessments, tutor-marked, with weights 10%, 12.5%, 17.5%, 20%, 20%, and 20%, due in weeks 4, 8, 13, 18, 24, and 30, plus an exam in week 38 (Howard, 14 Jan 2025).

assessment_performance is a student-level wide tibble in which each row is a student and each assessment becomes a separate column, named by id_assessment. Scores are on the 0–100 scale. It also computes average_CA_score, the student’s average weighted continuous assessment score for the included CA items. Exam scores are not included in average_CA_score. If a student did not submit an assessment, OULAD records NA; the user may decide whether missing assessment scores are excluded from the calculation (na.rm = TRUE) or replaced by 0, which is the default behavior implied by na.rm = FALSE (Howard, 14 Jan 2025). assessment_reactivity is another student-level wide tibble that stores reactivity values rather than scores. The paper defines reactivity, following Treuiller and Boyer, as “the delay between the date the assessment is returned and the deadline (in days).” Negative values mean the submission was overdue (Howard, 14 Jan 2025).

The two VLE loaders provide complementary analytical views. dataset_VLE_time() formats studentVle into student-level engagement summaries over time and accepts week_begin, week_end, and example_data. It returns filtered raw VLE event data, daily student-level VLE summaries, weekly student-level VLE summaries, the module/presentation/repeat settings, and the actual returned week_begin and week_end after filtering (Howard, 14 Jan 2025). The weekly output contains variables such as Week_pre-3, Week_pre-2, Week_pre-1, Week1, and Week2, supporting temporal learning analytics and early warning systems.

dataset_VLE_activity() uses studentVle plus vle to group clicks by resource/activity classification rather than by time. It returns a student-level tibble with counts of VLE accesses by activity category, including labels such as homepage, oucontent, and forumng (Howard, 14 Jan 2025). This representation privileges activity type over temporal sequence.

5. VLE transformations and the combined dataset workflow

Raw VLE click counts can have problematic distributions and scales, and ouladFormat therefore includes dedicated transformation functions. convert_VLE() changes VLE data from total counts into alternative formats: binary, standardised by variable, standardised globally, and logarithmic. The valid values documented are "total", "binary", "standardise1", "standardise2", and "logarithmic" (Howard, 14 Jan 2025). The paper explicitly motivates these conversions by noting that some methods, such as $k$-means, are sensitive to differences in scale and variance.

VLE_learning_classification() remaps original VLE activity types into broader pedagogical classifications used in prior studies. The supported classification schemes are FSLM, FSLSM, VARK, and OLS (Howard, 14 Jan 2025). The function returns both the mapping used and a tibble of VLE data aggregated according to the selected classification, enabling theory-driven feature engineering rather than only raw interaction counting.

The package’s centerpiece is combined_dataset(), which returns a single combined tibble, formatted for analysis, with one row per unique student (Howard, 14 Jan 2025). The function signature reported in the paper is:

combined_dataset( module = c("AAA", "BBB", "CCC", "DDD", "EEE", "FFF", "GGG"), presentation = c("2013J", "2014J", "2013B", "2014B", "All"), repeat_students = c("remove", "keep"), withdrawn_students = c("remove", "keep"), demographics = FALSE, registration = FALSE, VLE = c("omit", "daily", "weekly", "activity", "FSLM", "FSLSM", "OLS", "VARK"), VLE_clicks = c("total", "binary", "standardise1", "standardise2", "logarithmic"), week_begin = -4, week_end = 39, assessment = FALSE, na.rm = FALSE, example_data = FALSE )

This design exposes several substantive controls. Users can selectively include demographics, registration, assessment, and VLE data. The VLE argument supports "omit", "daily", "weekly", "activity", "FSLM", "FSLSM", "OLS", and "VARK", while VLE_clicks controls click representation (Howard, 14 Jan 2025). The withdrawn_students argument does not remove every student who ever withdrew when set to "remove"; rather, it removes students who withdrew up to and including the week indicated by week_end. This makes the output especially suitable for early-warning studies, where the prediction population must be defined relative to information available by a particular week (Howard, 14 Jan 2025).

The package’s end-to-end workflow can be summarized as follows: load source tables from GitHub .RData files into local environments; filter by module and presentation; optionally remove repeat students; optionally remove withdrawn students depending on week_end; merge and reshape assessment data; reshape raw VLE click logs into daily or weekly student-level wide tables or aggregate them by activity type; optionally transform VLE values or remap activities into learning-style frameworks; and merge selected categories into a single flat tibble with one row per student (Howard, 14 Jan 2025). This suggests that the package’s principal technical contribution lies in operationalizing a repeatable preprocessing pipeline rather than proposing a new analytical model.

6. Case studies, analytical uses, and significance

The first case study presents ouladFormat as a tool for research design and study preparation. The motivating question asks whether extra supports for students from low-income backgrounds might reduce dropout and failure rates. Using dataset_demographics(module = 'DDD', presentation = 'All', repeat_students = 'keep'), the analysis cross-tabulates final_result with imd_band (Howard, 14 Jan 2025). The paper reports that among students who withdrew or failed, a larger proportion came from lower imd bands, with a $\chi^2$ statistic = 161.74 and 27 degrees of freedom (Howard, 14 Jan 2025). The significance of this example lies less in the inferential novelty than in the fact that the package directly returns a ready-to-use tibble without manual import and join logic.

The second case study concerns early identification of at-risk students. The paper connects this use case to early warning systems that aim to identify students at risk of failing or dropping out as early as possible, and references prior work by Drousiotis, Shi, and Maskell (2021) (Howard, 14 Jan 2025). The study constructs an analysis dataset through a single call to combined_dataset() with demographics = TRUE, assessment = TRUE, registration = TRUE, VLE = "weekly", VLE_clicks = 'total', week_begin = -4, and week_end = 4, then engineers features such as summed pre-start clicks and renames the first assessment score (Howard, 14 Jan 2025). The downstream models are a Random Forest and a Decision Tree classifier (ctree). Reported accuracy values are 0.5262 for the Decision Tree and 0.5011 for the Random Forest, so in this example the Decision Tree performed better (Howard, 14 Jan 2025).

These case studies support the package’s recurring claims about accessibility, reproducibility, and comparability. ouladFormat makes OULAD easier to access for researchers, practitioners, and educators by standardizing preprocessing that would otherwise vary from study to study (Howard, 14 Jan 2025). A plausible implication is that its main scholarly importance is methodological standardization: by reducing researcher-specific differences in how OULAD is cleaned, joined, filtered, and reshaped, it supports more comparable educational studies while leaving substantive model choice open.

The overall significance of ouladFormat is therefore not new statistical methodology but a formalized preprocessing layer for OULAD. It helps users load OULAD without manual import scripts, subset by module and presentation, handle repeat and withdrawn students, filter data by time windows, merge assessment and VLE tables correctly, reshape long event logs into student-level feature matrices, compute derived variables such as average_CA_score and reactivity, transform VLE clicks for downstream modeling, and build flat, analysis-ready datasets suitable for standard R workflows (Howard, 14 Jan 2025).