Updating to RDA format coding Joel Hahn Cooperative Computer Services No More RDA GMD? OMG! Updating to RDA format coding Joel Hahn Cooperative Computer Services

The Problem

The Problem In the RDA cataloging rules, the piece of the catalog record most commonly used for relaying format information to library patrons and staff—General Material Designation, or GMD—is no longer used. How can we quickly identify the formats of those items for users in WorkFlows, e-Library, Enterprise, and other catalog resources? What can we do to avoid having to account for two very different ways of identifying formats, one for RDA records and one for the thousands of AACR2 (and AACR1) records we still have?

Where did the GMD go? Under RDA, the information typically recorded in the GMD has been split up into three fields: Content Type (MARC field 336) Media Type (MARC field 337) Carrier Type (MARC field 338) The 3XX fields in MARC are used for describing the characteristics & physical nature of the resource This is a more logical place for the information But they are buried deep in the MARC record Some catalogs are not able to display the information where it will be easily noticed by users

Where did the GMD go? The British Library officially switched to RDA on April 1, 2013 OCLC will globally remove GMDs from WorldCat after March 31, 2016 Starting some time before that, they also plan to globally add Content Type, Media Type, and Carrier Type fields to existing WorldCat records that lack them

Content Type The official “content” terms are sometimes patron-unfriendly A movie is a “two-dimensional moving image” or “three-dimensional moving image” A globe is a “cartographic three-dimensional form” If it has raised mountains, it’s a “cartographic tactile three-dimensional form” RDA’s defense is that it doesn’t address data display, therefore OPACs should be programmed to transform unfriendly terms into something more user-friendly If the terms should not be displayed as is, then why must they be recorded as full, English phrases instead of only as codes?

Media Type The official “media type” terms are generally useless for the end user Books and anything else that doesn’t need a player of some kind are “unmediated” Online resources are “computer” rather than “electronic” Others merely duplicate the list of carriers Audio, video, microform Maybe these will be more useful for computer-based record processing than they are for end users

Carrier Type The official “carrier type” terms are more numerous than the GMDs, but are potentially more useful to end-users Many are a little more specific than the GMD Instead of “sound recording”, there is “audio disc”, “audiocassette”, etc. Instead of “videorecording”, there is “videodisc”, videocassette”, etc. But still not all that specific DVDs, Blu-rays, HD-DVDs, and laserdiscs are all “videodisc”

Qualified GMDs Some sites (including mine) locally modified audio-visual GMDs with more specific qualifiers Following the precedent set by AACR2 1.1C1’s use of “text (large print)”, “music (braille)”, and “cartographic material (tactile)” sound recording (CD) sound recording (Cassette) videorecording (Blu-ray) videorecording (DVD) videorecording (VHS) electronic resource (CD-ROM) electronic resource (Wii) electronic resource (Xbox One) In RDA, this data is usually in the 340-347 fields

Qualified GMDs These qualifiers are often represented in some way in the 007 and 340-347 fields 007: Physical description fixed field 340: Physical medium 345: Projection characteristics [for movies] 346: Video characteristics [for videocassettes] 347: Digital file characteristics [including CDs and DVDs]

Qualified GMDs Spreading this data among so many fields can make it difficult to easily pull it together in a way that will be coherent for end users Coming up with something patron-friendly may require some complex programming—not something every library is going to be able to do in-house

Possible Solutions

Possible Solutions Keep using the GMD Create a new field Display the Carrier Type Display the Carrier Type & Content Type Display Other Physical Information Display format icons Display Item Type or an Item Category

Keep Using the GMD Continue to record GMD in the 245 subfield h Advantages Matches existing records Uses standard rules rather than making up your own Can be included as part of the title in displays Can be scripted in Connexion, MarcEdit, etc. Disadvantages Can be tricky to automatically insert it in the correct place Will involve more local work as time goes on and fewer records are done according to AACR2R

Create a New Field Perhaps a field in the 900s, or maybe a 290 or 390 field Some options for what to put in the new field RDA Carrier & Content Types ISBD Content Form & Media Types ( |2isbdcontent |2isbnmedia) “image (moving ; 2-dimensional)” instead of “two-dimensional moving image” http://www.ifla.org/node/5618 http://www.ifla.org/files/assets/cataloguing/isbd/area-0_2009.pdf MARC Specific Material Form Term list ( |2marcsmd) Human-readable version of 007/01 values sound disc, videodisc, large print, atlas, etc. http://www.loc.gov/standards/valuelist/marcsmd.html MARC Genre Term list (|2marcgt) art original, comic or graphic novel, videorecording http://www.loc.gov/standards/valuelist/marcgt.html AACR2R GMD list Create your own list

Create a New Field Define your own local “format” field Advantages Easier to write scripts to automatically insert an entire field than to insert text into an existing field Since it’s purely local practice, the your list can include whatever would most benefit your users Including the GMD list, or a different standard list Could be added to Workflows & e-Library hit lists Could be added as a search facet in Enterprise Disadvantages Will never be present in records you import Not part of “title” field displays in WorkFlows New employees won’t be familiar with the practice

Keep Using GMDs & Create New Field These approaches may work better for libraries who generally do not acquire catalog records from elsewhere Also for those who already frequently add fields to most catalog records they acquire from WorldCat or elsewhere Otherwise, over time these approaches will be harder to maintain as other libraries move away from using the GMD Few or no new records will already include the data Newly hired catalogers will need extra training in how to assign local GMDs

Display Carrier Types One common suggestion for replacing the GMD is to display the RDA carrier type somewhere near the title Add the field to WorkFlows, e-Library, or Enterprise hit lists In WorkFlows & e-Library hit lists, when a record has multiple 338 fields, only the first will display In Enterprise, it can also be a search facet In e-Library or Enterprise, it can be displayed in square brackets if that makes people more comfortable

Display Carrier Types Advantages Disadvantages Similar to the existing GMD lists No need to edit this in all new records Helps make old and new records look similar In Enterprise, multiple carrier types can all show up Disadvantages “Legacy” AACR2, AACR1, etc. records use different terms Not as specific as some libraries would prefer Displays for multi-format items may be confusing Workflows & e-Library display fields may already be used

Mapping GMDs to Carrier Types GMDs (LCRI 1.1C) Carrier Type (338) electronic resource filmstrip graphic microform motion picture online resource computer disc computer chip cartridge filmstrip codes for graphics vary microfilm microfiche film reel

Mapping GMDs to Carrier Types GMDs (LCRI 1.1C) Carrier Type (338) slide sound recording transparency videorecording slide audio disc audiocassette overhead transparency videodisc videocassette

Displaying Carrier & Content Types Another common suggestion is to display both Carrier Type and Content Type For WorkFlows & e-Library: Add fields 338 & 336 to the “FULL” entry list for each catalog format, right after the 245 field The carrier & content types will display on the line after the title in full record displays In Enterprise: Create a MARC Map & Search Field containing the 338 & 336 fields Add that to a profile’s search display & detail display

Display Carrier & Content Types Another common suggestion is to display both Carrier Type and Content Type Advantages No need to edit this in all new records Helps make old and new records look similar In Enterprise, multiple fields will all show up Disadvantages “Legacy” AACR2, AACR1, etc. records use different terms Displays for multi-format items will often be confusing Workflows & e-Library display fields may already be used

Mapping GMDs to Carriers & Content GMDs (AACR2 1.1C) Carrier : Content (336) activity card braille cartographic material kit music realia text card : still image volume : tactile text sheet : cartographic image Each format in the kit gets its own content/ media/carrier fields sheet : notated music object : other volume : text

Display Other Physical Information A solution with more detailed results than the others is to display the detailed physical information from the 34X fields Alone, or in conjunction with the Carrier Type and possibly also the Content Type May better match locally customized GMDs

Display Other Physical Information The information is sprinkled across several fields 340 $n large print $2 rda 345 $a 3D $2 rda 346 $a VHS $b NTSC $2 rda 347 $a audio file $b CD audio $2 rda 347 $a audio file $b MP3 $2 rda 347 $a video file $b Blu-ray $2 rda 347 $a video file $b DVD video $2 rda And most of it is present in coded form in 007 fields Even in AACR2R records

Display Other Physical Information Display just the relevant subfields for user-friendly displays Samples CD audio MP3 DVD video Blu-ray Could display 338 : 336 : 340n 346a 347b 345a to mimic many common qualified or local GMDs videodisc : two-dimensional moving image : Blu-ray audio disc : performed music : CD audio volume : text

Display Carrier Type & Physical Info Much of the data in the 34X fields is also present in 007 fields Even many AACR2 records will already contain the relevant 007 fields Not quite all of the data in 34X fields is also present in 007 fields 007 fields exist exclusively in fixed-position coded format So when 34X fields are not available, the data would have to be parsed & converted by display routines into something human-readable

Display Carrier Type & Physical Info Advantages Can be very detailed Typically are terms users are familiar with Disadvantages Fields 345-347 aren’t in common use yet, though that’s improving Field 340 for large print may not come into common use May use very unfamiliar terms E.g. Playaway audiobooks often show up as just “ACELP” When combined with Carrier Type, displays get long & stodgy Displays for multi-format items will likely be even more confusing than the previous suggestions

Format Icons Icons can be used to visually indicate the format Commonly used by OPACs, discovery services, and other web sites They can usually be displayed based on existing data Thus might be made to work with both AACR2R- and RDA-based records They can usually be accompanied by text, either next to the image or as the image’s “title”, for use by screen readers and other tools for people with impaired vision.

Format Icons Enterprise defaults to using format icons on the hit list Based solely on the record format and the first two positions of each 007 field Multiple formats = multiple 007 fields = multiple format icons Also includes 007 fields of any MARC Holdings records Must add an 007 field to every large print & braille book record if you want “large print” & “braille” icons Few libraries normally use either one Can’t differentiate between laserdisc, DVD, and Blu-ray Default icon for all three includes the text “DVD” in the image Can’t differentiate between LP and CD

Format Icons E-Library can be customized via API to display format icons for all formats, using all 006, 007, and 008 fields Enterprise widgets could be used to generate format icons based on Carrier Types or all 006, 007, and 008 fields rather than on Enterprise’s “format” field Would not impact the “format” facet, though BlueCloud Cataloging client will likely be able to display format icons for staff Using the same criteria as Enterprise

Mapping Format Icons

Format Icons Advantages Disadvantages May not need to edit records to implement Generally language-independent Unlike the GMD, 33X, and 34X fields Can make it easier for users to quickly scan through hit lists In Enterprise, can make it easier for patrons to realize when they need to include a format facet to get more focused results Can sometimes be based on data anywhere in the MARC record Disadvantages Cannot affect the facet text & indexing that are part of Enterprise’s default icon functionality Workflows cannot display format icons Complex data mapping can require a lot of detailed script programming Need alternatives for people with impaired vision

Display Item Type or Category Another option is to use the Item Type or one of the Item Category fields and either display the policy description or use the field as the basis for assigning format icons Advantages Fields already exist in the database Can be used as Enterprise facets Doesn’t require altering existing or imported catalog records Works equally well with both AACR2 & RDA records Disadvantages Item Types often aren’t descriptive or many types share the same description “21 Day Loan” or “DVD” vs. “DVD-NOHOLD” Different copies may have different values Especially in a consortium

Which Method is Best? Unfortunately, there isn’t a clear front-runner that is objectively the best practice for most libraries All of these approaches have significant pros & cons An approach that works well enough for one library may not work at all for other libraries

Retrospective Conversion

Retrospective Conversion Retro-converting existing AACR2 (and AACR1) records to match new RDA records lets you use only one scheme for identifying formats RDA-specific fields are valid for use in existing non-RDA records Just like every other field that is valid in MARC but not prescribed by AACR2 Otherwise, every format-related process must account for two (or more) possibly very different ways of encoding If one encoding method is ignored, then those records, and thus that entire segment of your collection, becomes more inaccessible

Retrospective Conversion Export, Edit, Re-import Globally edit in place Symphony API Manual labor

Export, Edit, Re-import One way to globally add these format fields to existing AACR2 (or even AACR1) records is to export the records, use a third-party editor to insert the fields, then re-import the records MarcEdit, by Terry Reese (free) http://marcedit.reeset.net/ MarcReport with MarcGlobal, by TMQ (not free) http://www.marcofquality.com/soft/softindex.html Some vendors offer conversion/enrichment services to upgrade records from AACR2 to RDA Marcive, Backstage, and others Can also fix other problems at the same time

Export, Edit, Re-import Some vendors offer conversion/enrichment services to upgrade records from AACR2 to RDA Marcive, Backstage, and others Can also fix other problems with your older records at the same time The export & re-import parts of the process work the same as if you had edited the records yourself

Export, Edit, Re-import If you do not have a guaranteed unique match point, be sure to include your current Title Control Number in the exported data Then you can match on it when re-importing the records When re-importing many thousand records, either Break up the files and load a few thousand a day (small enough for your server to handle with the nightly run of the adutext report), or Load all of the records with the “Bibliographic Database Overlay” report (a.k.a. bibloadbatch) and then rebuild your text indexes and headings database This report does not mark records for overnight reindexing

Globally Edit in Place The delivered “Edit Database Globally” report (a.k.a. globaledit) can edit or remove existing fields No export needed Cannot insert new fields Could be used to globally remove the GMD from older records Use #0 as a search string to select your entire database Use \ to make certain metacharacters function as metacharacters \[|] will match a subfield delimiter Be careful about the impact on the nightly reindexing report May want to use format, date, etc. selection to limit how many records are edited per run

API SirsiDynix has several API tools that can help, too If you haven’t taken the API class, cover your eyes for this slide editmarc: same tool as the Globaledit report, except it can do more than the report can editrawmarc: Same thing as editmarc, except it works on files of records rather than on the database catalogmerge: Can insert fields into existing records flatskip: Can turn exported MARC records into human-readable text Makes it easier for Perl scripts or shell scripts to edit, insert, or delete fields

Good, Old-fashioned Elbow Grease For some types of changes or for some libraries, there may be no better method available than manual labor Windows keyboard macros can automate some of the process Open a record, add a field in the proper place in the record, then press a key combination to insert the proper field text Split up lists of records among several people over the course of several months or years to spread out the load Perhaps recruit volunteers from public service librarians If the end result will greatly aid their ability to find records and help library users, it’s in their best interest to help the project get done faster An excuse for a “get to know each other” or “shared hardship brings us together” bonding exercise that could help open lines of interdepartmental communication

Conclusion

Conclusion

Any questions?