[OPEN-ILS-DEV] Monograph Parts

[Dan Wells]

Hello Mike,

>>> On 2/16/2011 at 12:37 PM, Mike Rylander <mrylander at gmail.com> wrote:
> 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?


Sounds good to me.


> 
> (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? ;)
> 


It makes good sense, but I think we could ultimately benefit by putting less
emphasis on a bib record point of view and tilting things a bit more towards
the item point of view.  From the item perspective these proposals are modeling
the same thing, a mapping of items to contents, and the fewer ways we have to
do that, the better (as long as we cover all the cases).  With a simpler
mapping table of item to record(-part), we easily traverse in either direction,
and we have ultimate flexibility.  So, if I have a bib record on my screen, and
I ask the question, "which items' contents does this record represent?", we can
simply go record->part(s)->item(s).  On the other hand, if I have an item, and
I ask the question "what are the contents of this item?", we can go
item->part(s)->record(s).  Naturally we can traverse related records (via
items) and related items (via records/parts) as well.  This also eliminates the
primacy of call numbers when managing items, which I see as a benefit.

Or stated more simply, I feel our foundational assumptions in relating items
to records should be:
1) Records describe contents
2) Items contain contents
3) Item content boundaries can overlap record content boundaries in various
ways

All that said, I know from experience to trust your judgement (most of the
time ;).  For my own future benefit, do you have cases already in mind where
this flexibility would end up causing 'split-brain' logic?  (Or maybe I have a
split brain...)

Also, I think this quote from Elaine deserves a bit more attention:

>> I'm particularly interested in how this would function in a consortium
>> like PINES where different libraries might process a multipart set
>> differently. For example, one library might process and circulate a 3
>> part DVD set as one item, where another might put each in a separate
>> container with a separate barcode.

If we want the complete-set copy from Library A to conclusively fulfill a
P-level hold from Library B, we will want to allow multiple parts per copy.  Or
am I missing something?

Finally, for those it may help, here is a quick version of a simple
item-record schema.  The part concerning copy_type is optional, but I wanted it
to show a more complete replacement for the proposed tables:

CREATE TABLE biblio.part (
	id SERIAL PRIMARY KEY,
	record BIGINT NOT NULL REFERENCES biblio.record_entry (id),
	label TEXT NOT NULL,
	label_sortkey TEXT NOT NULL,
	CONSTRAINT record_label_unique UNIQUE (record,label)
);

CREATE TABLE asset.copy_contents_map (
	id SERIAL PRIMARY KEY,
	--record BIGINT NOT NULL REFERENCES biblio.record_entry (id),
--optional path to partless items, or we force records to have at least one
part
	part INT NOT NULL REFERENCES biblio.part (id) ON DELETE CASCADE
	target_copy BIGINT NOT NULL -- points to asset.copy
);

CREATE TABLE asset.copy_type (
	id SERIAL PRIMARY KEY,
	name TEXT NOT NULL UNIQUE -- i18n
);
 
INSERT INTO asset.copy_type (name) VALUES
	(‘Bound Volume’),
	(‘Bilingual’),
	(‘Back-to-back’),
	(‘Set’),
	(‘Multi-part’);  --generic type

-- ALSO:
-- asset.copy grows a nullable reference to asset.copy_type
-- asset.call_number.record is nullable (should be null for new-style copies)

Dan



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