As one of the "authors" of Discussion Paper No. 106 (New Type of Date
code), let me make a preliminary attempt to answer the questions at the end
of the paper (and also some other issues raised).
1. What do local systems and vendors do with the different types
of dates now? Will the addition of another type be of value or
would expansion of an existing one be more useful?
More specifically, what processing do systems do on 008/06 (as opposed to
the dates codes in 008/07-14)? My suspicion -- which I hope others will
confirm or deny -- is that byte 6 is used almost exclusively to determine
how to process the date elements in bytes 7-14. In other words, Type of
date codes "c" "d" "i" "k" "m" are used to specify matching within the
range between the two dates; codes "p" "r" and "t" are used to specify
matching on either date as a distinct single date; etc. If this is true,
then 008/06 contains INFORMATION about the type of date from which is
deduced a smaller number of processing choices; the present request is for
a distinct code, but the processing choice is the same as for code "t" (and
probably "p" and "r"). This is another example in the formats of where we
code one thing (the nature of the dates) but use the information is
somewhat different ways (how to process the date elements); if we actually
coded for the latter, there would be fewer codes needed.
Let me make it clear that the information function of the new code (being
able to identify bibliographic records containing corrected dates) is far
less important than the processing function -- that we be able to qualify
searches by either the given date or the corrected date -- and that the
processing requirements are the same as those for existing codes
(particularly "t").
2. Many non-early and non-rare materials have the above date
characteristics. Would practices change for all of these? How
about atlases which regularly have "incorrect" dates on the item
since the atlas is for the next year? Would the added complexity
of coding be valuable for current material?
It is certainly true that publishers occasionally make typographical errors
in publication dates (although this is much less common than in the
hand-press period) or incorrectly estimate when an item will actually be
published (items with 1998 publication dates, but received in Nov. 1997,
for example). In the former case, I think most catalogers would include a
correction in 260$c if they are aware of the error and knew the correct
date. The latter case, on the other hand, comes up for discussion almost
every December and I'm not sure that there is a consensus about whether the
corrected date should be added; I don't believe that LC routinely does this
in upgrading CIP records. And in the case of the atlases noted in the
question, if the date is treated as a coverage date rather than a date of
publication, then this coding would not be appropriate; if the publication
date is "anticipated" by the publisher, I'm not sure that catalogers would
routinely correct the date in 260$c. In other words, outside of rare
materials, I'm not at all sure how widespread is the practice of correcting
dates in 260$c -- and if the correction is not given in 260$c, then this
coding would not be appropriate in 008. My own approach is pragmatic: once
I have decided that it is worthwhile to record a correction in 260$c, then
I want to make sure that a user can retrieve this item using either the
given or the corrected date. Whether the item is rare or old or not may be
one factor in my decision whether to record the corrected date, but it
shouldn't be a factor in determining whether the record is retrievable.
3. Can a value be limited to early printed books?
Probably not, but (as indicated above) I'm not sure that is necessary.
4. Could any of the other existing date type codes be expanded to
include these dates, such as value m?
See the answer to question 1. Functionally, the new code works like code
"t"; the only difference is that the information content identifies Date 2
in one case as a given date and in the other as a copyright date. I would
hope (given that we are already coding 008/06 in this way) that the new
code could be defined and that it would not be too difficult for processing
programs to treat code "x" like code "t". Alternatively, we could redefine
code "t" (or one of the other codes) so that it would cover two quite
distinct cases in which we treat Date 2 as an alternative single date.
Personally, I think this would be terribly confusing. Another alternative
would be to rework 008/06 completely, using fewer codes to simply indicate
different ways of processing the date elements: single date, two single
dates, range of dates, detailed date, etc. I suspect that this would be
(a) more invasive than a new type code, and (b) a loss of the ability to
make some distinctions other than date processing based on this value
(e.g., being able to pull out current and/or ceased serials).
X. The Discussion Paper notes that one of the examples is not in fact a
corrected date. That example shows a given date based on the Julian
calendar which has been "corrected" (as instructed in the rules) by adding
the Gregorian date. It is true that this is not really a corrected date;
"normalized" might be a better term. There are other cases in which such
normalization takes place: where the given date follows a calendar such as
the Hebrew calendar or the Roman "ab urbe condita" calendar or the British
legal calendar or the Japanese calendar based on the imperial eras. Is
this really another distinctive date type ("Gregorian date/Non-Gregorian
date")? I suspect that in most of the cases above, there is no point in
recording the non-Gregorian date in 008 because it isn't a 4-character
numeric or (in the case of the Hebrew or Roman calendars) it is unlikely to
be confused with a Gregorian date; only in the case of the Julian calendar
-- which is identical in form to the Gregorian year and is easily
mis-identified as a Gregorian year -- is it important both to record the
Gregorian year in 260$c and (because it appears on the item) to be able to
retrieve on the non-Gregorian year. For this reason, it seemed to us that
this case was not that different from the corrected dates;
"corrected/normalized" would be a more accurate description and should
probably be included in the code description in the USMARC documentation.
In summary, I think that the authors of this change request are hoping that
these questions can be resolved without too much difficulty. We are
dealing with a very real issue involving retrieval of bibliographic
information, a situation in which we have felt the need to record two dates
in the imprint area of the description -- one because it appears on the
item and one because it is the correct date -- and in which we cannot
presently use the date appearing on the item to retrieve the record. We
need to find a way to fix this.
John Attig
Penn State University Libraries
814/865-1755
[log in to unmask]
|