1. Area of conflict between ANSI/NISO Z39.71 and MARC 21

ANSI/NISO Z39.71 is a little inconsistent about what it calls a separate 
level and what it means by that.  In the case of day notations, it seems 
to mean nothing more than an instruction not to use a colon.  Our system 
(Aleph) accomplishes this even though the day is in a separate subfield 
in the MARC holdings format.  I don't see any need to change the format. 
  If the month were combined with the day, I don't see how prediction or 
expansion could work, and you couldn't use numeric codes for the months.

On the other hand, there is nothing to prevent you from combining the 
levels in your holdings record if you prefer, e.g.
863 ... $i 2006 $j May 12
If you're only concerned with display and not with prediction or 
expansion, it doesn't matter what you put in 853/863 $j.  The 853 could 
be (month) or (date) or whatever.  But the best solution is probably to 
program the system to recognize when it should omit the colon.

2.	Allowing for flexibility in how libraries choose to display serial 
holdings

Even though we try to follow Z39.71 as much as possible, we feel no 
qualms about displaying *item* records for serials in reverse 
chronological order.   I don't think it occurred to anyone that this 
rule might apply to item records.  Serial *holdings* are usually 
displayed as compressed statements, and I can't think of any way to do 
that besides lowest to highest, earliest to latest.

3.	Additional example within Enumeration section

Agree that another example would be useful, but since the maintenance 
revision of Z39.71 is now out for ballot, I don't think there's a chance 
of such a change this time around.  However, see examples 18-19 in the 
appendix.

John Hostage


Julian Everett Allgood wrote:
> Comments on ANSI/NISO Z39.71
> 
> 1.	Area of conflict between ANSI/NISO Z39.71 and MARC 21
> 
> While it is understood that ANSI/NISO Z39.71 is primarily a standard
> addressing holdings displays and that MARC 21 represents the standard
> libraries use to record, store and exchange data, we need to be careful
> in developing instructions that may result in conflicts between the two.
> 
> In attempting to migrate NYU's holdings data in our current ILMS
> migration, NYU has encountered one such area of conflict.
> 
> In Section 5.5.5.2 addressing Dates, ANSI/NISO Z39.71 states clearly:
> 
> <snip>
> 
> "When chronology below the first level is recorded, use a colon to
> separate the year from the month. In recording chronology data that
> contains day notations, do *not* treat these as a separate hierarchical
> level, and do *not* separate them with a colon." [Emphasis added] (p. 34
> of ANSI/NISO Z39.71 1999, and p. 44 of the revised standard).
> 
> Examples:
> 	
> 	1982:Feb
> 
> 	1982:Feb 1 not 1982:Feb.:1
> 
> 
> <snip>
> 
> However, in the MARC 21 Holdings Format documentation, examples that
> include both month and day designations do treat them as separate
> hierarchical levels and by placing them in separate subfields, do
> separate them with a colon.
> 
> The following is copied from the MARC 21 Holdings documentation via the
> MARC website:
> 
> <snip>
> 
> 
> 853 
> 00$81$av.$bsect.$u12$vr$cno.$u7$vr$dpt.$uvar$vr$i(year)$j(month)$k(day)$lweek$wd$x01
> 
> 853 
> 22$81$av.$bno.$u12$vr$i(year)$j(month)$k(day)$wm$x01
> 
> <snip>
> 
> In this instance I actually believe it is ANSI/NISO Z39.71 that is
> correct, and the MARC 21 Holdings instructions that need to be revised
> to align these instructions. Here's why:
> 
> In the case of serial dailies or weeklies that bear specific day
> chronological designations, I believe the month and day combination
> represent a single intellectual data element – two bits of data, but a
> single data element. That is, the designation for May 12, 2006 is a
> singular hierarchical concept consisting of two data elements: the
> month/day designation and the year designation. May 12, 1492 represents
> a very different concept than May 12, 2006. Nonetheless, both are valid
> date designations.
> 
> However, if we parse that day designation into a separate hierarchical
> unit, systems are left with three separate data elements, and a much
> greater potential for confusion. Once we separate the 12th from May, the
> number itself loses an important contextual relationship and the month
> designation represents a 31 day period rather than a 24 hour period.
> 
> I feel very strongly that the MARC 21 Holdings instructions should be
> revised to parallel the current instructions in Section 5.5.5.2 of
> ANSI/NISO Z39.71.
> 
> 
> 2.	Allowing for flexibility in how libraries choose to display serial
> holdings
> 
> Page 24 of ANSI/NISO Z39.71 1999 (and p. 34 of the revised text),
> includes the following instruction :
> 
> "Record enumeration and chronology data in logical sequence; that is,
> lowest enumeration data to highest, earliest to latest."
> 
> I realize that this instruction only addresses how data is 'recorded,'
> however as this is a display standard I have had colleagues and systems
> librarians question how this statement should apply to displays.
> 
> For multipart monographs, librarians and users prefer to sequence
> holdings in ascending order, from earliest to latest.
> 
> However, serial usage studies demonstrate that many users are more
> interested in the most recent issues of serial titles. Therefore for
> serial resources, most librarians and users prefer systems to display
> the latest issues received first. That is, serial holdings should be
> displayed in descending order, from the latest to the earliest. 
> 
> The standard would benefit from a clear statement allowing libraries
> flexibility in determining how best to sequence and display Continuing
> Resource holdings based on the above.
> 
> 
> 3.	Additional example within Enumeration section
> 
> ANSI/NISO Z39.71 Section 5.5.4 addresses enumeration and chronology data
> elements as separate but parallel and in the majority of cases when both
> are present, this is the case. However there are some instances in which
> a chronological designation must serve as the highest level of
> enumeration. I believe including an explanation and example of this
> would be helpful.
> 
> For example, with a title like the monthly Voprosy istorii (Moscow,
> Russia : 1945) ((DLC)   49035588), the twelve issue designations repeat
> each year using the year designation as the highest level of enumeration
> (i.e., 2006:no.1, 2006:no.2, 2006:no.3, 2006:no.4, … ).
> 
> An example of this quite common occurrence within Section 5.5.4.1 Levels
> of Enumeration would be instructive. 
> 
> 
> 4.	Miscellaneous concerns regarding the current automation environment
> 
> Finally, I believe that based on the punctuation guidelines in ANSI/NISO
> Z39.71, there may be some concerns regarding library web-based catalogs. 
> 
> 1.	Some of these display statements include spaces or blanks, which to
> many systems are significant data elements having specific meaning.
> Within long, detailed holdings statements the presence of spaces also
> often results in <hard returns> that can interrupt holding statements
> and generate confusion. 
> 
> 2.	ANSI/NISO Z39.71 instructs catalogers to enclose Specific Extent
> Notes (5.5.6) in angle brackets. I have heard some concern that these
> punctuation elements may be misinterpreted within HTML web-based
> catalogs. Is that possible?
> 
> 
> I hope this is helpful, and please let me know if any of it needs
> further explanation.

-- 
___________________________________________________________
John Hostage                  Authorities Librarian
Langdell Hall                 [log in to unmask]
Harvard Law School Library    (617) 495-3974 (voice)
Cambridge, MA 02138           (617) 496-4409 (fax)
http://www.law.harvard.edu/library/
-----------------------------------------------------------