Fwd: [MARC] MARC Advisory Committee Midwinter Meeting - TUESDAY MEETING (January 31) WEBEX ACCESS LINK
Sherman Clarke
From: Zagas, John <jz...@loc.gov>
Date: Wed, Jan 25, 2023 at 11:44 AM
Subject: [MARC] MARC Advisory Committee Midwinter Meeting - TUESDAY MEETING (January 31) WEBEX ACCESS LINK
To: <MA...@listserv.loc.gov>
MARC ADVISORY COMMITTEE (MAC) MIDWINTER MEETING
January 31 – February 2, 2023, on WebEx
MEETING #1:
Tuesday, January 31, 2023
10:30 AM – 12:30 PM Eastern Time (7:30 AM – 9:30 AM Pacific Time)
WebEx Link: https://secure.icohere.com/PCC?pnum=YNZ77098
If you are only able to connect by phone:
Call in Number for Phone Only Access:
Call-in Number:
+1-415-655-0003
Access Code: 242 182 58376 #
The agenda for the MAC meetings is available at: https://www.loc.gov/marc/mac/mw2023_age.html
Members of the MARC community are invited to join the proceedings of the MARC Advisory Committee as it holds its online Midwinter Meeting. The above link allows access to the meeting as an audience member. Audience members will have the opportunity to listen to and watch the event, but, due to the business nature of the meeting, their microphone and chat functions will not be open.
The MAC meetings will be recorded and linked to the MARC website after the event.
WebEx links for the Wednesday (February 1) and Thursday (February 2) meetings will be posted on the MARC Listserv separately, after the first meeting.
-----------------------------------------------
Network Development and MARC Standards Office
101 Independence Ave., S.E.
Washington, DC 20540-4402 U.S.A.
TEL: +1-202-707-6237
FAX: +1-202-707-0115
NET: nd...@loc.gov
-----------------------------------------------
Liz OKeefe
NAME: Defining a New Subfield in Field 264 to Record an Unsubfielded Statement in the MARC 21 Bibliographic Format
6. QUESTIONS FOR DISCUSSION
6.1. Do you agree there is an acceptable case to employ a single subfield for imprint/provision? EOK: Yes, but ...
6.2. Does the proposed solution meet the needs discussed? EOK: Well, yes and no. I thought at first that the goal was to present an exact transcription of what appeared on the item, but judging from the examples, you will still have to re-order data elements so that they fit the pattern of Place, Publisher, etc., Date. If re-ordering is not required, then there should be examples illustrating this, e.g. a statement where the publisher name precedes the place name, or a date comes first in the statement (as occasionally they do). And the examples include interpolations, such as "[Place of publication not identified]". If you are not going to transcribe the information exactly as it appears on the source, I don't see the benefit of one subfield over multiple subfields (except maybe for BIBFRAME purposes).
6.3. Other than those covered in this discussion paper, what other downstream impacts should be considered with respect to adding subfield $s to the 264?
6.4. Are there any other potential consequences that this paper does not address?
6.5. Would it be worth revisiting the definition and intended use of Field 881?
6.6. Should a subfield for the General Statement be defined in field 260 as well?
6.7. Are there any alternative format solutions to what is being proposed?
MARC DISCUSSION PAPER NO. 2023-DP03
NAME: Renaming and Redefining Field 368 Subfield $d in the MARC 21 Authority Format
6. QUESTIONS FOR DISCUSSION
6.1. Do you agree that the definition of 368 $d should be changed to make it clear that any term of rank, honor, or office may be recorded in it? EOK: (see comment on 6.4)
6.2. Is the proposed revision of the definition to match more closely what is in official RDA acceptable? EOK: I guess, if we have to follow RDA.
6.3. Should the subfield also be renamed to match the element name in official RDA?
6.4. Are there any other issues that should be considered? EOK: I regret the decision to mingle terms of rank, honor, or office that are used as terms of address (Doctor, Colonel, Reverend) with terms of rank, honor, or office that are not used as terms of address (Ph.D, FRS, M.D.). For manipulation of data elements, it would be much better to differentiate between them . But I guess the problem is with RDA, which has decided to bundle them all in together, under "term of rank or honour or office".
One other thing: the wording of the redefinition ("This includes designations indicative of royalty, nobility, ecclesiastical rank or office, terms of address for a person of religious vocation, and initials or abbreviations representing an academic degree or membership in an organization") and the examples given for it could be interpreted to mean that it is limited to terms that consist of initials or abbreviations. Is that intended by RDA and MARC? I can't come up with examples offhand, but I would think there are times when an academic degree or membership in an organization is spelled out following a personal name
MARC DISCUSSION PAPER NO. 2023-DP04
NAME: Attributes of Family in the MARC 21 Authority Format
5.1. Should MARC accommodate recording of other attributes of family? Yes
5.1.1. If yes, which of the options (OPTION 1: add new subfield $d to 376 or OPTION 2: expand scope of 368 to families) is preferable? EOK: Better to expand scope of 368 to family, than record it in a family-specific field .
5.2. Do you agree that the proposed redefinition of the scope of fields 371 and 372 and their subfields accommodates new RDA elements Address of family and Field of activity of family? EOK: not totally convinced that address is meaningful for family. Would the "family seats" of landed gentry/aristocracy (Windsor Castle, Blenheim Palace) be examples? Some examples for this would help. Activity is fine, though.
5.3. Do you agree that MARC should accommodate recording of profession or occupation of families? EOK: Yes! Very useful
5.4. Throughout the above proposed revisions, would it be preferable to use the termin ology "agent" instead of "person, family, or corporate body"? EOK: Okay, as long as all the relevant categories are mentioned in "Field definition and scope".
5.5. Are there any other issues that should be considered?
--
To unsubscribe from this group and stop receiving emails from it, send an email to arlis-cpdg+...@nyu.edu.