Changes

'''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.

'''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.

== What are the prescribed elements in the 670 field? ==

== What are the prescribed elements in the 670 field? ==

'''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.

'''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.

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

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

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

''  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''

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

 

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

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

670 $a OCLC, January 23, 2001 $b (access point: González Cuesta, Pablo Juan; usage: P.J. González Cuesta)

670 $a OCLC, January 23, 2001 $b (access point: 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.  

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.  

==How much clean-up is required in this field?==

==How much clean-up is required in this field?==

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

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

== 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)? ==

== 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)? ==

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).

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).

==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.?==

==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.?==

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.

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.

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

== 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.

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.

== 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)? ==

== 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."

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."

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

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

Example:

Example:

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

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

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

== 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.

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.

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

== 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

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

== 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? ==

== 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? ==

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

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, accessed July 14, 2004: $b Business education - W.P. Carey School of Business, Dean's welcome (As of 2003, our name is the W.P. Carey School of Business)

670      $a Arizona State University Colleges and Schools web resource, accessed July 14, 2004: $b Business education - W.P. Carey School of Business, Dean's welcome (As of 2003, our name is the W.P. Carey School of Business)

== May I modify existing 670 fields? ==

== May I modify existing 670 fields? ==

1. To correct catalogers’ typos  or clarify information that may be needlessly confusing.

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.

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.

PFAN version last updated: XXXXX

PFAN version last updated: XXXXX