OiRc-0003 Early designs for a library system

LibrarySystem

As the son of a professional librarian, Anna Rovira, the librarian who set up the first computerized library system in Quebec, Canada, I had the opportunity to be exposed to a great deal of information (and the occasional ''juicy'' epithet hurled at MIS folks, [Think librarians are ''quiet little ol' ladies?'' Think again. They know all the ''dirty words'' and a lot more that you've never even heard of. They are second only to mathematicians in their alcohol consumption capacity and as ribald a bunch as have reddened my ears.] :-) about the data structures and functionality of a public library.

In fact it shaped my understanding of my profession before I even knew it was going to be my profession. I started my school life as an engineer and an architect by inclination. I thought in terms of Frank Lloyd Wright, Ludwig Mies van der Rohe and Buckminster Fuller and I wasn't aware of the existence of Donald Knuth or John McCarthy or Alan Kay.

Rather than plow old ground that I honestly haven't seen in years, its been done by others much better than I could do it. I will instead point to a great source of information and defer to Library Information Interchange Standards and here is a good glossary and another and another.

As we evolve the data structure to support the functionality a library system must have and extend to what functionality it could possibly have if we exploit the data structures and object relationships to their fullest, it will become clear that there's a lot more to systems design than ''Use Cases''.

Data Structure

Lets start with the two basic objects:

a Library and
a Member.

Leaving aside for the moment the possibility of inter-library loans, we are going to explore the objects and their relationships. We will describe the syntax of our discussion more fully in RelationshipNomenclatureAndSymbology. Suffice it to say that the diagrams are slightly modified BachmanDiagrams for rendering as text-only in a fixed width font.

For the scope of this system, we will consider a single library system. A single entity which lends material to its membership. Exploring this yields the folowing structure:

. Library --> Member

What constitutes this relationship? The library lend material to its members. This material can be books, periodials, audio/visual resources. The library tracks all of its material as acquisition and the purchases by accession numbers. This yelds the folowing data structure diagram:

Grrr! There is one reason to hate the editor that you get with blogger. I can't draw the ascii art that appear on my original wiki page. It loses the interword spacing and collapses it all back to a single space. I'll have to speak to somebody about this.

. .-----------------------------.
. | v
. Library --> Acquisition |<--| Member

This is the basis for a Circulation system.

First though, lets take a moment to notice something about both these objects. They are both entities and any Entity has a Location in space/time. Of course a location can be shared by many entities. And Entities can change their Location over time (perhaps periodically).

. Location
. ^
. |
. v
. .----------- Entity ----------.
. |.---------------------------.|
. || v|
. Library --> Acquisition |<--| Member


Now the relationship between a Library's Members and a Library's Acquisitions is not as simple as the ownership relationship between the Library and its Acquisitions. Members can borrow individual Acquisitions or they can reserve any copy of a similar Acquisition.

This gets us into the basic functionality of circulation. We'll get back to function in a moment. While we circulate an Acquisition we reserve any acquisitions which is described in a Catalogue. We are now going to explore cataloguing.

Location
^
|
v
.----------- Entity ----------.
|.---------------------------.|
|| v|
Library --> Acquisition |<--| Member
^ ^
| |
Catalogue <--------.

Now in order to be useful, a catalogue has to be organized (you'll see why just being searchable isn't enough in a second,) and the mechanism used since the founding of the Great Library of Alexandria is the use of a taxonomy (which for the sale of simplicity we'll call a Category).

If you use only keywords, you can't even formulate a proper query. Think about this: ''Is a word used in an Acquisition or in a query an author, a subject, a title or something else altogether?'' Shakespeare was the author of many plays, the subject of a lot of books by other people and has been the title of many books and movies.

Location
^
|
v
.----------- Entity ----------.
|.---------------------------.|
|| v|
Library --> Acquisition |<--| Member
^ ^
| |
Catalogue <--------.
^
|
v
.-> Category->index
| | ^
'-----' |
Keyword

These are the basic objects apart from a few additional relationships between:

• Catalogue antry and the entity known as its publisher,
• the Entity know as its authority and between an
• Acquisition the entity known as its vendor and
• Member and another (family) member .

Location
^.--------------------.
||.------------------.|
v|| |A
.----------- Entity ----------. |
|.---------------------------.|.--. |
|| v|v | |
Library --> Acquisition |<--| Member| |
^ \ ^ '-' |
| '-A | |
Catalogue <--------. |
^ \ |
| '-----------------'
v
.-> Category->index
| | ^
'-----' |
Keyword

On-page connectors like A there are why I developped ArticleRoviraRepresentations a technique for seeing tables and relationships in 3D. (I can't pull it up and it deserves its own entry so you'll just have to wait. :-)

Functional Structure

So what can we do with this data structure? (Here we touch CRUDE matrices and the ConceptsOfApplicationSecurity, which is the subject of another wiki page I can't pull up right now and therefore another blog entry. :-)

• We can maintain the Library's information (and its related Entity and its related current Location.)
• We can Maintain any Member's information (and its related Entity and its related current Location.)
• We can maintain any Entity's information (and its related locations).
• We can maintain any Entity's Location information.
• We can maintain an Acquisition's information (and its related Supplier Entity and its related Catalog entry.)
• We can maintain Keyword entries.
• We can maintain any Category and its relationships to other categories and its relationships to Catalog entries.)
• We can maintain any Catalog entry's information (and its relationships to Acquisitions and its relationship to category/keyword entries.)

To make life simpler, we want a Front Desk to organize the functionality and to sweep through the database and to maintain things like:

• Membership maintenance (and produce Late Notices.)
• Reservations (Member Catalog relationship) (and produce Reservation Notices.)
• Loans (creating a Member Acquisition relationship)
• Returns (Dissolving a Member Acquisition relationship)

To make life simpler, we want a Cataloging Desk to organize the functionality of the catalog and the indexing of acquisitions and maintain things like:

• Suppliers
• Categories (and category taxonomy.)
• Keywords
• Catalogue entries

I have mercifully omitted See and See Also references but these are actually just N:M relationships between catalogue entries. (Actually I've got some thoughts about objects and relationships that have to be seen to really be Groked' :-)

To make life simpler, we want an Acquisition Desk to organize fhe functionality and to maintain things like:

• Supplier Entries,
• The links to Catalogue entries (and produce New Acquisitions Notices.)

So far, this stuff is all back-end or ''behind the desk'' functionality.

For the membership, we want Reference Desk functionality which will allow them to explore the entire holding regardless complexity and play with keyword searches and the taxonomy. (For this we might want to allow this to spawn windows and to change search pivots from taxonomy to keyword.)

There are a couple of things missing from this analysis. Chief among there are:

• Objects instances have states
• relationships should be clearly named

We'll return to the topic in a future cast.