DATE: May 7, 2001
REVISED:
NAME: Expanding Field 046 for Other Dates in the MARC 21 Bibliographic and Community Information Formats
SOURCE: Library of Congress; CORC
SUMMARY: This paper explores whether some specific types of dates which are not accommodated in the MARC 21 formats are important for bibliographic description and if so, it examines using field 046 (Special coded dates) as an alternative for providing appropriate places for them.
KEYWORDS: Dates; Field 046 (BD, CI); Modified dates (BD, CI); Valid dates (BD, CI); Created dates (BD, CI); Special coded dates (BD, CI)
RELATED: 98-04 (January 1998); 98-07 (June 1998); 2001-DP03 (January 2001)
STATUS/COMMENTS
05/07/01 - Made available to the MARC 21 community for discussion.
6/17/01 - Results of the MARC Advisory Committee discussion - The participants felt that fields 046 should not be merged together for their separate uses are too different in scope to conceptually combine. Subfield code values should also be defined in field 046 for new types of dates because using coded values in subfield $a may hinder retrieval. Separate subfields should be defined for the following (avoiding use of any subfield codes already defined in the community information field):
Subfield $2 (Source) should be also defined to allow for the use of different types of date schemes in the field. A proposal may be written reflecting these decisions for the midwinter meeting.
Discussion Paper No. 2001-DP04: Expanding Field 046 for Other Dates
Dates associated with bibliographic items are included in several fields in the MARC bibliographic format for various reasons. For example, field 260 (Date of publication, distribution, etc.) is for the publication date and field 005 (Date and Time of Latest Transaction) is for the date and time of the latest transaction. Although the format contains many dates, the question arises as to whether others are needed for new types of materials, especially for electronic resources.
In January 2001, the MARC Advisory Committee discussed Discussion Paper 2001-DP03 (Types of Dates for Electronic Resources in MARC 21 Formats). The paper originally dealt with dates needed for the Dublin Core element set qualifiers. The group decided that a new discussion paper should be presented that explored different types of dates that are currently not in the MARC 21 formats. Two were specifically identified: the date that a resource has been modified and the date that a resource is valid. In addition, a discussion is needed on the date that a resource has been created and how it is represented in the format. Participants felt that these types of dates may also be applicable to most other types of resources, such as loose-leaf materials, and thus, adding them to the formats may be beneficial for both resource management and information retrieval purposes.
Field 046 (Special coded dates) in both the bibliographic and community information formats is a possible field in which to code these dates. It is defined in the MARC 21 bibliographic format to contain date information that cannot be recorded in field 008/06-14. It was recently expanded in Proposal No. 98-07 to include not only B.C. dates, but also incorrect publication dates, a need requested by the rare book community. It could be expanded further to include other types of dates, although now it is primarily used for dates of publication. In this field, there are subfields defined for the beginning and ending dates for A.D. and BC dates (subfields $b, c, d, and e). The type of date recorded is in subfield $a in coded form.
Field 046 is also available in the community information format, where it is used for coded date information that is potentially useful for retrieval and data management purposes for community information resource records. This information had previously been recorded in field 004, but was changed to field 046 in the effort to resolve discrepancies in the bibliographic and community information formats for the SGML/MARC DTD that combined these formats. (See Proposal No. 98-04). Separate subfields are defined for different types of dates: action date ($f), purge date ($g), beginning date of event or program ($h), ending date of event or program ($i).
The MARC Advisory Committee discussion on Discussion Paper 2001-DP03 recommended exploring the harmonization of field 046 in the two formats.
2.1 Date Modified
Date modified describes a date in which a resource has been changed or updated. It is usually discussed in the context of webpages and other electronic media that routinely contain the date of last update; in some cases this may be the only date provided. In general, cataloging rules call for the creation of a new record when changes are made to an item that constitutes a "new edition." However, this practice may be impractical when cataloging electronic resources which are updated frequently. Date modified may be an important element to record in MARC records to allow for accurate, up-to-date information discovery of webpages in library catalogs. Moreover, because there is currently no place in the MARC 21 formats where date modified is recorded (field 005 is used for a modification date, the date in which the record was modified rather than the resource), defining a new data element could facilitate the mapping of the MARC 21 formats to other metadata standards that include this information, such as the Dublin Core standard. Unfortunately, the practice of recording date modified is very laborious and prone to errors. Likewise, it may be misleading for in most cases, only the top level pages on websites are cataloged and thus, this date may exclude all of the modified dates in the content-rich lower level pages. Finally, a clear definition of what "date modified" actually means is needed (e.g., date the page was updated, date the page was uploaded, etc.) if it is to be meaningful and accurately recorded.
Because date modified may not be very dependable, it may be more advantageous to record a statement of frequency in a note field to give the user information about the currency of the data. However, placing this information in a note field could hinder information retrieval by not allowing access to it through searching or limiting techniques.
2.2.1 Date Modified with Loose-Leaf Materials
In the January 2001 MARC Advisory Committee meetings, the consensus of members felt that further exploration in how date modified affects loose-leaf materials was warranted. Although some cataloging rules for loose-leaf materials are changing that may allow an updated date in the notes area of the description, (The revision of chapter 12 of the AACR2 allows the date updated to be added in the 260 field after the publication is discontinued), it could be impractical to code date modified in loose-leafs for often none of the bibliographic data elements may change when updates are added into publications. Moreover, many libraries currently use either their check-in systems or a holdings field to keep track of the latest date of updates filed into loose-leaf materials.
2.2 Date Valid
Date valid is the date of validity of a resource. It is often a range of dates and generally applies to resources whose content is valid only within a certain time period. Examples include a webpage of train schedules or a piece of legislation that may not apply until a particular point in time. Although field 518$a (Date/Time and Place of an Event Note) could be used for this type of date, its definition may not always be applicable for this concept. Because many websites and other electronic resources contain date-sensitive information, this element could be a very useful one to record and thus, a consistent place in the format for this information may need to be considered. Unfortunately, providing date valid data could be very laborious to keep current because of the fluid nature of information on the web.
2.3 Date Created
Date created is a primary date used for resource discovery. There is no one place used in the MARC 21 formats for creation date, since date of creation can mean various things (e.g., date the item was produced, date the intellectual content was created, date the original was created when a reproduction). When an item is unpublished, the date created is generally recorded in field 260$c. (Note that recent discussion, particularly in the context of the ISBD for Electronic Resources, considers electronic resources "published." A revision to AACR2 Chapter 9 will include the stipulation that all remote access electronic resources are to be considered published for cataloging purposes). There are other possible places in the format for date created (for published materials), depending upon the circumstances. These include, but are not limited to, the date in a uniform title in field 130 or 240, date of the reproduction in field 533, date of the original in field 534 (but not separately subfielded), or 260$g (date of manufacture). However, because web and other more fluid electronic resources contain somewhat ambiguous dates of creation that do not fall within these traditional guidelines, it may be advantageous to provide clearer guidance on how to code for date created for them in the formats. Defining a data element for creation date not recorded elsewhere could also help map the formats to other metadata standards with greater success.
2.4 Field 046 (Special Coded Dates)
Because there are many different types of dates used by electronic media whose meanings are somewhat ambiguously defined and because electronic resources reside in very dynamic environments, it may be advantageous to consider using one data element for all dates that do not fit into the other date fields currently defined in the MARC 21 formats. This data element could contain the dates for when an item was modified, valid, created and any other date associated with an item that an agency may deem important. Field 046 could be used for this purpose with the type of date identified either as codes in subfield $a or with specific subfields.
2.4.1 - Harmonizing field 046 in the bibliographic and community information formats
In the January 2001 MARC Advisory Committee meeting, the consensus was that field 046 would be a good candidate to include new dates for electronic resources, such as date modified, date valid and date created. However, if field 046 were to include these new types of dates, it might also be considered whether it is advantageous to align the subfields in the bibliographic and community information formats. This discussion also arose in consideration of Proposal No. 98-04. Defining subfields $a-$e in the community information format and subfields $f-$i in the bibliographic format could be desirable to keep them in alignment with each other. The harmonized 046 field could then be defined as:
Indicators - Undefined
Subfields
$a - Type of date code (NR)
Codes
t - Publication and copyright dates
i - Inclusive dates of collection
k - Bulk of collection
m - Multiple dates
n - Unknown date
p - Distribution/release/issue and production/recording session dates
q - Questionable date
r - Reissue and original dates
s - Single known/probable date
x - Incorrect dates$b - Date 1 (BC date) (NR)
$c - Date 1 (C.E. date) (NR)
$d - Date 2 (BC date) (NR)
$e - Date 2 (CE date) (NR)
$f - Action date (NR)
$g - Purge date (NR)
$h - Beginning date of event or program (NR)
$i - Ending date of event or program (NR)
$6 - Linkage (NR)
$8 - Field link and sequence number (R)
However, because field 046 in the bibliographic format includes dates about bibliographic items and field 046 in the community information format holds dates for events, the two groups of subfields may not be very compatible with each other when combined. Furthermore, although the bibliographic 046 field uses codes placed in subfield $a to describe the type of date, the community information format 046 field uses separate subfields. It could thus be difficult to broaden the existing subfield definitions to include the date needs of both formats.
To solve this incompatibility problem, subfield descriptions or names could specify which subfields are used in what type of records. For example, subfield $f could be renamed as "Record action date." Alternatively, the individual descriptions of subfields $f-$i in the bibliographic format could contain statements that the subfields are not used in bibliographic records. Another option could group the subfields together in the documentation using captions. For example, the field could resemble the following:
Bibliographic Dates
$a - Type of date code (NR)
Codes
t - Publication and copyright dates
i - Inclusive dates of collection
k - Bulk of collection
m - Multiple dates
n - Unknown date
p - Distribution/release/issue and production/recording session dates
q - Questionable date
r - Reissue and original dates
s - Single known/probable date
x - Incorrect dates$b - Date 1 (BC date) (NR)
$c - Date 1 (CE date) (NR)
$d - Date 2 (BC date) (NR)
$e - Date 2 (CE date) (NR)
Record Dates
$f - Action date (NR)
$g - Purge date (NR)
Event Dates
$h - Beginning date of event or program (NR)
$i - Ending date of event or program (NR)
Control Subfields
$6 - Linkage (NR)
$8 - Field link and sequence number (R)
2.4.2 Defining data elements in field 046 for dates used in electronic resources
2.4.2.1 Broadening the definition of existing subfields
Some subfields in the existing community information field 046 could be applicable for electronic resources if the definitions were slightly broadened. For instance, subfields $h (Beginning date of event or program) and $i (Ending date of event or program) could be used to record date valid if they were broadened to include dates for bibliographic items. Subfields $h and $i could be defined as:
$h - Beginning date
Subfield $h contains the beginning date of an event, program or the beginning date of the validity period for a bibliographic item.
$i - Ending date
Subfield $i contains the ending date of an event, program or the ending date of the validity period for a bibliographic item.
2.4.2.2 Defining new data elements
New codes in subfield $a (Type of date code) could also be defined for new dates, such as date modified, date created and date valid. Unfortunately, many library systems may have difficulty deriving display or meaningful searches using date codes in subfields. Moreover, because the codes currently defined for subfield $a correspond to those used in field 008/06 (Type of date/Publication status), it may be cleaner to define new subfields for these dates since they are not represented in field 008/06.
Subfield $j could be defined for date modified and subfield $k could be defined for date created in field 046. However, it may also be necessary to define two subfields for each type of date to account for beginning and ending dates. In this case, subfields $j and $k could be defined for beginning and ending of the date that an item was modified and subfields $l and $m could be defined for beginning and ending of the date that an item was created.
2.4.3 Repeatability of field 046 and definition of subfield $2
Because dates can be recorded in many different forms (for example, ISO 8601, International standard for the representation of dates and times, describes two types of date/time formats), it is important that they are recorded in predictable ways in order to accurately interpret them. Currently field 046 is non-repeatable, however, to broaden its use to record different types of date formats it could be made repeatable to specify each form of date used in the field. This would provide both flexibility in the kinds of dates used and allow metadata standards to be mapped to the MARC 21 formats with greater ease.
Because different date schemes could be used in field 046, subfield $2 (Source of date) could also be defined to indicate the source of date scheme used in the field. It could be defined as:
$2 - Source of date
Subfield $2 contains a code that identifies the source of the date scheme used in the field. The source of the code is the MARC Code Lists for Relators, Sources, Description Conventions, that is maintained by the Library of Congress. [A list of codes would be developed.]
Library of Congress