[OPEN-ILS-DEV] Discussion wanted: Volumes (Parts) in Evergreen

[Dan Wells]

Hello all,

After trying very hard to convince myself otherwise, it is yet my belief that Evergreen needs to augment its current item organization hierarchy with an additional layer for proper volume (part) support.  My only intention in writing this email is to hopefully spur a larger discussion on this matter.  For the purpose of this discussion, I will define volume as "a portion of a bibliographic whole."  

As it stands, the asset.call_number table is being overloaded to function as both a place to hold the call number and a place to hold volume information.  Under non-volume circumstances, the call number (and subsequently its attached copy-items*) are representative of the bibliographic whole, and everything is simple, predictable, and working.  However, when one introduces volume information into the call number field, two problems result.

First, it becomes difficult (computationally) to group together the bibliographic wholes.  For instance, consider a minority case of three copies* of John Calvin's Institutes, often sold in a multi-volume set.  It is not uncommon for our library to have the same exact bibliographic entity in multiple collections serving different user needs.  Currently in Evergreen we might end up with something like:

Title: Institutes
    Call Number 1: CN123.A123 V.1
    Call Number 2: CN123.A123 V.2
    Call Number 3: P345.A345 V.1
    Call Number 4: P345.A345 V.2
    Call Number 5: J789.A789 V.1
    Call Number 6: J789.A789 V.2

This sort of setup is generally still useable, but what if we want to determine the seemingly simple question of "How many copies* of this title do we have?"?  We cannot easily answer it, as the computer does not understand the implied relationship between call numbers which are only related by being mostly the same.  We also need to be very careful when doing simple operations such as changing a call number or discarding a copy*, as we need to do the same action multiple times.

A more complete setup would simply add a new layer to clarify things:

Title: Institutes
    Call Number 1:CN123.A123
        Part: V.1
        Part: V.2
    Call Number 2:P345.A345
        Part: V.1
        Part: V.2
...

I am using the word "Part" here to imply that this layer would be useful for other titles which have multiple parts that are not necessary volumes.

The second volume-related problem involves any operation which may be specific to a certain volume, such as holds.  If all items from the above example are checked out, but I need V.1, what do I place a hold on?  To address this concern, we would need to add some sort of "meta-volume" table.  Where call numbers now expressly represent a grouping of a bibliographic whole, "meta-volumes" are a separate but complementary grouping of like parts:

Title: Institutes
    Meta-volume 1:
        Part: V.1 (CN123.A123)
        Part: V.1 (P345.A345)
        Part: V.1 (J789.A789)
    Meta-volume 2:
        Part: V.2 (CN123.A123)
        Part: V.2 (P345.A345)
        Part: V.2 (J789.A789)

This concept is in most ways independent of the first, and could be dealt with separately, but I am introducing it here because I am well aware that there are many other ways to model all of these relationships, and recognizing this need might inspire a better overall model.  I have tried to focus my thoughts on a minimal disruption to the current structure, but perhaps this discussion will conclude that a larger overhaul is needed.

At this point, my primary concern is how best to deal with the 95% of cases which do not need this additional layer.  Ideally any changes made would augment the current model in an unobtrusive way.

I hope that this message can inspire an interesting and fruitful dialog.

Sincerely,
Dan Wells

* (The term "copies" is also overloaded in this discussion, as it could mean the physical manifestation of a single volume (part) or the entire whole, but I will do my best to keep things clear by referring to rows in asset.copy as "copy-items".)