1 of 15

MarcEdit/Alma Integration

Israel Yáñez�ULMS Technical Services Open Forum

July 21, 2022

2 of 15

Overview

MarcEdit�
MarcEdit/Alma integration�
Batch editing bibliographic records�
Batch editing holdings records�
MarcEdit/Alma integration vs. Alma normalization processes

3 of 15

MarcEdit

4 of 15

MarcEdit

5 of 15

MarcEdit

So that’s what we see here in the main window.��The delimited text translator will take data from a delimited text file, or an Excel spreadsheet, and create MARC records.

The merge records tool is exactly what it sounds like– merging metadata from two MARC files, as long as the records in the two files have a common identifier to match on. In Alma records, for example, that could be the MMSID field or the OCLC number.

I use the Export Tab Delimited tool often, and that’s used to select specific MARC fields and export that metadata from MARC records to create a tab delimited file which you can open in, or convert to, Excel.

The MarcEditor is the interface you use to review and edit MARC records. In the MarcEditor, you can globally add or delete fields, subfields or indicators. And you can use regular expressions. The MarcEditor displays MARC records in a mnemonic, or readable, format.

So, when we export bibs from Alma, or receive a MARC file of records from vendors, those files are typically in binary MARC, and you’ll see a .mrc extension. What MarcEdit will do is transform that binary marc file into a mnemonic format and display it in the MarcEditor. You could then review your records, make your edits if necessary, and then compile the file back into binary MARC.

6 of 15

Binary MARC (.mrc)

7 of 15

Mnemonic MARC (.mrk)

So you can read it more easily. And the file extension is different– .mrk.

This may still look a little foreign to you if you’ve never worked in the MarcEditor before, but once you realize that each MARC field begins with an equal sign, and that the back slashes after the MARC tags simply represent blank indicators, it starts to make a little more sense. We only see one record in this screenshot, but if there were more records in this file, each record would be separated by at least one blank line. We’ll see an example later.

So, that’s a very basic introduction to just a few of the tools available in MarcEdit, the MarcEditor, and the differences between a .mrc and a .mrk file. If there is interest, we could have a more in-depth session on MarcEdit on another occasion. I’m sure I’m not the only one who uses it, so that could be an opportunity to collaborate on a presentation. For today, we’ll focus on the MarcEdit/Alma integration.

8 of 15

MarcEdit/Alma Integration

Obtain Alma API key �
Set up SRU integration profile in Alma�
Configure MarcEdit

This integration allows MarcEdit to search and retrieve Alma records. You can then make global edits and update the Alma records from within the MarcEditor.

The first couple of things you need to do is obtain an Alma API key that supports the Bib API and the User API. The Bib API must be read/write, and the User API is necessary for authentication purposes. You also need to set up the SRU integration profile in Alma. If you don’t have the Alma role to set up this integration profile, you can probably talk to the Alma administrator for your campus and they can take care of that for you. They can provide the API key as well.

Once you have those first two items taken care of, you can configure MarcEdit for the integration. It’s somewhat involved, but relatively simple. I’m sharing local procedures I put together for Sac State. You’ll find those on the Resources slide at the end of this presentation.

9 of 15

Editing Bibliographic Records

Search and retrieve Alma records from within MarcEdit �
Can only add local extensions/fields to NZ-linked records�
Requires $9LOCAL at end of local fields�

10 of 15

Editing Bibliographic Records

11 of 15

Editing Holdings Records

No restrictions on fields you can add/edit�
Includes 999 field with MMSID in $b and holding ID in $d

12 of 15

Editing Holdings Records

13 of 15

MarcEdit/Alma integration:�

Will update bib and holdings record even if the records are open in the MDE
Easy to view, select, and edit multiple records
Possible to move metadata from bibs to holdings with Merge Records tool
Apparent limit to number of records it can handle in one batch edit�

Alma:�

Does not yet run jobs on sets of holdings records
Norm processes can handle a larger number of records�

A comparison between the two approaches for batch editing Alma records–

When you run a normalization process on a set of bibs in Alma, the norm process will not act on any records that are open in the metadata editor. Meaning that if you, or any of your colleagues have any of those records open, those records will not be affected by the norm process. With the MarcEdit/Alma integration, the API will update the record, EVEN if someone has it open in the metadata editor. However, if whoever has that bib open SAVES that record instead of simply releasing it, then the API changes will be overridden with the older version of the record. In my experience, typically I’m the one who has had the record open in Alma, so I know to not save the record if the API has just made a change.

(this is my opinion) MarcEdit is a more nimble and powerful tool for selecting and editing MARC records, so working with Alma records within MarcEdit can be more efficient, and it’s easier to review multiple records because you have them open in a single file.

You can’t use Alma norm processes to move metadata from bibs to holdings records, but you can move metadata from Alma bibs to Alma holdings using a workflow involving the Merge Records tool in MarcEdit. I won’t demonstrate that today, but I can confirm that we’ve done at least a couple of projects using this method at Sac State. We had serials summary holdings statements in a bib 9XX field, and we were able to move that metadata to the holdings record. And I believe, more recently, we moved local notes from the bibs to holdings records for special collections.

The integration does have an apparent limit to how many records it can handle. For now, I’m keeping batches of records to under 1,000.

In Alma, while you can create sets of holdings records, the change holdings information job will only run on sets of physical items and physical titles; you can’t run that job on a holdings set, as far as I know.

The one advantage Alma normalization processes have over the integration is that Alma can handle a larger number of records than the integration. Like I said, I haven’t attempted more than a 1,000 records at a time with the integration. Still, using the MarcEdit/Alma integration is very effective for batch editing if you can break up your project into records of 1,000 or less.

14 of 15

I have this short recorded demo of the integration retrieving Alma bibs, editing them in batch, and updating them from within MarcEdit. I recorded this demo last month because I needed to update these records in Alma then and because July is a slow month in terms of new materials coming in, I wasn’t sure I’d have a live example for this process.

Some background on this use case– we have a Greek collection, the Tsakopoulos Hellenic Collection, and all the bibs for the resources in this collection get a local extension 973 field.

Part of what I’ve been doing, in an effort to streamline our copy cataloging workflow is to minimize the number of things copy catalogers have to look out for– for example, whether a resource is part of the Tsakopoulos collection, or whether it needs a digital bookplate. Especially if these fields can be added in batch. So, I’ve created Analytics reports and I’m using widgets to keep on top of these, and in turn, the copy catalogers have two fewer things to look out for in their workflow.

15 of 15

Resources

MarcEdit Downloads�
MarcEdit Field Guide�
MarcEdit 101 Webinar Series�
SRU/SRW Search (Ex Libris Knowledge Center)�
MarcEdit/Alma Integration (Sac State instructions)�With links to Ex Libris and Terry Reese documentation