FAQ on the 670 (Source Data Found) Field in Name Authority Records (NARs) for NACO

About PFAN

News and Updates

Rules for Contributions

Name Authority Manual

Participant's Manual

PFAN Policy Statements

PFAN Training

Frequently Asked Questions (FAQ)

Other Documentation

LAC

Is there any required punctuation or style in the 670 field?

There is no required punctuation and style in the 670 field. There is some prescribed content (per the MARC 21 Authority Format) and some suggested punctuation (see no. 2-4 of this FAQ). The 670 section in the Descriptive Cataloging Manual (DCM) Z1 supplement to the MARC 21 Authority Format states, "conventions in regard to punctuation and style ... are not prescriptive ... Punctuation and style need not be consistent from record to record as long as the information is clear and accurate." For historical purposes and because catalogers will continue to find NARs in the authority file which contain "old style" citations, the DCM Z1 shows varied examples.

Note: DCM Z1 tells catalogers to spell out or abbreviate the names of months (e.g., January or Jan.) rather than using a numeral to represent them (e.g., 1/5/14) when giving dates in the 670 field (e.g., when recording a person's birth or death date or the date an online resource was viewed) because U.S. practice for recording dates using only numerals differs from the practice in some other countries. This helps to facilitate international participation in NACO.

Return to Table of Contents ⮝

What are the prescribed elements in the 670 field?

The MARC 21 Authority Format defines the 670 (source data found) field as a repeatable variable field which is comprised of non-repeatable subfields $a and $b. Subfield $a (source citation) is always required; however, subfield $b (information found) is necessary only when information is being provided to support access points or entity attributes being recorded in the 0XX, 1XX, 3XX, 4XX and sometimes the 5XX fields. DCM Z1 prescribes four elements:

In subfield $a of the 670:

The title proper of the resource being cited. The date of publication, etc. In subfield $b:

The specific location(s) of the information found. The information found (enclosed in parentheses) See the DCM Z1 for additional guidelines and examples for specific categories of materials, types of dates, etc.

Note: DCM Z1, reminds catalogers that: "the NAR does not serve as a biographical sketch of a person ..." and to "use judgment to determine how much data to record ..." The ideal 670 is cogent and concise yet complete.

Return to Table of Contents ⮝

Is a subfield $b always required in a 670 field?

As noted in Question 2 of this FAQ, the MARC 21 Authority Format requires a subfield $a; however, subfield $b is necessary only when information is being provided to support access points or entity attributes being recorded in the 0XX, 1XX, 3XX, 4XX and sometimes the 5XX fields.

For example, if usage for the entity being established is contained in the title of the item being cataloged (subfield $a), and the item contains no other usage or identifying information about the entity, the subfield $b may be omitted. When creating or updating work/expression NARs it is seldom necessary to add a subfield $b to the NAR unless recording research. Nonetheless, in both these cases the inclusion/repetition of information in a subfield $b is not prohibited.

Examples:

670 $a The autobiography of Ethel Firebrace, 1937.

    Access point established as: Firebrace, Ethel

670 $a Actes du 26e Congrès international de papyrologie, Genève, 16-21 août 2010, 2012.

   Access point established as: Congrès international de papyrologie $n (26e : $d 2010 : $c Genève, Suisse)

but

670 $a Autobiography of Mrs. Laura Dickey and choice miscellaneous selections, 1895: $b page 5 (née le 27 septembre 1811 à Newstead, Erie County, New York)

  Access point established as: Dickey, Laura, $d 1811-

  Place of birth entered in 370 $a as: Newstead (N.Y. : Ville)

 Date of birth entered in 046 $f as: 1811-09-27 $2 edtf

Return to Table of Contents ⮝

Is adding the name of the agent responsible for creating the work cited in the 670 subfield $a totally forbidden?

No. According to DCM Z1, if the title of the item being cataloged is generic or indistinctive, the name of the agent responsible for creating the work should be included preceding the title proper in 670 subfield $a. Also see Question 6.

Example:

670 $a Dickinson, Emily. Selected poems, [1990]: $b achevé d’imprimer (Gregory C. Aaron) 

What would a "typical" 670 field in an NAR look like?

A typical 670 field would include the following prescribed content and suggested punctuation:

A monograph:

670 $a La pasión de Octubre, 1996 : $b p. de t. (P.J. González Cuesta) rabat arrière (Pablo González Cuesta, né à Séville, en 1969)

A database reference source:

670 $a OCLC, 23 janvier 2001 $b (point d’accès : González Cuesta, Pablo Juan; usage : P.J. González Cuesta) 

OCLC and many local systems have macros to "machine assist" the creation of NARs, which may generate more information in 670 fields than is necessary.

Return to Table of Contents ⮝

How much clean-up is required in this field?

The 670 section of the DCM Z1 states: "In authority records created using an automated authority generation program, the 670 information may include the main entry name ... it is recommended that catalogers accept the additional information as generated."

Catalogers should use judgment in deciding what other information can remain or what should be deleted.

Return to Table of Contents ⮝

When is it necessary to provide more than one 670 field in an NAR for a personal name access point being newly established that does not conflict with another name in the name authority file (NAF)?

In general, when newly establishing a personal name that does not conflict with another access point in the database within which one is cataloging, it is not necessary to cite another source beyond the item in hand except in the following situations:

A. When the rules for establishing personal names require consultation with a reference source (e.g., RDA 9.2.2.2 and 9.2.2.5.2)

B. When justifying an addition to the name access point (fuller form of name, dates, title, etc.) and that information was found in a source other than the item in hand (i.e., during the normal course of searching in the database in which the work is being performed).

C. When justifying a variant access point and that information was found in a source other than the item in hand (i.e., during the normal course of searching in the database in which the work is being performed).

D. When recording a variant usage which would not require a variant access point (e.g., unused additional forenames for a person, a minor difference in a corporate body name that occurs several words into the name, etc.) and that information is found in a source other than the item in hand (i.e., during the normal course of searching in the database in which the work is being performed).

E. When recording elements other than access points (e.g., an associated place, occupation, etc.) and that information is found in a source other than the item in hand (i.e. during the normal course of searching in the database in which the work is being performed).

Return to Table of Contents ⮝

When do NACO procedures require a cataloger to look in other sources (beyond the item in hand and the database in which one is cataloging) for variant usages, fuller forms of the name, dates, etc.?

Generally, only when the access point conflicts with another in the NAF and the item in hand does not provide enough information to break the conflict or, as noted in response to Question 7 of this FAQ, when the rules call for consultation with a reference source.

That said, PCC policy does not allow RDA NACO records to be coded “undifferentiated” (see DCM Z1 008/32) so it is important to identify each name entity unambiguously. Therefore when additional attributes such as fuller forms of name, dates, etc. are available, NACO catalogers are encouraged to include them in 046/3XX fields when creating or updating NARs.

Return to Table of Contents ⮝

Should we use the designation "PCC in OCLC" in a 670 field to cite a heading found on a PCC (042=pcc) record?

No, there is no convention for citing PCC records in the 670 field and at this point it is not cost-effective to add another layer of complexity to citations in the 670 field. Instead, cite the access point and usage as found in the OCLC database as of a particular date.

Return to Table of Contents ⮝

Doesn't it "help" or give more "authority" to the access point being established if a 670 field is included showing that the same formulation has previously been used on bibliographic records (especially if it's an LC record)?

No, although some catalogers seem to think so. It is RDA, the LC-PCC Policy Statements, and usage which provide the authority for establishing an access point. To cite the occurrence of an access point that does not provide any additional information in an additional 670 field (regardless of its provenance) adds to the time it takes to create an authority record and is contrary to the PCC principle of "the timely creation and maintenance of authoritative, cost-effective bibliographic and authority records."

Return to Table of Contents ⮝

If I search the LC database should I provide an "LC database" citation in a 670 field?

Searching the LC database is not a NACO requirement. NACO catalogers may provide a 670 field with an "LC database" citation but should do so only if the information provides additional support for the formulation of the 1XX, etc. If citing an access point labelled “[from old catalog]”, remember to include that label in the citation (for more information, see the FAQ on these access points).

Example: 670 $a LC database, May 14, 2012 $b (access point: Poschmann, Bernhard, $d 1878-1955 [from old catalog]; usage not given)

Return to Table of Contents ⮝

Is it OK to include URIs in subfield $u in 670 fields?

Within reason. Although subfield $u was authorized for use in NARs on February 1, 2006, NACO catalogers are expected to apply its use judiciously. Optional use of the 670 $u should be for those cases when the source contains significant information related to the established access point that cannot be cited succinctly in the 670 field. Remember: citing a URI in 670 $u does not take the place of the requirement to cite relevant data in subfields $a and $b of the 670 (i.e., enough information to support the authorized, variant, and related access points in addition to other entity attributes contained in the NAR). This source material will then be available to future users of the authority data even if the website itself disappears.

Return to Table of Contents ⮝

May I also use URIs in subfields $a or $b in 670 fields?

Generally, no. However, some corporate names and/or title strings may have the general appearance of URIs (usually without the Internet protocol designation, e.g., http://), and may be cited as names and titles in 670 $a as needed (cf. //www.loc.gov/aba/pcc/naco/corpfaq.html#9 for more information). In order to be “actionable,” URIs found in $u should include the protocol, e.g., $u http://www.stephenking.com

Return to Table of Contents ⮝

Should I change a 675 (source data not found) field that contains information from the consulted source to a 670 (source data found) field when editing a record?

It is recommended but not required to change a 675 (source data not found) field to one or more 670 (source data found) fields when editing a record if the 675 field contains information from the consulted source. A 675 field that contains no information from the consulted source should be left as is.

(Historical note: The definition of field 675 was changed in 2012 to: “Citation for a consulted source in which no information is found related in any manner to the entity represented by the authority record or related entities.” Prior to this change, catalogers used 675 when either no information about the entity represented by the authority record was found in the source or when the only information found in it justified a 5XX related entity. Field 670 is now used for the latter purpose.)

Example:

BEFORE EDITING

110 2 $a Arizona State University. $b College of Business

510 2 $w a $a Arizona State University. $b College of Business Administration

510 2 $w b $a W.P. Carey School of Business

670 $a Job growth update, Sept. 1990: $bp. de t. (College of Business, Arizona State University)

670 $a Arizona State University Colleges and Schools web resource, consulté le 14 juillet 2004 : $b Business education - W.P. Carey School of Business, Dean's welcome (Depuis 2003, notre nom est la W.P. Carey School of Business)

675 $a LC database, 1-10-91 (vedette : Arizona State University. College of Business Administration); $a Arizona blue chip economic forecast, janv. 2004 : p. 4 (W.P. Carey School of Business, Arizona State University)

AFTER EDITING

046 $t 2003 $2 edtf

110 2 $a Arizona State University. $b College of Business

368 $a Écoles de commerce $2 rvm

377 $a eng

510 2 $w r $i Supérieur hiérarchique : $a Arizona State University

510 2 $w r $i Prédécesseur : $a Arizona State University. $b College of Business Administration

510 2 $w r $i Successeur : $a W.P. Carey School of Business

670 $a Job growth update, Sept. 1990: $b p. de t. (College of Business, Arizona State University)

670 $a Base de données de LC, 10 janvier 1991 $b (point d’accès : Arizona State University. College of Business Administration)

670 $a Arizona blue chip economic forecast, Jan. 2004 : $b p. 4 (W.P. Carey School of Business, Arizona State University)

670 $a Arizona State University Colleges and Schools web resource, consulté le 14 juillet 2004 : $b Business education - W.P. Carey School of Business, Dean's welcome (Depuis 2003, notre nom est la W.P. Carey School of Business)

Return to Table of Contents ⮝

May I modify existing 670 fields?

Generally, existing 670 fields should not be modified, however, there are some cases where modification may be warranted:

1. To correct catalogers’ typos or clarify information that may be needlessly confusing. 2. To include additional entity attribute information (e.g., fuller form of name, date information, place of birth/death, etc.) encountered when consulting the same resource.

Return to Table of Contents ⮝

PFAN version last updated: XXXXX

PFAN version adpapted from original NACO version last updated: 2017-09-08