Mashing and Mapping

Middlemash, the third Mashed Library event, took place on the 30th November. Hosted by Damyanti Patel (my other half) and her team (Mark, Robin, Chris and John) at Birmingham City Unversity, the day was once again a split between talks and hands on mashing. In some ways I think it may have been the most ‘twitter active’ event I’ve been at so far – there were around 560 tweets tagged with #middlemash on the day itself. Although possibly some of the bigger conferences I’ve been at had more volume, I don’t think any has had the density of ‘tweets per delegate’ 🙂 There was even an ‘official tweeter’ in the form of @joeyanne. There is an archive of all the tweets at

The day started with Tamar Sadeh from Ex Libris (who also sponsored the day) talking about a variety of things including the Ex Libris Code Share wiki – I was really pleased to see that this is accessible to everyone – although only Ex Libris customers can post code .

Following this Mark van Harmelen from HedTek Ltd introduced concepts of rapid prototyping and working with users – stressing the flexibility of paper, pens and post-it notes in the design process, and also the importance of making development a collaborative process.

Then we had three ‘case studies’ from Edith Speller, Paul Stainthorp and Chris Keene – it was great to see some examples of mashing in action from real situations, solving practical problems.

In the afternoon I’d already decided I wanted to pick up something I’d played with briefly at the first Mashed Library event (#mashlib08), which was using the Google Maps interface. I’d sort of volunteered to ‘lead’ a session – which I’m afraid I didn’t do a brilliant job of – not enough preparation I’m afraid – so if you came along I’m sorry about that.

We started with (I think) a good discussion of how Google Maps (and similar systems like OpenMap) work (more on this in a minute), and what the practical issues of maintaining floorplans for the library were – especially where you wanted to be able to indicate where a specific book is. The truth is that locating an item on a specific piece of shelving has not been something that most libraries have bothered to do in the past (certainly on open shelving) – relying instead on a set of ‘rules’ you can follow to work out where a specific book will be – at least, relative to the other books in the library. In theory the item record on the catalogue will give you enough information to find the item – typically the information will include:

  • Library site (for multi-site libraries)
  • Collection (sometimes based on discrete sets of material, but sometimes general geographic locations like ‘First floor’)
  • Loan period (this is sometimes, but not always, linked to a physical location)
  • Classmark or Shelfmark

In well designed modern libraries, you can usually use this information to work out where a book is relatively easily. However, when you sometimes have shelfmarks like “Cupboard S” (real example) basically there is no way of working out where the book is – you just have to ask where “Cupboard S” is.

Of course, books are relatively easy – tracking down a journal volume or item almost always relies on simply knowing how the alphabetical sequence of titles winds its way around a set of shelving (and sometimes where older materials have been shelved in separate, less accessible, shelving).

What is perhaps slightly odd is that most libraries do keep somekind of signing up to date – usually in the form of ‘shelf ends’ which indicate which range of classmarks (or journal titles) is on a specific shelf. However, it seems that these are not usually linked into the library systems at all (although at least one library in the group did record these in a an Access database). One of the issues with this kind of signing, and the general idea of linking an item to a specific shelf, is that for the items that are close to the start or end of a shelf unit, there is a relatively high likelihood they will be slipped ono the previous or next unit as they are reshelved and the amount of stock on the unit changes.

We had some discussion of how libraries might keep track of what books were on which shelf unit more closely – either by scanning the first and last book on a shelf each time, or looking to RFID to help – and Dave Pattern reminded us (over Twitter) that he had blogged an idea of using RFID for this purpose a couple of years ago.

At this point I wanted to see if we could get something done with Google Maps and a library floorplan during the afternoon, and so I wanted to move on this with. While I settled down to this with Rob Styles from Talis, others started to look at what the various requirements were for a ‘library map’ application – which Graham Seaman gathered together and posted on the mashed library wiki – there are some great ideas, and it feels like there is a real application waiting to be specified there.

Back to the maps. Essentially the way the various mapping systems work is to have ’tiles’ which each represent a section of the map. With Google Maps (and I think this is common to other platforms) the tiles are 256 x 256 pixels. This concept of tiling works in conjunction with the ability to zoom in and out of the map. The basic idea is that at maximum zoom out, you fit the entire map on a single 256 x 256 tile. As you zoom in, you double the number of tiles both along the width and height of the map (i.e. the x and y axis). For Google Maps zoom starts ‘0’ (zero) – a single 256 x 256 tile. This means a zoom of ‘1’ is 2 x 2 tiles (i.e. 4 tiles), zoom ‘2’ is 4 x 4 (16 tiles) etc. Much of the documentation I found suggested that Google currently supported zoom up to 17 – but on the day we actually found that it supported zoom up to a value of 21 – and I guess if they ever get more detailed maps or satellite they will support higher levels of zoom. There is more on how tiles work at

Lyn Parker from the University of Sheffield ‘volunteered’ their floorplans ( to be used in our project. So the first job was to create the tiles we needed. I have to admit that I’d thought of this stage as the ‘boring but necessary’ bit – however, looking back on this it is in some ways the most complicated bit as for each level of zoom you want, you need to resize the graphic and cut it into appropriate tiles. Luckily there are already some scripts available to do all this work for you. Even better, Rob had Photoshop on his Mac, and we got a Photoshop ’tiling’ script from Mapki – a wiki about the Google Maps API.

Our original idea had been to create a ‘custom map’ to essentially present the floorplan within the Google Maps interface. However, the tools available generally seemed to be aimed at overlaying information on the ‘real world’ as represented in Google Maps. So, we got slightly diverted at this point, and decided to see if we could insert the Sheffield floorplan over the real building in Google Maps. With some help from Lyn, we found the building on Google Maps and Rob started to manipulate the floorplan image so we could align it with the building on the map.

Although this took us away from the initial idea, we were quite excited by the idea that if we got this right, we would be able to assign real world latitude and longitude to items marked on the floorplan – including shelf-units. There is definitely something satisfying about this idea, although whether it would turn out to be of practical benefit is less clear to me.

As well as re-orienting the floorplan image, we also had to work out where it should display on the Google Map. This, rather frustratingly, involves knowing the numerical identifiers of the actual Google Maps tiles – after some hunting around, the best tool for this turned out to be one provided by Google at – this allows you to identify both the tile identifiers and the latitude and longitude (which you also need) – although frustratingly you can’t just type in a postcode or lat/long value to get to the location you want. This tool also gives you the ‘zoom’ level – which you also need.

Once you’ve gathered all the relevant information, you can feed it into the tile cutter – including the number of ‘zoom’ levels you want to produce tiles for. Having done this we finally needed to write a web page to display the google map, with our new tiles integrated into the dispay. This involves using the Google Maps API, and I cannibalised the example script at by Mike Williams (whose tutorial at I found reasonably useful throughout the exercise).

With various adjustments as we reached the end of the afternoon (moving from using jpg images to png for the tiles, so we could create a transparency effect), and some minor adjustments by me after the event, we got a map up and working at

It’s pretty obvious we didn’t quite manage to align the map properly 🙂 We did find some tools that are mean to help with this – but they didn’t always seem to work, and some links were just dead. I guess a little more investigation – or some trial and error – would get this solved. However, I’m pretty pleased with what we got done in limited time – thanks to Rob working with me on this.

Actually I think we did one of the hardest things we could have picked to be honest. Looking at it again now, and perhaps understanding it a bit more in retrospect, I think we could have assigned arbitrary tile numbers if we had simply wanted to achieve a Google Maps interface to the floorplan – and it looks to me like then doing overlays on this would have been pretty straightforward as well – when I get a chance I’ll try and test this theory! I really like the idea of the ‘heatmap’ for library stock usage (first suggested by Amy Hadfield at Mash Oop North) and would like to get a demonstration of this running.

So – a great day’s mashing – thanks to all at Birmingham City University who organised and ran the day, and everyone who came along and made it such fun.

Middlemash, Middlemarch, Middlemap

The next Mashed Library event was announced a few months ago, but now more details are available. Middlemash is happening at Birmingham City University on 30th November 2009. I hope to see you there.

In discussion with Damyanti Patel, who is organising Middlemash, we thought it would be nice to do a little project in advance of Middlemash. When we brainstormed what we could do I originally suggested that maybe someone had drawn a map of the fictional geography of Middlemarch, and if we could find one, we could make it interactive in some way. Unfortunately a quick search turned up no such map. However, what it did turn up was something equally interesting – this map of relationships between characters in Middlemarch on LibraryThing.

This inspired a new idea – whether this could be represented in RDF somehow. My first thought was FOAF, but initially this seemed limited as it doesn’t allow for the expression of different types of relationship. However, I then came across this post from Ian Davis (this is the first in a series of 3), which used the Relationship vocabulary in addition to FOAF to express more the kind of thing I was looking for.

The resulting RDF is at However, if you want to explore this is a more user-friendly manner, you probably want to use an RDF viewer. Although there are several you could use, the one I found easiest as a starting point was the Zitgist dataviewer. You should be able to browse the file directly with Zitgist via this link. There are however a couple of issues:

  • Zitgist doesn’t seem to display the whole file, although if you browse through relationships you can view all records evenutally
  • At time of posting I’m having some problems with Zitgist response times, but hopefully these are temporary

This is the first time I’d written any RDF, and I did it by hand, and I was learning as I went along. So I’d be very glad to know what I’ve done wrong, and how to improve it – leave comments on this post please.

I did find some problems with the Relationship vocabulary. It still only expresses a specific range of relationships. It also seems to rely on inferred relationships in some cases. The relationships uncle/aunt/nephew/niece aren’t expressed directly in the relationship vocabulary – presumably on the basis that they could be inferred through other relationships of ‘parentOf’, ‘childOf’ and ‘siblingOf’ (i.e. your uncle is your father’s brother etc.). However, in Middlemarch there are a few characters who are described as related in this manner, but to my knowledge no mention of the intermediary relationships are made. So we know that Edward Causubon has an Aunt Julia, but it is not stated whether she is his father’s or mother’s sister, and further his parents are not mentioned (this is as far as I know, I haven’t read Middlemarch for many years, and I went from SparkNotes and the relationship map on LibraryThing).

Something that seemed odd is that the Relationship vocabulary does allow you explicitly to relate grandparents to grandchildren without relying on the inferrence from two parentOf relathionships.

Another problem, which is one that Ian Davis explores at length in his posts on representing Einsteins biography in RDF is the time element. The relationships I express here aren’t linked to time – so where someone has remarried it is impossible to say from the work I have done here whether they are polygamous or not! I suspect that at least some of this could have been dealt with by adding details like dates of marriages via the Bio vocabulary Ian uses, but I think this would be a problem in terms of the details available from Middlemarch itself (I’m not confident that dates would necessarily be given). It also looked like hard work 🙂

So – there you have it, my first foray into RDF – a nice experiment, and potentially an interesting way of developing representations of literary works in the future?