[OPEN-ILS-DEV] Monograph Parts

[Mike Rylander]

On Tue, Feb 15, 2011 at 4:35 PM, Dan Wells <dbw2 at calvin.edu> wrote:
> Hello Mike,
>
> At first glance I think this is a very welcome development, and I have a just a few comments.  First, I would advocate for some kind of a 'label_sortkey' on biblio.monograph_part.  Even if all it did was pad numbers, it would solve 95% of 'part' sorting problems.

That's a very good idea ... I will make it so.  Proposed initial
algorithm: strip non-spacing marks, force everything to upper case,
remove all spaces, left-pad numeric strings with '0' to 5 characters.
Thoughts?

(NOTE: I'm kinda loath to invent something like the call number
classification normalizer setup for this, and I don't think that will
work directly with these strings.  And without some field testing we
won't do a good jobs of covering our bases with anything non-trival.)

> Second, and perhaps this was already discarded as a simplification measure, but I think we should consider dropping the primary key on asset.copy_part_map.target_copy to allow for multiple parts per copy.  This would not only better reflect reality in certain cases, but I think it could also lay some groundwork for future bound-with functionality (put 'part's on your boundwith records (or let the map point to a part *or* a record), then sever the link from call_number to record).
>

Before spec'ing out this, I'd already begun working up something
separate to cover (among several other use-cases) bound-with.  I'll
post that soon (hopefully today).  The short version of why I
intentionally kept bound-with and monograph parts separate is that the
former is about aggregating multiple bib records (several metadata
records involved in one physical thing) and the latter is about
dis-integration (one metadata records covering multiple physical
things).  While we /could/ design a subsystem that goes both ways, the
implicit complexity (and split-brain logic) required outweighs both
the design and maintenance simplicity of single-function
infrastructure.  I'm normally in favor of infrastructure re-use, but
in this case the concepts being modeled have opposite purposes (from
the bib record point of view).

Is that too ramble-y to make sense? ;)

--miker

> Dan
>
> --
> *********************************************************************************
> Daniel Wells, Library Programmer Analyst dbw2 at calvin.edu
> Hekman Library at Calvin College
> 616.526.7133
>
>
>>>> On 2/15/2011 at 3:09 PM, Mike Rylander <mrylander at gmail.com> wrote:
>> I'll be starting work on an implementation of Monograph Parts (think:
>> DIsks 1-3; Volume A-D; etc), well, right now, in a git branch that
>> I'll push to http://git.esilibrary.com/?p=evergreen-equinox.git;a=summary
>> but I wanted to get the basic plan out there for comment.  So,
>> attached you'll find a PDF outlining the plan.  Comments and feedback
>> are welcome, but time for significant changes is slim.
>>
>> This is not intended to cover every single possible use of the concept
>> of Monograph Parts, but I believe it is a straight-forward design that
>> offers a very good code-to-feature ratio and should be readily used by
>> existing sites after upgrading to a version containing the code.
>
>



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