XCRI-CAP data items: some points for discussion

Over the last couple of weeks we’ve been looking at actually producing our XCRI-CAP feeds.  In our original planning we put this task later in the project, after we’d mapped our processes and checked our data.  But, in hindsight, it was better to start with this task.  By producing the feeds we now know what we have readily available and what we might have some difficulty with.  This will help us focus our efforts when it comes to process improvement.

Two data items produced quite a lot of discussion at our last working group meeting and I’m going to share that discussion here.  I’d love to hear how other projects are thinking about these fields.  These fields are attendanceMode and attendancePattern.  studyMode has a similar mapping, but that mapping is relatively simple.  We can easily map the values listed to values in our system, and those values are mutually exclusive and clearly defined.


CM = Campus
DA = Distance with attendance
DS = Distance without attendance
NC = Face-to-face non-campus
MM = Mixed Mode
ON = Online (no attendance)
WB = Work-based

Firstly, there is the issue of figuring out which ones actually apply to UH provision.  We don’t have ‘distance’ courses that are separate to ‘online’ courses within our data structure.  However, we do have ‘distance-online’ courses with and without attendance.

Secondly, what is the definition of ‘Campus’.  Does this mean only courses delivered on a UH campus, or could they be delivered on any campus (i.e. partner Colleges) as opposed to delivery in a non-campus location?

When it comes to being able to apply these, we have another difficulty, which is that this is not data we can draw out of our authoritative systems in the kind of detail suggested above.  We would be able to pick out UH campus, online and partner deliveries, but not whether the online had attendance or not, and not a work-based partner delivery as opposed to a campus based one.  We would need to create extra markers against courses delivered online and delivery locations in order to produce the additional categories.


DT = Daytime
EV = Evening
TW = Twilight
DR = Day/Block release
WE = Weekend
CS = Customised

This produced even more discussion.  In particular, around the boundaries of each definition.  For example, a standard Undergraduate on a course at UH might have classes that run early in the morning, right up to 7pm at night.  If we were to list this as ‘Daytime’ then students might feel we misled them.  But on the same basis, ‘Twilight’ or ‘Evening’ would also be misleading.  We are then left with ‘Customised’, only delivery isn’t customisable, its just varied.

Again, we also have the difficulty of this not being recorded in our system in a simple way and I’m not sure we will be able to resolve this one.  Whilst we could look to our timetabling system, such information would only be relevant for a short time, as students might have a 7pm lecture one Semester and none the next Semester.

As it stands, I don’t think we will use this particular field.  I can see for some types of provision it can be particularly useful, and for some providers it would help to highlight their unique selling points, but with all of the complications listed above I am not sure that the work required would be justified.  If  a particular aggregator was using this field in a more useful way, i.e. within a limited set of courses where the answers were simpler, or with a different set of definitions, we would review it.

Populating fields for XCRI-CAP
This discussion has also brought into focus a practical choice we need to make with XCRI-CAP feeds for the course data programme. Where fields and limits on fields are not mandatory, we need to consider carefully how much work we as an institution want to put into populating them.  Given that specific uses of XCRI-CAP will likely have specific data definitions that may well vary from the course data project definitions, we could well end up populating fields that are never used outside of this programme.  We also do not want to populate fields in a style that will suit just this programme, as we would like the work produced to be easily transferrable.

The outcome of this is that we have decided not to use some of the fields.  For example, ‘applyFrom’ and ‘applyUntil’.  The information underlying these fields is currently not held within our authoritative systems.  With these systems currently undergoing their first academic cycle, the work involved in setting them up and populating them would be substantial for this single use.  It has therefore been decided not to use these.  On the other hand, it has been decided to produce the 140 character abstract for all courses.  It was felt that this would have other applications with an ever increasing focus on social networking and mobile applications as tools for recruitment.

A gaggle of aggregators

What is the collective noun for course aggregators?  I’ve gone with a gaggle because right now we have a number of different people who all want our course marketing data for their own purposes.

Who wants our course marketing data?
The key consumers of course marketing data at this time:

  • Key Information Sets (Unistats)
  • UCAS
  • Course data project
  • University website

There could also be other potential users in the future.  Aggregating websites is one we often consider.  Mobile applications is another that is being talked about.  I’m sure that reporters will be mining KIS data for stories, and perhaps other data sets too.  Then there is the untapped potential of XCRI-CAP within larger XML schemes such as the HEAR XML and ‘big’ XCRI.  Not to mention the uses we haven’t even thought of yet as enterprising organisations come up with new ideas to market University courses.

Which of these can use XCRI-CAP specifically?
The course data project is the only one of these that will be using our XCRI-CAP feeds in the first instance.  Further uses of the feed itself might come about as a result of this work.  Beyond that, the systems to produce XCRI-CAP feeds will be available for any future feeds we decide to produce.

There are two particular approaches to data that we are hoping to foster through the project.  I want to illustrate how the varying demands of the gaggle of aggregators might affect those principles.

Principle One: Enter data once, and use it multiple times

There are suggestions that UCAS might use XCRI-CAP feeds in the future and we are very much hoping this is the case.  There is a strong message from all parts of the University of Hertfordshire who interact with external organisations, and UCAS in particular, that they want to avoid rekeying information.  To achieve that we need UCAS to support the ‘enter once, use multiple times’ philosophy.

Course title
Within the institution we have looked at how the gaggle of aggregators might want information in different ways.  The title of a course might seem like one of the simplest fields to complete.  Its not!  Even in a world where all your titles are beautifully and consistently formatted in the student record system of your choice there are issues.

For example, a course on our record system might have the name BSc (Hons) Knitting Pathways.  This accurately reflects the administrative programme and JACS content it contains.  However, it holds two routes with different UCAS codes, since UCAS has finer level of granularity in this area.  They might have the UCAS titles BSc (Hons) Experimental Knitting and BSc (Hons) Knitting and Marketing.

There would be two entries on our website.  Students would follow a different path through them and only one contains a compulsory placement year.  This means for the purposes of the KIS, we will be creating two KIS courses.  The KIS and website courses would use the same course titles as UCAS.

Then, when you look at XCRI-CAP, the course title must not include the award.  So we will need to record this somewhere else as well, probably manually.  Unfortunately there isn’t a space to keep the award and title separately in our student record system!  This will mean there is a lot of up front work for producing such feeds, and that we are definitely unable to enter what seems to be one data item just once!  On the other hand, we should be able to reuse those entries once they are made.

Principle 2: Consistency of information

XCRI-CAP field Cost + KIS fee related fields
Fee information , like course title, would appear in the first instance to be a consistent factual piece of data, which it is.  The problem with fee information is its complexity.  The gaggle of aggregators are each trying to pick out the relevant pieces of information for their audience.

The fee related fields for KIS will be filled automatically via data we provide to UCAS for UCAS programmes, and entered by us for non-UCAS programmes.  They are tightly defined and are either the maximum fee for the four UK based domiciles (UK, Wales, Scotland, Northern Ireland) or Yes/No answers as to the availability of support and bursaries.

The Cost field in XCRI-CAP, in contrast, is a free text field.  This is necessary for the course data project because of the varying communities of practice involved.  Now, if UCAS were to pick up XCRI-CAP, their version of the feed would likely need fee information in one way which would also meet the requirements of the KIS (enter once, use multiple times).

Even where the fee information is the same, aggregators might present the data in the different ways, with one choosing to show a range and another choosing to show an average.  Another might allow you to enter data so it knows what your fee status would be and can display only the fee relevant to you.  And KIS and UCAS are only looking at a portion of fee information – other information would need to be available in other places for students who look for courses through other routes.

Put quite simply – ‘cost’ is very dependent on the questions being asked.  It isn’t the only piece of data where this is the case, but its likely to be one of the most noticeable.  This isn’t a problem we can solve within the project because it isn’t solvable within the definition of XCRI-CAP.  It needs to be solved by the aggregator, who need to ensure that they outline how they want this information to providers and what the information represents to students.  What we can do is ensure our fee pages on our own websites support cost related information provided to any aggregator so that a confused student can find an answer to their question.

Starting at the beginning

Stage 2 of the project has started at UH and we are working on putting a detailed project plan in place and doing some initial investigative work to establish where the institution is currently in relation to XCRI-CAP and COOL URIs.  Some of the things we have done include:

  • An initial mapping of XCRI-CAP to the authoritative systems that will be used to deliver the data (in our case the Student Record System and the Marking System);
  • Recruitment of a Project Officer;
  • Identifying the example programmes to be included (four undergraduate full time courses, an online programme, a postgraduate programme and a health CPD programme);
  • A review of the programme specification to ensure that all relevant information is collected (of the data items we would expect to sit within that document);
  • Initial discussions regarding data flows and procedures helping to understand what we already have in place;
  • Attendance at the start up meeting and the webinars.

There are a number of external factors that all the projects are likely considering (KIS, HEAR and the UCAS course finder for example).  At UH we are also conducting this project alongside the implementation of a new Student Record System (we are transitioning from a bespoke in-house system to a system provided by Campus IT) and a new Marketing System (an in-house system designed to interact with the SRS).  This represents both a challenge and an opportunity.  The challenge is to examine course data processes and ensure they are fit for this purpose when those very processes are in flux as new parts of the record system are implemented.  The opportunity is to influence the processes from the very start so that work to produce XCRI-CAP feeds and other course data is a core part of our procedures from day one.

The project start up meeting was interesting.  It highlighted that most institutions share certain issues on the project.  Perhaps we can work together to overcome some of these.  It also highlighted that there is a lot of information we don’t yet know about the aggregator and about external influences such as the KIS and UCAS.  Whilst we can start to move forward with what we have, it is hard to make concrete decisions with much of that information still up in the air.  I’m going to write a further blog post about the issues with the three different aggregators next.  Moving forward for now, we intend to start looking at that interaction in depth by mapping the KIS and XCRI-CAP to a sample programme (and, as a result, to each other).

We are not just at the beginning of this project, but at the beginning of a brave new world of course data, both internally and externally.  This makes for exciting (if very busy) times.

JISC XCRI-CAP Project Blog

The JISC initiative on ‘Making the most of your Course Data’ is of specific interest to the University of Hertfordshire (UH). UH recognises the challenges inherent in the increased demands on course data that the sector must respond to, specifically the need to provide up to date, transparent data to prospective students. UH endorses the initiative and the aim to provide standardised course information that can be easily accessed and understood by prospective students seeking to view course data across multiple institutions.

Throughout Stage 1 UH will be assessing our institutional readiness to progress to Stage 2 of the project. Exploration of the following courses will allow us to identify specific issues for inclusion in the implementation plan and to allow us to assess whether UH should progress to Stage 2.

  • Full time Undergraduate programmes as defined by the Key Information Set (KIS)
  • A Part-time Postgraduate programme
  • Computer Science Online Distance Learning programme
  • A CPD Health programme

Project Manager: Helen Bennett
Contact: H.1.Bennett@herts.ac.uk or 01707 286282