Jisc Learning Analytics Unified Data Definitions v1.2.7

Introduction

The Unified Data Definitions (UDD) of the Jisc analytics project is a vocabulary of the chief data entities of interest to learning analytics: students, courses, modules, etc. as well as their characteristics. The data coded with this vocabulary is typically extracted from the student record system of a particular college or university.

Along with xAPI recipes, the UDD makes up the core data specification of the Jisc learning analytics architecture.

Differences between 1.1 and 1.2

The development of 1.2 involved a number of additions and changes. This overview page provides a mapped listing of each change, with links through to the relevant pages in the UDD 1.1 and 1.2 documentation.

Data format

UDD data must be UTF-8 encoded. JSON is the preferred data format, but XML data is also supported. Other formats are not supported.

When providing UDD data, supply the data for different entities in separate files, 1 file per entity, using the UDD filename conventions.

Diagram

An entity relation diagram of the whole UDD 1.2 provides a one page overview of the specification.

Core sections

assessment_instance

course

course_instance

institution

module

module_instance

module_vle_map

student

student_course_membership

student_on_assessment_instance

student_on_a_module_instance

student_on_course_instance

Additional sections

staff

staff_on_course_instance

staff_on_mod_instance

Mandatory and optional properties

The properties of the UDD are required in compliant datasets to different degrees. The Mandatory properties in the UDD guide outlines the different categories of UDD property. It is available as both Excel and ODF spreadsheets.

Specification development workflow

The simplest way of contributing to the UDD works as follows:

1. add an issue to the issue tracker to alert everyone to what you are working on and why
2. tag the issue with the version milestone you'd like the patch to be a part of
3. make an edit or add a file in this repository, and save it to your own branch. If you prefer, you can fork the whole repository and work in your own repository
4. send a pull request once you're done
5. the pull request will be discussed at our weekly meeting and either merged, or kept in the queue, depending on whether more work is required

You can do all this through the Github GUI, but you're welcome to use any other git tool you prefer.

Particular release versions will get their own branches, but the main branch will always contain the latest agreed release. Releases will be made after the group has come to an agreement.

Versioning is done broadly as follows: major versions (majorVersion.minorVersion.patch) indicate major datamodel changes. Minor versions denote changes that can break applications, such as the deletion of properties that were valid in earlier versions. Patches can include the addition of new properties.

Note that some properties will be marked as 'deprecated'. This means that the property is still valid, but will be removed by the next minor version update.

Acknowledgements

Many thanks to all contributors who have raised issues, sent pull requests, commented and made suggestions. The UDD specification is the achievement of all of you.

• @alanepaull
• @andrewhickey
• @arc12
• @christoffballard
• @ds10
• @gryglbrt
• @ht2
• @huwrobertsjisc
• @jfmullaney
• @michaelwebjisc
• @MiroslavKratchounov
• @robwynj
• @ryansmith94
• @sandeepmjay
• @wilmTap

This work is licensed under a Creative Commons Attribution 4.0 International License.