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

[Mike Rylander]

On Tue, Jan 11, 2011 at 12:43 PM, Lebbeous Fogle-Weekley
<lebbeous at esilibrary.com> wrote:
>
> 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.
>

UIs can come later, as long as the underlying data is entirely
optional, and other parts of the system don't depend on the data for
linkage.

> - 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 enforcement is my primary /technical/ concern.  There are
identified use cases for not requiring this label, and so I don't
think we can go requiring it.

So the question is, can this be a nullable field?

> - 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.
>

This is my primary objection.  We've managed to avoid schema changes
(other than functions, but those are opaque, and don't change other
bits) and that stablization is important.

If we can see a patch for the whole thing, schema and code changes,
I'd feel better about evaluating things this late, but as it stands I
think 2.1 (which may follow on fast, mind you) is the correct target.

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com