The Library of Congress >> Librarians, Archivists >> Standards
MARC Standards
MARC 21 HOME >> MAC

MAC Meeting Minutes
MARC Advisory Committee


Annual Meeting
Online Meeting - June 25, 2024


MARC Steering Group Members:

Sally H. McCallum               LC                Library of Congress
Hong Cui                        LAC               Library and Archives Canada 
Thurstan Young                  BL                British Library

MAC Chair and Secretary

Catherine Gerhart, Chair        UW                University of Washington
Everett Allgood, Secretary      NYU               New York University

MARC Advisory Committee Representatives and Liaisons:

Nick Curotto                    ARLIS/NA        Virginia Museum of Fine Arts
Ethan D'Ver                     MLA             The  Juilliard School
Peter Fletcher                  SAC             University of California, Los Angeles (UCLA)
Matthew Haugen (sub.)           RBMS            Columbia University/PCC SCS
TJ Kao                          PCC             University of California, Davis
Yoko Kudo                       OLAC            University of California, Riverside
Xiaoli Ma                       VRA             University of Florida
Susan M. Moore                  MAGIRT          University of Northern Iowa
Hayley Moreno                   OCLC            OCLC
John F. Myers                   CC:DA           Union College
Kate Peck                       AALL            UC Berekeley, School of Law
Elizabeth Plantz                NLM             National Library of Medicine
Regina Reynolds                 LC/ISSN         Library of Congress
Ricardo Santos Muñoz            BNE             Biblioteca Nacional de España
John Zagas                      LC              Library of Congress

Other Attendees:

Allison Bailund                 San Diego State University
Bryan Baldus                    OCLC
Rebecca Belford                 Oberlin College
Charlene Chou                   New York University/RSC
Sherman Clarke                  Alfred University and Avery Index
Lia Contursi                    Princeton University
Andrew Dunnett                  Library and Archives Canada
Kevin Ford                      Library of Congress
Paul Frank                      Library of Congress
Basil Freeling                  University of Washington
Britannia Gammond               Northern Lights College
Sarah Hovde                     University of Maryland
Melanie Janßen                  GBV Common Library Network, Göttingen, Germany
Audra Kackley                   St. Tammany Parish Library, Louisiana
Caroline Kent                   British Library
Junghae Lee                     University of Washington
Elizabeth Lilker                National Library of Medicine
Christina Manzella              Duke University
Timothy Ryan Mendenhall         Columbia University/ALA-LOC Romanization Table Review Board
Adrian Nolte                    Axiell Germany
Iris O'Brien                    British Library
Michelle Pfost                  Pikes Peak Library District
Pat Riva                        Concordia University/CCM
Charles Riley                   Yale University
Karen Ross                      Library of Congress
Adam Schiff                     University of Washington
Naomi Shiraishi                 University of California, Berkeley
Trina Soderquist                Library of Congress
Keiko Suzuki                    The New School
Rebecca Wiederhold              Brigham Young University/SAA
Jenny Wright                    Bibliographic Data Services Ltd.
Jodi Williamschen               Library of Congress
Erica Zhang                     UCLA
Jessalyn Zoom                   Library of Congress

[Note: anyone who attended and is not listed, please inform LC/Network 
Development and MARC Standards Office.]

Preliminaries

Cate Gerhart (University of Washington, Chair) began with an explication of the online meeting protocols and voting procedures.

Introduction of members

Cate Gerhart (University of Washington, Chair) performed a roll call and asked committee members to introduce themselves. 17 MAC voting members were present.

Approval of minutes from MAC January/February 2023 meetings
The minutes of the MAC Midwinter meeting, held online on January 24-25, 2024, were approved without correction.

Fast-track proposals
Three Fast-track proposals were approved since the Midwinter meeting:

Business meeting
Scheduling of 2025 Midwinter meeting: there was a proposal to hold the next MAC meeting on Jan. 29-30, 2025, after the ALA LibLearnX event. John Myers (CC:DA) announced the pending vacancy of CC:DA liaison following the end of his current appointment next year. Matthew Haugen (Columbia University) will become the next RBMS liaison to MAC.

Library of Congress report
MARC 21 Update No. 38 was published in June 2024. ALA-BIBFRAME Update held on July 1st will report on various initiatives with Share VDE and OCLC, plus non-Latin script implementation.

NOTE:
Full pre-meeting feedback commentary of the MARC proposals and discussion papers can be accessed on the MARC Listserv at: https://listserv.loc.gov/cgi-bin/wa?A1=202406-202406&L=MARC&O=&D=&TOC=&S=

MARC PROPOSALS

 

PROPOSAL 2024-05: Adding Subfields $0 and $1 to Fields 506 and 540 in the MARC 21 Bibliographic Format
URL: https://www.loc.gov/marc/mac/2024/2024-05.html
Source: PCC Standing Committee on Standards, PCC Standing Committee on Applications
Summary: This proposal adds subfields $0 (Authority record control number or standard number) and $1 (Real World Object URI) to fields 506 (Restrictions on Access Note) and 540 (Terms Governing Use and Reproduction Note) in the MARC 21 Bibliographic Format.
Related Documents: 2024-DP04; 2020-FT02; 2020-FT03; 2021-04; 2023-FT01; 2017-06; 2017-08; 2002-10

Summary of pre-meeting comments:
Support: LC, Spain, Australia, NLM, PCC, OCLC, Music, Canada, CC:DA, ARLIS, Britain., Germany, and RBMS. CCM had an editorial suggestion to align the name of the 540 $f with the 506 by adding "Standardized terminology…" to the beginning of the name.  OLAC is concerned that the lack of a $2 to go with $f might find uncontrolled terms being put here. AALL thinks there should be a systematic look at renaming "URI" to "URL" in the $u. While NLM supports the proposal they wondered about the comment in the paper that best practices might be needed to recommend using separate MARC fields when multiple $0/$1's are needed -- is this statement meant to be included in the format, or is it just a general comment? Britain would also like to see the development of best practice guidance with regard to the application of $0 and $1 in situations where other subfields are present in the same string. Germany pointed out that not only the $0 but also $1 refer to a specific value of the standardized terminology for access restriction regardless of whether this value is in the $f. They think this relationship should also be included in the subfield definition of $1.  Germany also wondered why in the 4.2. examples the dereferenceable URIs were in $0 and not $1.

MAC Discussion:
Matthew Haugen (Columbia University/PCC SCS) introduced the proposal and agreed with the pre-meeting suggestion to align subfield $f in fields 506 and 540.

John Myers (CC:DA) asked whether MAC needed to formally amend the agreed-upon changes to subfield $f.

Cate Gerhart (University of Washington, Chair) responded yes, a motion to amend the paper would be needed in order to approve changes to $f.

Thurstan Young (BL) described additional inconsistencies in subfield $0 and $1 linkage/pairings in the formats. He asked whether there was  some way we may be able to address these holistically rather than as one-offs.

Cate Gerhart (University of Washington, Chair) asked Matthew Haugen (Columbia University/PCC SCS) if he thought there may be PCC interest (or willingness) to look more closely at the MARC 21 fields lacking subfield $0 and $1 in order to apply them more systematically and uniformly.

Matthew Haugen (Columbia University/PCC SCS) responded that the PCC Standing Committee on Applications (SCA) has reviewed the Bibliographic format amd PCC Standing Committee on Standards is responsible for the resulting papers. They concluded that they prefer to address the $0/$1 question on a field-by-field basis. SCS has another paper forthcoming for the 586 field. There were 3 of these SCS papers altogether, of which the 586 one is the last. The papers were submitted to MAC separately based on differing use cases.

MAC Action:
Proposal approved, with the amendment to change the name of field 540 subfield $f (Use and reproduction rights) to "Standardized terminology for use and reproduction rights" in order to better align with the name of field 506 subfield $f (Standardized terminology for access restriction).


MARC DISCUSSION PAPERS

 

DISCUSSION PAPER 2024-DP06: Adding Subfields $0 and $1 to Field 024 in the MARC 21 Bibliographic Format
URL: https://www.loc.gov/marc/mac/2024/2024-dp06.html
Source: PCC Standing Committee on Standards, PCC Standing Committee on Applications
Summary: This paper proposes adding subfields $0 (Authority record control number or standard number) and $1 (Real World Object URI) to field 024 (Other Standard Identifier) in the MARC 21 Bibliographic Format.
Related Documents: 2019-03; 2020-FT02; 2020-FT03; 2021-04; 2023-FT01; 2024-DP08

Summary of pre-meeting comments:
Support: CC:DA, Canada, RBMS, OLAC, Spain, Australia, NLM, PCC, OCLC, Britain. Does not support: LC. No comment: ARLIS. There were a number of suggestions for improving the paper if it comes back as a proposal. LC sees the use of the $0 and $1 in this paper as a large departure from the use in other parts of the MARC format, because this 024 identifier represents the entity described in the 245. Germany sees no use case for the $0 in this paper. LC and OCLC wonder if the 758 was considered since it already performs the role envisaged for the 024 and asked whether we want/need yet another duplicate place to encode the same data. CC:DA, Spain, MLA, NLM, PCC, OCLC, and RBMS all think the $0 and $1 should not be repeatable. Britain thinks it should follow the pattern elsewhere and be repeatable. While most agreed about expanding the $2, Britain thinks there is no need since the URI itself should indicate the source. OLAC, Germany, and MLA recommended some changes to the wording in 3.3 since what is written is confusing.  Germany also thinks that the examples need to be reviewed especially in regard to the $1 and in general more guidance on when to use $0 and $1.  Especially example 6 should be replaced with a different one since the VIAF record for this is very confusing. While MLA agrees that there is a use for the $0/1 in the 024 and that the $2 should be expanded as suggested, they have concerns about including identifiers not on the item in this field.  The music community relies on the identifiers in this field to point to a manifestation of a work, not the work itself.  They feel there is a good reason to have the 024 defined differently between the MARC 21 Authority and Bibliographic formats because the Authority 024 usually represents a Work or Expression while the Bibliographic format describes specific, individual Manifestations. NLM would like the text of future proposals to use more consistent language and perhaps always to use "identifier" instead of sometimes using number or code. OCLC also suggested a change to the second indicator so that it can also mean "not applicable". Britian also suggests that $0/1 be added to all the fields in MARC that may carry URIs instead of addressing them individually.  They wonder why the DOI in example 2 is not in an 856 field. Canada feels there is no case for fast-tracking the change.

MAC Discussion:
T. J. Kao (PCC) introduced the discussion paper and responded to pre-meeting comments, agreeing that a Bibliographic format 024 identifier must represent the Bibliographic Manifestation as opposed to Authority format 024s, which represent Work and Expression entities. He also agreed with the stated concerns over Example 6. Regarding repeatability of subfields $0 and $1 in Bibliographic 024, the authors are leaning toward non-repeatable subfields within the same 024 field, aligning with established MARC best practices.

Ethan D’Ver (MLA) expressed concern about the potential for numerous or multiple Manifestation 024 identifiers being conflated on a single Manifestation description. Music and OLAC catalogers in particular are very specific about usage of 024 field identifiers and the importance of distinguishing among numerous Manifestations and similar entity descriptions. Multiple 024 identifiers being mistakenly conflated is a troubling thought and would certainly lead to confusion among catalogers and within Discovery System displays.

Thurstan Young (BL) reminded T.J. Kao (PCC) and the authors about Britain's concerns and comments regarding 024 subfield $2. There is more of a case for amending paragraph 1 than paragraph 2 of the field definition. Besides the issue of using $2 to identify the source of a URI (which should identify itself), there is the principle of adding guidance which is better accommodated in best practice documentation rather than MARC 21.  In addition,  regarding Example 2 he queried whether the  DOI identifier should be recorded in an 856 rather than an 024 field.

Kevin Ford (LC) expressed the desire to further explore the suggested alternative of using the Bibliographic 758 (Resource Identifier) field for 2024-DP06's stated purpose. He also described how the proposed subfields $0 and $1 in this Bibliographic 024 field will be quite different from subfields $0 and $1 used elsewhere in the MARC 21 Bibliographic Format (i.e., these 024 $0/$1 are intended to identify a Manifestation resource description as a whole rather than the content of one or more subfields encoded in the same MARC field).

T.J. Kao (PCC), responding to Kevin Ford (LC), acknowledged that the Bibliographic 758 field is a legitimate option to consider and that the authors will look at Kevin's suggestions carefully.

Thurstan Young (BL) said that from an RDA perspective, Kevin Ford's (LC) point about how different these 024 subfields $0 and $1 will be from other Bibliographic format uses of subfields $0 and $1 is striking. It may represent a single Bibliographic Manifestation description in MARC combining two different RDA transcription methods. He also suggested that T.J. Kao and the authors look back at the PCC document, PCC Task Group on Linked Data Best Practices Final Report.

Matthew Haugen (Columbia University/PCC SCS) responded to  Kevin Ford's (LC) point by saying that there may be some parallels with how 024s in the MARC Authority format are being applied to represent the NAR's 1XX entity description (not the 024 field content); elsewhere in the Bibliographic format $0 and $1 identifiers align with the entities described in the field content where they are recorded (e.g., 6XX, 7XX, etc.).

The paper will return as a proposal.


DISCUSSION PAPER 2024-DP07
:
Adding Subfield $3 to Fields 508 and 511 in the MARC 21 Bibliographic Format
URL: https://www.loc.gov/marc/mac/2024/2024-dp07.html
Source: PCC Standing Committee on Standards
Summary: This paper considers adding subfield $3 (Materials specified) in fields 508 (Creation/Production Credits Note) and 511 (Participant or Performer Note) in the MARC 21 Bibliographic Format.
Related Documents: 2002-02; 2024-DP08

Summary of pre-meeting comments:
Support: LC, CC:DA, ARLIS, Canada, RBMS, OLAC, Spain, MLA, Australia, NLM, PCC, OCLC, Britain, and Germany. All agree that it can be fast-tracked.

MAC Discussion:
Junghae Lee (University of Washington) introduced the discussion paper.

With no substantive discussion given the unanimity of supportive responses, a straw poll was held and MAC agreed that Discussion Paper 2024-DP07 should be processed as Fast-Track proposal.

The paper was referred to the MARC Steering Group for final approval as a Fast-Track proposal.


DISCUSSION PAPER 2024-DP08
:
Adding Subfield $7 for Data Provenance to Additional Fields in the MARC 21 Bibliographic Format
URL: https://www.loc.gov/marc/mac/2024/2024-dp08.html
Source: PCC Standing Committee on Standards
Summary: This paper proposes adding subfield $7 (Data provenance) in fields 024 (Other Standard Identifier), 506 (Restriction Access Note), 511 (Participant or Performer Note), 540 (Terms Governing Use and Reproduction Note), and 586 (Awards Note) in the MARC 21 Bibliographic Format.
Related Documents: 2022-05; 2024-05; 2024-DP06; 2024-DP07

Summary of pre-meeting comments:
Support:  LC, CC:DA, ARLIS, RBMS, OLAC, Spain, MLA, Australia, OCLC, Britain and Germany. Qualified support: NLM and Canada and they are not convinced that the $7 is necessary in these fields. Mixed support: PCC. There was mixed support for going further than what the paper already sets out and conducting a systematic review of MARC 21 to add $7s, with NLM, Canada and Britain pointing out that this is not how the standard has been developed up to this point. MARC 21 development generally occurs based on an existing requirement or proven use case (e.g., that was set out by the German community when $7 was first defined to carry data provenance information). A wider deployment of $7 for the sole purpose of consistency would not be sufficient justification. While many agreed to fast-track this paper, NLM and Canada disagreed.

MAC Discussion:
Matthew Haugen (Columbia University/PCC SCS) introduced the discussion paper and responded to pre-meeting comments, saying that SCS did not recognize explicit "use cases" for each individual field in the original MARC proposal which established the $7 to record data provenance information, but rather felt that the paper presented a general top level statement that $7 was being requested for use in a list of fields by primarily the German community.

Thurstan Young (BL) appreciated the SCS analysis, but also noted the German community's previous use of local fields to record data provenance information in each field covered by the original papers. This was the established practice which an original deployment of $7 (and other subfields by exception) was intended to support within the MARC 21 formats themselves. Regarding the current usage of subfield $7 etc. to record data provenance, the bulk of usage is still seen within the German cataloging community rather than elsewhere. LC-PCC have drafted Metadata Guidance Documents to support an implementation of the new RDA Toolkit. However, they include no coverage of $7 to record data provenance at present. It would be encouraging to see what PCC has in mind to use existing MARC 21 provenance coding for as well as coding which has not yet been defined in the formats.  

John Myers (CC:DA) commented that even if MAC decides to advise against the "holistic approach" to provide subfield $7 across the MARC formats, then the paper still identifies needs/use case examples for the identified fields. He suggested that these specific cases might be fast-tracked.

Hong Cui (LAC) offered a reminder to MAC regarding the expense of changes to the MARC 21 standard, documentation, implementation, etc. If and when MAC considers such changes without specific, identified "use cases", these expenses are difficult to justify.

A motion to consider the discussion paper as a Fast-track proposal did not pass.

The paper may return as a proposal.


DISCUSSION PAPER 2024-DP09
:
Adding Subfields $i and $4 to Fields 368, 376, and 381 in the MARC 21 Authority and Bibliographic Formats
URL: https://www.loc.gov/marc/mac/2024/2024-dp09.html
Source: PCC Standing Committee on Standards
Summary: This paper proposes adding subfield $i (Relationship information) and subfield $4 (Relationship) in fields 368 (Other Attributes of Person or Corporate Body) and 376 (Family Information) in the MARC 21 Authority Format, and in field 381 (Other Distinguishing Characteristics of Work or Expression) in the MARC 21 Authority and Bibliographic Formats.
Related Documents: 2017-02; 2017-03; 2022-FT01

Summary of pre-meeting comments:
Support: ARLIS, RBMS, OLAC, Spain, Australia, PCC, Germany; Qualified support: LC, CC:DA, AALL, MLA, OCLC, Britain; Does not support: Canada, NLM. Suggestion to fast-track: OLAC. There was concern from a few groups that the 368, 376 and 381 $i is being used as a label rather than a relationship in the use case set out.  Also, there was concern about where the content of these subfields would come from: i.e., whether they would be from a vocabulary or the cataloger would use anything they wanted to.  Some were concerned that the labels might introduce too much information that could be harmful. One commenter pointed out that when there is only one relationship, time might be wasted by explicitly encoding it. Britain also wondered why field 387 was not included in the list set out by the paper since its coverage is similar to the 381.

MAC Discussion:
Adam Schiff (University of Washington) introduced the discussion paper and responded to pre-meeting comments by saying that MAC defined subfield $i in the MARC 21 formats to carry either a controlled phrase or free text. This decision and best practices implementation has been left to user communities applying the subfield; the examples set out by the paper were deliberately made inconsistent and reflected what was available from Wikidata and LCDGT vocabularies. In terms of MAC’s stated concerns regarding privacy, again these are best left to the user communities. Regarding Britain's suggestion to include the 387 (Representative Expression Characteristics) field within this paper, it did not come up during SCS discussions, because the subjects of the paper do not generally concern works/expressions.

Kate Peck (AALL) spoke in support of subfield $i, specifically for the 381 field. This is definitely helpful for clarifying the relationship between the described entities. For some of the other fields in this paper (i.e., 368, and 376), it does however seem that the field/subfield label itself is often sufficient.

Adam Schiff (University of Washington) asked if the paper should be fast-tracked. There was broad sentiment among MAC members that the paper should not be fast-tracked.

In response to Cate Gerhart's (University of Washington, Chair) question, Matthew Haugen (Columbia University/PCC SCS) responded that SCS had the clarification needed to revise and move this paper forward.

The paper will return as a proposal.


DISCUSSION PAPER 2024-DP10
:
Redefining Subfield $b in X00 Fields in the MARC 21 Authority and Bibliographic Formats
URL: https://www.loc.gov/marc/mac/2024/2024-dp10.html
Source: PCC Standing Committee on Standards
Summary: This paper proposes redefining subfield $b (Numeration) in X00 Fields in the MARC 21 Authority and Bibliographic Formats to allow the recording of forms of numeration other than roman numerals.
Related Documents: [None]

Summary of pre-meeting comments:
Support: CC:DA, ARLIS, Canada, RBMS, OLAC, Spain, MLA, Australia, PCC, OCLC, Britain and Germany. Qualified support: LC, NLM. CC:DA, Spain, and RBMS wondered if there was another word to use instead of "regnal". OLAC and MLA suggest adding the end of section 2 to the definition for clarity. There was some concern about costs of database cleanup and the effect on legacy data. Britain would like the paper to address scripts that read right to left and ones that are composed of Roman and non-Roman scripts. While there was some support to fast-track the paper, most indicated they would like to see a paper that addressed the points already mentioned. 

MAC Discussion:
Adam Schiff (University of Washington) introduced the discussion paper and responded to pre-meeting comments by noting that within the context of this MAC Paper, the term "regnal" refers to the numbering of official names of rulers, religious figures, etc. (e.g., queens, kings, popes).

Cate Gerhart (Univesity of Washington, Chair) asked whether MAC could find some other more inclusive term than "regnal". She also asked Adam Schiff (University of Washington) to address the Non-Roman script aspects, right to left text orientations, etc.

Adam Schiff (University of Washington) added that the NACO and Bibliographic files currently include access points containing both Roman and non-Roman scripts; this is not a new problem/challenge. Working with the PCC SCS Task Group for Evaluation of Non-Latin Script References in Name Authority Records,  there are initiatives underway to more systematically evaluate and address usage and application of X00 subfield $b.

Ethan D’Ver (MLA) expressed the view that if MAC intended to use the term "regnal" within the revised X00 subfield $b definition(s), then the specific, intended definition of "regnal" should also be included for clarification.

Adam Schiff (University of Washington) agreed with Ethan D’Ver (MLA); he offered to work with NDMSO to ensure this happened.

A motion to fast-track 2024-DP10 failed due to some of the previously-stated concerns and uncertainty.

The paper will return as a proposal.


DISCUSSION PAPER 2024-DP11
:
Tagging Transliteration Schemes and BCP 47 in Data Provenance Subfields in the MARC 21 Authority and Bibliographic Formats
URL: https://www.loc.gov/marc/mac/2024/2024-dp11.html
Source: ALA-LC Romanization Table Review Board, PCC Standing Committee on Standards, ALA Core Committee on Cataloging: Asian and African Materials.
Summary: This paper proposes the addition of category codes for use with MARC data provenance subfields to accommodate transliteration scheme codes and BCP 47 tags in the MARC 21 Authority and Bibliographic Formats.
Related Documents: 2022-05, 2021-DP10, 2021-DP06, 2016-DP26, DP109

Summary of pre-meeting comments:
Support Option 1: PCC, Germany. Support Option 2: LC. No comments: ARLIS, RBMS, Spain, Australia. Several respondents liked neither option. CC:DA would prefer a robust, flexible, source-agnostic solution. They feel both solutions would be a challenge for either human use or computer use. Canada would prefer a solution that addressed the actual needs in the authority file and bibliographic file. They also feel transliteration is not really provenance. MLA would prefer the authors look for other options. NLM found both solutions too complicated to use and the paper was unclear how the data would be used. OCLC was not clear about which option is best since there are pros and cons for each; they find both solutions confusing but do not have a suggestion for a better way to do it. Britain is not sure this is necessary at all and recommends returning to the RSC for more discussion on the best way forward; if a choice has to be made then option 2 should be avoided due to the impact it would have on the only widespread implementation of $7 to carry data provenance so far (i.e., Germany). OLAC was unsure which option to choose and generally thought more instruction on use would be needed. While PCC indicated that there was a preference for option 1, they see many problems with how it would be implemented.

MAC Discussion:
Timothy Ryan Mendenhall (Columbia University/ALA-LOC Romanization Table Review Board) introduced the discussion paper and responded to the pre-meeting concerns expressed about possible alternative options, saying that he presumed this data could/would likely be entered in an automated or programmatic way rather than encoded by hand. Libraries appear to be on a trajectory that we will soon be entering a more pronounced "hybrid environment" in regard to BIBFRAME and MARC encoding. Further, he offered that, if this data is tagged within BIBFRAME and then "lost" during any conversion to MARC, that would be unfortunate.

Regina Reynolds (LC/ISSN) commented that the ISSN Network with its many member countries are of course interested in more availability and access to numerous transliteration schemes. This is complicated, so they are interested in other options; they are also very interested in the ability to tag data provenance information at the field or subfield level.

Thurstan Young (BL) said, in terms of how $7 (and other subfields by exception) are defined to carry data provenance in the MARC formats, usage of category codes and subfield relationship codes is not mandated. The community can choose to deploy them or not based on local use cases; their utility rests on being able to support a greater degree of machine actionability than would be available without them. The existing data provenance category code definitions were established based on consultation with the  RDA RSC and German National Library to cover the latter's use cases. More specific coverage of transliteration schemes in RDA was discussed at the time and there was a suggestion that the element "scheme of nomen" might be a better fit than "source consulted"; another suggestion was that a new element be created to cover transliteration schemes. This was not resolved and feedback from the German National Library indicated that it had no plans to implement the Nomen entity as part of the new RDA Toolkit. Therefore, it was decided to use "source consulted" for designating transliteration schemes instead.  Thurstan encouraged the authors of this discussion paper to contact RSC and establish whether a new element covering transliteration schemes might still be the subject of an RDA development. He also noted that some of the examples included in the discussion paper were of a highly complex nature and appeared to rely upon subfield sequencing in order to denote a relationship between multiple subfields in the same string; this was a risky approach to take, since it relied on consistent input conventions to make it work.

Timothy Ryan Mendenhall (Columbia University/ALA-LOC Romanization Table Review Board) responded by saying that after the paper was submitted and comments came in, the authors recognized that less complex examples should have been selected because the current examples obscure the primary definition of how MARC tags transliteration schemes. They were included for the sake of discussion; in regard to aligning with RDA, MARC is not bound to RDA or any specific content standard, though it is important to take into consideration. Regarding discussion with the RSC, the authors of this paper would welcome that opportunity; because of the time-crunch when submitting this discussion paper though, there was not enough opportunity. Another concern with RDA is that the post-3R Project RDA content is configured for various implementation scenarios, including RDF. Yet BCP47 is the only scheme for RDF tagging that RSC keeps separate. Enabling a robust RDF implementation compatible with RDA would warrant an involved conversation with the RSC.

John Myers (CC:DA) echoed the ISSN Centre's comments and supported for field-level tagging of data provenance, etc. Separately, he felt somewhat concerned with the maturity of this paper. There are 17 specific questions which represents a lot to place on MAC's plate. However, he felt that the paper's authors need not apologize for the complexity of these examples – these are necessary and are welcomed by MAC. We need to be able to consider and anticipate as many difficult, complex examples as possible when considering changes to and enhancements of the MARC 21 encoding structure.

Ethan D’Ver (MLA) addressed the hybrid era (MARC-BIBFRAME/BIBFRAME-MARC) described by Timothy Ryan Mendenhall (Columbia University/ALA-LOC Romanization Table Review Board). He expressed concern that the library community is possibly being held back in regard to BIBFRAME implementation because of this insistence on aligning the two platforms.

Thurstan Young (BL) responded to Timothy Ryan Mendenhall's (Columbia University/ALA-LOC Romanization Table Review Board) point about BCP47 by saying that Britain disagreed with the premise that it represents a form of transliteration standard. BCP 47 is geared more towards informing the user whether the related value is recorded in a dialect form rather than what script it is in.

Kevin Ford (LC) responded to Thurstan Young's (BL) point by seeking clarification on some  BCP47 specifics; they included,  the letter "t" which in the examples is a marker for a special, informal extension in BCP47 to capture transliteration, etc.

Adam Schiff (University of Washington) explained that, as the paper's co-author, he had worked with some other groups looking at transliterations. He described discussions of these groups and the need to encode variant entries in non-Latin scripts based on different transliteration schemes, etc. He had heard no talk or discussions at all about using any other format than MARC to encode entity or agent descriptions (i.e., LC-NAF, NACO, etc.) and was unaware of any BIBFRAME discussions on that topic. That will clearly need to be considered and developed at some point in order to support the ongoing encoding of name identifiers and agent/entity descriptions.

Timothy Ryan Mendenhall (Columbia University/ALA-LOC Romanization Table Review Board) responded positively to Cate Gerhart's (University of Washington, Chair) question about whether the paper authors had what they needed to move forward with a proposal. He said that, based on MAC discussion and various comments, it may be wise to not deprecate existing codes. Perhaps the way to go is "big tent" including proposing new codes, for a hybrid approach (i.e., keeping old codes and also adding new codes for this identified need). There is concern and a recognized need for the MARC environment to implement BCP47, to enable the insertion of BCP47 tags in a non-manual manner. The SCS Task Group on Evaluation Guidelines for Non-Latin Script References in Name Authority Records has an urgent need. Perhaps there might be a tag for transliteration and for BCP47.

Pat Riva (Concordia University/CCM) expressed the view that it was extremely interesting to learn more about BCP47. She agreed this was the kind of standard that MARC tries to support, but that RDA does not at present and that it was best  not to try mixing up different conventions. RDA has not addressed transliteration because it is not explicit in LRM, where a transliteration involves the relation of one Nomen to another Nomen. LRMoo version 1 (available on the CIDOC website) has been approved and it contains a more detailed treatment of transliteration.

The paper will return as a proposal.



Respectfully submitted,
Everett Allgood


MARC 21 HOME >> MAC

The Library of Congress >> Librarians, Archivists >> Standards
( 11/18/2024 )
Legal | External Link Disclaimer

Contact Us