NAME: Define a Generic Author Field in the Bibliographic, Authority, Classification, and Community Information Formats.
SOURCE: OCLC/NCSA Metadata Workshop, NLM
SUMMARY: This paper proposes defining a new, repeatable field for names of authors not formulated according to cataloging rules. This field would be useful in the internet environment where names are not designated as "main" or "added" and the distinction between personal and corporate name is not made.
RELATED: DP88 (June 1995); DP86 (June 1995)
KEYWORDS: OCLC/NCSA Metadata Workshop; Dublin core data elements; Author; Name; 7XX fields
STATUS/COMMENTS: 12/1/95 - Forwarded to USMARC Advisory Group for discussion at the MARBI meetings.
1/21/96 - Results of the USMARC Advisory Group discussion - Approved as amended, with Option 2 (defined first indicator) preferred; the first indicator value # should be called "Not specified". The description of the new field should indicate that the names are not "necessarily formulated according to cataloging rules or contained in an authority file or list". The proposal does NOT apply to the Authority format, as was erroneously indicated. The name in the field may be in any order, e.g., forename surname. Field tag is to be 720.
2/15/96 - Results of final LC review - Agreed with MARBI desicion.
PROPOSAL NO. 96-2: Define a Generic Author Field 1. INTRODUCTION The USMARC bibliographic format was designed primarily to support library cataloging, and to be used in conjunction with cataloging rules that specify the formulation of the data. Therefore there are many data elements defined in USMARC that relate specifically to particular cataloging constructs. Such integral support for cataloging is clearly a desirable feature in the bibliographic formats, but it also raises problems when creating bibliographic data for other purposes. For example, there is no MARC field defined specifically for author, but rather sets of fields defined for main and added entries, concepts that exist within cataloging codes (and which also encompass a number of non-authorial relationships). Since the 1XX and 7XX tag ranges are defined explicitly in terms of the cataloging concepts main and added entry, it is difficult to use them in an environment that lacks these concepts. In addition, in order to properly encode the 1XX and 7XX name fields, one has to know quite a large number of things, including the author's relation to the work, whether the name in question is that of a person, corporate body, or meeting, and the form of entry of element of the name. There is no option in USMARC to choose not to supply any of this information or to indicate that it is unknown. This can pose a barrier to use of these fields for non-cataloging purposes. A few such situations are the following. - A bibliographic record might be used in a library acquisitions system for the purpose of creating a purchase order. In this case, the data may not be cataloging data, and the acquisitions clerk creating the data may neither know the rules governing form and choice of entry nor have sufficient information in the source citation to assign content designation congruent with the cataloging rules. - Bibliographic records might be created for the purpose of generating a set of references (endnotes or footnotes) according to some external authority such as the Chicago Manual of Style, which has quite different rules for citing authors' names than most cataloging standards. For example, according to the Chicago Manual, the names of all four editors of a jointly edited work should be listed; whereas according to AACR2, the name of the first editor only would be recorded as an added entry. - An increasingly common use of USMARC bibliographic records is as a vehicle for metadata created by various communities according to various other standards. For example, the Government Information Locator Service (GILS) defines a set of GILS Core Elements and specifies that these must be represented in three different record syntaxes, one of them USMARC. Another example is the National Library of Medicine (NLM) data from their MEDLINE database which has never distinguished the type of element for personal names, yet there is a need to distribute those records in MARC. More recently another standard known as the Dublin Core Element set was proposed for describing network accessible electronic resources. The Dublin Core, with only minor variations, is also being incorporated into the emerging IETF standard for Uniform Resource Characteristic (URC). There is clearly great utility in being able to represent metadata created according to standards other than AACR and AACR2 into USMARC. The data can then be edited and manipulated by the many existing software packages for processing MARC bibliographic records, and the records can be integrated into existing library catalogs and searched by MARC-based bibliographic retrieval systems. Both the library community and the information providers are benefited. 2. DISCUSSION In general the most problematic element for mapping into MARC is the author. The GILS Core Element set has no element for author but does have an element for originator which identifies the originator of the information resource. This is by convention mapped to the USMARC 710 field. The X10 was chosen because GILS originators can be assumed to be government agencies, and the 7XX block was chosen over the 1XX block because of its repeatability. The Dublin Core, which is more fully described in Discussion Paper No. 86 contains two data elements for names of entities responsible for intellectual content, Author and Other Agent, which are not necessarily governed by cataloging rules and which map only imperfectly to USMARC 1XX and 7XX fields. The Author element could be recorded simply as "AUTHOR = Miller, Bruce". A cataloger converting this data to USMARC is likely to be able to infer that this is a personal name, but may be less likely to know whether Mr. Miller is related to the resource in the capacity of main or added entry. The Dublin Core does allow for qualifiers which, if extensively used, could provide enough information about a name for accurate human or even machine mapping to USMARC, assuming the name was formulated according to cataloging rules. The "scheme" qualifier can be used to specify the cataloging rules, the "type" qualifier can specify personal, corporate or other authorship, etc. AUTHOR (scheme = AACR2, role = Main Entry, type = Personal, form = Surname) = Miller, Bruce However, since the Dublin Core was defined expressly for the purpose of encouraging metadata creation by non-catalogers, the likelihood of this information being supplied for the majority of objects is low. Three alternatives for solutions were discussed in DP88 in June 1995. They included putting the data in the currently defined 1XX and 7XX fields, making guesses for the supplying of content designation and allowing irregularities. This was rejected as diminishing the usefulness of the highly controlled and refined data in the existing fields. A second solution, to adjust the content designation in the 7XX fields so that non-standard data could be identified was rejected as it would still require a level of identification of names (e.g., distinguishing personal, corporate, etc.) that would not meet the needs indicated. A third solution was endorsed: to create a new 7XX field for uncontrolled names. This "generic name" field would not distinguish between main and added entry, and would not require the distinction between types of authors. Internal content designation would be optional and kept to a minimum. This solution is parallel to fields that have been established for uncontrolled subject terms (field 653) and titles (field 740). There was a question concerning whether to provide an indicator for showing the type of name, when that was known. 3. PROPOSED CHANGES -- Define a new, repeatable field for names (non-subject) that are not formulated according to cataloging rules or contained in an authority file or list. 713 Uncontrolled Name (R) This field contains names associated with a work that are not controlled by an authority file or list. The names may be personal, corporate, or meeting. Indicators First (see below) Second Undefined; contains a blank Subfield codes $a Name (NR $e Relator term (R) -- Options for first indicator Option 1: First Undefined; contains a blank 720 ## $aBlacklock, Joseph 720 ## $aVonderohe, Robert, 1934-$eeditor 720 ## $aCAPCON Library Network$eauthor Option 2: First Type of name # Unknown or not specified 1 Personal 2 Other 720 ## $aBlacklock, Joseph 720 1# $aVonderohe, Robert, 1934-$eeditor 720 2# $aCAPCON Library Network$eauthor