The Academic Programme Management System (APMS) is designed to allow read-only access to the course data through APIs. However, these APIs allow for very little (if any) search parameters to be used and as such were unsuitable for our use cases when developing applications based around course data. As such it was necessary to import this data into our own data platform, ‘Nucleus’.

Firstly it was necessary to design a database structure that would allow the effective storage of a large amount of course data. The Nucleus Database  stores a lot of institutional data, as shown in the database diagram.

By taking the data from the APMS APIs and breaking it down into its constituent objects, the data is much easier to work with. For example, in the APIS from the APMS, learning outcomes can only be accessed as follows:

• Get all modules.
• Find module in array of results.
• Follow API URL for this module to the module endpoint (uses internal ID number)
• Access learning outcomes

Obviously, if we’re wanting to repeat this process multiple times, for multiple modules; or to carry out some form of processing on JUST the learning outcomes, the entire process would be very heavy handed and overly complicated. By breaking the data down on the import process into Nucleus, then re-exposing the objects in their smallest form, the data becomes much more usable.

At the time of writing, Nucleus (which is documented here) contains API endpoints for the following course-related objects:

• Academic Years
• Accrediting Bodies
• Assessments
• Awards
• Benchmark Statements
• Benchmark Statement Levels
• Benchmark Subjects
• Benchmark Subject Types
• Contact Time
• Contact Type
• Contact Type Category
• Course Codes
• Curriculum Mappings
• Delivery Modes
• Marketing Records
• Learning Outcomes
• Levels
• Module Code
• Module Link
• Modules
• Programme Outcomes
• Programme Outcome Categories
• Programmes
• Subjects

Obviously these can be combined with other data from within Nucleus, such as organizational structure, staff details, location data etc to provide useful and interesting applications.

Each API endpoint is documented at docs.n2.online.lincoln.ac.uk, each having appropriate query parameters to narrow down the search results returned. For example, assessments has many parameters that can be used to query the database, allowing the results to be narrowed down depending on the week the assessments (should) be due, the weighting of the assessment, the module the assessments are related to, if the assessment contains group work or is the final assessment for that module.

Using Nucleus APIs, you could get details of  all assessments that are the final assessment for the module, that contain group work at: https://n2.online.lincoln.ac.uk/assessments?access_token=ACCESSTOKEN&group_work=1&final_assessment=1. To get the same data using the original APIs would require the user to retrieve all of the module records, loop through each module, loop through each assessment, check against the criteria and assign the matching assessments to some form of output. The advantages of absorbing the data from the APMS, storing it in our own Nucleus database and re-exposing the data through our own hand-crafted APIs are obvious : easier, faster, more efficient.