MARC21 changes to accommodate RDA This part is a quick look at the changes to MARC coding that we will start to see in copy, and perhaps include in our original records, for both bibliographic and authority data. Trina Grover June 2, 2010

With considerable help from … Alan Danskin (JSC Chair) Tom Delsey (Former RDA editor) Pat Riva (CCM Chair) Adam Schiff (University of Washington) Margaret Stewart (Library & Archives Canada) Barbara Tillett (Library of Congress) With help from the experts out there, in alphabetical order on this slide, who share their presentations and notes online so that we can all learn from them. and the test documentation on LC’s website, updated recently with examples and webcasts

Topics New MARC tags, subfields and codes for bibliographic data authority data Checklist for local integrated library systems some of the changes and additions made to the MARC formats, For the most part these changes will not mandate big changes in our MARC-reading ILS systems on day one of implementation. But they move us a bit closer to a new database model, the MARC record structure is considered “flat”, so it does not make the most of our RDA content

RMWG working principles MARC21 must remain neutral and flexible as to which types of records, fields and subfields map to which FRBR entities database design All changes to support the granularity of RDA data are based on an assessment of the benefits for end-users, and consideration of cost implications Since early 2008 a working group has been developing discussion papers and proposals for changes to the MARC formats to accommodate RDA elements. The RDA/MARC working group (RMWG) includes Bill Leonard and Margaret Stewart from Library and Archives Canada. Membership – LC, LAC, BL, DNB, OCLC, VTLS, ALA, JSC

MARC21 updates Updates 10 and 11 contain the changes to accommodate RDA Proposal No. 2010-07: ISBD punctuation in the MARC 21 Bibliographic Format Proposals are reviewed and sometimes debated, edited and resubmitted, and some get approved. update number 10 and 11 contain the changes to MARC 21 to accommodate RDA; there is a concise list of changes on the LC MARC site, “RDA in MARC -- Summary of Additions” This summer there is only one proposal that relates to RDA Proposal No. 2010-07: ISBD punctuation in the MARC 21 Bibliographic Format And work continues.

“Introduction of explicit elements is good metadata practice” -- Alan Danskin (JSC Chair) So what is new? A good quote from Alan Danskin, Chair of the JSC: Introduction of explicit elements is good metadata practice Metadata is most useful when it is parsed out in separate chunks that computers can work with; strings of text are not efficient

Leader and 00X MARC records containing RDA descriptions will have leader/18 = i for ISBD leader/06 Type of record will continue to contain the code for primary content Some additional codes in various 007 and 008 character positions In RDA records we will set leader byte 18 to “i” for ISBD --- most likely A proposal to change the definitions of the values in Leader/18 has been submitted to MARBI for the summer meeting. The proposal redefines the exist code “i” and introduces a new code to indicate the absence of ISBD punctuation at the end of subfields, to indicate up front in a record that certain punctuation will not be carried at the ends of subfields in the fields that contain title page transcription. The JSC national libraries did say we would be using ISBD punctuation in our records so we would code Leader/18 i. However, with the proposed change in definition this might change or not...we will have to see what happens at the MARBI meeting in June Leader byte 6 continues to contain the code for primary content, no change there Some extensions made to fields 007, 008 to accommodate RDA terms, nothing major, but you’ll need to add those values to your validation tables

040 Cataloging Source $b language of cataloguing (NR) $e description conventions (R) 040 $a DLC $b eng $c DLC $e rda 040 $a CaOTR $b fre $c CaOTR $e rda LC test documentation instructs testers to include language of cataloguing in subfield $b as well as “rda” in subfield $e for description conventions. So we will start to see $b again in LC records and LAC always codes it So we will have 2 flags that a MARC record contains an RDA description: the leader byte 18 set to i (meaning ISBD punctuation is used) and the 040 subfield $e

No subfield $h in field 245 General material designations have been replaced by 3 new variable fields 336 Content Type (RDA 6.9) 337 Media Type (RDA 3.2) 338 Carrier Type (RDA 3.3) Core element A big change next, the elimination of general material designations. We did not include GMDs in all records, it was an option in AACR2, however two of the three data elements that replace the GMD are core, so they should be present even when you have a simple book. Therefore these fields are ideal for templates in your ILS, which will make sure they are not forgotten or coded incorrectly Field 336 Content type is a core element in RDA, found in section 2 chapter 6 which instructs us how to identify works and expressions RDA Content Types * MARC already indicates content type in LDR/06 but we will code this as it is a core element; RDA contains a list of English language content types 337 Media type is found in section 2 chapter 3 which instructs us how to describe carriers; RDA contains a list of English language media types 338 carrier type is also in section 2 chapter 3 on describing carriers; RDA contains a list of English language carrier types All three fields may contain the RDA term ($a) or a code ($b); codes were established in MARC Update 10. RDA has controlled vocabularies for each of these elements. Some of this information is coded in 006/007, but it is in various places and not in the RDA way. Content, carrier and media information will be coded into 3XX fields for systems to use to filter results, cluster results as per the FRBR model. Core element

Website with photographs 245 $a The sartorialist 300 $a 1 online resource 336 $a text $2 marccontent 336 $a still image $2 marccontent 337 $a computer $2 marcmedia 338 $a online resource $2 marccarrier Based on an example in Barbara Tillett’s presentation at midwinter 2010, I edited it slightly for a fashion blog; notice field 245 does not have subfield $h These fields can be repeated ; All three new fields include subfield $b for the code form of the information, but LC test instructions say not to include the code in subfield $b -- isn’t the code easier for computers to work with? Are we not meant to be creating actionable metadata? The idea is to use either the term or code, not both. Barbara said they will not code field 337, it is not core and they expect the ILS to generate that field based on other fields … I think its in her recent webinar It is possible for a system to decide to display a user-friendly term or an icon generated from these fields. Some systems may decide to display the RDA terms as well.

Welcome back subfield $e 100 $a Blais, Marie-Claire, $d 1939- $e author 240 $a Belle bête. $l English 245 $a Mad shadows / $ c Marie-Claire Blais ; translated from the French by Merloyd Lawrence. 700 $a Lawrence, Merloyd. $e translator In addition to naming the person by using an access point, RDA includes a relationship designator to show what role that person plays with respect to the resources being described. In the MARC format this is shown with a relator term or code in subfield $e. A list of relationship designators is found in RDA appendix I

Attributes of persons 046 special coded dates 370 associated place 371 address 372 field of activity 373 affiliation 374 occupation 375 gender 377 associated language We have some new elements for authority data, based on attributes defined in the Functional Requirements for Authority Data. These were published in MARC 21 Update 10 & Update 11 Here are some the new fields in MARC for attributes for the group 2 entity person In some cases we’ve been recording the information in field 670. Now the data gets separate fields -- the “explicit” part of Alan’s quote

ILS checklist Review indexing and display configurations for example subfield $e in 7XX Add fields for core elements to templates such as 336 and 338 Make changes to validation tables Create new macros Configure import and export profiles to include new fields In terms of what we need for day one implementation, the changes are simple for now. This checklist is a work in progress, there are still decisions to be made and all decisions and documentation will be shared with everyone, put online on the tsig wiki . Quote from Margaret Stewart – today’s experimentation will inform future direction