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

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

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

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

5. MARC21 updates
Updates 10 and 11 contain the changes to accommodate RDA
Proposal No : 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 : ISBD punctuation in the MARC 21 Bibliographic Format
And work continues.

6. “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

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

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

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

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

11. Welcome back subfield $e
100 $a Blais, Marie-Claire, $d $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

12. 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 Now the data gets separate fields -- the “explicit” part of Alan’s quote

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