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

MARC Standards

HOME >> MARC Development >> Proposals List


MARC PROPOSAL NO. 2022-05

DATE: December 21, 2021
REVISED:

NAME: Recording Data Provenance in the MARC 21 Authority and Bibliographic Formats

SOURCE: MARC/RDA Working Group

SUMMARY: This proposal discusses the potential for encoding data provenance in the MARC 21 Formats using subfield $7 and other subfield values where $7 is no longer available.

KEYWORDS: Data Provenance (AD, BD); Metadata Statement (AD, BD); Metadata Description Set (AD, BD); RDA Toolkit Restructure and Redesign Project; RDA

RELATED: 2021-DP06; 2021-DP10

STATUS/COMMENTS:
12/21/21 – Made available to the MARC community for discussion.

01/26/22 – Results of MARC Advisory Committee discussion: Approved, with the following amendments:

05/17/22 – Results of MARC Steering Group review - Agreed with the MAC decision.

06/03/22 – Amendment to proposal - During the MARC Update No. 34 process, the MARC Steering Group proposed that $7 (Data provenance) should be added to all the 3XX fields in the Bibliographic format that align with those in the Authority format in order to keep both formats in sync.

06/14/22 – Results of MARC Steering Group review - Amendment approved.


Proposal No. 2022-05: Recording Data Provenance

1. BACKGROUND

The new RDA Toolkit glossary defines data provenance as: "Information about the metadata recorded in an element or set of elements. Metadata about metadata, or metametadata." The Toolkit guidance chapter on data provenance explains that: "This information can be used to infer the context and quality of the metadata". Data provenance information, as conceived by RDA, can already be recorded in MARC 21 at the record, field and subfield level using a variety of elements. However, coverage at the field and subfield level is often sparse and uneven. This paper sets out the parameters of data provenance in RDA and its current coverage in MARC 21. It goes on to make a case for expanding MARC 21's accommodation of data provenance in order to better support established and emerging applications. Finally, it puts forward a method of using subfield $7 (and subfield $5 or $z where $7 is no longer available) as a means of encoding data provenance at a granular level in the MARC Authority and Bibliographic formats. This could be used in combination with two sets of coded values in order to designate the category of data provenance and subfield within the same string to which data provenance relates. The approach described above was one of several which were set out in the previous MARC discussion papers 2021-DP06 and 2021-DP10. Other options from 2021-DP06 and 2021-DP10 which met with less favor in the community at the 2021 Midwinter and Summer MARC Advisory Committee meetings are not being developed further at this time. RDA does not make the recording of data provenance information a required aspect of resource description.

2. DISCUSSION

2.1. RDA and Data Provenance

Data provenance information can be recorded in various ways using the current RDA Toolkit. It offers a number of elements, levels of granularity and recording methods for doing so.

2.1.1. RDA and data provenance elements

RDA supports the recording of data provenance information using a range of different elements. Some elements can only be used for the purpose of recording data provenance information, while others can be used for this and other purposes. The following elements can be used exclusively to record data provenance information and may, collectively, be referred to as "meta-elements":

The following elements can be used exclusively to record data provenance information for Nomen entity-related elements:

The following elements can be used to record data provenance information in addition to other aspects of resource description. In each case the circumstance under which an element may be used for recording data provenance is given in parentheses:

These 30 elements or a selection of them could be accommodated at a greater level of granularity in MARC 21.

*More granular refinements of each element are available if there is a requirement to subcategorize by person, collective agent, family or corporate body.

2.1.2. RDA and data provenance granularity

Data provenance information can be recorded using different levels of granularity in RDA. It does this by specifying two subcategories of metadata work: metadata statements and metadata description sets.

metadata statement is defined in the glossary as:

"A piece of metadata that assigns a value to an RDA element that describes an individual instance of an RDA entity."

In a MARC 21 context, examples of metadata statements include the values recorded in individual subfields.

metadata description set is defined in the glossary as:

"One or more metadata statements that describe and relate individual instances of one or more RDA entities."

In a MARC 21 context, examples of metadata description sets include the values recorded collectively in records and in the fields belonging to those records which are composed of more than one subfield.

2.1.3. RDA and data provenance recording methods

Besides providing a range of elements and degrees of specificity for recording data provenance information, RDA also offers several methods with which to record it. These are listed below:

2.2. RDA Data Provenance Information in MARC 21

At the present time, MARC 21 can be used to record all of the RDA elements previously mentioned, using varying degrees of granularity and selective recording methods. Some examples are given below. In each case, the RDA element label, granularity and recording method of the data provenance information is provided for context.

Example 1

005 20190129073611.0

Element : date of publication (recording a timespan when metadata are published)
Granularity : metadata description set (any MARC 21 format)
Recording method : structured

Example 2

667 ## $a Machine –derived non-Latin script reference project.

Element : context of use
Granularity : metadata description set (MARC 21 authority format)
Recording method : unstructured

Example 3

382 0# $a clarinet $n 1 $a piano $n 1 $s 2 $2 lcmpt

Element : source consulted (recording a content standard used for metadata)
Granularity : metadata description set (MARC 21 bibliographic and authority formats)
Recording method : identifier

Example 4

338 ## $a volume $2 rdact

Element : source consulted (recording a content standard used for metadata)
Granularity : metadata statement (MARC 21 bibliographic and holdings formats)
Recording method : identifier

2.2.1. Benefits and Challenges of Recording Data in MARC 21

Recording data provenance information in a resource description context is beneficial from the perspectives of managing the metadata creation process and supporting end users. It serves library staff engaged in collection-related cataloging activities as well as library patrons whose goal it is to access holdings. Apart from these more traditional functions, data provenance information also supports the development of emerging products and services which are based on the selective transformation of cataloging metadata into non-MARC formats.

More value can be derived from data provenance information when it is recorded to a greater rather than lesser degree of granularity. Specificity reduces the need for interpretation on the part of a human user. It also increases the machine actionability of data provenance information. Conversely, recording data provenance information at the record or field rather than at the subfield level can result in its being of limited value from both perspectives. The MARC 21 formats currently provide some coverage of data provenance information at the field and subfield as well as record level. However, the field and subfield level coverage of data provenance in the formats is piecemeal across the formats.

It may be considered that expanding the coverage of data provenance information in the MARC formats will result in a more labor intensive process of resource description. However, this could be minimized at the start of the cataloging process by using templates which prepopulate data provenance information in MARC records. In cases where records are derived from an external source and enhanced locally, then data provenance information could be added using macros which enter standardized strings of metadata.

It may also be considered that the full range of data provenance elements and recording methods available for recording them are surplus to any single, local need. However, it should be noted that the recording of data provenance information is not a requirement in RDA. Rather, RDA sets out the practical benefits of recording data provenance information and a variety of options for doing so. One cataloging agency may choose to record a specific type or types of data provenance information, while another chooses to record others. The key requirement is that the data which they share remains interoperable.

Further analysis and examples which demonstrate the issues set out above can be found in sections 2.2.1 – 2.2.4 of the preceding Discussion Paper 2021-DP10.

2.2.2. Community Preferences Regarding the Expanded Coverage of Data Provenance in MARC 21

The case made by Discussion Paper 2021-DP10 for expanding MARC 21's coverage of data provenance met with various feedback from the community. Concerns were raised with regard to the potential disruption, unreliability and maintenance costs of such a change if it were to be implemented by one section of the community and not by others. Equally, the suggestion has been made that data provenance information is local in nature and therefore of questionable value to a wider audience. Questions have also been raised in terms of the scope for additional coverage of data provenance information in MARC 21. A view has been expressed that only specific categories of data provenance information should be encoded to an enhanced level and only once their necessity has been justified. In addition, it has been noted that not every data provenance related element in RDA should be expressed in every MARC 21 field. The element "undifferentiated name indicator" is a case in point since its relevance is specific to Nomen entities.

While the caution noted above has arisen from several quarters, the German MARC 21 community has expressed considerable enthusiasm for a more comprehensive approach to data provenance in the Authority and Bibliographic formats, although it does not have a current use case which extends to the Classification, Community or Holdings formats. The German community already encodes several categories of data provenance information at the granular level supported by RDA, using established routines for its generation and maintenance in authority and bibliographic records. Examples of these elements include "author agent", "context of use", "language of expression", "note on metadata work", "related manifestation of work", "related timespan of work" and "script". There is also a long standing, currently unimplemented desire on the part of the German community to record the transliteration standard which has been used during the creation of a Latin script string in the Bibliographic format. From an RDA data provenance perspective, such a standard could be characterized as a "source consulted". In addition, the German use case for further developing field 856 (Electronic Location and Access)  in the Authority and Bibliographic formats includes a preference to record supplying agency information analogous to that already recorded in subfield $q of fields 506 (Restrictions on Access Note) and 540 (Terms Governing Use and Reproduction Note). From an RDA perspective, such information could be characterized as an "author agent".

Thus far, the German community has used used the following set of fields to record data provenance information at a granular level:

Table 1

RDA Element

MARC Field / Subfield / Format

author agent

024 / 034 / 043 / 065 / 3XX / 4XX / 5XX / 670 / 672 / 675 / 677 / 678 / 680 $9 (Local - Authority format) ;

883 / $8 (Field link and sequence number - Bibliographic format)

context of use

024 / 034 / 043 / 065 / 3XX / 4XX / 5XX / 670 / 672 / 675 / 677 / 678 / 680 / 7XX $9 (Local - Authority format)

language of expression

4XX / 7XX $9 (Local - Authority format)

note on metadata work

024 / 034 / 1XX / 260 / 375 / 4XX / 5XX / 7XX $9 (Local - Authority format)

related manifestation of work

883 / $8 (Field link and sequence number - Bibliographic format)

related timespan of work

083 / 5XX $9 (Local - Authority format) ;

883 / $8 (Field link and sequence number - Bibliographic format)

script

4XX / 7XX $9 (Local - Authority format) ;

880 / $6 (Linkage - Bibliographic format)

However, this has not been by choice, but rather because no alternative has been available. Moreover, no solution (either using local coding or linkage) has yet been found to address the issues of recording transliteration standards or supplying agencies for electronic location and access. Henceforth, the German community would like to explore the opportunities for encoding such data provenance information in a way that supports the wider cataloging community's goals as well as its own and in a way which avoids the use of subfields $6, $8 and $9.

One application which may serve the wider community is the creation of data provenance information to support linked data initiatives. For instance, in the process of replicating the GND in a Wikibase environment, the German community has found that metametadata is key in supporting the usage of metadata and forms an important, contextual layer around it.

As regards minimizing the potential disruption associated with expanding the coverage of data provenance, the German community advocates an approach of using subfield $7 and other subfields by exception where $7 has already been defined in the formats (hereafter referred to as “$7+” for short). If the wider community considers that such information is surplus or runs counter to its needs, then this could be stripped out on import to local systems. Alternatively, the related MARC 21 changes could simply not be configured at a local level unless and until they are considered beneficial.

As the most immediate implementer of MARC 21 enhancements around data provenance, the German community expressed a preference for using $7+ over the other two options outlined in Discussion Paper 2021-DP10. Expanding the use of field 883 (Metadata Provenance) was considered impractical for reasons of reliably using subfield $8 for linking purposes at scale. The German community has found this to be particularly difficult in an environment where record match and merge processes render field sequencing unstable. Equally, the usage of non-standard subfield delimiters was considered undesirable. This was due to the scale of disruption such an approach would likely cause to the existing MARC 21 formats. Such a move would require amendments to the MARC 21 Formats : Background and Principles and may be out of scope for configuration within existing MARC 21 based library management systems. A series of straw polls were conducted at the Summer 2021 MAC meetings based on the options discussed in 2021-DP10 and approval was given that the $7+ approach should be further developed for a follow up paper.

The following table lists those Authority format fields and field ranges in which the German community would welcome the deployment of a $7+ solution to support the recording of data provenance information as it relates to RDA:

Table 2

Tag

Label

024 

Other Standard Identifier

034 

Coded Cartographic Mathematical Data

043 

Geographic Area Code

065 

Other Classification Number

1XX

Heading Information Fields

260

Complex See Reference - Subject

3XX 

Heading Information Fields

4XX 

See From Tracing Fields

5XX 

See Also From Tracing Fields

670 

Source Data Found

672 

Title Related to the Entity

675 

Source Data Not Found

677 

Definition

678 

Biographical or Historical Data

680 

Public General Note 

7XX 

Heading Linking Entry Fields

856

Electronic Location and Access

The following table lists those Bibliographic format fields and field ranges in which the German community would welcome the deployment of a $7+ solution to support the recording of data provenance information as it relates to RDA:

Table 3

Tag

Label

041

Language Code

082

Dewey Decimal Classification Number

083

Additional Dewey Decimal Classification Number

084

Other Classification Number

1XX

Main Entry Fields

210

Abbreviated Title

240

Uniform Title

245

Title Statement

246

Varying Form of Title

247

Former Title

250

Edition Statement

255

Cartographic Mathematical Data

256

Computer File Characteristics

264

Production, Publication, Distribution, Manufacture, and

Copyright Notice

300

Physical Description

385

Audience Characteristics

490

Series Statement

500

General Note

501

With Note

502

Dissertation Note

505

Formatted Contents Note

508

Creation/Production Credits Note

510

Citation/References Note

515

Numbering Peculiarities Note

518

Date/Time and Place of an Event Note

520

Summary, etc.

533

Reproduction Note

546

Language Note

550

Issuing Body Note

555

Cumulative Index/Finding Aids Note

583

Action Note

600

Subject Added Entry - Personal Name

610

Subject Added Entry - Corporate Name

611

Subject Added Entry - Meeting Name

630

Subject Added Entry - Uniform Title

648

Subject Added Entry - Chronological Term

650

Subject Added Entry - Topical Term

651

Subject Added Entry - Geographic Name

653

Index Term - Uncontrolled

655

Index Term - Genre/Form

700

Added Entry - Personal Name

710

Added Entry - Corporate Name

711

Added Entry - Meeting Name

751

Added Entry - Geographic Name

76X-78X

Linking Entries

80X-83X

Series Added Entry Fields

856

Electronic Location and Access

2.2.3. Encoding Data Provenance in the MARC 21 Authority and Bibliographic Formats Using Subfield $7 and Other Subfields by Exception ($7+)

Although no lower case alphabetic or numeric character remains wholly undefined in the MARC 21 formats, there are some characters which have rarely been used up until this point. Foremost amongst these is subfield $7 which has hitherto only been deployed in two fields belonging to the Authority format and only twenty-two fields belonging to the Bibliographic format. In both cases alternative subfield characters are still free for use in fields where $7 has already been defined. The use of different subfields to record equivalent values is generally avoided in the MARC 21 formats, but is not entirely without precedent. For example, subfields $e and $j in the Bibliographic format may both carry a value for a relator term in circumstances where that term describes the relationship between a name and a work.

In the MARC 21 Authority Format no fields apart from the following currently contain subfield $7:

856 (Electronic Location and Access)
Note: Subfields $e, $0, $1, $4 and $5 are still available for use and have not been previously made obsolete.

880 (Alternate Graphic Representation)
Note: With the exception of subfield $6 (Linkage), 880 subfielding follows that in linked fields, so this tag is excluded from further analysis.

In the MARC 21 Bibliographic Format, no fields apart from the following currently contain subfield $7:

533 (Reproduction Note)
Note: Subfields $g-$l, $0, $1, $2, $4 and $5 are still available for use.

760-787 (Linking Entries)
Note: Subfields $l (lowercase ell), $0, $1, $2, $3 and $5 are still available for use.

800-830 (Series Added Entries)
Note: Subfields $i, $y and $z are still available for use.

856 (Electronic Location and Access)
Note: Subfields $e, $0, $1, $4 and $5 are still available for use and have not been previously made obsolete.

880 (Alternate Graphic Representation)
Note: With the exception of subfield $6 (Linkage), 880 subfielding follows that in linked fields, so this tag is excluded from further analysis.

In order to reduce the variability of coding to a minimum, the same subfield could be used to record data provenance information in the Authority and Bibliographic format field 856 as well the Bibliographic field 533 and range 760-787: subfield $5 is recommended for this purpose. Again, in order to reduce variability, the same subfield could be used to record data provenance information in the Bibliographic format range 800-830: subfield $z is recommended for this purpose. For all other fields which the German community has listed as being desirable locations to record data provenance information, it is recommended that subfield $7 be used.

2.2.4. Using $7+ in Combination with Coded Values

While the definition $7+ alone allows for the recording of data provenance values at the field level, it does not allow for a categorization of the data provenance being recorded. Nor does it allow for unambiguous linkage if the field in question is composed of more than one other subfield. It is proposed that an internal structure is defined for use in the $7+ context so that both of these issues can be addressed to support machine actionability. Such a structure would use coded values and punctuation to create a standardized syntax for recording a category of data provenance, a subfield relationship for data provenance and a value associated with that category and relationship as the following modeled example demonstrates:

100    1# $a Zweig, Stefan, $d 1881-1942
400    1# $a צוויג , סטפן , $d 1881-1942 $7 (dpes/dpsfa) Hebrew

Key to subfield $7 internal structure

Data provenance category: script, i.e. “dpes”
Data provenance relationship: subfield $a, i.e. “dpsfa”  
Data provenance value: “Hebrew”

The approach set out above is analogous to that which is already used in subfield $0 where it is defined as "Authority record control number or standard number" in the MARC 21 formats:

"Subfield $0 contains the system control number of the related authority or classification record, or a standard identifier. These identifiers may be in the form of text or a Uniform Resource Identifier (URI). If the identifier is text, the control number or identifier is preceded by the appropriate MARC Organization code (for a related authority record) or the Standard Identifier source code (for a standard identifier scheme), enclosed in parentheses. When the identifier is given in the form of a Web retrieval protocol, e.g., HTTP URI, no preceding parenthetical is used."
cf. e.g., MARC 21 Bibliographic, Appendix A-Control Subfields, (https://www.loc.gov/marc/bibliographic/ecbdcntf.html).

Code lists for the data provenance category and data provenance relationship would need to be established and maintained by NDMSO at the Library of Congress.

A list of data provenance category codes is modeled below, based on the eight elements which the German community has so far established a requirement for recording at a granular level:

dpeaa           -         Data provenance element author agent
dpecou         -         Data provenance element context of use
dpeloe          -         Data provenance element language of expression
dpenmw       -         Data provenance element note on metadata work
dpermw        -         Data provenance element related manifestation of work     
dpertow        -         Data provenance element related timespan of work
dpes              -         Data provenance element script
dpesc            -         Data provenance element source consulted

These codes could be supplemented to over time as and when a need arises to flag the presence of additional data provenance elements. Possible use cases for the addition of new codes could include a community's decision to describe the following:

A list of data provenance subfield relationship codes is modeled below:

dpsfa            -         Data provenance relates to subfield $a
dpsfb            -         Data provenance relates to subfield $b
dpsfc            -         Data provenance relates to subfield $c
dpsfd            -         Data provenance relates to subfield $d
dpsfe            -         Data provenance relates to subfield $e
dpsff             -         Data provenance relates to subfield $f
dpsfg            -         Data provenance relates to subfield $g
dpsfh            -         Data provenance relates to subfield $h
dpsfi             -         Data provenance relates to subfield $i
dpsfj             -         Data provenance relates to subfield $j
dpsfk            -         Data provenance relates to subfield $k
dpsfl             -         Data provenance relates to subfield $l
dpsfm           -         Data provenance relates to subfield $m
dpsfn            -         Data provenance relates to subfield $n
dpsfo            -         Data provenance relates to subfield $o
dpsfp            -         Data provenance relates to subfield $p
dpsfq            -         Data provenance relates to subfield $q
dpsfr             -         Data provenance relates to subfield $r
dpsfs            -         Data provenance relates to subfield $s
dpsft             -         Data provenance relates to subfield $t
dpsfu            -         Data provenance relates to subfield $u
dpsfv            -         Data provenance relates to subfield $v
dpsfw           -         Data provenance relates to subfield $w
dpsfx            -         Data provenance relates to subfield $x
dpsfy            -         Data provenance relates to subfield $y
dpsfz            -         Data provenance relates to subfield $z
dpsf0            -         Data provenance relates to subfield $0
dpsf1            -         Data provenance relates to subfield $1
dpsf2            -         Data provenance relates to subfield $2
dpsf3            -         Data provenance relates to subfield $3
dpsf4            -         Data provenance relates to subfield $4
dpsf5            -         Data provenance relates to subfield $5
dpsf6            -         Data provenance relates to subfield $6
dpsf7            -         Data provenance relates to subfield $7
dpsf8            -         Data provenance relates to subfield $8

Depending on the application, a value of data provenance may be recorded with or without codes which specify the category or subfield in a preceding string to which it relates. The omission of these codes may, on the one hand, allow for a greater flexibility of use. On the other hand, their omission may also result in a lesser degree of machine actionability and greater need for interpretation by the human user.

3. PROPOSED CHANGES 

3.1. Define Subfields for Data Provenance


3.1.1. Subfield $7

In the MARC 21 Authority and Bibliographic Formats define $7 in fields listed in Tables 2 and 3 (as discussed in Section 2.2.2.) with the exception of:

Define $7 as follows:

$7 - Data provenance
Subfield $7 contains a data provenance value for a related subfield or related subfields in the same subfield string. If the value is preceded by a MARC Data Provenance Category code or a MARC Data Provenance Relationship code, then this is enclosed by parentheses. If the value is preceded by both a MARC Data Provenance Category code and a MARC Data Provenance Relationship code, then these are separated by a forward slash and enclosed by parentheses. A MARC Data Provenance Category code precedes a MARC Data Provenance Relationship code if both are recorded.

3.1.2. Subfield $5

Define $5 in the following fields:

Define subfield $5 as folllows:

$5 - Data provenance
Subfield $5 contains a data provenance value for a related subfield or related subfields in the same subfield string. If the value is preceded by a MARC Data Provenance Category code or MARC Data Provenance Relationship code, then  this is enclosed by parentheses. If the value is preceded by both a MARC Data Provenance Category code and a MARC Data Provenance Relationship code, then these are separated by a forward slash and enclosed by parentheses. A MARC Data Provenance Category code precedes a MARC Data Provenance Relationship code if both are recorded.

3.1.3. Subfield $z

In the MARC 21 Bibliographic Format define $z in fields 800-830 (Series Added Entry Fields), as follows:

$z - Data provenance
Subfield $z contains a data provenance value for a related subfield or related subfields in the same subfield string. If the value is preceded by a MARC Data Provenance Category code or MARC Data Provenance Relationship code, then this is enclosed by parentheses. If the value is preceded by both a MARC Data Provenance Category code and a MARC Data Provenance Relationship code, then these are separated by a forward slash and enclosed by parentheses. A MARC Data Provenance Category code precedes a MARC Data Provenance Relationship code if both are recorded.

3.2. Define Code Lists for Data Provenance

On the Library of Congress website establish code lists for data provenance categories and data provenance subfield relationships as listed in discussion Section 2.2.4.

4. EXAMPLES

The following examples model the changes proposed above. These are intended to be illustrative rather than prescriptive. Additional notes are supplied in order to provide context.

4.1 Authority Format


4.1.1.

151 ## $a Schweiz
451 ## $a Switzerland $5 CH-000001-5 $7 (dpeloe) eng

Additional Notes:

Field 451 models data provenance element "language of expression" with value "eng" in subfield $7 relating to another subfield in the same string.

4.1.2.

130 #0 $a Manessische Handschrift
430 #0 $a Codex Manesse
430 #0 $a Handschrift  $g Universitätsbibliothek Heidelberg $n Cod. Pal.germ. 848 $5 DE-2489 $7 (dpecou) Manuscript cataloging

Additional Notes:

Field 430/2 models data provenance element "context of use" with value "Manuscript cataloging" in subfield $7 relating to other subfields in the same string.

4.1.3.

111 2# $a Internationale Musikfestwochen $d 1998 $c Luzern
411 2# $a International Festival of Music $d 1998 $c Luzern $5 CH-000001-5 $7 (dpeloe/dpsfa) eng $7 (dpecou/dpsfa) Alternative preferred name
 
Additional Notes:

Field 411 models:

  1. data provenance element "language of expression" with value "eng" in subfield $7 relating to subfield $a in the same string.
  2. data provenance element "context of use" with value "Alternative preferred name" in subfield $7 relating to subfield $a in the same string.

4.1.4.

100 1# $a Reyff, Hans Franz $d 1614-1673
400 1# $a Reiff, Hans Franz $d 1614-1673 $7 (dpeloe/dpsfa) ger $7 (dpenmw/dpsfa) Thieme-Becker

Additional Notes:

Field 400 models:

  1. data provenance element "language of expression" with value "ger" in subfield $7 relating to subfield $a in the same string.
  2. data provenance element "note on metadata work" with value "Thieme-Becker" in subfield $7 relating to subfield $a in the same string.

4.1.5.

100 1# $a Zweig, Stefan $d 1881-1942
400 1# $a צוויג , סטפן , $d 1881-1942 $7 (dpes/dpsfa) Hebr
400 1# $a Цвейг, Стефан, $d 1881-1942 $7 (dpes/dpsfa) Cyrl $7 (dpeloe/dpsfa) rus  
551 ## $0 (DE-101)040221539 $0 (DE-588)4022153-2 $a Großbritannien $4 ortx $wr $i Exil $7 (dpertow/dpsfi) 1934

Additional Notes:

Field 400/1 models data provenance element "script" with value "Hebr" in subfield $7 relating to subfield $a in the same string.

Field 400/2 models:

  1. data provenance element "script" with value "Cyrl" in subfield $7 relating to subfield $a in the same string.
  2. data provenance element "language of expression" with code "rus" relating to subfield $a in the same string.

Field 551 models data provenance element "related timespan of work" with value "1934" relating to subfield $i in the same string.

4.2 Bibliographic Format


4.2.1
.

245 10 $a Asʾila ḥaula 'l-marʾa wa-'l-masǧid $b fī ḍauʾ nuṣūṣ aš-šarīʿa wa-maq ṣidih $c d. sir ʿAuda $7 (dpesc) DIN 31635:2011

Additional Notes:
Field 245 models data provenance element "source consulted" with value for transliteration standard "DIN 31635:2011" in subfield $7 relating to other subfields in the same string.

4.2.2.

700 1# $0 (DE-588)103331727$0(DE-603)138744165 $a Michajlova, Natalʹja I. $4 aut $7 (dpes/dpsfa) Latn

Additional Notes:
Field 700 models data provenance element "script" with value "Latn" in subfield $7 relating to subfield $a in the same string.

4.2.3.

600 07 $8 5\p $0 (DE-588)118650130 $0 https://d-nb.info/gnd/118650130 $0(DE-101)118650130 $a Aristoteles $d v384-v322 $2 gnd $7 (dpermw) aep-gnd $7 https://d-nb.info/provenance/plan#aep-gnd

Additional Notes:

Field 600 models:

  1. data provenance element "related manifestation of work" with value "aep-gnd" in subfield $7 relating to other subfields in the same string.
  2. data provenance element with value https://d-nb.info/provenance/plan#aep-gnd in subfield $7 relating to other subfields in the same string.

4.2.4.

856 40 $u http://nbn-resolving.de/urn:nbn:de:bsz:25-freidok-146567 $x Resolving-System $5 (dpeaa) DE-101

Additional Notes:
Field 856 models data provenance element "author agent" with value "DE-101" in subfield $5 relating to other subfields in the same string.

5. BIBFRAME DISCUSSION

BIBFRAME allows the recording of provenance-type information and when the change to MARC is determined, further analysis of any needed changes would be made.

6. SUMMARY OF PROPOSED CHANGES

6.1. Define the following subfields for data provenance:

6.2. Define code lists for data provenance as described in Sections 2.2.4. and 3.2.


HOME >> MARC Development >> Proposals List

The Library of Congress >> Especially for Librarians and Archivists >> Standards
(05/17/2022)
Legal | External Link Disclaimer Contact Us