No subject

that don't seem to fit directly into this response elsewhere ... ;)

When going from records to items (via the Monograph Parts
infrastructure as described), we need to be able to name label the
subdivision that the part represents in relation to the record as a
whole -- we need to be able to say "barcode X contains only Volume 1
of the content described by record A".  This is not something we need
to do for binding in the general case (note, however, that you can
indeed use both at the same time -- multi-home and parts -- to get the
effect of "volume 1 of record A is bound with some other things").
Also, the only purpose of the record-to-item path is to dis-integrate
the record into constituent, separately barcoded items, so there is
only one relationship type.

However, going in the other direction, from items to records (via
Multi-homed Items as described) we do not need a label -- what we need
instead is a /reason/ for the relationship.  Bound-with, e-reader,
etc.  IOW, there are multiple potenial causes for the relationship
being created.

Not surfacing these differences explicitly (in my case, by using
separate, though admittedly superficially similar mechanisms) is
inviting trouble down the road, IMO.

Now (fastforwarding to your schema outline below), IIUC, what you're
attempting to do with the copy_type table is to have a magic value of
"Multi-part" inform us that the direction is from record to item, and
all others are the other direction.  From a bibliographic point of
view this is incorrect -- it's not the copy that is Multi-part, it is
the record.  From a normalization point of view, this is not modeling
reality IMO, and because it uses magic rows in a table it's brittle
against DML.

> 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 cop=
y. =A0Or
> am I missing something?
>

You're not ... I interpreted what she was saying differently (that
different libraries would be /able/ to spit records along different
lines), and I see what you're saying.  We could allow a copy to belong
to multiple parts (it's a trivial change to the schema), but it would
be the responsibility of the cataloger with the item in hand to make
sure that the copy is in the appropriate parts -- not hard, except
that some parts may not exist yet. ;)  (And, of course, this
existential problem exists no matter the scheme*.)

Converting from one part per copy to multiple is simple at the
database level, and would be nearly trivial in higher level code, but
until we have use in the field I think it's a solution without a
problem, because of the cataloging overhead of trying to keep every
copy current across all parts as parts are added to a bib when each
library adds their own subdivision scheme for the bib.  For that
reason I left it out explicitly.  (*It also invites the desire for a
"collection of parts" concept that is a much bigger, and more
importantly, controversial project.  That too, though, is not barred
from the future with the design as it stands.)

> Finally, for those it may help, here is a quick version of a simple
> item-record schema. =A0The part concerning copy_type is optional, but I w=
anted it
> to show a more complete replacement for the proposed tables:
>
> CREATE TABLE biblio.part (
> =A0 =A0 =A0 =A0id SERIAL PRIMARY KEY,
> =A0 =A0 =A0 =A0record BIGINT NOT NULL REFERENCES biblio.record_entry (id)=
,
> =A0 =A0 =A0 =A0label TEXT NOT NULL,
> =A0 =A0 =A0 =A0label_sortkey TEXT NOT NULL,
> =A0 =A0 =A0 =A0CONSTRAINT record_label_unique UNIQUE (record,label)
> );
>
> CREATE TABLE asset.copy_contents_map (
> =A0 =A0 =A0 =A0id SERIAL PRIMARY KEY,
> =A0 =A0 =A0 =A0--record BIGINT NOT NULL REFERENCES biblio.record_entry (i=
d),
> --optional path to partless items, or we force records to have at least o=
ne
> part
> =A0 =A0 =A0 =A0part INT NOT NULL REFERENCES biblio.part (id) ON DELETE CA=
SCADE
> =A0 =A0 =A0 =A0target_copy BIGINT NOT NULL -- points to asset.copy
> );
>
> CREATE TABLE asset.copy_type (
> =A0 =A0 =A0 =A0id SERIAL PRIMARY KEY,
> =A0 =A0 =A0 =A0name TEXT NOT NULL UNIQUE -- i18n
> );
>
> INSERT INTO asset.copy_type (name) VALUES
> =A0 =A0 =A0 =A0(=91Bound Volume=92),
> =A0 =A0 =A0 =A0(=91Bilingual=92),
> =A0 =A0 =A0 =A0(=91Back-to-back=92),
> =A0 =A0 =A0 =A0(=91Set=92),
> =A0 =A0 =A0 =A0(=91Multi-part=92); =A0--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 cop=
ies)
>

Given the codebase, that will be a large and separate project, if ever
undertaken, and is not something we can look at now if we want
anything discussed here to happen in a near-term release.  I won't
discount it out of hand for all time, just for this time. ;)

--miker

> 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=3Devergreen-equinox.git;a=3D=
summary
>
>>>> but I wanted to get the basic plan out there for comment. =A0So,
>>>> attached you'll find a PDF outlining the plan. =A0Comments and feedbac=
k
>>>> 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.
>>>
>>>
>>
>



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