 |
 |
Yep, and there's also a new code 'n' defined for the same leader element that indicates that non-ISBD punctuation was omitted. Still a lot of work if you weren't already having the code provide the punctuation. But I'm not complaining because the greater data granularity supported by MARC itself is really a win. -Kristina > -----Original Message----- > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of > Roy Tennant > Sent: Wednesday, May 3, 2017 1:19 PM > To: [log in to unmask] > Subject: Re: [CODE4LIB] ISBD punctuation (related to [CODE4LIB] rda) > > >Now I'll need to detect when a record is not providing punctuation, and > have my code insert it based on the MARC element. > > Presumably you could check the appropriate leader element: > > "In 2010, MARBI (Machine-Readable Bibliographic Information Committee) > approved MARC proposal no. 2010-07 submitted by the Deutsche > Nationalbibliothek to add a code to Leader/18 (Descriptive Cataloging Form) > to indicate the omission of ISBD punctuation in MARC 21 records." > > Roy (who can't believe that we're finally doing this) > > On Wed, May 3, 2017 at 10:11 AM, Spurgin, Kristina M. < > [log in to unmask]> wrote: > > > Related to Eric's question re: RDA, the following news hit my inbox > > this > > morning: > > > > The library community is moving ahead to, in general, stop using most > > ISBD punctuation in MARC records beginning January 2018. > > > > I've not spent that much time thinking through this, but my initial > > take is that it's going to require a lot more work for me than the RDA > > change did. > > > > A number of substantial changes are needed to the MARC format to > > support this. These are listed in this document: > > https://www.loc.gov/aba/pcc/documents/isbdmarc2016.pdf > > These will need to be understood/supported by our systems and code. > > > > Data-wise, this is a good move overall, however the reality of all our > > legacy MARC makes it somewhat nightmarish, at least in my first > assessment. > > > > We've always relied on that punctuation in the MARC itself to provide > > the punctuation in the extracted/transformed MARC data that ends up > > populating our catalog displays. Now I'll need to detect when a record > > is not providing punctuation, and have my code insert it based on the > > MARC element. I don't think we can strip out all the punctuation > > (tricky to JUST remove the ISBD punctuation) and provide the needed > > display punctuation programmatically because the legacy records won't > > have the new MARC elements required to code the data with more > > granularity---so it will be unclear what punctuation the code should provide > in many cases. > > > > Bah... > > > > Anyway, heads up in case it affects any of the stuff you are doing > > with catalog data... > > > > Pasting relevant listserv message below... > > > > -=- > > Kristina M. Spurgin -- Library Data Strategist > > E-Resources & Serials Management, Davis Library > > University of North Carolina at Chapel Hill > > CB#3938, Davis Library -- Chapel Hill, NC 27514-8890 > > 919-962-3825 -- [log in to unmask] > > > > > > > > From: Program for Cooperative Cataloging > > [mailto:[log in to unmask]] On Behalf Of Beacom, Matthew > > Sent: Monday, May 1, 2017 4:31 PM > > To: [log in to unmask] > > Subject: [PCCLIST] Removing Punctuation in MARC records (PCC ISBD and > > MARC Task Group Revised Final Report (2016): a timeline > > > > Hi all, > > > > The attached is a brief rationale and a timeline for implementing the > > recommendations of the PCC ISBD and MARC Task Group (Revised Final > > Report 2016). > > > > The Task Group recommendation is at https://www.loc.gov/aba/pcc/ > > documents/isbdmarc2016.pdf > > > > Here, in the body of this message, is the text of the attached, the > > rationale and the timeline for action. > > > > Rationale: > > A fuller rationale for removing ISBD punctuation from MARC records is > > in the report of the PCC ISBD and MARC Task Group Final Report (2016). > > In brief, the rationale for removing the ISBD punctuation is that > > since the ISBD punctuation was designed for the card catalog format, > > it is now an unnecessary burden within MARC; and that, as we prepare > > for a post-MARC bibliographic environment, the ISBD punctuation is a > > hindrance to that transition. > > > > The argument against making the change is a pragmatic one that > > combines concerns about timing—doing this just at MARC’s ‘end-of-life’ > > moment—and the potential for labor-intensive disruption in that time. > > In 2014, it was thought that the impact of the change on our systems > > before the anticipated migration to linked data and BIBFRAME in 3-5 > > years would be a double whammy that should be avoided, and we hoped > > removing the ISBD punctuation could be handled on the conversion of > > our MARC data to BIBFRAME. But in 2017, the anticipated migration > > seems at least as far off as it did in 2014: a sure sign that imminence was > over-predicted. > > > > Removing the ISBD punctuation would improve MARC as a format for > > bibliographic data for the duration of the MARC format’s use. As noted > > above, the use of MARC can be reasonably expected to continue far > > longer than some anticipated in 2014. The benefits of removing ISBD > > punctuation from MARC records include: > > > > MARC coding can be used alone to designate parts of the bibliographic > > description, eliminating the redundancy of parallel input of > > punctuation and MARC coding. Eliminating most punctuation from MARC > > records simplifies data entry and allows catalogers to focus solely on > > coding to better identify parts of the bibliographic description. It > > also allows for flexibility in the design of online displays without > > the need for suppressing punctuation. Omission of ISBD punctuation in > > MARC records is routine in other MARC formats used around the world. > > > > MARC 21 will be around for many years with millions of additional > > records created as libraries slowly move to working with BIBFRAME. > > With a transition to BIBFRAME, local systems and bibliographic > > utilities will need the ability to readily map data back and forth, > > i.e., BIBFRAME to MARC and MARC to BIBFRAME. Those mapping programs > > would be greatly simplified and more easily maintained if punctuation > > did not have to be added or removed at the same time. Developing > > programs now to remove punctuation from MARC > > 21 will facilitate a transition to BIBFRAME in the future. > > > > Actions: > > 1. TIMELINE: new start date set to Jan. 1, 2018 for going live with > > the permission to not use ISBD punctuation; 9-10 months to prepare and > > adapt. > > a. Phase 1: Now to ALA Annual 2017: Make and distribute record sets > > for initial preparation testing for impact in local systems, etc. > > b. Phase 2: July 1, 2017-Oct. 1, 2017: Use this preparatory period (3 > > months) to complete initial testing of record sets in local systems > > and report on impact. > > Initial testing is for non-access points in bibliographic records. > > Vendors shall be made aware that further testing will address access points > and > > authority records, where applicable. Furthermore, only records with ISBD > > punctuation are included in the initial testing. The records do not > > include coding that needs to be developed by MAC. > > c. Phase 3: Oct. 1, 2017 to Jan. 1, 2018: Analyze results of > > testing in local systems, and evaluate responses from system vendors > > (including any projections they may have regarding development and > > release of upgrades to accommodate proposed changes). Use this second > > preparatory period (3 months) to understand or make any local changes > > necessary to tools, workflows, policies. > > d. Phase 4: Jan. 1, 2018-? Based on analysis of phase 3, develop > > timeline, revise specifications, plan changes to tools, workflows, > > policies as necessary. > > January 1, 2018 is a “check-in” date to understand the status after > > hearing from vendors, testers, etc. > > 1. might vendors need to fold punctuation changes into a multi-year > > development cycle? > > 2. Will there be any MAC actions and MARC documentation updates > needed? > > 3. Confirm assumption that this proposal would ease conversion to > > linked data. > > > > 2. COMMUNICATION: PCC community outreach to stakeholders (i.e. > local > > system vendors: ILMS and discovery tool providers) Goes through all 4 > > phases. > > a. OCLC will reach out to ILMS vendors > > b. PCC group will also reach out to discovery tool vendors (some > > overlap between a & b; redundancy OK) > > c. PCC institutional members reach out to vendors as customers > > d. PCC Steering will monitor progress through each phase and chair > > will report to PoCo and PCC > > > > 3. TESTING RECORD SETS: OCLC and LC will create and distribute small > > record sets for PCC institutional members and vendors to use to test > > impact of ISBD-punctuation-less records on import, workflow, indexing, > > sorting, display, etc. > > a. OCLC will have some number of pairs of records (with > > punctuation/without punctuation) --some English, some German--to test > > by end of phase 1 > > b. LC will have some number of pairs of records (with > > punctuation/without punctuation) to test by end of phase 1 > > c. PCC institutions may create pairs of records (with > > punctuation/without punctuation), too. > > d. PCC institutional members and vendors will report on impact (using > > the test record sets) at end of phase 2 > > > > The phases 1-3 above, in short, prepare us to systematically and > > effectively remove unneeded punctuation from the MARC records. Phase > > 4, beginning Jan. 1, 2018, is when preparation will morph into > implementation. > > > > PCC will be working through Policy Committee, the Standing > > Committees—each will have its role, and whatever ad hoc or temporary > groups may be needed. > > > > Thank you and all the best to you, > > > > Matthew Beacom > > PCC Chair > > > > Lori Robare > > PCC Chair-Elect > > > > Kate Harcourt > > PCC Past Chair > > > > > -----Original Message----- > > > From: Code for Libraries [mailto:[log in to unmask]] On Behalf > > > Of Eric Lease Morgan > > > Sent: Wednesday, May 3, 2017 11:14 AM > > > To: [log in to unmask] > > > Subject: [CODE4LIB] rda > > > > > > To what degree have any of us done massive RDA work in our catalogs, > > > and similarly, to what degree have some of the community's MARC > > > programming libraries have been modified to account for RDA rules? > > > > > > For example, has anybody done any large scale find & replace > > > operations against their catalogs to create RDA fields with values > > > found in other > > MARC > > > fields? Why or why not? Similarly, RDA seems to define a publication > > field in > > > MARC 264. Correct? Yet the venerable Perl-based MARC::Record module > > > (still) pulls publication dates from MARC 260. [1] A colleague found > > > a > > bit of a > > > discussion of this issue from the VuFind community. [2] Which leaves > > > me > > to > > > ask another question, “Why is there so much business logic embedded > > > into the MARC cataloging rules?” > > > > > > Alas. How in the world is the library community ever going to have > > > more consistently encoded data so it can actually disseminate > information? > > > > > > [1] MARC::Record - http://bit.ly/2px2sC6 [2] discussion - > > > https://vufind.org/jira/browse/VUFIND-749 > > > > > > — > > > Eric Morgan > >