Discussion Paper 2001-DP03

DATE: December 28, 2000

NAME: Types of Dates for Electronic Resources in MARC 21 Formats

SOURCE: Library of Congress; CORC

SUMMARY: This paper reviews the different types of dates for electronic resources that are used as qualifiers in the Dublin Core Metadata Element Set and how they correspond with defined MARC 21 fields. It discusses whether some specific types of dates which do not have an accurate mapping to MARC 21 are important for bibliographic description and, if so, alternatives for providing appropriate fields/subfields for them.

KEYWORDS: Dublin Core; Dates (BD, CI); Field 046 (BD, CI); Field 260 (BD); Field 583 (BD, HD)

RELATED: 98-04; 98-07


12/28/00 - Forwarded to the MARC Advisory Committee for discussion at the January 2001 MARBI meetings.

01/14/01 - Results of the MARC Advisory Committee discussion - Participants felt that field 046 would be better for other dates since it is more expandable. A new discussion paper was requested for the annual 2001 meeting focusing on using field 046 with the following points:

Discussion Paper No. 2001-DP03: Types of Dates for Electronic Resources


The Dublin Core Metadata Initiative (DCMI) includes a list of fifteen data elements intended to facilitate discovery of electronic resources. Since its formation, many implementers have found the need to qualify the elements in various ways to provide for more precision in searching and allow for more complex descriptions than the 15 elements alone allow for. One Dublin Core element that is semantically imprecise without some sort of qualifier indicating the type is Date.

DCMI undertook a process to develop and approve qualifiers for each of the 15 elements in the Dublin Core Metadata Element Set (DCMES), which was initially completed during the first half of 2000. Qualifiers that were approved for Date were:

Definitions for Dublin Core qualifiers are at: http://purl.org/dc/documents/rec/dcmes-qualifiers-20000711.htm

OCLC's product, the Cooperative Online Resource Catalog (CORC) includes descriptions of Web resources which may be created or displayed in either a MARC or Dublin Core view. A crosswalk between MARC and Dublin Core elements was developed by OCLC in consultation with LC's Network Development MARC Standards Office, which allows for the data transformations in either format. As part of that effort, it has been found that some elements and/or qualifiers do not map easily to metadata or elements already defined in library MARC databases.

Although it may be logical to expect that a very broad metadata element set such as Dublin Core would be a subset of elements in the more complex MARC 21 formats, some of those elements with qualifiers do not have an obvious match with an already defined element in MARC. It needs to be considered whether the characteristics of electronic resources, the focus of Dublin Core descriptions, might warrant the definition of new elements that are not already available. The broad degree of consensus in different domains and applications achieved in the approval of qualifiers for these specific types of dates may point to a need for the same distinctions to be made in MARC 21 applications. This paper considers qualifiers and their mappings for the Dublin Core Date element.


2.1. Mapping of Dublin Core qualified dates.

The Dublin Core/MARC crosswalk includes the following mapping between qualified Dublin Core dates and MARC fields. (For further information see: //www.loc.gov/marc/dccross.html).

2.1.1. Date available. Date available is defined as the Date that the resource will become or did become available. Field 307 was originally defined in the Community Information Format for hours or dates that an event or program was available or accessible. It was extended to the bibliographic format especially for electronic resources, to provide for dates associated with the availability of electronic systems and services. This mapping is appropriate for the sort of information expected.

2.1.2. Date created. Date created is a primary date that is used for resource discovery. There is no one place used in MARC 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 among others 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).

The basic Dublin Core/MARC mapping provides for an unqualified date, which is used for simple Dublin Core (without qualifiers) or when a system does not understand qualifiers (the "dumb-down" rule). Because of the ambiguity of the definition of a Dublin Core unqualified date ("A date associated with an event in the life cycle of the resource") it is difficult to determine whether to consider date the resource is created as the default date and map it to 260$c, which would allow for it to be used in a MARC element often indexed as a primary date. As noted above, this subfield is used for a creation date for material that is not formally published. However, since Date issued is another Dublin Core element, it was decided to provide another subfield for date created, and field 260$g (date of manufacture) was provided. Although not a perfect mapping, it was felt that the date created could go in this field; the identification of the record as a Dublin Core record (in field 042) could help the user or system in interpreting the type of date.

2.1.3. Date issued. Since in qualified Dublin Core date issued is defined as "the formal issuance (e.g., publication) of the resource" mapping to 260$c is appropriate (also if electronic resources are to be considered published). In this case, as with date created, the distinction between the two dates is problematic, especially since MARC has used 260$c for creation date of non-published material.

2.1.4. Date modified. In the current crosswalk, a mapping for this type of date has not been provided. Field 005 is used for a modification date, but this is the date the record was modified rather than the resource. Dublin Core date modified is defined as "date on which the resource was changed". It needs to be considered whether this date is an important one that needs to be identified as such, particularly for electronic resources. In general, cataloging rules call for the creation of a new record when changes are made to an item. However, the nature of electronic resources may warrant the inclusion of a date modified element in MARC. In addition, it cannot be assumed that a record created in (or converted to) MARC that uses the Dublin Core element set for description follows AACR2 cataloging rules.

The MARC/Dublin Core crosswalk defined for CORC has used 562$c (Copy and Version Identification Note/Version identification) for Date modified. This subfield has not traditionally included dates, and the field itself has been used for archival and manuscript descriptions. However, one could consider that date modified is version information.

Other possible mappings include use of field 583 (Action note) subfield $c (Date and time of action), with the possibility of defining some terms for subfield $a (e.g. modified). Another candidate is field 046 (Special Coded Dates); see discussion below.

2.1.5. Date valid. Date valid is defined as "Date (often a range) of validity of a resource." It generally applies to resources whose content is valid only within a certain time period; an example frequently given is train schedules on the Web, which may not apply until a particular point in time. It needs to be considered whether this type of date might apply to MARC-created or converted records. The DC/MARC crosswalk uses field 518$a (Date/Time and Place of an Event Note), which is used for "date/time or place of creation, capture, or broadcast associated with an event or the finding of a naturally occurring object. " Although not exactly the same definition, this element was mapped here, since it is defined to include an event date. As with other elements, identifying the record as one that uses Dublin Core descriptions could facilitate in interpreting this as date valid.

Note that unqualified Dublin Core date (i.e., if the type of date is not specified) uses 260$c.

2.2. Need for identifying more types of dates in MARC.

The MARC community needs to consider whether the format has sufficient data elements to distinguish types of dates important for electronic resources that perhaps have not been necessary to identify for other types of material. Types of dates that were considered important to distinguish during the process of approving qualifiers for Dublin Core elements, although not the last word on the subject, may point to a need, since the qualifiers are intended for general applications across domains and communities. In addition, there has been much discussion recently about a new category of bibliographic level, referred to as "integrating resource". In this context date the resource was last updated (i.e. modification date) may be important data to capture. The need for recording additional types of dates has been recognized in revisions to AACR2, which will likely include recording more dates for verification and identification purposes, probably in notes.

A paper presented at the LC Bicentennial Conference on Bibliographic Control for the New Millennium discussed the importance of events in the life of electronic resources. Because of the fluidity of electronic resources both in their creation and distribution, a contrast to the fixity of information in the pre-digital age, new models for resource description need to be considered. This paper written by Carl Lagoze and entitled "Business Unusual: How "Event-Awareness" May Breathe Life Into the Catalog?" argues the need for more event-centered cataloging whereby a record needs to describe a resource's transition events, including, among other elements, the nature and time of events in the life- cycle of the resource. The types of transformations made to resources need to be documented in the resource's metadata. Whether the types of dates approved as Dublin Core qualifiers are needed in MARC where there is not a reasonable mapping needs to be considered as a starting point for event-aware cataloging.

Dates discussed above that may not have an adequate mapping are:

2.3. Date formats.

Dates can be recorded in various different formats in both MARC and Dublin Core. They can be free-text or formatted according to different schemes. Both MARC and Dublin Core use a form of ISO 8601, which is the International Standard for the representation of dates and times. ISO 8601 describes a large number of date/time formats. In several MARC 21 data elements, the format of YYYYMMDD is used. In Dublin Core, the scheme of the date format may be specified, and best practice is defined as a profile of ISO 8601 called W3C-DTF (Date and Time Formats, which is a note made available by W3C). This specifies the format YYYY-MM-DD. Because of the limitations of the fixed field dates (008/07-14) in the bibliographic format, variable fields have been chosen for mapping Dublin Core dates; this allows for any format to be used. (Note that the specification of which format is used, e.g. "W3C-DTF" is outside the scope of this paper.)

Dates in a coded form are easier for computers to parse and reliably use. Thus, a coded date field may have advantages over a field intended for human readability and display. This has implications for where these types of dates might be recorded.

2.4. Possible solutions.

2.4.1. Field 046 (Special Coded Dates). Field 046 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 dates, a need requested by the rare book community. It could be expanded 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 B.C. 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 a CIF 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 discussion of the proposal suggested that LC should investigate whether defining subfields $a-$e in the Community Information Format and subfields $f-$i in the Bibliographic Format was desirable and if so, whether it would be problematic for either set of users.

If field 046 were considered to include new types of dates, it might also be considered whether it is advantageous to align the two groups of subfields in the two formats. Some subfields in the existing community information field 046 may be applicable for electronic resources if the definitions are slightly broadened. For instance, subfield $g could be used for date valid (with an ending date in subfield $i).

Field 046 has the advantage of using a coded date which is machine-parseable. If this field were used for other types of dates, it would need to be made repeatable.

2.4.2. Field 583 (Action Note). Field 583 is used to record information about processing and reference actions relating to an item. It may use a controlled list of terms (currently for preservation actions). Standard terms could be included in subfield $a for dates relating to electronic resources that are recorded in subfield $c. (Example: 583 $a modified $c 20010120).

2.4.3. Other fields. Existing fields/subfields such as field 518 or 562$c could be broadened to more closely correspond to the definitions of other types of dates such as date valid or date modified rather than use any of the above fields. It is important that any such effort not affect existing records.

Because of the increasing practice of mapping metadata between different formats for various purposes, it is important that the MARC community consider providing for specific elements for those that may be necessary for general types of applications. Although complete round-trip mapping between metadata schemes is not necessarily possible or desirable, the types of dates that have been determined to be important for electronic resources in the Dublin Core community may also be of interest in the MARC community.


3.1. Which types of dates represented in qualified Dublin Core have applicability for MARC records, especially for electronic resources?

3.2. Are the mappings used in the DC/MARC mapping adequate? In particular:
3.2.1. Since Date modified has not so far been included, what would be an appropriate place?
3.2.2. What is the best mapping for date created, in that only one place can be provided? Assuming it needs a different mapping than that for date issued, where could it be included given its importance in resource discovery? (Note that a MARC to Dublin Core mapping may contain multiple fields/subfields mapped to one Dublin Core element, while a Dublin Core to MARC mapping would include only one.)

3.3. Could field 046 be adapted to include other types of special coded dates?
3.3.1. If so, which subfields should be used?
3.3.2. Should the community information subfields be defined in the bibliographic format and vice versa? If so, is it a problem that type of date is in coded form in subfield $a, with the same subfields used regardless of type, while the community information fields define specific subfields on the basis of type?

3.4. Could field 583 be used for other types of dates? If so, which ones?

3.5. Are there other fields that could be used, perhaps with modified definitions? If so, which ones?

Go to:

Library of Congress Library of Congress
Library of Congress Help Desk (02/01/01)