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.