ADS takes shape

The Academic Data Store, a new database which I'm bringing into being, is starting to take shape. We've nearly finished designing it and next week we install the software that will drive it, and start sucking in data from many sources.

It's hard to be interested in databases, especially when they don't hold much data of their own, and a large part of why we're building the ADS is to make all the connections between datbases and other databases easier to manage – a purely administrative benefit. But the user-facing things ADS will make possible are increasingly looking quite interesting:

tasks + data = checklist

We're introducing the concept of a task, which is essentially just some text which describes some data. Together with the data from a variety of different databases (ID card issuing, academic enrolment status, the sports centre, maybe the library), this will make us able to provide a checklist of all the administrative things new students need to do and actually display which ones have been done. With the new web signon system in service, it will be easier than ever to hop from one web system to another to complete the tasks.

lectures + module registrations = personal timetable

With module lecture data from the timetabling office and student module registrations from OMR, we'll be able to produce personalised timetables for students which just show the lectures they need to go to, something which hasn't hitherto been possible.

modules + arbitrary groups + events = seminar groups

With data from OMR defining what students are taking a module, and the ability to define arbitrary sub-groups (and 'supergroups', a group plus hangers-on) of those students, it will be easy for staff to define groups of students for seminar groups. Once defined, these can be used in mass mailing, for controlling access to SiteBuilder pages etc. Generalising the concept of a lecture into an event with a start and end time, times for seminar group meetings can be defined and automatically mass-mailed out to the participants.

events + tasks = deadlines

Using the task concept and event concept together, you can define a task to be presented to students with a start and end time. The timing could be applied so that a SiteBuilder page becomes accessible only for a defined period, perhaps with another event publishing the solutions page immediately afterwards, and a reminder event happening a certain amount of time before the end of the first event, triggering a mass mail reminder that the deadline is approaching. Students who miss the first 5 minutes of the lecture will have no excuse now.

It's all getting awfully joined-up. And this is just an initial bunch of ideas, that we hope to have built on top of ADS by xmas or so. Further ideas for joined-upness are welcomed.

: 14 Jun 2005 16:49 |  Comments (0) |  Report a problem