>>>>> "KC" == Karen Coyle <[log in to unmask]> writes:

KC> At 11:28 AM 5/1/2003 -0500, Tod Olson wrote:
>> One would not blindly remove any "c" in an AACR2 date, but rather write a
>> parser to cover a variety of cases.  This is something of a nightmare,
>> given that the date in AACR2 is little better than free text, but the
>> majority of cases can be identified and handled.

KC> For the conversion from MARC21 to MODS, wouldn't we want to use the 008
KC> date, which is already normalized, as well as the 260 $c date, which is
KC> really for display? It would be a shame to only keep the 260 $c date and
KC> have to parse it when a fully normalized date is available in the 008.,

Probably most of the time.  One would want to check that there are
acceptably few errors in the 008s (positions. 06, 07-10, and 11-14),
that one does not care about the "between" dates, and that sort of

In general, if both the display and normalized date forms are
important for an application, then we either (1) store both in MODS,
as we do in MARC, and distinguish them implicitly by their attributes,
or (2) assert that a display form should be generated from a
normalized form and provide the appropriate support.  I think (2) is
the way to go, though I may be in the minority.

Tod A. Olson <[log in to unmask]>     "How do you know I'm mad?" said Alice.
Sr. Programmer / Analyst            "If you weren't mad, you wouldn't have
The University of Chicago Library    come here," said the Cat.