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

[David J. Fiander]

Frances,

Thank you for the statistics, but they do raise some more questions.   
The MARC format defines fields 853, 854, and 856, that hold the  
caption and publication pattern information for the containing  
bibliographic item:

	854: Basic Bibliographic Unit
	855: Supplementary Material
	856: Indexes

It does not define fields for describing the other types of materials  
that you list in your reply.

Just to make sure that we're talking about the same sort of thing, let  
me construct a scenario for you. Imagine that the Georgia State  
Library Association publishes The Southeast Library Journal, a  
monthly. Volumes consist of twelve issues, and issue 1 is published  
January. The Journal also issues a separate annual index for the  
preceding year, usually in February, and publishes the proceedings of  
the annual conference as a supplementary item in September (following  
the conference held in June). This information could all be recorded  
in a single bibliographic record for the journal:

	245 04 $aSoutheast Library Journal.
	260    $aAthens, GA
	300    $av.$billus.
	310    $aMonthly
	853 20 $81$av.$bno.$u12$vr$i(year)$j(month)$wm$x01
	854 00 $82$av.$bsuppl.$u1$vr$i(year)$j(month)$wa$ypm09
	855    $83$av.$i(year)$wa$ypm02
	863 30 $81.1$a1-7$i2001-2007
	864 30 $82.1$a1-7$i2001-2007
	865 4  $83.1$a1-6$oannual index

(this is close enough for descriptive purposes, but I wouldn't claim  
it is a completely conforming MARC Holdings statement.)

So, in this example, we have seven volumes of serials, seven  
supplementary material items (the conference proceedings), and six  
annual indexes, all documented in this one record.

Do those numbers correspond to the numbers that you report below? And  
if that is the case, then what field does your current ILS use to  
document the "pocketpart" holdings when exporting in MARC format?

- David

On 22-Oct-2008, at 14:07 , Frances Dean McNamara wrote:

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

-- 
David J. Fiander
Library Software Development