Tuesday, 21 September 2010

JISClms Programme Meeting 7-8 September 2010, Glasgow University

Before attending

I was reluctant to attend the meeting, because it seemed to be too much: two full days for two of us, when the project itself lasts only six months and doesn't employ either of us involved in it full time. And we don't really fit into the groups suggested for discussion. John, being a busy local councillor, was unable to attend, but even so it seemed like a lot of time, particularly as Glasgow is not a convenient place to go from Cambridge where I am based, and as it clashed with the time I usually take my holidays. And I hate conferences, anyway. Like training sessions, they don't usually offer much beyond poorly organised presentations and certainly are no substitute for the material available on the Internet. So perhaps I attended determined to feel that it wasn't worth the effort.

I don't object to Glasgow as a venue, particularly. Having worked in Northern Ireland, I know that those who are involved in JISC projects from those parts of the UK distant from London face frequent and distant travel: in eighteen months based in Coleraine, I flew to England nine times. So it does seem only fair that occasional meetings should redress the balance somewhat by being held outside London and the south east of England. Even with decent bandwidth, JANET and Skype videoconferencing are no substitute for an actual meeting, either; but perhaps the future should be about virtual conferences, either using video or in virtual worlds such as Second Life.

Day 1

Each project was asked to provide a single powerpoint, as the basis for a three minute presentation as could be made to senior management. It was useful to see these, though I could have picked up more by looking at the project websites/blogs. (But I might not have done so if I hadn't been forced to sit through them!) It was a pity I couldn't get the WIFI to work - my netbook is short of space, so I hadn't installed Java, needed to run the applet which allows authentication to the Glasgow University guest network. Why wasn't there any support for Eduroam at the meeting, which would seeem a much better proposition for most of the delegates to this particular conference than Glasgow's conference guest network? (The answer, it appears, is that Glasgow isn't an eduroam site.) It looked as though there was some lively chat on twitter, which I will need to look at later.

There was some interest in the locator, mainly questions about how we are handling the location discovery side (which is detailed here). We also came into a small amount of criticism, for apparently setting up requirements because they seemed interesting to us as developers rather than because they came from genuine user need. I suspect this is prompted by this blog post, about choosing to use latitude and longitude to identify a location; in our defence, we had to choose some sort of co-ordinate system, which could be independent between different maps on which the same location might be found; for this purpose, lat/long serves almost as well as any other (though it does suffer from the complication that latitude goes upwards on a map, while the y co-ordinate of a spot on a graphic increases downwards from the top). It was this choice which makes it possible for us to add in new features without any significant development cost, such as allowing the display of the map to link to Google map centred at the same location.

It was also useful to renew acquaintances with several of the other participants, including some who have previously worked with us on projects, such as Dan Sheppard (from Caret in Cambridge and the FAR Project) and Owen Stephens (now a consultant, but formerly at RHUL and the ShibboLEAP Project).

The main event of the morning was the keynote, devliered by Lynn Silipigni Connaway from OCLC. This was interesting in its analysis of a lot of work over the last few years looking into how users regard libraries, coming to the conclusion that things are going to change and that academic libraries cannot wait until the current teenagers, with their familiarity with online tools going far beyond that of previous students, arrive before planning for this change. This was based on Lynn's report available online, which I would urge those interested in the future of UK academic libraries to read.

The catering for lunch was not wonderful, though of course the expectation was that most people were staying in the hotel and would have hot meals there. But it was perhaps a bit of a confirmation of the stereotype that Scotland is the home of unhealthy eating to have a choice of cakes and no fruit as a sweet, which is certainly unusual for this type of catering.

During the afternoon, we split into three groups, user experience, electronic resource management and open source. The locator project doesn't neatly fit into any of these categories, so I joined the open source discussion, as the one most interesting to me personally. The focus here was on the possibility of UK HE institutions adopting open source LMS systems, something which, by the end of the afternoon, I felt seemed likely but only on a small scale (mainly because of lacking functionality in existing OSS candidates, in addition to the usual fears about large scale OSS software, such as support, risk and sustainability). since the UK community has some distinct requirements, and there is not yet a significant UK community around OSS LMS systems, such issues are unlikely to go away any time soon. My impression at the end of the day - though I had to leave early - was that the outlook for open source LMS in the UK is pretty pessimistic.

The highlight of the day occurred on the trip back to the cottage near Penrith in which I was staying, as a kestrel stooped on the dual carriageway and landed about four feet away from me on the verge as I passed. Unfortunately, this trumps LMS and open source for me!

Day 2

A different venue (downstairs in the same building), but still no access to the WIFI.

The morning session was about turning what was thought yesterday about OSS LMS into an event for later in the year. The tone seemed rather more optimistic, as the focus was on how to get the messages of some of the advantages of OSS which are applicable to LMS (as on the white board in the morning): competition is good, there is an ability to show rather than say, and that in the current climate, we need cost saving options. Added to this, the discussion identified the need for flexibility - libraries are starting to want to add community developed widgets and use open interfaces for delivery of information to wherever it is wanted - VLEs, Facebook, mobile apps, etc.

By the end of the discussion, the remit of the event under discussion had moved away from a discussion of OSS to interoperability and flexibility of this sort: the event will have the tag (better than a title nowadays!) LibOpenEdge. It will be two days in January, one day for technicians, to look at some of the tools (OSS LMS, VUFind, etc) and then discuss the problems they have encountered (and the flip side, success stories) of trying to integrate data from diverse systems including the library. the style of the event would be mashedlib. This would be followed by a day aimed at senior managers, which will present the interoperability message, including the bad and good things noted on the first day. Vendors will be invited, and should hope not to be embarrassed!

Lunch was followed by a series of surgeries. The purpose of these was to help refine the three minute project pitches from the first day into something which could really be used to explain the importance of a project to senior management. This was actually quite helpful, with critical questions from experienced experts to elicit more benefits oriented pitches: less about what the project does, more about what the project does for you. The pitches are then supposed to become a  blog post, so I won't repeat it here. The meeting then finished early, leaving me with an hour and a half to fill before the train I had booked a seat on left. So I hung around and continued to talk to people for a while, before finally catching the subway to Glasgow Central.

Overall

I ended up enjoying the conference more than I expected to beforehand. Our project is perhaps an outlier in the programme, rather different from the others: it is more about development than integration, and this was why it was hard to fit into the groups on the afternoon of the first day and the morning of the second. The best parts of it were the opportunities to talk to people, and to establish some community ideas about issues such as the role of OSS in library IT.

Did I take away anything that would really help with the project? No, I don't really think so; our concerns are a little too different from most of the other projects. Were the discussions interesting? Yes, but they could have just as easily have taken place online, as far as I am concerned. Whether the discussions would have happened online is another matter; the event provided the impetus needed for them to take place. To me, this impetus was more than was needed, a big effort for something which I would have done with less effort. But that is largely just my preference for online tools over meetings.

On the other hand, the conference was about community building, and it pretty much succeeded in this. So JISC should count it a success.

Tuesday, 3 August 2010

Finding some book-seekers

We have various routes to contact 'tame' library users; but those are more likely to be the ones who already know which shelves the subjects they want live on.

A way to make contact with 'users in the wild' might be some cards (or Post-It notes) spread around the library, with our contact details and some eye-catching slogans ("Lost???", "Can't find your book???", "Where's my book??"). There's a possibility that this could annoy some library staff, or some library users; would that be a significant risk to the project, and how much do we care? We might get them on-side by running a competition (in the Library staff newsletter) to suggest the best messages...???

Postscript: I notice some internal discussion of QR (bar)codes amongst staff in Library IS today. If as it seems they're intending to post up 'fun' quizzes etc for students, around the Library, we could always disguise our messages as QR codes too, and take any user (with a suitable smartphone) to one of our URLs!!!

Thursday, 29 July 2010

Our first testable software

We now have our first working software. This is the map display component; it runs both as a servlet and as a command line application (which produced the image on the left).

This interface will retrieve one from a specific group of maps and mark a location on it. The generic URL for a map with a pointer displayed will be http://findmylibrarybook.in/library/mapgroup?location=longitude,latitude&bearing=angle-in-degrees&resolution=string-which-matches-a-filename.

Here, "mapgroup" indicates a collection of maps (e.g. "first-floor", "SouthLondonCampus"), location indicates the position to place the pointer in latitude and longitude, bearing the number of degrees from true north to rotate the pointer graphic, and resolution the particular map to choose from the collection, in this case "mapgroup-high.extension" - the application will cope with a number of extensions and corresponding file formats, but will choose the first matching one if there are identically named files but for the extension.

We have some test URLs to see a variety of behaviour of the servlet, including the expected errors from incorrect URLs (e.g. specifying a non-numeric latitude or orientation). Note that these are not guaranteed to continue to work, as we refine the software. Further work clearly needs to be done to refine the display of the arrow (persuading the Java JAI that the rotated image should be surrounded by a transparent rather than a black background). The map graphics used come from OpenStreetMap and from the LSE hosted archive of the Booth maps of poverty in London at the end of the nineteenth century.

Note: The links below have been updated to reflect the new working location of the test locator (there were java versioning problems in the old location which prevented the servlet working properly). The new location does not have a commercial web server certificate but will only accept external connections via https, so access will require the user to accept a self signed certificate (i.e. one which a web browser will flag as invalid).

Firstly, https://far-project.lse.ac.uk/LibraryLocator/DisplayMap/lse-campus?resolution=openstreetmaplibrary&;location=51.514532,-0.117057 should place arrow pointing due north.

Rotate arrow to each quadrant

https://far-project.lse.ac.uk/LibraryLocator/DisplayMap/lse-campus?resolution=openstreetmaplibrary&location=51.514532,-0.117057&bearing=35

https://far-project.lse.ac.uk/LibraryLocator/DisplayMap/lse-campus?resolution=openstreetmaplibrary&location=51.514532,-0.117057&bearing=162

https://far-project.lse.ac.uk/LibraryLocator/lse-campus?resolution=openstreetmaplibrary&location=51.514532,-0.117057&bearing=223

https://far-project.lse.ac.uk/LibraryLocator/DisplayMap/lse-campus?resolution=openstreetmaplibrary&location=51.514532,-0.117057&bearing=309

Different maps

https://far-project.lse.ac.uk/LibraryLocator/DisplayMap/lse-campus?resolution=openstreetmapclose&location=51.514532,-0.117057&bearing=162

https://far-project.lse.ac.uk/LibraryLocator/lse-campus?resolution=openstreetmapmedium&location=51.514532,-0.117057&bearing=162

https://far-project.lse.ac.uk/LibraryLocator/DisplayMap/lse-campus?resolution=openstreetmaplarge&location=51.514532,-0.117057&bearing=162

Errors

This should display map with no arrow (because the requested position is off the map): https://far-project.lse.ac.uk/LibraryLocator/DisplayMap/lse-campus?resolution=booth&location=51.514532,-0.117057&bearing=162

This should return 404 not found (no map file of that name): https://far-project.lse.ac.uk/LibraryLocator/lse-campus?resolution=openstreetmaplibrary&location=71.514532,5.117057&bearing=309

This should return 503 (because location doesn't make sense): https://far-project.lse.ac.uk/LibraryLocator/lse-campus?resolution=openstreetmaplibrary&location=71.gdsryer514532,5.117057&bearing=309

Monday, 26 July 2010

CampusM at LSE

A secondary objective of the Library Locator project is integration on mobile devices with the CampusM service, for which LSE has contracted with oMbiel.

This launched on Apple iPhones only, but is now available in a generic 'mobile web' version at http://lse.ombiel.co.uk. (It will reject access by browsers identified as 'not mobile devices'. Either try this on a mobile browser, or use User Agent Switcher or similar to fool it into talking to your big browser.) Proper apps for Android and Blackberry are forthcoming.

Further information about CampusM is at http://www.ombiel.com/campusm.html

Wednesday, 7 July 2010

How does a Library relate to the Real World?


If we want to find a book (in the spatial sense we're talking about in this project), let's assume we start from somewhere in the known physical universe (a fairly safe assumption).

Let's look at some other assumptions we can make, and assess how safe each is, or what caveats (i.e. restrictions to functionality generated) we need to add to them.

A first pass of requirements at how a location should be indicated elicited the requirement (from one of our Library IT Team colleagues) that "the top priority requirement [for the LibraryLocator] is that the orientation of arrows on the map can be controlled - so they don't obscure text or other details". I'd question whether this is really the "top" priority - either for end users or for the librarians who will need to edit this data (for each of the assumed <=5,000 distinct shelf-bay locations that are likely to be our maximum resolution).


We have problem of deciding how a location can be recorded just once, and then displayed on a variety of background plans which may be at different scales (to suit display on different end-user devices etc), different orientations (of text on a plan) and different levels of detail.

A long lunch in the Senior Dining Room (lamb tangine with cous-cous and preserved fruits) yielded the diagram above and the realisation that the best sort of coordinates to use will be those of the real world.

Whenever a plan is imported to the LL (this shouldn't happen very often, and there are only likely to be <=20 of them), it needs to have metadata added (either in standard internal JPEG/PNG fields, or in an external registry file/table of known plans). This metadata for all plans can be read in just when the LLmapdisplayer initialises (not for every search) and should include:

  • the real-world Lat-Long of the bottom-left corner of the plan graphic;
  • the real-world Lat-Long of the top-right corner of the plan graphic (both so that orientation of the plan is sensible when displayed w.r.t. text/symbols shown);
  • the X,Y dimensions in pixels of the plan graphic (we assume all graphic files are rectangular).
When a plan is imported, the LLeditor must allow this to be done reasonably easily (there are only about 20 of them and they don't change often). In v1 it would be acceptable to expect a user to click two points on the plan, and locate the corresponding points on the building as depicted by GoogleEarth, copy-pasting in the Lat-Long values. (A smarter v2 may be able to use a GoogleMaps API to capture the values, or even allow positioning/rotation/scaling of the plan image overlaid on GoogleMaps to align with the real-world features - OutOfScope for now!)

When an arrow (or whatever appropriate location indicator graphic - also a rectangular image) is placed, the LLeditor must allow this to be done very easily (there may be 5,000 of them!). It must allow a hot-spot (e.g. arrow-point) to be positioned, and then allow for the arrow graphic to be rotated around the hot-spot point. The location and orientation of the arrow should each be recorded by translating into real-world coordinates (Lat-Long and compass bearing) so they're effectively absolute. They can then be rendered by the LLmapdisplayer using any background plan. If an editor-user chooses an orientation for the arrow which clashes with some other background plans, that's OutOfScope for now too.

A little experimentation with Google maps and at http://pagesperso-orange.fr/universimmedia/geo/loc.htm (to pick one site from a quick search) was in order. Searching for Portugal Street London makes it easy  to view the LSE library (if you know which building it is!) and find the latitude and longitude of the corners of the building, to five decimal places (lat 51.51473, long -0.11641; lat 51.51494, long -0.11563 for the western and northern corners respectively). This would give a resolution of about 60x130 for a map which has a pixel for each square corresponding to the least significant digit produced, clearly not enough for our purposes. But Google maps will at least accept more places of decimals, so as long as the initial processing of the map graphics is done more carefully, it should be possible to get higher resolution numbers for the corners, and so to place a pointer more accurately in a range of maps with different edges.

Tuesday, 6 July 2010

How Can We Find a Library Book?

This is the fundamental question which we need to answer to carry out this project. We have assumed that the best way to do this is to take a unique ID for the book (or other item held by the library) and obtain the information need to find it from the LMS system database. But...

  1. Different libraries use different LMS products. So the information is found in the same place: different queries will be needed depending on the product used.
  2. Even if two libraries use the same LMS, their holdings may be organised differently. For example, one library might have two items with the same classmark which are in different locations because of their acquisition date, while the acquisition date might be totally irrelevant in another library. So the information needed to find an item is not necessarily the same, even when the library system is the same.
  3. Even if two libraries organised their holdings in identical fashion, their different holdings might still require different information. For example, in the LSE library, paper archives of academic journals are organised by the classmark which represents the scope of their contents, so that journals which cover all of economics need to be given the Library of Congress classmark H (this covers the whole of the social sciences, but a journal can't be given the classmarks HB-HJ, all of which cover subjects which could be seen as sub-divisions of Economics as a whole. This means that the journal title is needed to narrow down the location to a single bookcase. But with a library which doesn't have such extensive journal holdings within a particular subject area, this might well not be necessary.
  4. Even if two libraries organised their holdings in identical fashion, their cataloguers might enter data into the system in different ways. LMS databases are complex, and decisions have to be made as to where particular information should be stored.
This is a potential minefield, if we want the locator software to be reusable. The difficult thing is to design a database structure which is sufficiently general and at the same time comprehensible to be managed (so that just having tables for "field1", "field2", etc. is not sensible).

There are, in the end, five database fields whose values are sufficient to determine location (to the level at which the locator will operate) in every case (though they are not all needed for some items). Using English language labels rather than the actual column names, we have, in approximate order of specificity:
  • Location In the LSE's LMS database, the "location" field is rather overloaded, as it contains information which is not location related (e.g. "Main collection - normal loan": though the collections contain items with different loan lengths depending on anticipated use, these are all shelved together).
  • Item type Journals, books, theses, DVDs, and other media types may well share classmarks and yet be shelved separately. Of course, they may also be shelved together - CDROMs are shelved among the books at the LSE library.
  • Item status This is needed to determine whether the item is on the shelve, or on loan, lost, or requiring a fetch service. In most of these cases, displaying the location is beyond the scope of the locator - but the locator will need to know what to do about it (e.g. offer a link to a reservation form) if asked.
  • Classmark Probably the most important single piece of information for determining the location. Usually LOC, but there are also some local schemes (theses, official publications, etc.).
  • Title As mentioned above, this is needed for some journals. 
I now define a collection to be "a set of items such that two items which share the same classmark will be shelved together". This is just so I can use a convenient word for this, and despite the fact that I have been told that this doesn't necessarily equate to what a librarian would mean by a collection. (If you have a better idea for the name to use, let me know!) Then the five fields which determine the location of an item can be divided into those which determine the collection containing the item (the first three) and those which specify the location of an item in a collection (the remaining two).

It seems likely that this division will be possible for most, if not quite all, academic libraries, whatever the information which needs to be placed in each category: the fields will often be different, but the two groups of fields will still be definable. So the proposed solution to the problems of the undefinable nature of the database fields to use is this:
In order to find an item, obtain the field values which make up the two location defining groups of fields. Order them (in a vague way) in terms of specificity: this will make it easier to find the required items. Concatenate these values (with a certain amount of abbreviation, which should be configurable). The two long strings should then uniquely define the location of the item, to the level of a bookcase, so a lookup table simply checks these two strings, and takes the longest match from the table to define the location. (Which means in practice that the title will be ignored unless needed, and that shorter versions of classmarks can be used to define larger areas if this is considered desirable.)
 Is this the answer? It's certainly rather messy, but should prove both portable and lightweight. It will make updating more difficult, because exact versions of the various strings will be needed to specify the location. This could be overcome by an interface for administration which allows the user to specify the location of a single item, and then fuzz the item information, by deleting parts of the concatenated strings obtained for the item from the LMS database or using wildcards, to indicate that the same location should be used for other items with similar information stored by the LMS.

    Wednesday, 16 June 2010

    How many shelves are in the LSE Library?


    We don't know! Asking various colleagues who (arguably) should know (they 'do books'; we don't) the estimated answers varied between 2,500 and 18,000. My rough estimate after a quick count of one area was about 5,000 and this tallied with the un-prompted guess from our LMS manager.

    By 'shelves' we mean one side of a single vertical stack, about 1.2m wide and normally of 7 actual rows of books. Here is an overview of one typical area of our stacks.

    We think LSE is fairly representative of the 'large' end of libraries for which the LibraryLocator will be usable (i.e. not the BL or the Library of Congress). If the answer is in the region of 5,000 we can probably use a simple and fast in-memory approach to lookup; but not using a rdb backend would mean we'd have to do slightly more work on the maintenance user interface.