Skip to Main Content
It looks like you're using Internet Explorer 11 or older. This website works best with modern browsers such as the latest versions of Chrome, Firefox, Safari, and Edge. If you continue with this browser, you may see unexpected results.

Yale Library

Reparative Archival Description Working Group: Versioning MARC records


One of RAD's recommendations, in line with its guiding principle of transparency, is to "Provide access to previous versions of records [...] RAD recommends providing access to previous versions of records to patrons upon request, as well as retaining these records internally."

Yale University Library's current Integrated Library System (Voyager, which is the backbone of the library's catalog) does not have versioning functionality. Staff members conducting reparative archival description should therefore follow one of the processes below; both processes require capturing "before" versions of records before any reparative changes are made.

Process for RAD Reparative Work and Other Programmatic Work

  1. Before making any changes, compile a list of all bibIDs that are going to be changed. Put the list in an Excel spreadsheet. Make note of how many records you’re working with, as you’ll need that number in step 4c. 
  2. In the YUL MARC Self Service Tool (; requires campus access or VPN connection; more information is here:, copy and paste the list of bibIDs into the Paste BibIDs or item Barcodes tab. As indicated in the YUL MARC Self Service Tool, the bibIDs should be separated; it’s easiest to put them on separate lines, as that’s how they’ll be copied over from Excel. Click Submit.
  3. Retrieve the automatic email from the MARC Self Service Tool, which will have a subject line like “MARCexport Self-Service files are ready.” Save the bib .mrc file (not the one with the mfhd information) attached to that email to your computer. This .mrc file will have all bib records you’ve retrieved stored in a single file.
  4. Using MARCEdit, split the .mrc file into the appropriate number of MARC records by doing the following:
    1. Open MARCEdit, click MARC Tools, click the yellow wrench in the upper left corner, and select MARCSplit.
    2. In the MARCSplit Utility window, navigate to your .mrc file in the Source File field. Select any destination folder you’d like the split files to go to in the Destination Folder field.
    3. In Options, indicate how you’d like the files split. For this purpose, you’ll want 1 record per file. This means that, for example, if you retrieved a .mrc file from the YUL MARC Self Service Tool of records for 6 bibIDs, you’ll enter 1 in the Records per File field; check the # of files box; and enter 6 in the # of files box. Hit Process. When the Save File Name menu pops up asking if you want to use a control field in the file name, enter 001, as that should name the records with the bibID.
  5. Once you have your separate .mrc files, convert them in bulk to .mrk files by doing the following:
    1. Put the .mrc files in a designated directory
    2. Open MARCEdit; click MARC Tools; click the yellow wrench in the upper left corner; and select Batch Process Records.
      1. In the Batch Process Records menu, select your Source Directory where you’ve put the .mrc files.
      2. In the Options pane, put .mrc in the Process Files Type field and .mrk in the Output File Type field.
      3. Hit process
  6. Once you have your separate .mrk files, confirm contents look correct by opening a sample in WordPad or a similar tool, and then upload them to the yul-marc GitHub repository ( You’ll upload the files in a commit. You may optionally include an “optional extended description” of the commit in GitHub (e.g., MARC records for single items and collections pertaining to Japanese American incarceration during World War II, prior to reparative description edits.)
    1. Note: Contact the Archival and Manuscript Description Committee if you require upload access to the GitHub repository.
  7. Make your desired changes in Voyager.
  8. Repeat steps 1-7 for the updated files. Since the .mrk files with the updates should and will have the same filename (i.e., [bibID].mrk) as the .mrk files for the pre-updated records, GitHub will automatically version the files in the repository.
  9. You’re done!

Process for One-Off Updates

  1. Before doing any work, determine whether you’re going to be making changes to several records or whether you’ll be working with a single record or one-off edits. If you’re working with several records, consider following the Process for RAD Reparative Work and Other Programmatic Work. If you’re working with a single record or with one-off edits, consider following the below procedure.
  2. Before making changes, capture the existing version of the MARC record by opening it in Voyager, going to File, and saving the record to your computer. Name it with its bibID as the filename (e.g., 4780407.bib).
  3. Open MARCEdit, click the MARC Tools option, and use MarcBreaker to convert the .bib file to a .mrk file by doing the following:
    1. Make sure MarcBreaker is listed under Select Operation. 
    2. Under Select Data to Process, navigate to your saved .bib record in the Open… field by clicking on the folder icon to the right of the field. You may need to change MARC Files (*.mrc) in the dropdown menu in the bottom right corner of the navigation pane to All Files (*.*) in order to get your .bib record to display. Once you’ve navigated to it, hit Open.
    3. In the Save As... field, click the folder icon with the green arrow to the right of the field to specify where and how to save the file. Select MARC Text File (*.mrk) in the Save as type menu.
    4. Leave the current Character Encoding Options in place (should say Default Character Encoding: MARC8, and Translate to MARC-8 and Translate to UTF8 boxes should be unchecked).
    5. Click Execute.
  4. Once you have your .mrk file, confirm that it is named with the appropriate bibID (e.g., 4780407.mrk) and upload it to GitHub.
  5. Make desired changes to your record.
  6. Repeat steps 2-4 to upload the new version of the record to GitHub.