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

[Dan Wells]

Hello Lebbeous,

Thanks for the thoughtful reply.  The only problem I have with the people around here is that everyone is so reasonable all the time :)

My main motivation is to make sure the two serials interfaces are completely interchangeable before any live data diverges irrevocably.  Right now they are very close, but not quite.

Based on your reaction and the reaction of others in IRC, we'll probably be best served to find a way to keep the 'traditional' call numbers for 2.0, but I still hope we can do so in such a way that the two interfaces are more coherent for the 2.0 release, and thereby better able to tackle the previously stated goals in 2.x.

Here is my compromise solution:

1) Distributions will be required to have a 'Receive Call Number Base' field populated.
2) Distributions will optionally have a 'Bind Call Number Base' field populated.
3a) When using the 'Batch Receive' interface, the 'Receive Call Number Base' will be pre-populated into the call number field, and the user will then append to it as needed.
3b) When using the Items interface receive feature, the 'Receive Call Number Base' will be combined with the summary contents to create a complete call number in a similar fashion.
4) *_call_number fields will be hidden from the editors for now, reserved for later use.

These changes provide the following benefits:

1) We can postpone 'unit-awareness' until 2.1.
2) The two distribution editors will be fundamentally compatible.
3) The two receiving interfaces will be fundamentally compatible.
4) We will be well positioned to re-split the call numbers in 2.1 by consulting the defined base(s).

One outstanding question is where to store this 'base' data.  If keeping the schema intact is paramount, then temporarily annexing unit_label_base and unit_label_suffix is one possibility (while referenced in the code, they are currently more-or-less unused in practice, AFAIK).  If not, adding two text fields to serial.distribution will be necessary.

Thoughts?

Dan



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


>>> On 1/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.
> 
> - 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