Archive for the ‘Data’ Category

As outlined in a previous blog post, Tony Hirst has blogged about his experience of using our course data APIs and offered feedback on them. As a result of this, we’ve made some changes to our course data APIs.

Firstly, we’ve introduced paging to the APIs, so now results can be easily broken down into pages, with the amount of results per page set to a reasonable amount, depending on the size of the objects being returned. The pagination object returned with each page of results shows useful information, including the size of the page, the amount of results the page contains, if there is a previous page available or a next page available. This will make the process of programatically searching through all of the results much easier.

Whilst using the APIs, Tony also highlighted several typographical errors, particularly with the URLs of child objects that were returned in the results, we’ve since corrected these.

These are only relatively minor changes, but should improve the usability of the course data APIs!

After realizing that I’d made the database design too complicated, and eventually re-designing it, an alpha version of the assignment wizard is up and running and is available at wizard.lncd.lincoln.ac.uk. The application meets the basic functional requirements of the proposed assignment wizard, but will require further development and testing before being used properly. The main functions of the current iteration of the assignment wizard are as follows:

An earlier blog post describing (briefly) the process / logic behind the application can be found here.

First off, a quick tour through the application.

Search parameters are broken down into 3 categories: subjects studied, subjects interested in and general keywords. The first two are based on benchmark subjects used in QAA validation of programmes. This makes it easier to tie subjects to programmes offered by the university, but does present a problem in that some words aren’t recognized that a potential user may expect. For instance, ‘religion’ is not recognized, instead the QAA benchmark subject is ‘theology’. The latter input field is based on keywords identified by Open Calais (explain in a previous post). This offers a wider range of keywords, but these keywords often link to quite a large range of programmes offered by the university. Obviously some kind of middle ground would be ideal, but that is not explored in this initial application.

Entering the following parameters – studied : education, interested in: psychology, keywords – teacher. Generates the results as shown above. The results are broken down by how many of the specified criteria they meet. In this example, the PGCE course meets two of the specified criteria, which seems reasonable. Selecting the result from the list takes the user through to the screen shown below.

This screen should contain whatever data is considered pertinent to the user discovering if this course is suitable for them. At the moment this screen just contains the aims and objectives of the programme, but can easily be extended (and should be, should the application be developed and used properly). The screen also allows the user to recommend this course as being relevant to their search parameters, as well as showing similar courses. Similar courses are (at the moment) based on the keywords as identified by Open Calais, with suitable limits and restrictions put in place. These restrictions are discussed in an earlier blog post, but there seems to be a fine line between having every course linked through keywords such as education (everything identifies with this keyword as they’re university courses) and having very few courses identified as being similar, even when they obviously are. Further work would have to be done on this to improve it.

Recommending the course as matching your criteria improves the search process for anyone else that may search for the criteria you specified. If entering the same criteria in a new search, the results look slightly different – recommended results have a star next to them, indicating that they have been recommended.

As mentioned previously, this application (at it currently stands) is merely a proof of concept, and would require further development before being used properly. Points to consider for further development include:

How should we allow users to enter search criteria? A free-form text field would allow users to search for exactly what they want, but searching all of the relevant data sources would prove challenging and would be very time consuming. Using high-level JACS codes means that far too many potential matches are returned, with only a few courses being truly relevant, surrounded by a large amount of, essentially, noise.

If the OpenCalais keywords are to be used, more work would have to be done on determining the correct level of filtering to be carried out. At the moment courses that are obviously similar are not being shown as so. This is, however, an improvement over a previous point at which a ridiculously high amount of courses were being identified as similar, when they obviously were not.

A lot of data is being stored relating to click-throughs for search results. This *could* be integrated into the search rankings, so that courses that are often clicked on are moved further up the rankings.

There are many ways in which this application could, and should, be improved, but as a proof of concept it demonstrates what can be done with course data to potentially improve the student experience.

Over the course of our project, Dr. Tony Hirst from the Open University has helped us think through the way course data might be visualised and built upon. Recently, he’s written a series of blog posts that discuss this in more detail and offers useful feedback to the project team about our APIs. You can read Tony’s blog posts on OUseful.info

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’.