So yesterday afternoon, Nick and I found ourselves talking about the data available for us to mash, mungle and meddle with here at Lincoln. Both of us have been working on our own pet projects utilising what data we can lay our paws (read: code) on, however there really isn’t much we can play with.
Therefore, armed with borrowed marker pens we headed to the “bean bag room” (MB 1009) to see if we could lay out a University data flow diagram, highlighting the core stores that we believe are needed to provide a functional base from which to build almost any possible service.
After much discussion we decided that the following seven core data stores are needed:
Core Data Stores - Location, People, Messages, Me, Groups, Events, and Auth
Location – This is a store listing campuses, buildings on a campus, rooms in a building (and other objects such as corridors, stairs, lifts, etc) and a list of links between different building objects (for use in routing). Buildings have geolocation meta (i.e. latitude and longitude) and building objects have XY meta so that routes can be made between objects (more on this in another post).
People – This store is basically an interface to the University’s LDAP servers that provide basic personal information on staff and students (such as names, email addresses, phone numbers, etc) and extended meta such as which year group students are in or which departments staff work for.
Both Location and People are considered “static” stores (hence the different colour) because the data inside will rarely change.
Me - This store contains custom meta for individual users, e.g. which student societies they are members of, how they’d like to be contacted (e.g. SMS, email, Twitter, snail mail) and what preferences they have to communications (e.g. an interest in computing related news but not sport).
Groups – Groups are collections of users who are associated in the same way, e.g. all level 2 students, all students in the computing faculty or all students in the drama society. This data is drawn from both People and Me.
Events – This store holds information concerning the availability of locations. These events could be academic lessons or seminars, room bookings for staff meetings, or events that the student union are putting on however this information is not stored at this level, Events merely stores the fact that a location is (un)available at a specific date and time.
Messages - Messages is a global notifications system for pushing content out to individuals or groups according to their individual contact preferences (defined in Me). For example, a timetabling application can push a message out to students if a lecture is cancelled and they’ll be informed of it however they elected, be it email or Twitter.
Auth – Auth is a store containing data concerning session data for signed in users, application API keys and application authentication states (e.g. OAuth tokens).
Using these core data stores applications can then be built on top, all using the same authentication methods, and all making use of the available services meaning users get very fine control over their computing experience and applications are able to access very rich datasets.
We’re looking into exposing personal user data (from People and Me) using OAuth, which gives both users and the University control as to how personal data can be used. Obviously some internal services such as timetabling can’t be opted out of, however other applications such as those used by student societies can be granted or revoked access (much like Facebook Connect or Twitter’s OAuth implementation) as needed.
When working on the white board we tried to identify the flow of data between services and this is what we came up with (click for larger image):
Our white board data flow diagram
Here is the cleaned up version (click for larger image):
University of Lincoln's data flow between services
I’m not going to go over all of the points on this chart as some are internal projects which we’ll talk about later and others are just self explanatory, however I will cover a few:
Find a Free Room – a frequent complaint by both staff and students is that it can be difficult to find a free room at a moments notice. This could be for an impromptu meeting or a student society looking to find a room for a session. Staff can currently access a number of timetables via Portal including their own timetable, and room timetables however going through every room just to find a free one isn’t a quick task (and then, as Nick and I found yesterday when we were trying to find a room with a whiteboard, it doesn’t mean a room is free just because there isn’t a timetabled event). Therefore, a “find a free room” application would make use of the Events store to return a list of rooms that are currently available (which can be further limited to specific rooms/buildings and at certain dates/times). All staff and students would have to go through this application to make bookings in order for this to work.
Calendar – the calendar service would provide data drawn from the Events and Me service. For students this would show their academic timetable, as well as any events for any affiliations they’re involved with (e.g. student societies or research groups) or custom events they’ve created themselves (such as assignment deadlines). For staff this could show academic timetables (for teaching staff), meetings and personal events.
Hopefully implementing some (or even better, all) of these services will result in us able to truly implement the Strategic Plan Overview that describes the experience of the 2012 student, and hopefully Nick’s rewrite too.
Nick Jackson 11:48 pm on February 4, 2010 Permalink
Minor point, they’re not data stores. They’re services which expose the data within them through RESTful API methods.
Christopher Gutteridge 11:24 am on February 5, 2010 Permalink
We did some work on this a few years back: http://id.ecs.soton.ac.uk/docs/ which may give you some ideas. I am really happy with the URI scheme we used, and the URI/URL system works well. I am less happy with the RDF and if I had it over we’d use common schema, but there wasn’t much around back then.
Note we have both rdf.ecs.soton.ac.uk and intra.rdf.ecs.soton.ac.uk — Intranet (IP restricted) data makes lots of sense. Our students can play with it, but it’s not visible on the external web. It contains things like peoples informal interests (as oppose to professional interests) and their locations (building/room) which we don’t place on the public pages.
One thing I think is missing from your diagram: “Articles” or “Resources”. Things like your publications, press releases and so forth.