Music Library Association Cataloging and Metadata Committee Encoding Standards Subcommittee Business Meeting 2022
Thursday, February 24, 2022 1:30-2:55 EST (via Zoom)
Agenda: https://docs.google.com/document/d/12uSN0PPjIiVtDkYMvfRM4BAxqrgIsuKH/edit
Members in attendance: Karen Peters (Chair), Jim Alberts, Ethan D’Ver, Chelsea Hoover, Rahni Kennedy, Anna Alfeld LoPrete, Jeff Lyon, Tomoko Shibuya, Amy Strickland, Laura Thompson, Damian Iseminger (LC representative), Jay Weitz (OCLC representative).
The Chair would like to express her gratitude to Rahni Kennedy for monitoring the chat during the meeting, and to Chelsea Hoover for serving as backup monitor
1) Welcome and introductions; adjustments to agenda
The Chair welcomed attendees to the meeting and asked Subcommittee members to introduce themselves. After introductions, the Chair noted that the agenda might have to be adjusted: due to unforeseen circumstances, Damian Iseminger might not be available to give the LC Liaison Report at the time currently scheduled.
2) ESS Chair’s report (Peters)
The Chair briefly pointed out the links in the agenda to her reports on the June 2021 and January 2022 MARC Advisory Committee (MAC) Meetings (in lieu of the usual ALA reports); acknowledged new (since the last meeting) Subcommittee members Anna LoPrete and Laura Thompson; thanked outgoing Subcommittee members Chelsea Hoover, Tomoko Shibuya, and Amy Strickland for their past service; and issued a call for applications from new members. She also pointed out that the upcoming year will be her last as Chair and that CMC would soon be looking for her successor. Anybody interested in possibly succeeding her as ESS Chair should feel free to get in touch with her to discuss further.
3) Updates on MARC development this year (Peters)
The Chair briefly outlined the mechanism of making changes to the MARC encoding standard, as well as ESS’s and her involvement in the process. She then described a few changes of particular interest to MLA members that were made during the previous year:
i. Proposal No. 2021-14 and the related Proposal No. 2021-15, authored by NDMSO (Network Development and MARC Standards Office, Library of Congress). The point of 2021-14 was to add a new subfield ($j) to MARC field 344 (Sound Characteristics) for the encoding of original sound recording capture and storage technique. While this information is already encoded in byte 13 of field 007 (Physical Description Fixed Fields—Sound Recordings), NDMSO was looking for a more linked data-friendly encoding solution—one that would enable conversion of this information between MARC and BIBFRAME and contribute to the goal of eliminating the MARC 007 field entirely. In considering this change, commenters noticed that the labels used for the techniques were inconsistent—some reflected both capture and storage, while others reflected only one of the two—and so the labels were modified to reflect both as needed, with some definitions rewritten to improve clarity. This work was done with significant input from MLA and a great deal of help from Jay Weitz, as well as advice from one of the Chair’s sound engineering colleagues at the National Audiovisual Conservation Center. The two proposals were approved at the annual MAC meetings in June 2021, and subsequently incorporated into MARC (Update 33, November 2021).
ii. Proposal No. 2022-01, authored by OCLC. This proposal redefined MARC 340 (Physical Medium) subfield $f (formerly Production rate/ratio) to limit its use to microforms. Previously, $f was used to record playing speed for sound recordings. Subsequently, field 344 (Sound Characteristics) subfield $c (Playing speed) and field 347 (Digital File Characteristics) subfield $f (Encoded bitrate) were added to MARC specifically for this purpose. MARC 340 $f was similarly used at one time by other cataloging communities working with other formats, but MARC has since been modified to encode that information more specifically as well. The results of this proposal, which was approved at the MAC Midwinter meetings in January 2022, will appear in MARC Update 34 in mid-2022.
iii. Discussion Paper No. 2022-DP04, authored by the PCC Standing Committee on Standards, and converted to a fast-track proposal that was approved at the 2022 MAC Midwinter meetings, added subfields $i (Relationship information) and $4 (Relationship) to field 373 (Associated Group). This change permits relationships with entities whose names have not been established in the National Authority File to be encoded in authority records, much as is currently done in 5XX (See Also from Tracing) fields for names that have been established in the NAF. The results of this proposal will also appear in MARC Update 34 later this year.
iv. Proposal No. 2022-04, “Recording Representative Expressions in the MARC 21 Authority and Bibliographic Formats,” authored by the MARC/RDA Working Group (of which the ESS Chair is a member, representing the interests of the music community). The proposal was preceded by MARC Discussion Paper No. 2021-DP12, which presented a number of options for the recording of representative expression elements in MARC. Note that much of that sort of information could not at be encoded in MARC at that time; but for the information that could, concern was expressed that there might be no way to modify MARC to accommodate the addition of the new representative expression information without defining one or more new fields.
From CMC’s perspective, certain representative expression elements are not new information as such, but rather represent a recharacterization of attributes that we have been encoding for some time already. Thus, adding representative expression indicators to the relevant fields for use in recoding this soon-to-be recharacterized information would be preferable to re-encoding it in one or more different MARC fields. After consideration of the possible options presented in MARC Discussion Paper 2021-DP12, however, the broader MARC community expressed a preference for creating an entirely new field in which to encode all representative expression information. In consideration of the music community’s preferences, however, exceptions for Medium of Performance and Key were permitted.
The result, Proposal No. 2022-04, defined a new field, MARC 387 (Representative Expression Characteristics), made up of one linkable subfield for each representative expression element other than Medium of Performance and Key. The proposal also added a new first indicator 2 to fields 382 (Medium of Performance) and 384 (Key) accommodate those representative expression elements. This is particularly important in the case field 382, as the manner in which we currently encode medium of performance in MARC could rarely, if ever, be reduced to a single subfield.
We will still need to determine how to make use of the new field 387, as it includes such elements as date, date and place of capture, duration, and language, but we have some time yet in which to do this: while 2022-04 was approved at the 2022 MAC Midwinter Meetings and will soon be made available via MARC Update 34, we will not need to encode representative expression elements before adoption of Official RDA (currently, no sooner than October 2022).
v. Discussion Paper No. 2022-DP05, authored by the PCC Standing Committee on Standards, considers how subject relationships of works and expressions might be encoded in the Authority format. When presented at the 2022 Midwinter MAC meetings, however, Library of Congress representation indicated LC’s rejection of any such changes in the following statement. Recently, the statement was published as part of the 2021 MAC Midwinter Meeting Minutes:
“LC conducted an internal, detailed study 3 years ago that explored the idea of migrating the Title records in the Authority file to the Bibliographic file. The study group included a variety of stakeholders representing standard specialists, policy specialists, catalogers, and administrators. The general consensus was that it was a compelling, logical idea but would require additional effort to implement. Part of the report was an analysis of what changes would need to be made to the MARC Bibliographic format to accommodate this change – in all very few changes are needed, which was one of the primary reasons the idea was viewed as compelling. One reason so few additions are needed in the Bibliographic format is because there is already overlap between the Bibliographic format and Authority format when describing Titles. Because the community has tried to wedge Work/Expression elements into the Authority format to accommodate RDA, a number of MAC papers over the last 6+ years have requested changes to both formats, increasing MAC and LC maintenance overhead for MARC and further increasing the incoherence of the formats.
More recently, LC’s initial work with BIBFRAME Hubs has demonstrated not only the feasibility of these types of entities in the Work/Expression description environment, but also that they have a rather natural implementation. LC has commissioned XSLT code to convert MARC Authority records to MARC Bibliographic records to better understand the conversion challenges, if any. Experimentation with the actual XSLT will begin next month. Additionally, the MARC-to-BIBFRAME conversion was modified to produce Hubs from these MARC Bibliographic Title records. Virtually no changes had to be made to the BIBFRAME model or vocabulary to accommodate a full conversion of a MARC Bibliographic Title (formerly a MARC Authority Title) to a BIBFRAME Hub/Work using this workflow. BIBFRAME contains no, or very few, elements related to traditional library authority records; it is almost exclusively bibliographic in nature. The fact that so little needed to change in BIBFRAME further cemented the notion to LC that the more natural ‘format’ for these entities is a bibliographic one, not an authority one.
This DP would make additional changes to the Authority format to support what is basically bibliographic description. LC does not support this effort and would not implement this for a variety of reasons beyond the conceptual issue which has been the focus here. LC believes it is time to step back and evaluate what these entities are and how they function.”
In the end, the status of the discussion paper was not determined, although it was agreed that LC should work with Adam Schiff (representing PCC) on revising it [but note that no further proposal or discussion paper along these lines has been submitted for consideration at the 2022 Annual MAC Meetings in June]. Regardless of the results of LC’s proposed test conversion of authority records, it was pointed out at the MAC meeting that the PCC will continue to create Authority records in the MARC Authority format after the adoption of BIBFRAME.
4) Final Report of the MARC Cataloging Inefficiency Task Group (Jeff Lyon, TG Leader)
In the past year, the MCI TG discussed the results of the previous year’s survey of six selected MARC cataloging inefficiencies. All of CMC was subsequently invited to join the discussion, after which the TG decided to recommend action on four of the six inefficiencies: (1) for genre/form, to prefer field 655 over 047 in bibliographic records; (2) for medium of performance, to prefer field 382 over 048 in bibliographic records; (3) for genre/form, to prefer field 655 in bibliographic records and field 380 in authority records; and (4) in general, to prefer field 028 $q over clarifying notes in field 500. As for the remaining two inefficiencies, the TG agreed that further discovery system development and discussion would be necessary before any action on the remaining two items (making the 007 field optional when 34X fields are used; and making field 008/20 optional when fields 655/546/348 are used) could be recommended. The four recommended actions can now be passed on to Keith Knop for inclusion in the MLA cataloging best practices, and Keith indicated that he could add them to the best practices immediately if desired.
In the discussion that followed, Thom Pease asked if these recommendations would be distributed to the wider cataloging community outside of the best practices document. His concern is that these recommendations might be obscured due to the fact that the best practices document resides in the RDA toolkit, which may be inaccessible, for example, to cataloging teachers or trainees who might therefore be unaware of them. To increase awareness of these recommendations, Thom suggested that somebody involved in the TG should write an article about the recommendations, or perhaps an article more broadly describing the TG’s work toward making MARC more efficient. The Chair, however, expressed her opinion that this recommendation went well beyond the task group’s charge; and that furthermore, the survey results indicate a great deal of resistance to the proposed changes due to the requirements of the various discovery systems in use. Yet in spite of this resistance, everything is, in fact, changing: not only encoding standards, but content standards too, not to mention technology in general. Perhaps what is needed now is not so much an attempt at advocacy by one or more members of the TG—which has competed its charge and is about to be disbanded—but rather some sort of broader advocacy mechanism, perhaps an MLA advocacy group of some similar to MOUG’s former Reference Services Committee, which successfully advocated for changes to OCLC discovery platforms some years back.
Mark Scharff asked for clarification regarding the recommendation to prefer use of field 028 $q over 500 notes in cases where a 500 note is required to ensure that the publisher’s number can be reflected as it appears on the item. For example, a number might appear with an “Nr.” in front of it, but the “Nr.” should be omitted from the 028 $a to avoid improper indexing. The Chair clarified that the recommendation did not prohibit somebody from making a 500 note when deemed necessary, but was simply intended to indicate that it is not necessary to repeat information clearly encoded in field 028 elsewhere in a bibliographic record. Jeff suggested modifying the language of the TG’s recommendation to clarify the intent. Keith Knop further noted that Mark’s concern has, in fact, already been addressed in the MLA cataloging best practices document.
Mark then referred to Thom’s idea of writing an article vis-à-vis the Chair’s suggestion of the need for advocacy, noting that such an article would itself be a form of advocacy/education. The Chair in turn asked who should be responsible for this sort of advocacy/education, as these are not solely encoding issues. Does MLA have such an advocacy body, and if not, do we need to form one? It is not only catalogers who need the advocacy; the needs of reference people, for example, should to be considered in this regard as well. Mark agreed, suggesting that a task group made up of members drawn from across public and technical services might be formed to tackle these issues. The Chair agreed, and pointed out that the survey did not investigate all cataloging inefficiencies, but only a select few. The Chair further suggested to CMC Chair Hermine Vermeij that this is an issue that should be addressed at the next CMC meeting.
In her turn, Hermine spoke of how the University of California system had just gone through a migration to Alma, and the frustration of trying to get Alma’s developers to take their concerns seriously, noting how the situation is even more difficult for smaller communities like music. She really likes the approach Bruce Evans and Margaret Corby are taking (see their poster session on the subject, which was presented later in the conference). Another suggestion, that discovery system vendors be provided with MLA’s Music Discovery Requirements document, would likely be overwhelming; perhaps narrowing advocacy’s focus to the most vital changes needed would be a more successful approach. Ethan D’Ver agreed, adding that presenting something to vendors that flat-out does not work has more of an impact than saying that something that does work is inefficient because it creates more work for catalogers. The ESS Chair suggested that in the interest of time, discussion of this important issue should be continued at a later time.
Speaking of the Music Discovery Requirements, Chris Holden suggested that it might be time for an MDR update. The Chair agreed, noting that it has been three or four years since version 2.0 was released, and that in the meantime, each CMC subcommittee has had a member or two keeping track of to the MDR changes that might be needed. She asked if anybody knew what was needed to initiate an update. Tracey Snyder answered that she believed it is up to CMC and the ETSC (Emerging Technologies and Services Committee) to decide whether there are sufficient changes to justify convening a group of people to draft a revision. Josh Henry seconded Tracey’s comment.
Thom Pease asked if OCLC documentation would incorporate or mention MLA cataloging best practices. Jay Weitz said OCLC often includes their own cataloging preferences, as well as the best practices of music and other specialist communities, throughout BFAS (OCLC’s Bibliographic Formats and Standards) to guide catalogers. Since he will be aware of published changes to MLA cataloging best practices, Jay will try to make sure that these are reflected in BFAS. Jay also notes that MOUG’s Reference, Discovery, and Collection Committee tries to ensure that other OCLC non-cataloging interfaces such as WorldCat Discovery reflect changes in such preferences. In connection with this, the Chair reiterated that some years ago, MOUG’s then-Reference Services Committee successfully lobbied for display changes in OCLC’s discovery platforms and wondered if MLA shouldn’t also have a similar group; but she noted again that this is more appropriately a CMC discussion as the issue is not solely an ESS one.
Having completed its work, the MCI Task Group will now disband. The Chair thanked the TG for its work, expressing particular gratitude to Jeff Lyon for stepping up to lead the TG through its final year and write its final report.
5) LC Liaison report (Damian Iseminger)
Within the Library of Congress, there is a MARC advisory group, of which Damian is a part, that reviews all MARC proposals and discussion papers and gathers LC reaction, which is usually put forward as comments at the MARC Advisory Committee meetings where the papers are considered. Lately, the focus has been on BIBFRAME development, as that is currently NDMSO’s major concern. Damian noted that his report is necessarily brief, as the ESS Chair has already reported sufficiently on LC activity in regards to MARC, and thanked her for her work in this regard.
6) Report of the Metadata for Music Resources Task Group (Ethan D’Ver, TG Leader)
The MMR TG has had a busy year digesting responses to last year’s usability test and subsequently redesigning the MMR website. The MMR site has now been reorganized into four categories (Training, Tools, Standards, and Reference), each with user-friendly subcategories. In its redesign, the TG decided not to retain the current site’s news section: instead, a blog-type structure that could be used report developments in non-MARC metadata is being considered.
Before introducing the new MMR site, Ethan outlined some of the old site’s issues and explained what had been done to address these on the new site. He then gave a brief “tour” of the new site, noting the removal of outdated and irrelevant resources and the fixing/updating of broken/older links.
With this work completed, Ethan asked for input regarding how best to maintain the site and keep it up to date, as well as thoughts on what should be done in terms of providing the site with news content. He also asked for thoughts regarding how the community might best make suggestions for changes and additions to the site, and how the site should fit into ESS’s role in terms of serving the non-MARC/BIBFRAME metadata community. Additionally, Ethan asked what the future of the MMR TG should be and suggested three possibilities: (1) disband the TG, with ESS members taking responsibility for the MMR’s maintenance; (2) keep the TG going to provide the MMR site’s maintenance; (3) keep the TG going not only to maintain the site, but also to serve the needs of the non-MARC metadata community more broadly.
Finally, Ethan gave special thanks to CMC Webmaster Josh Henry for the very considerable amount of work he did in making the TG’s redesign of the MMR site a reality.
Mark Scharff asked if there would be some sort of mechanism for notifying interested parties of changes to the MMR site content. Ethan answered that when a critical mass of such changes accumulated, it would be possible to create something along the lines of a CMC blog post to convey these. Thom Pease suggested that an RSS feed might be used to be for change notification as well.
Ethan then asked the Chair for her thoughts on the future of the MMR Task Group. She clarified that as long as ESS is responsible for MMR, there is an ongoing need for the TG and so it is intended to be permanent.
Regarding community reporting of suggestions for additions or revisions to the MMR site, there is currently a mechanism in place, and Rebecca Belford chatted a reminder that these suggestions currently go to the ESS Chair rather than directly to the MMR TG leader. The Chair recalled that the reason for this is that the succession of ESS Chair is stable, whereas the leadership of the MMR TG is not so predictable. As for whether this reporting method works well in practice or not, she suggested it could be tested by having a couple of people send mock suggestions and checking the result. Ethan said that he could recall only one instance of receiving a suggestion, which was essentially an instance of somebody promoting their own proprietary software.
Finally, the Chair noted that placement of the MMR TG report at this point in the agenda was intended to lead into a discussion of ESS’s new work in the coming year, and perhaps now was the time to do that. She thanked Ethan and the Task Group for their work, pointing out that MARC and Metadata had originally been separate CMC subcommittees and that, in her opinion, Metadata had come out the worse of the two following the merger. The Chair doesn’t use non-MARC/BIBFRAME metadata in her own work and suspects that to be the case with many of us. As a result, she was skeptical of ESS’s ability to maintain and improve the MMR site, but is pleased to have been proven wrong on the matter by the successful activities of the MMR TG.
7) New work for the coming year: non-MARC metadata
For now, BIBFRAME seems to be the province of the Linked Data Working Group (LDWG) and, as successor to MARC, will likely replace MARC as the/a primary focus of ESS in the future; and it is now clear that the development and maintenance of the Metadata for Music Resources site is being handled successfully by the MMR TG. Does the music community have any additional needs in the realm of non-MARC metadata that ESS should be addressing, and if so, how might we do that?
Regarding the how, the Chair noted that Ethan had just made a suggestion for accomplishing this—broaden the MMR TG’s charge to encompass the general needs of the non-MARC metadata community—and asked for thoughts on the matter. More specifically, she asked if attendees could articulate what these needs might be and how they were not being met, and for suggestions about how ESS might be more proactive in addressing the needs of those using non-MARC metadata.
Thom Pease suggested reaching out to MLA’s Digital Humanities Interest Group. Ethan reminded us that we had tried that once: we had wanted to get one or more people from the DHIG to join the MMR TG, but nobody expressed an interest in doing so. The Chair suggested that perhaps it was time to approach DHIG once again.
Kevin Kishimoto indicated that it would be useful to have MODS best practices for music, as there are many digital music objects in need of description. A number of other individuals indicated their agreement with Kevin.
Thom pointed out that there might be people in IAML (International Association of Music Libraries, Archives, and Documentation Centres) who might be interested in non-MARC metadata and perhaps we should reach out to them.
As no further suggestions were forthcoming, the Chair recommended that ESS discuss the matter further after the meeting, but said that if anybody had other ideas or suggestions, they could use the suggestion function on the MMR website could be used to make them.
8) New work for the upcoming year: MARC
a) Reminder regarding ESS work
The Chair reminded ESS members that we can’t do anything to influence or change the MARC Advisory Committee meeting schedule, and while the result is that we must actively review and comment on MARC proposals and papers at generally inconvenient times (during or shortly following holiday season late in the year, and again towards the end of the academic year), it is still necessary for us to do this work, especially when it may affect music cataloging: other people involved in MARC cataloging work do not always understand the needs and requirements of the music community, and we need to advocate for ourselves. There is generally very little time between the point at which the papers are published and feedback can be submitted, and we all struggle to meet these particular obligations as a result. She noted that when she sends out a call for comments or other work to be done, she is often met with complete silence for an extended period of time, leaving her to wonder what if her request has been received or is being considered. ESS members are asked to be sensitive to this circumstance, and if unable to respond to the request for comment in the short term, to please let her know that her message has at least been received, and a response is being considered.
b) MARC 384 (Key) (Bibliographic and Authority formats)
It has recently come to our attention that there is a (now long-standing) issue requiring editorial changes to/clarification of MARC 384 first indicator (Key type). Currently, there is no definition of first indicator 1 (Original key), but there is a curious definition of first indicator blank (Relationship to original key unknown): “The relationship of the specified key to the original key in which the musical composition was written.” The Chair discussed the issue with John Zagas (NDMSO), and we concluded that either the current first indicator blank definition was actually supposed to be the definition of the first indicator (Key type) itself; or perhaps that that definition was a somehow truncated definition of first indicator blank. Either way, the original intention could not be determined with any certainty, and the 2010 proposal that defined the field has left no clue for us. As a result, the Chair will be asking ESS members to take a look at field 384 and suggest what needs to be done to clarify the issue.
In the meantime, an additional issue has surfaced regarding the 384 field. In January, when MARC Proposal No. 2022-04 (Recording Representative Expressions in the MARC 21 Authority and Bibliographic Formats) was being approved, Adam Schiff asked if the field should be made repeatable in the Authority format (it is already repeatable in the Bibliographic format) due to the possibility that somebody might want to record both Key of representative expression (new first indicator 2) and Original key (first indicator 1) in the same authority record. The Chair, representing MLA at the MARC Advisory Committee meetings in January, couldn’t immediately think of a use case, and the MARC Advisory Committee decided that, rather than trying to make a snap decision, it would be better for MLA to submit a fast-track proposal later if/when we determine that the field should be repeatable. The Chair asks that attendees who can provide a use case demonstrating the need for field 384 to be repeatable under Official RDA please get in touch with that information. Either way, we will still need to request editorial changes correcting/clarifying the first indicator definitions, but will hold off on doing so until this matter is resolved.
c) MARC 383 (Numeric Designation of Musical Work) (Authority format)
Recognizing that some expressions have their own opus/thematic index numbers, Chris Holden has asked if field 383 should be updated to include expressions in the Authority format. In relation to this, Damian Iseminger noted that under Official RDA, a thematic index number can be recorded as an Identifier for Expression element; but if we want a specific Thematic Index Number for Expression element, we should first propose this as a change to RDA, as having this as an element in RDA would strengthen the case for making the analogous supporting change to MARC. Damian believes that Chris makes a good case that this is a necessary element, and if MLA wants to propose this change to RDA, we can do so through CC:DA, which would then submit the proposal to NARDAC.
The Chair asked anybody who could provide examples of opus/thematic index numbers for expressions to please send them along. Damian suggested that the Liszt thematic index can provide good examples (see Grove online), as thematic index numbers are provided for different instrumental versions of the same piece, which could plausibly be considered expressions. Ethan believes there are similar examples for Prokofiev, and Damian noted the same to be true in the case of Johann Strauss’s various waltzes. Chris offered to send [and subsequently did send] additional examples as well.
Mark asked if this change would also cover the situation of nineteenth century adaptations, (arrangements, potpourris, etc.) where opus/thematic index numbers are assigned for the arranging/adapting composer. Ferdinand Beyer is one example of a composer making such adaptations of works by other composers. We will need to take this issue into consideration in attempting these changes.
d) On hold from 2021 (for details, please see the Minutes from last year’s ESS Business meeting)
i. Where are we at regarding use of MARC 758 (Resource Identifier)?
For the past few years, we have been holding off on using field 758 pending recommendations from the PCC Linked Data Best Practices Task Group [in fact, a final report was submitted to PoCo September 19, 2019]. Formerly, Nancy Lorimer was monitoring the issue for us. Does anybody have any further information on the issue? Since nobody responded to this question, the Chair suggested that we drop this from our list of potential issues until such time as a need for the field has been articulated.
[In retrospect, the use of MARC 758 is a best practices issue, and so would be under the purview of the Content Standards Subcommittee. ESS should not be specifically involved unless it is determined that changes to the field need to be considered or proposed.]
ii. Do we need to consider moving duration out of MARC 300 subfield $a, encoding it elsewhere (such as an expanded version of MARC 306)?
At a previous meeting, Kathy Glennan suggested that we wait until corresponding changes had been made to Official RDA before pursuing such changes to MARC (note: these changes would also affect moving image resources cataloging). The Chair pointed out that duration of representative expression now has a place in the new Field 387 (Representative Expression Characteristics) (Bibliographic and Authority formats), subfield $f. Keith Knop noted that a task force/working group has recently been formed to look at extent (including duration) in RDA—so recently that it hasn’t yet had time to work on the issue. He therefore recommends that we (continue to) hold off proposing any changes to MARC in this regard until we know the end result of the group’s work. Based on Keith’s comments, the Chair suggested that this issue should remain on ESS’s radar for the time being.
Thom Pease noted that we will need to look at encoding not only for total duration, but for the duration of component units as well: for example, different indicators could be used to differentiate total duration from component unit duration.
e) Other ideas for changes to MARC?
Hearing none, the Chair reminded attendees that they can suggest potentially needed changes to ESS at any point in time.
9) New business (All)
None.
10) Adjournment
The Chair thanked attendees for their attention and interest and closed the meeting.