Home LITA Membership LITA Interest Groups MARC Formats (LITA/ALCTS) Midwinter 1999 Philadelphia Discussion on USMARC Holdings For

LITA/ALCTS MARC Formats Interest Group

DATE:   Saturday, January 30, 1999
TIME:   2:00pm - 4:00pm
PLACE:  Philadelphia convention Center, Room 109B

  The focus of this meeting will be a discussion regarding the USMARC
Holdings Format.  Attendees are encouraged to share their experience
in using the format or their plans to use it.  

  Specific issues will include:

 - the use of subfields of field 852 (Location)
 - coding of publication pattern subfields in 853 for predictive
check-in
 - linking to multiple bibliographic records for "bound-with" items
 - default values for holdings fixed fields
 - recording titles of supplements (see below)


Participants are encouraged to submit any other questions to the IG
chair at the address below in advance of the meeting.


  Information about the MARBI meetings and documents are available
as indicated:

 MARBI agendas-  http://lcweb.loc.gov/marc/marbi/mw1999age.html

 1999 Proposals-  http://lcweb.loc.gov/marc/marbi/list-p.html

 1999 Discussion Papers-  http://lcweb.loc.gov/marc/marbi/list-dp.html



QUESTIONS


A. Submitted to Library of Congress-


1. Coding regularity patterns for season designations

a. There appears to be a problem in the example mentioned
below.  The chronology levels ($i, $j) are given as year and
month, the calendar change (in $x) is a month (January), but the
regularity pattern ($y) is given as "$yps21,22,23,24" (meaning
published in seasons: spring, summer,..." etc.

Example (http://www.loc.gov/marc/holdings/echdcapt.html):

854 03$81 $av. $bno. $u4 $vr $i(year) $j(month) $w4 $x01 $yps21,22,23,24


QUESTION concerning "season" in Calendar Change (853-855 $x)
and in chronology values in 863-865 $i - $m :

Calendar change is defined in the spec ((853-855 $x) as "the
chronological point at which the next higher level increments or
changes."  In other words, for example, with what issue does the
volume numbering go up by one?

The problem is in knowing which season is the first (or last) of a
calendar year, so that an application using the spec can predict
the future issues of the publication accurately.  It is apparently
assumed  that "Spring" is always the first season of the calendar
year.  In the real world of serials, this is not always true.  Is
there any way to specify this? If not, consider enhancing the spec.

Example:  What if the first issue published in the calendar year of a
particular quarterly is called the "Winter [year]" issue, with a
volume number and an issue number, like "v.4, no.1, Winter 1997."
This is not an unusual pattern.  How would an application  "know"
whether the following issue, the Spring, is published in 1997 or
1998?


Perhaps 853 $y (Regularity Pattern) is supposed to control this:

854 .... $yps21,22,23,24

This 854 is explained as:  "Item has four numbers per volume; four
numbers per year, publshed in Spring, Summer, Autumn, and Winter."

This tells us WHICH seasonal issues are published, but the
question is:  does the ORDER of entering the season codes specify
which season is the first of the calendar year?

The example is not instructive, because it shows the seasons in the
same order as the list of season codes in the spec.  If the example
had said: 854 .... $yps24, 21, 22, 23 ..., then we could probably
conclude that Winter is the first issue of any given calendar year,
that Spring is the second, and so forth.

b. Is there something that needs to be changed in the format to 
accommodate this, or is it only necessary to prescribe that the codes
be input in the order to be received to enable predictive check-in on
this information?

c. Is it possible to code for publications with season designations that are
published in the southern hemisphere for accurate predictive check-in?


2. Type of Record coding

    It has only recently become clear that the Z39.57 and USMARC term
"bibliographic item" is a very different use of the term than some users
are accustomed.  Some users have thought of "item" in the context of item
records, i.e., physical pieces.  It has been thought that the Type of Record
code in a MHFD record described the holding itself (i.e., the physical piece
described by the MFHD record).  In other words, the code referred to the nature
of the physical item represented by the MFHD record.  This line of reasoning
suggests that Type "x" (single part item holdings) would be used for a single
piece represented by the MFHD record.

    The ambiguity begins with the example of a book accompanied by a disc housed
in a separate location.  One bibliographic record would have 2 MFHD records
attached because there are 2 locations involved.  Because each of the MFHD records
represents a single piece (the book and the disc separately), there would appear to
be two Type "x" MFHD records.

    Is this the correct interpretation or would both MFHD records be Type "v"
because the bibliographic record they are attached to describes a multipart
bibliographic item.


3. Display of secondary units-

  In the holdings standard (previously Z39.57-1989,) there are many examples given
for alternative ways to represent secondary bibliographic units either by using
separate full coding for each unit or by condensing them into one statement using a
"+" to connect them together.  An example is in section 4.4.1 (p.19 in my ANSI/NISO
copy from Transaction Publishers):

      (a,mm,1,2,8) 1 hand puppet + 1 sound disk + "Instruction books" pt.1-2
                                 or
      (b,zz,4,2,8) 1 hand puppet
      (b,zz,4,2,8) 1 sound disk
      (b,ta,1,2,8) "Instruction books" pt.1-2

    It is unclear whether this example illustrates the use of a single MFHD record
vs. three MFHD records.  Or, is this illustrating alternative public displays coming
from three MFHD records.  Is there an definite intended implementation of the MFHD
format to carry this type of information?      


4. Field 844 vs. 863-865$o for Name/title of unit-

    A field was defined for Name of Unit (Field 844) to accommodate the element in the
non-serial holdings standard. However, there is also subfield $o in 863-865 for Title
of supplementary material/index. The data in these fields are similar (the name or
title appearing on an item).  How are users differentiating these two? Are separate
holdings records created for supplements? If so, is 844 used?



B. MARBI holdings agenda items

Discussion Paper 113 (http://lcweb.loc.gov/marc/marbi/dp/dp113.html)-

1. How are systems using subfields $b, $c, $h, $k, and $m for various
functions?

2. Can both permanent and temporary locations be recorded in subfield $c?
Is there a need to distinguish at the holdings level (rather than item
level, as in field 876-878 subfield $l) between permanent and temporary
location?

3. How should call numbers be coded when the institution shelves the item
by a classified designation, such as the example in section 2.3, which
could use the hierarchical approach of $h and $i or the shelving control
number subfield $j?

4. How does one distinguish whether an element should be recorded as a call
number prefix or suffix, or as a sublocation or shelving location? Is the
decision made based on functionality of the system, for instance when the
system uses the data in $h, $i, $k, and $m to print a label? Shall
institutions make their decisions individually on what best fits their
needs, or should the format be more specific about how to distinguish
between these different data elements?

5. Would there be any problems making subfield $m repeatable? If so, should
subfield $k also become repeatable?


Proposal 99-02 (http://lcweb.loc.gov/marc/marbi/1999/99-02.html)-

1. Since the holdings field 004 is not repeatable, how are links to multiple
bibliographic records being made?

2. How are bound-with situations being handled?








Holdings format items on the MARBI agenda-

PROPOSAL NO: 99-02

This paper proposes making field 004 repeatable in the MARC
Holdings Format so that a holdings record can link to multiple
bibliographic records for the description of the item for which a holdings
record is created. This is particularly needed in the case of bound-with
items, where several bibliographic items, represented by separate
bibliographic records, are bound together and one holdings record may be
used for the physical entity.


PROPOSAL NO: 99-03

This paper proposes that a value be defined in Leader/06 (Type of
record) for "unspecified holdings" and in Leader/17 (Encoding level) for
"unknown". This is needed so that a default value can be system generated
in these positions when necessary.


DISCUSSION PAPER NO: 113

This paper considers the definitions and use of field 852
(Location) subfields $b (Sublocation or collection), $c (Shelving
location), $h (Classification part), $k (Call number prefix), and $m (Call
number suffix). It poses questions about how institutions are
distinguishing between these data elements and how they are used in
systems. The question of making subfield $m (and perhaps $k) repeatable is
posed.


William W. Jones
Chair, MARC Formats Interest Group

B45 Bobst Library
New York University Libraries
70 Washington Square South
New York, N.Y. 10012
Voice: (212) 998-2463
Fax: (212) 995-4366
william.jones@nyu.edu