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