This posting is in response to several others over the last two months. James Mouw of the University of Chicago (to whom I sent a personal reply) asked several questions on 14 Dec 1990 about the USMARC Format for Holdings Data (MFHL). Then there was a question by Thomas Sanders of Auburn University about MFHL and a reply by Linda Visk of Emory University. On 7 Feb 1991, Judith Hopkins at SUNY Buffalo reported on the LITA MARC Holdings Interest Group meeting at ALA Mid-Winter and mentioned some interest there in using MFHL for prediction and claiming purposes. I have considerable interest in MFHL. I have only a B.S. in secondary education and I do not belong to any professional organizations. I taught science and mathematics in the public schools for three years but quit that due to developing stomach ulcers. I worked at the library of Brigham Young University for many years in book repair and in the preparation of serials for commerical binding. In the 1970'S, Brigham Young University's library produced an automated serials system based upon a system developed at the U.C.L.A. biomedical library. Publication patterns and prediction of the expected issue were part the the B.Y.U. system. When B.Y.U. purchased NOTIS on 1985, it was desired to retain and maintain the publication pattern data and the predictive capability. By that time I had taken a COBOL programming class and was managing the B.Y.U. serials system. I designed a new serials system to "plug into" NOTIS. It utilizes the NOTIS bibliographic and holdings data, but runs as a program separate from NOTIS. Many of the existing features of the B.Y.U. system were kept, including selective automated claiming and binding notification and tracking. The data in the new system is not in the USMARC Format for Holdings. There was considerable pressure at the time to get a program up very quickly. There was some concern about making the new system much different than the old one. But I was determined to make the data as MFHL-like as possible and to predict every predictable issue. The data can easily be changed to the USMARC Format. A program has already been written which changes it. The new system went into production in March of 1989 with many problems. I have spent the last two years debugging the system and developing batch programs for it. The new system significantly enhanced our predictive capablility and much new MFHL-like data has been entered. >From my experience I have come upon what I consider to be some flaws in MFHL that I would like to air to someone out there who might be inclined to get some changes made. Since this posting is already over long, I will only mention one of them now. One of my first problems was the fact that some publishers consider Winter the first season of the year, others consider Winter the last season of the year and others refuse the make the decision and put both years with Winter. When does one change to a new year when there is only the chronology caption, "(season)" in the "j" subfield. The first season/last season thing could have been handled with the "y" subfield (regularity pattern), by putting, for example, "ps24,21,22,23". But how would one handle, for example, "1990/91:Winter". And besides, why should it be necesary to enter additional data for Winter as the first season. I believe the format should be able to handle one as easily as the other. The description of the "x" subfield (calendar change), would indicate that it might be helpful, e.g. "21" could be used to show that Spring is the first season of the year, and "24" could be used to show that Winter is the first season of the year. However, I did not understand exactly how subfield "x" is used and thus did not code it. This subfield is described as "codes that indicate the chronological point at which the next higher level increments or changes". The "next higher level" is not precisely defined in my December 1989 format documentation. One of the examples in the documentation seems to be in error as there is no subfield "a" (which is supposedly required). The other two examples indicate that the "next higher level" is subfield "a", but then it states that subfield "x" "is not related to a specific caption". This still would not have handled the case where Winter is in both years. My solution was to use single letter alphabetic codes as chronology captions. "(s)" means that Spring is the first season of the year (and thus Winter is the last season). "(t)" means that Winter is the first season of the year. "(u)" means that Winter is in both years. This solution saves space, saves data entry time, and may make MFHL data more transportable in international use. In addition, I found a need for four codes in place of the chronology caption, "(day)". "(d)" means that the number of days between the dates on consecutive issues is always the same (neglecting omitted dates). "(w)" means that the number of days between dates on consecutive issues is always some multiple of 7, i.e., weekly, biweekly or some integral number of weeks (again neglecting omitted dates). "(a)" means that the dates of issue are the same in each month and "(e)" means that the dates fall on the same day of the week and in the same weeks for each month, e.g., published on the first and third Thursdays, (once more neglecting omitted dates in each case). Dean L. Bennett Library Automations Harold B. Lee Library Brigham Young University Provo, Utah 84602 (801) 378-7688
