With LUMP what we’d like to achieve is a far more flexible database design than the previous versions of the LORLS reading list system. Traditionally we’ve modeled the database structure and the resulting relations on a fairly restricted model of book like objects and also had to work round limitations in the way reading lists were used. For example at Loughborough we were initially told that a module would have a single reading list. This proved to not always be true – sometimes a module would be taught by more than one lecturer and so we had to introduce the “bodge” of sub-lists linked to the main one. As other institutions used LORLS we also found that our way of linking reading lists to modules to courses to departments did not always match up with other organisations’ structures.

So we thought it was time for a rethink. We wondered if it was possible to come up with a generic data container that could be a reading list item, a reading list itself, a module, a course, a department, a faculty or indeed anything you like. We called these containers “structural units” and decided that they could contain metadata and/or other structural units. The more we thought about structural units, the more we realised that a generic concept such as this could allow great flexibility in a reading list system, and possibly also form the basis for other systems.

However it was also clear that we needed more than just the structural units themselves. For one thing it was felt to be advantageous to all structural units to be grouped by type, such as “reading list”, “module”, “department”, “book”, “video”, “3d holographic projection”, etc. The typing system would allow a set of custom metadata elements to be defined that would be available to all structural units of the given type. For example a “department” structural unit might have metadata of a department name, a URL pointing to a departmental website and another URL pointing to a departmental logo. A “book” on the other hand would have the normal bibliographic and holding information metadata that we have used in LORLS for some time.

Each piece of metadata itself has a type, and a value. The value is the actual piece of metadata (“Andrew S. Tanenbaum”, or “Computer Networking”, or “Prentice-Hall”, etc for a book for example). The data type on the other hand tells us information about whether this piece of metadata is repeatable or not (you might only allow one record of holding information but allow any number of authors for example), where it is ranked in the output, and how it is to be represented for editing (string, integer, date, etc). The data type can also be linked to a controlled vocabulary if required to limit the choices available for associated data values.

Structural unit types could also be linked to one another as parents and children, so that we could enforce certain heirarchical or mesh layouts on structural units of given types. For instance a structural unit type of “department” is a child of a type called “faculty”, so only structural units of type “faculty” can be a parent of a “department” typed structural unit.

The data structure also need to encompass information about the ownership of structural units, and the permissions users had to access and/or alter them. Users could be part of one or more usergroups, and the groups have access controls applied to them for access both to structural units themselves and also editing sections (the name of which was hotly debated for several weeks but which is currently “Data Type Groups”!). The editing sections allow us to group data types that are “similar” together, thereby allowing such things as tabbed editing for a single structural unit, with each tab holding a different sort of metadata (holdings, bibliographic, etc).

We wanted to allow structural units to be rendered in a variety of forms (HTML, BibTeX, RefWorks, etc) and had to decide whether this was a client or server side task. We decided on doing it on the server side as it meant that a single set of code at the server could then produce output for a larger number of simpler clients. It also meant that new or changed output formats only required changes to be made once at the server end, rather than in all the clients. For flexibility we could still return structural unit information to clients in “raw” XML so that they could process it themselves, or to allow them to provide editing features.

The current database ER diagram is :