Several weeks ago, I put in an entry to the JISC MOSAIC Library Data Competition based on a couple of earlier hacks I’d put together that were built around @daveyp’s MOSAIC API wrapper the competition dataset. Here’s the howto…
First thing to note is that the application built on stuff I’d posted about previously:
– an elaboration of UCAS course choice pages with a link that identified books related to a particular course based on course code: First Dabblings With @daveyp’s MOSAIC Library Competition Data API;
– a bookmarklet that would “look up to see whether there are any courses associated with a particular book (or its other ISBN variants) if its ISBN appears in the URI”: People Who Referred To This Book Were Taking This Course.
So what was the submission? A page, keyed in a RESTful way by a UCAS course code, that:
- takes a course code,
- looks for the set books that have been borrowed more than a certain number of time by students associated with that course code (“find popular books associated with this course”),
- grabs a review of each book from the Amazon mobile site,
- annotates each book with a list of courses whose students have borrowed the book (“find other courses whose students have used this book”).
This page can be called using the following URI pattern:
(Note that the service can be quite slow at times – the pipe is doing a fair bit of work and I’m not sure how quick the MOSAIC API is either. But that’s not the point, right? The point is identifying the logical glue required to join up the MOSAIC service API with a range of other index keys and web services, so that a production service could then potentially be implemented against a proven (-ish!;-) and demonstrably working (sometimes!) functional spec.)
The pipework itself can be found here: MOSAIC Data: Books on a course, with related courses
The first part takes a UCAS course code as key/index value, and queries the MOSAIC API; only books that have been taken out more than a specified minimum number of times in the context of a particular course are passed though:
A link to the book cover is then included in the description item of each book, and a call made to find the courses related to that book. A crude bit of screenscraping on the Amazon mobile page for each book brings in a book review. (I had originally intended to pull in more reviews from the Amazon API, but over the summer Amazon introduced a key based handshake to access to the API – so s***w ’em.)
The output of the pipe is pulled into this page as a JSON feed, and the data from it is used to populate the page.
The first column in the table simply displays the title of each book associated with the specified course code.
The book cover is pulled in from… Worldcat, I think…, keyed by ISBN10 (maybe there are licensing issues involved..?) The preview link pops up a preview of the book in a shadowbox, if available, or failing that a link to the generic book info page on Google Books. (Close the shadowbox using the X on the bottom right of the Shadowbox view.)
It should be possible to handle the previewer using code that is displayed directly within the shadowbox, but I ran out of time trying to get it to work, so resorted to using a helper page instead that could be embedded via an iframe in the shadowbox (the helper might be quite useful in it’s own right as a piece of rapid protoyping componentware? http://ouseful.open.ac.uk/gbookIframeEmbed.php?isbn=159059858X). The lightbox code is from Shadowbox.js.
The Amazon info (the ‘first’ listed Amazon review for the book) is pulled in from the Amazon mobile site via a Yahoo pipe. (The Amazon URIs I use look something like http://www.amazon.co.uk/gp/aw/d.html/?a=ISBN10&er=1) Since Amazon started requiring API requests to be signed, it’s made quick hacks difficult; the next quickest thing is to scrape the mobile site, which is what I’ve done here. A regular expression in the page rewrites the Amazon mobile URIs to the normal web URIs.
The course info columns shows info for courses that are also associated with the book; because not enough people in HE appear to care about URIs and “pivot data”, we often can’t just take a course code and create a URI that links to a corresponding course description. In the short term, I pivot back to this page, so you can see what other books are associated with the specified course. And as a hack, I munge together a Google search query that at least tries to track the course down based on course code and HEI name (e.g. http://www.google.com/search?q=BSc%28H%29+Computer+Games+Programming+%22University+of+Huddersfield%22. I don’t query UCAS page directly because the UCAS search uses session variables and a handshake as part of a shortlived URI to a set of search results.) Many of the results are to timed out UCAS searches indexed by Google though. It also amuses me that for some HEIs, searching their public site with the course code for a course they have ‘advertised’ on the UCAS site turns up no results. Zero. Zilch. None.
I also posted a complementary bookmarklet that can be used to annotate course search results page on the UCAS website with a link to the appropriate related books’n’courses page.
You may have noticed that the competition entry was posted in a minimal, unstyled form (I had hoped to make use of a Google visualisation API table widget to display the results, but proper work intruded ;-) This is in part to make the point that it is not – never was meant to be – a production service. It’s a working rapid prototype intended to demonstrate how Library data might be used outside the Library domain to act as a marketing support tool for Higher Education courses on the one hand, and an informal learning/related resources recommendation tool on the other.
These sorts of prototypes can be constructed in 1 to 2 hours and provide something tangible for Library folk to talk around (as opposed to documents produced at length describing how the needs of fictional characters and user scenarios generated by break out groups in “let’s reinvent our web presence” departmental away days…
They’re also the sorts of thing that we should be creating and discussing as throwaways on a regular basis, not hiding away for months end because they’re in some competition or other…
(As to why I haven’t posted this before – a huge half written blog post backlog; the how to has been available on the demo page, which was tweeted about widely as soon as I’d got it on to the server…)
PS see also @ostephen’s Read To Learn competition entry, which takes a set of ISBNs from an uploaded file, looks them up against the MOSAIC API and returns the UCAS course codes of courses that are associated through book loans with the uploaded ISBNs (and maybe xISBNs too?). Each course code is then looked up against the current UCAS course catalogue, and the search results (i.e. the list of corresponding courses at institutions across the UK) is retrieved and displayed. In short, Read To Learn takes a set of ISBNs and finds related courses from a course code lookup on the UCAS site. My app just took a single course code and tried to find related books (along with reviews of the books) and courses.
3 thoughts on “My (Rather Scruffy) MOSAIC Library Data Competition Entry”
Comments are closed.