The Library of Congress >> Especially for Librarians and Archivists >> Standards
HOME >> MARC Development >> Proposals List
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
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.
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.
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.
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.
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.
A 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.
A 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.
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:
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
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.
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:
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:
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 |
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.
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) HebrewKey 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.
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.
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.
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.
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.
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.1.
151 ## $a Schweiz
451 ## $a Switzerland $5 CH-000001-5 $7 (dpeloe) engAdditional 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 catalogingAdditional 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:
- data provenance element "language of expression" with value "eng" in subfield $7 relating to subfield $a in the same string.
- 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-BeckerAdditional Notes:
Field 400 models:
- data provenance element "language of expression" with value "ger" in subfield $7 relating to subfield $a in the same string.
- 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) 1934Additional 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:
- data provenance element "script" with value "Cyrl" in subfield $7 relating to subfield $a in the same string.
- 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.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:
- data provenance element "related manifestation of work" with value "aep-gnd" in subfield $7 relating to other subfields in the same string.
- 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.
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.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 |