The Library of Congress >> Especially for Librarians and Archivists >> Standards

MARC Standards

HOME >> MARC Development >> Proposals List


DATE: December 12, 2018

NAME: Defining Source for Names and Titles in the MARC 21 Bibliographic Format

SOURCE: PCC Task Group on URIs in MARC, Program for Cooperative Cataloging (PCC)

SUMMARY: This paper proposes defining $2 for source vocabulary in the 100, 110, 111, and 130 Main Entry fields, the 240 Uniform Title field, the 700, 710, 711, 730, and 758 Added Entry fields, and the 800, 810, 811, and 830 Series Added Entry fields in the Bibliographic Format.

KEYWORDS: Subfield $2, in name fields (BD); Subfield $2, in title fields (BD); Subfield $2, in fields 100-130 (BD); Subfield $2 in field 240 (BD); Subfield $2, in fields 700-730 (BD); Subfield $2, in field 758 (BD); Subfield $2, in fields 800-830 (BD); Source of name or name-title heading (BD); Source of title heading (BD); Name and title access points (BD)

RELATED: 2018-DP07

12/12/18 – Made available to the MARC community for discussion.

01/27/19 – Results of MARC Advisory Committee discussion: Approved, with the following amendment: remove the reference to name headings in the $2 definition for fields 800, 810, and 811; only name-title access points apply for these 8XX fields.

03/29/19 - Results of MARC Steering Group review - Agreed with the MAC decision.

Proposal No. 2019-02: Defining Source for Names and Titles


This proposal makes the case for defining $2 in MARC Bibliographic fields for name and title access points (1XX, 240, 7XX, and 8XX) as a means of specifying source vocabulary. The use of $2 to record a code for source vocabulary is already widely present in the MARC Bibliographic format (see, e.g., MARC fields 336-337, 347, 65X, 751, etc.) as well as in the MARC Authority format (see, e.g., MARC Authority fields 37X). This proposal seeks to extend those provisions to name and title access point fields in MARC bibliographic records.

The ability to specify a source for names will allow the MARC format to better support the multiplicity of name vocabularies that are now coming into use, such as the Virtual International Authority File (VIAF), the International Standard Name Identifier (ISNI), the Getty Union List of Artist Names (ULAN), and the Open Research IDentifier (ORCID). Similar considerations apply to titles, although use cases are not yet as prevalent.

This proposal originates from MARC Discussion Paper 2018-DP07, which outlined an alternative approach that would reserve the 100, 110, 111, 700, 710, and 711 fields for names taken from traditional name authority files and define a separate field to carry names from non-traditional sources. The MARC Advisory Committee (MAC) rejected this approach and it is not considered further in this proposal. This proposal reframes the issues presented in 2018-DP07 in the light of comments from MAC and further discussion by the PCC URI group and its stakeholders.


In traditional MARC cataloging, the lack of a means to specify the source of a name or title heading was not particularly problematic because these headings generally conformed to a single authority file or were at least constructed according to the same rules within a single catalog. The difference between explicitly authorized headings and those merely constructed by the same rules could still create difficulties, but there was at least a presumption of consistency. In that environment, and before the advent of aggregation services such as VIAF, names needed to be distinguished within an authority file, but not between two or more sources: the question of whether Henry Sargent in one authority file represented the same person as Henry Sargent in another did not arise.

The emergence of alternative vocabularies and their use within the same pool of bibliographic data provides a strong reason for making it possible to record the source from which a particular heading is derived. In addition to serving to distinguish headings drawn from different controlled vocabularies, designating the source of a term in $2 can also facilitate the management of data from multiple sources. For example, indicating the source vocabulary could allow an application to reconcile a name against the appropriate vocabulary. This can be important for purposes of conversion to linked data, as well as for more traditional purposes such as headings maintenance. Some current generation library systems, and some authority vendors, are able to maintain various subject terms based on the vocabulary specified in the tagging. Were $2 defined as proposed for the name fields, analogous functionality could be developed for names.

This proposal defines $2 as "Source of name or name-title heading"  for 100, 110, 111, 700, 710, and 711 name access points, “Source of title heading” for 130, 240, 730, 758, and 830 title access points, and “Source of name-title heading” for 800, 810, and 811 name-title series access points. (See section 3 below.) These definitions are exclusive of other data in the field, such as relationship designators. The question of how $2 relates to identifiers given in $0 or $1 remains open. As pointed out in 2018-DP07, MARC does not in general specify how an identifier given in these subfields relates to the textual label for the entity given in the same field. For the fields under discussion we suggest that alignment of headings, identifiers, and sources be handled through best practices. These issues are elaborated in the discussion and examples below.

2.1. URIs, names and sources

Modern data management techniques have long encouraged the use of identifiers. Linked data implementations take this principle a significant step further and use globally unique URIs. It is often observed that the availability of globally unique URIs for distinct entities largely removes the need to construct unique names for systems to distinguish among various entities.

$2 would not be necessary if names in bibliographic data were universally provided with their associated URIs, and if the infrastructure existed to permit those URIs easily to be parsed or dereferenced to identify the source. However, it seems unlikely that this state of affairs will be attained within the expected lifetime of MARC. 2018-DP07 also noted that while it is often possible to identify the source by parsing the URI, URIs from different sources do not follow a consistent pattern, and indeed the path could be completely opaque to human readers. The purpose of introducing $2 is to help manage ambiguity in the transitional environment we do in fact have, where multiple sources are in use with varying degrees of compliance with linked data principles.

2.2. Context and repeatability

Both $0 and $1 are defined as repeatable throughout the MARC format. This proposal follows that precedent in order to maintain consistency with existing definitions. As is the case elsewhere in the MARC format, this can create ambiguities if there is an expectation that the textual content of the field will be consistent with the preferred label associated with a given URI. These are existing issues in MARC and are not specifically created by the introduction of $2, but they would need to be addressed in its implementation. We believe that careful attention to best practices can mitigate these difficulties. For example, adopting a best practice of not repeating URI subfields would allow an access point, its associated authority identifier, and its source to be made consistent within a given occurrence of a field. At the time of writing, best practices for $0 and $1 are under consideration by the PCC Linked Data Best Practices Task Group, and should $2 be approved it would become part of the same discussion.

2.3. Headings maintenance

A use case often cited in support of populating $0 in MARC fields is to facilitate maintenance of headings. Linked data sources not originating in library authority practice typically provide RWO URIs coded in $1 rather than $0. They complicate the picture because it is characteristic of such sources not to provide a single preferred label. ISNI, for example, records multiple names that are accorded equal status. For this reason, such sources are less suited to traditional headings maintenance applications. It should be noted that this is a generalization and exceptions to this general rule exist: CERL and ULAN are examples of sources modelled as RWO which do offer a single preferred label, while VIAF provides a preferred name (indicated as a skos:prefLabel) for each language.

It is important to note that $2 can play a critical role in headings maintenance even if the source does not provide a preferred label. By clearly identifying headings that should not be subjected to conventional or default headings maintenance routines, $2 can help avoid bad matches. For example, a system that is designed to match 1XX and 7XX fields against LCNAF can be modified to disregard occurrences of these fields that contain a $2 naming a non-LCNAF source.

2.4. Names and titles

The use case motivating this proposal is the ability to specify source vocabulary for names. However, provisions for names and titles in the MARC Bibliographic format are closely intertwined, and we received feedback from stakeholders who felt strongly that both should be addressed in the proposal. Defining $2 for names in 100, 110, 111, 700, 710, and 711 unavoidably entails defining it for titles, since these fields carry name-title constructions as well as names alone. For the sake of uniformity this proposal also defines $2 for the remaining controlled title fields: 130, 240, 730, 758, 800, 810, 811, and 830. It may be noted that $0, $1, and $2 are already defined for names and titles in the 6XX subject added entry block and adding them to 1XX and 7XX will bring these three blocks into alignment.

It should be noted that field 240 is likely to be problematical for $2 as it already is for $0 and $1. Since field 240 does not carry a complete authorized access point it cannot by itself, under traditional MARC practice, name an entity. This difficulty is not specific to this proposal, but reflects a long-standing structural problem in the MARC format, and it will need to be addressed through best practice guidelines.

2.5. Optional or mandatory

2018-DP07 raised the further question of whether $2 should be optional or mandatory. Although MARC does not provide a way to specify whether a given subfield is mandatory, this would be an important question to address in implementation. The discussion paper suggested that it would be problematical to make $2 mandatory because to do so would invalidate a large number of legacy records. It would also deny legitimate uses of MARC where name or title headings are captured without reference to a specific rule set. MAC appeared to be in general agreement that making $2 optional would allow established uses of the field to continue while permitting needed context to be provided for name data from newer sources. This proposal assumes that use of $2 will be optional.

2.6. Source codes

The 1XX and 7XX fields can contain names or titles from sources other than the authority sources listed in the MARC Name and Title Authority Source Codes. If the proposal is accepted, NDMSO may wish to consider adding to this list some of the additional codes defined in the MARC Standard Identifier Source Codes. Alternatively, $2 may simply be permitted to accommodate values from either list. As noted above, sources named in the first list are the ones that will typically support traditional authority maintenance use cases.


3.1. Define $2 for fields 100, 110, 111, 700, 710, and 711 in the Bibliographic format as follows:
(See discussion in preceding section, 2.6. Source codes)

$2 - Source of name or name-title heading (NR)
MARC code that identifies the source list from which the name or name-title heading was assigned. Code from: Name and Title Authority Source Codes or Standard Identifier Source Codes.

3.2. Define $2 for fields 130, 240, 730, 758, and 830 in the Bibliographic format as follows:

$2 - Source of title heading (NR)
MARC code that identifies the source list from which the title heading was assigned. Code from: Name and Title Authority Source Codes or Standard Identifier Source Codes.

3.3. Define $2 for fields 800, 810, and 811 in the Bibliographic format as follows:

$2 - Source of name-title heading (NR)
MARC code that identifies the source list from which the name or name-title heading was assigned. Code from: Name and Title Authority Source Codes or Standard Identifier Source Codes.

This definition excludes other data elements in the same fields such as relators.


The examples below illustrate a variety of potential scenarios, and include discussion of the issues they raise and some possible best practices that would help to address them. For purposes of illustration, they include source vocabularies drawn from the MARC Standard Identifier Source Codes as well as the MARC Name and Title Authority Source Codes.

4.1. Name without identifier

100 1# $a Sargent, Henry. $2 naf

100 1# $a Sargent, Henry. $2 ulan

The use of $2 distinguishes these names, which refer to different people. An authority control routine can be designed to match the first heading against the LC name authority file, but disregard the second. Similarly $2 can be taken into account by reconciliation services designed to provide identifiers.

(Note regarding source codes: The code for the Getty Union List of Artist Names is “ulan” in the Name and Title Authority Source Codes but “gettyulan” in the Standard Identifier Source Codes. By contrast, the German National Library’s Gemeinsame Normdatei is coded “gnd” in both lists. Some rationalization of the two code lists may be advisable.)

4.2. Name with single $0

100 1# $a Zhao, Yingzhu. $0 $2 naf

Similar to the examples given in 4.1., but with $0 also provided for the relevant vocabulary.

4.3. Name with single $1

100 0# $a John Mark Ockerbloom. $1 $2 orcid

100 0# $a Edgar Jones. $1 $2 wikidata

700 1# $a Creede, Thomas, $e printer. $1 $2 cerl

700 1# $a 朝比奈, 隆, $d 1908-2001. $1 $2 viaf

The names given here are taken from the linked data sources named in $2. Because these sources typically do not give a single preferred name, they are usually less suited than traditional authorities to supporting headings maintenance. The information within each field is nevertheless complete and consistent.

As noted in case 4.1., an authority control application can screen out headings for maintenance based on the values given in $2.

4.4. Names with multiple identifier subfields

100 1# $a Harle, John. $0 $0 (DLC)n##83005097 $2 naf

710 2# $a Museum of Fine Arts, Boston. $0 $0 $2 naf

700 0# $a Hiroyuki Iwaki. $1 $1 $2 wikidata

710 2# $a Beijing gong ye da xue. $0 $1 $2 naf

The first example shows two NAF identifiers in separate occurrences of $0. Since the two identifiers come from the same vocabulary, their presence in the same field, although perhaps redundant, is not otherwise problematical.

The remaining examples show identifiers from two different sources. Although legal by the definitions provided in this proposal, they create potential difficulties in that $2 can no longer be read as applying to all the name data (heading as well as identifiers) in the same field. In an ideal scenario the additional identifiers would be stored not in the bibliographic record, but in an authority record or other external concordance.

The second example, showing identifiers from two authority files, is arguably the most problematical of the three. The name given in the heading conforms to only one of the sources, the one named in $2, and is in conflict with the heading used in the other. A possible best practice response would be to discourage inclusion of multiple occurrences of $0.

In the third example, the identifiers come from two linked data sources rather than traditional authority files. Again, $2 indicates the source the label is taken from. However, because such sources will not generally be expected to support traditional headings maintenance routines, the conflict is arguably less critical in this case.

In the fourth example, the identifier given in $0 corresponds to the name and source given in $a and $2 respectively. Although $1 is also given, it could be disregarded for headings maintenance applications. Examples of this kind would still be able to satisfy headings maintenance use cases.

4.5. Titles (including name-titles)

130 0# $a King Kong (Motion picture : 1976) $2 naf

700 1# $a Beethoven, Ludwig van, $d 1770-1827. $t Veränderungen über einen Walzer $0 $2 naf

700 12 $i Container of (work): $a Schumann, Clara, $d 1819-1896. $t Soirées musicales. $0 $2 naf

730 0# $i Musical theatre adaptation of (work): $a Beowulf $0 $2 naf

758 ## $4 $i Is container of (work): $a Joe Turner’s Come and Gone $1 $2 wikidata

830 #0 $a Melbourne international philosophy series ; $v v. 6. $1 $2 viaf

The coding of URIs in these examples reflects the outcome of an analysis by the PCC Task Group on URIs in MARC. In the titles with a name element, coded 700, the URI refers to the work (i.e. the entity referred to by the access point as a whole), not the person. In the last example, the URI refers to the series rather the individual volume, since in MARC practice the relevant authorities are established for the series rather than volumes within the series.


Recording the source vocabulary for names and titles could be useful for reconciling a name or title with the appropriate source vocabulary during conversion to BIBFRAME and supplying the relevant URI if it is not already in the field. Specifying the source vocabulary in MARC would also allow mapping of an appropriate value to bf:Source in BIBFRAME. This would be especially useful where a URI cannot be supplied.


In the MARC 21 Bibliographic format:
Define $2 for source in name, name-title, and title access point fields as described in section 3 above.

HOME >> MARC Development >> Proposals List

The Library of Congress >> Especially for Librarians and Archivists >> Standards
Legal | External Link Disclaimer Contact Us