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.

    Tuesday 15 June 2010

    The reality of books on shelves

    We had a useful discussion today around the relative benefits of simplicity and complexity (of the LibraryLocator). It's very tempting to get sucked into the complexity, built up by several generations of librarians, of cataloguing one particular library collection; and then design a data model and a system that reflects this complexity - which will be very hard to adapt to any other library, or to some future change in our own complexity by the next generation.

    Alternatively we can generalise (and simplify) as much as possible, whilst checking that any assumptions we make (e.g. "All classmark systems are (mathematically) continuous; and linear") don't break any desired functionality for our own implementation at LSE, and clearly stating these in the "Is this suitable for your library?" section of the re-use guide. (For example, the Bodleian and the British Library both use LMSs that have inherent fetch locations for all items, so may not fit the above assumption.)

    The original SHerLoc system used a very simple 'longest possible' match of the desired classmark against a simple Perl hash, so that location data could be maintained at whatever granularity the library staff could manage - maybe just locating an item down to a particular floor or room. It allowed for just two distinct 'collections' (books and journals) because that's how most things were organised then. Can we reflect all our current requirements, just by defining a larger number of collections to cover the different things with different identification schemes?

    We set off into the bowels of the LSE Library to check-out two things: How many shelves does the LSE Library have? and How are 'government publications' organised? (apparently these are tricky.)

    I'll add some pics from Flickr to a further post.

    Friday 7 May 2010

    Project Plan Post 5 of 7: Project Team Relationships and End User Engagement











    John Paschoud will manage the project and coordinate liaison with stakeholders (including end-users) and dissemination. John is also currently managing the JISC-funded Identity Management Toolkit Project. He has over ten years of experience in managing projects funded by JISC and other agencies, including the HeadLine Project.










    Dr Simon McLeish will act as Software Developer for the project.
    Simon has extensive experience of open source software development
    and use of the technologies required by this project.


    Staff from the LSE Library IT Support Team will assist in integration with existing LMS and location data. Staff from other sections of the LSE Library will assist in collating and checking new location data and layout maps of the Library building. Library helpdesk staff will assist with recruiting test end-users, and with directing users to the Locator service.

    Thursday 6 May 2010

    Project Plan Post 4 of 7: IPR (Creative Commons Use & Open Source Software License)

    All material on this blog and other documentary outputs of the project are the property of the contributing authors and are licensed under this Creative Commons Licence except where otherwise noted.

    Software outputs are licensed under the GNU General Public License version 3.

    Outputs from the project will be  copyright 2010.

    Wednesday 5 May 2010

    Project Plan Post 3 of 7: Risk Analysis and Success Plan


    Risk
    Probability (1-5)
    Severity (1-5)
    Score (P x S)
    Action to Reduce/Manage Risk
    Staffing: Loss of key project staff
    2
    3
    6
    Ensure technical implementation and design are well-documented so that alternative staff can take over.
    Technical: Failure of hardware or supporting software
    1
    3
    3
    Use of operationally hosted/managed servers and replaceable virtual server hosting where possible; maintain good communication with staff managing servers.
    Legal: IPR
    1
    1
    1
    No IPR difficulties are anticipated as the project is undertaking technical development based on code written and owned by the LSE Project Team and already covered by Creative Commons license.
    Organisational: Difficulty in recruiting sufficient numbers to join test user panels
    2
    4
    8
    Local staff with existing relationships with potential user panel members are engaged with the project. Budget allows for some incentives for participation.
    Organisational: User testing is held up by unpredicted delays in technical development
    1
    5
    5
    First stages of user testing are on concepts/language only. Subsequent stages are dependent only on implementation of HTML 'controls' - not fully functioning webservices.
    Technical: tools fail to provide minimum required functionality
    1
    5
    5
    Development entirely in-house with no external dependencies; Development work will be organised to be as incremental as possible
    Technical: tools developed prove impossible to integrate with other services
    1
    5
    5
    The design of the tools developed will use standards and mechanisms already proven to integrate with a wide variety of services
     

    Tuesday 4 May 2010

    Project Plan Post 2 of 7: Wider Benefits to Sector & Achievements for Host Institution

    Benefits for the University Sector

    Most universities will have complex holdings in their libraries, and library users often find it hard to understand cataloguing systems. So there is a general need for software which can help to find hardcopy materials as well as electronic resources. Several libraries have set up their own locator systems, of varying degrees of sophistication and ease of use: examples include Brunel (which maps to the shelf location) and Cambridge (which maps to the room). Others do not do so; a informal random search of five university libraries picked up only these two having interactive maps at all. The JISC funded HeadLine project found that shelf mark locations were the second most common query at library help desks in 1998. In the absence of more recent data, this seems likely still to be true and so provide a driver for improved discovery tools for books and paper journals which this locator would fulfil.

    The tool to be developed by this project should satisfy this need. It should be easy to install and manage, and should, through its simple RESTful interface, be easy to integrate into a range of other tools, including LMS and VLE software.

    Benefits for the LSE

    The LSE library already has a system in place for showing the location of books found through the library catalogue, originally developed as part of the JISC funded HeadLine project in the late 1990s. However, there are distinct benefits associated with a re-write:
    • The code now very old and because of multiple iterations becoming difficult to maintain.
    • The locator was designed to work with the LMS OPAC and would need to be revised if linking in directly with VLE or supplying location maps suitable to formats requiring less than a full PC display (widgets within social spaces as well as portable devices).
    • It is tightly tied into specific LMS software and will have to be reworked if the system used at the LSE changes.
    • It does not work for all items in the catalogue (e.g. books which share the same classmark but are shelved separately.
    • The administrative interface is cryptic and very basic: it is maintained by IT staff rather than cataloguers despite the data itself being catalogue related.

    Saturday 1 May 2010

    Project Plan Post 1 of 7: Aims, Objectives and Final Output(s) of the project

    Aims

    The principal aim of the project is to produce software which is:

    1. Functionally capable of returning a map graphic with the location of an object from a library catalogue marked on it (or appropriate error message) on query via a RESTful interface;
    2. Conceptually capable of being re-used by other members of the HE community, not tied in any way to the specific complexities of the LSE's cataloguing and shelving;
    3. Technically capable of being re-used by other members of the HE community: well documented, tested, and easy to set up and administer;
    4. Using open standards and providing a (documented) RESTful interface to enable re-use in other contexts than a library catalogue;
    5. Freely available as open source re-usable software.
    Objectives

    Satisfying the following objectives should make it possible to realise the above principal aim.

    • To understand and meet user/administrator requirements from a locator service at the LSE.
    • To understand and cater for the complexities of shelving and cataloguing at the LSE.
    • To ensure sufficient flexibility to make the application usable outside the LSE.
    • To produce documentation which is clear to potential deployers and administrators.
    These objectives will inform the design, testing and packaging of the locator service, on the assumption that most of the complexities of any HE academic library's shelving can be modelled from that of the LSE. In one important aspect, this is not quite true, in that the LSE has a single library on a single campus, but when this limitation is taken into account in the data model design, it should result in one which is transferrable elsewhere in the UK. The model itself will be available for scrutiny, of course, and librarians from other institutions than the LSE will be specifically invited to comment.