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.