LISTSERV mailing list manager LISTSERV 16.5

Help for CODE4LIB Archives


CODE4LIB Archives

CODE4LIB Archives


CODE4LIB@LISTS.CLIR.ORG


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

CODE4LIB Home

CODE4LIB Home

CODE4LIB  May 2017

CODE4LIB May 2017

Subject:

Re: ISBD punctuation (related to [CODE4LIB] rda)

From:

Roy Tennant <[log in to unmask]>

Reply-To:

Code for Libraries <[log in to unmask]>

Date:

Wed, 3 May 2017 10:19:21 -0700

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (227 lines)

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003

ATOM RSS1 RSS2



LISTS.CLIR.ORG

CataList Email List Search Powered by the LISTSERV Email List Manager