[OPEN-ILS-DEV] Monograph Parts

[Hardy, Elaine]

Yes -- PINES libraries take different approaches to mutivolume sets. We do
find the differences in approach to multivols primarily in DVDs and
audiobooks and not in print material. We actively discourage creating
separate bib records for a multipart-set or serial but libraries can and
do attach their holdings in a variety of ways. Some libraries separate out
multi DVD sets and circulate one at a time, others may package them in a
container that houses them all and circulate them as one piece.  There are
advantages to both ways; but, I think we would find more libraries
processing them individually if placing holds on specific volumes became
easier.


Elaine
 

J. Elaine Hardy
PINES Bibliographic Projects and Metadata Manager
Georgia Public Library Service,
A Unit of the University System of Georgia
1800 Century Place, Suite 150
Atlanta, Ga. 30345-4304
404.235-7128
404.235-7201, fax

ehardy at georgialibraries.org
www.georgialibraries.org
http://www.georgialibraries.org/pines/



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

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