[OPEN-ILS-DEV] What do we want from MARC Format for Holdings Data?

[Frances Dean McNamara]

In our database here are the counts for holding_summaries:

adv     182
index   17071
looself 6512
main    878462
pocktpt 1043
supp    36375


The main includes multivolume monographs, not just serials.  But you can see there are quite a few indexes and supplements as well as looseleaf, pocketparts and advance sheets.

We would need indexes and supplements since serials holdings are extremely important to us and we maintain backfiles of print copies and will into the future.  It might not be so important to others.  This information is not stored in MFHD format in our db but can be exported in MARC.

Frances McNamara
University of Chicago

-----Original Message-----
From: open-ils-dev-bounces at list.georgialibraries.org [mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of David J. Fiander
Sent: Tuesday, October 21, 2008 9:38 PM
To: Evergreen Development Discussion List
Subject: [OPEN-ILS-DEV] What do we want from MARC Format for Holdings Data?

I've checked in some basic MFHD code. It's a bit further along than
Dan's parser, but it's still not good. Basically all it does right now
is generated a formatted list of the "basic" holdings information for
display, using the correct captioning information.

As written, the code doesn't do anything with 854/864 "Supplementary
Material" or 855/865 "Indexes" fields in the MARC records, and it
would be difficult to support them.

Rather than focusing on the data structures, it would probably be more
useful to focus on the functionality we need. How do these methods
sound?

mfhd.format(boolean compressed): return formated holdings statement
suitable for display, either detailed or compressed.

mfhd.predict(vol, iss, yr, mo, day): return information about issue
that follows that described by the arguments. The return value does
not necessarily describe something that we hold (it is predicting the
next issue). This method may return false to indicate that no
prediction is possible (for example, the captions and pattern data is
incomplete or indicates that the serial is completely irregular).

This method will be one of the basic building blocks for the claims
process.

mfhd.iter(): Iterate through holdings in chronological order,
returning information about each item held.

All methods will have to take an argument indicating whether we want
"basic", "supplementary" or "indexes" holdings. Calling a method for a
type of holding that doesn't apply is not an error: we just don't hold
any of that (or is it an error?).

QUESTIONS

How common is non-"basic" holdings information in the wild? Do we
really need to support anything beyond the basic serial holdings?

How essential is it that Evergreen be able to export MFHD formatted
data?

What else do people need to be able to do, or expect to do?

- David

--
David J. Fiander
Library Software Development