[OPEN-ILS-DEV] Call Numbers for Serials in 2.0

[Dan Wells]

Hello all,

I have been reluctant to send this message, mostly due to my hope that things would somehow work themselves out in time, but with 2.0 just around the corner, I think it would be a mistake to not reach an agreement pre-release on how call numbers relate to the serials data.

At this point I will accept my portion of the blame, specifically for my replacement of the unit 'label' field with a 'summary_contents' field.  While these fields will have the same contents in a large number of cases, this change does not allow for all cases, and also clouds the intended purpose.  The label field was meant to function primarily as a call number "analytic", something missing from the current call number setup.  This provides an additional, useful display and management layer, something like:

CALL_NUMBER_1
   UNIT_LABEL_1
      ITEM_INFORMATION_1
      ITEM_INFORMATION_2
   UNIT_LABEL_2
      ITEM_INFORMATION_3
      ITEM_INFORMATION_4
...

which might be:

Z671.L7
   V.59
      33108001234567 - 5th Floor
      33108002345678 - Reference
   V.60
      33108003456789 - 5th Floor
      33108004567890 - Reference

As for the items themselves, the printed label would reflect both (CALL_NUMBER + UNIT_LABEL), as expected (e.g. Z671.L7 V.59).

With this approach we gain the following general benefits:
1) Intentional separation -> better sorting.  Analytics sort using different criteria than the accompanying call number.  Keeping them distinct is the surest way to make sure this happens properly.
2) Less duplication of data -> easier management.  If a serial run needs a new call number, you only need to edit it in one place, not (potentially) hundreds of places.
3) Less duplication of data -> simpler display.  There is no need to visually or programmatically determine whether a different call number indicates a run shelved in a different location or a different volume in the same location.
4) Less duplication of data -> faster catalog (?).  I am not 100% certain here, but my understanding is that org unit scoping in the catalog happens at the call number level.  Having an unnecessarily large number of call numbers for every serial (when only a few would suffice) adds an additional burden to catalog searches.


I am also aware of at least two drawbacks:
1) Units under the same distribution must have a shared 'root' call number.

While this may be a technical limitation, I haven't been able to come up with a real world example where this would matter.  Please do share an example if your library requires this 'root' to vary between issues of the same distribution (that is, issues from the same subscription going to the same place).

2) Serial holdings are different and more complex than monograph holdings.

I currently see this drawback as the more serious of the two.  If we want to intentionally scale things back in order to make serial holdings less disruptive, I can understand that.  We will be missing an opportunity, and we will also need to wait on the benefits outlined above, but at least we will be working towards a common goal.


Clearly I am a proponent of the described separation, especially because I feel it is well within reach.  It would mean restoring the 'label' field to the unit table to allow for a proper level of flexibility, but the amount of overall code changes would be fairly minimal (essentially, call number inputs (where needed) become unit label inputs).  From an end-user perspective, these internal changes mean very little, but the differences are quickly amplified when trying to create refined interfaces for holdings display.  And while this change doesn't quite get us all in the same boat again, at least we will be paddling in the same direction.

Please reply, thanks,
Dan



-- 
*********************************************************************************
Daniel Wells, Library Programmer Analyst dbw2 at calvin.edu
Hekman Library at Calvin College
616.526.7133