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:
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.
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
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.
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.
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,
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.  A colleague found a bit of a
> discussion of this issue from the VuFind community.  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?
>  MARC::Record - http://bit.ly/2px2sC6  discussion -
> Eric Morgan