 |
 |
>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 >