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

[Lebbeous Fogle-Weekley]

On Tue, 11 Jan 2011 12:13:15 -0500, "Dan Wells" <dbw2 at calvin.edu> wrote:
> 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:
> 

I think there's no need to take any blame or apologize for anything.  This
is all very, very new code that has hardly seen any testing by real users
until recently (and kudos are due to those users now).  It's okay that it's
evolving, IMO.

> 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).
> 
> [snip]

I think this would be a great and sensible model for organizing serial
holdings under unit labels and fewer call numbers, but:

- no work that I'm aware of exists for displaying anything about units in
the OPAC, other than in cases where they stand in for copies and look like
ordinary copies.

- to my understanding (and I'm not a librarian so I could be wrong on this,
but I don't think so in this case), some (public only?) libraries simply
expect that every issue of a serial have its own call numbern and they want
things organized this way. Or maybe they're used to other ILSes where
they've cataloged their serials in this way. Could everyone be convinced to
adapt to a new model?  Perhaps, but I think we'd be springing a lot on
users to enforce such a model now.

- the developers in general have been trying to limit their work on 2.0 to
bug fixes only over the course of several betas and release candidates now.
I'm willing to help on something like this for 2.something.else, but I
really think it's late for work like this to be trying to make it into the
2.0 release.

Perhaps some others will chime in?

-- 
Lebbeous