MARC Mapping in RIMMF

The first version of RIMMF supports a simplistic MARC mapping.

By this we mean you can fill out the appropriate MARC coding for the RDA2MARC columns in your templates for the entities using the element editor (which we will describe below), and then, when editing/saving a record for an entity, you can press <F9> and RIMMF will create a MARC record from the RDA data (and put that record in your data folder), using the mapping that was specified in the RDA2MARC column for that entity.

Note: this page was written at a time when RIMMF supported only RDA-to-MARC mapping; beginning with RIMMF version 120622, we have started to experiment mapping MARC-to-RDA (via the program's new 'Linked Data Demo' tool). Thus, this page is subject to a lot of change (and perhaps needs to be split into two pages, one for each mapping direction).

Warning About the RIMMF implementation of mapping

Yes, it is possible to customize the mapping in RIMMF but we do have the problem in version 1 of RIMMF of not being able to preserve user customizations to the default RDA elements. Thus, its possible (even likely) that if you customize the mapping fields using the element editor, the next time you update RIMMF, your customizations will get clobbered. This is just bad design on our part. It will be fixed in the next major RIMMF release, when we plan to move the mapping support into a separate module, where we can support multiple mappings for each element.

There are four fields in the Element Editor that you can use to control MARC mapping from RIMMF data to MARC records.

For example, you could customize the MARC mapping for Person data this way:

• Go to the RIMMF main menu
• Under the 'Edit menu', open the Element Editor
• Under the Element tab, set the 'FRBR Entity' to 'Person'
• In the box for Element Name list, select 'addressOfThePerson':

This will have put you at the start of the element list for Person.

• Now, switch to the RDA tab of the Element Editor, and find the four 'MARC' boxes in the middle of the form:

• Find the 'Rda2Marc/A' box: this is where you can enter the instructions to map the data from an RDA record made in RIMMF to the appropriate fields/subfields in a MARC Authorities (A) record.
• Use the appropriate Mapping Syntax (explained below) to specify the MARC field, indicators, and subfield for the RIMMF data.
• Click the <Next> button to on to the next Person data element in the list, and map that element
• Close this window (using the <x> button on the top right corner, when you are finished
• What you have entered in this Element Editor, will now show up in the appropriate column in your template and in any records you make, using that template

Note that in this version of RIMMF, only the the RDA2MARC mapping is supported, but you may seem some MARC coding in the other MARC boxes, as we also try to work out how to set this up. Because we are also working on this MARC mapping, we recommend that you copy our default TMQ template and customize it, so that you do not lose your changes when you update RIMMF.

In version 1, we have, so far, provided a basic mapping for the Person entity only; since it seemed to us that these Person 'records', going from RDA to MARC, were the most amenable to such treatment¹⁾.

So, you should see a value in the 'RDA2MARC/A' boxes of the Element Editor for most of the elements for Person. You can scroll through all of the Person elements by pressing the Prev and Next buttons at the bottom-left corner of the page (not shown above)

²⁾.

RDA-to-MARC

The syntax you must use in order for <F9> MARC record creation to work, is as follows (using the example of the MARC 100 tag):

no               --do not map the RDA element to the MARC record
100              --map RDA element into Tag 100 subfield $a with blank indicators
100\\            --ibid
100\\a           --ibid
100\3 \          --map RDA element into Tag 100 subfield $a with Ind1 = '3' and Ind2 = blank
100\3 \a         --ibid
100\\q           --map RDA element into Tag 100 subfield $q

Control number

The RIMMF Id for the record is mapped into the MARC 001 field. You may additionally map the RIMMF Id into an 035, as we do in the default mapping provided.

Default mapping

Any RIMMF element that contains data, but does not contain a mapping value in the RDA2MARC column, will be mapped to a 999 tag in the MARC record that is created. Use the “no” mapping to disable this behavior.

Literal data

Literal data may be added to a mapping; literal data is any string that follows the subfield in a RDA2MARC mapping. A pre-requisite for a literal is that a subfield be specified; if it is not, the program will use the first character of your literal as the subfield. For example:

035\\a(RIMMF)  --maps RDA element into Tag 035 subfield $a following literal '(RIMMF)'

but not:

035\\(RIMMF)  --maps RDA element into Tag 035 subfield $( following literal 'RIMMF)'

And, of course, to support our beloved fixed fields, we need to add support for indicating a position (0-based, as in LC documentation); we do this using a single forward slash following the tag:

008/32b        --map RDA element into Tag 008 position 32 as literal 'b'

MARC-to-RDA

When mapping MARC to RDA, do not use the shortcuts shown above. Indicators and subfields must always be explicitly stated. For example:

375\\a           --map tag 375 subfield a, regardless of indicators, into the RDA element

and not:

375  

When specifying indicators, the dot or period ('.') will match any single character:

100\3.\a         --map tag 100 subfield a when Ind1 is '3' and Ind2 is any character or blank

To map the complete contents of a MARC field to an RDA element, use the word 'all' (with no intervening spaces):

100\\all         --map MARC field 100, regardless of indicators, to the RDA element

If the data being mapped from MARC may be found in more than one location, enter all of the locations that you want to check, in order of preference, and separate each with the word ' or ':

100\0.\q or 100\1.\q  --if 100 I1=0, then map $q into the RDA element; else, if 100 I1=1 then ...

If instead, you want to map more than one MARC tag to the same RDA element (eg. Identifier for the Manifestation), then enter all of the locations that you want to map to that element, and separate each with the word ' and ':

010\\a and 035\\a   --map both MARC tags into the same RDA element (the element is repeated for each tag)

The syntax above is all that is supported at present.

Here is a snapshot of an RDA record for a Person in RIMMF:

Here is the 'same record' in MARC Report, after being converted to MARC (Note: When pressing <F9> in RIMMF, if the conversion is successful, RIMMF will add the caption '+MARC' to the window banner–as a simple visual indication that 'something' happened):

There are obvious shortcomings to the resulting rudimentary MARC record.

1. The leader, and especially the fixed field (008), are pretty much left to one's imagination–lots of blank spaces!
2. There is no way, as of yet, to indicate that separate elements that are mapped to the same MARC field should be concatenated in that field. So, when exporting a Person record to MARC, if the Person has both Date of Birth and Date of Death elements assigned, the resulting MARC record will contain two 046 fields, one with subfield $f (for Date of Birth), and one with subfield $g (for Date of Death).
3. There is no parsing performed on the data on the RDA/RIMMF side of the mapping. For example, as shown above the Authorized Access Point (for a Person), contains a name and a date (Marsh, Ngaio, 1895-1982), and in the resulting MARC record, the entire string is given in a 100$a Marsh, Ngaio, 1895-1982–this will, of course need fixing.
4. The mapping performed by RIMMF is extremely literal. So, for example, you cannot map both Preferred Name for the Person and Authorized Access Point (for the Person) to a 100 tag, because the result will be two separate 100 tags in the MARC record–not a good idea.
5. Note that if you remove the mapping of Preferred Name for the Person to a 100 field, and just leave the mapping for that element blank (as #4 above would suggest) then that element is currently exported in a 999 field–the bit bucket used by RIMMF for any data in the RDA record that is not mapped to a MARC tag. We are considering adding a code (to the 'syntax' above) that will cancel this behavior, i.e., a 'do not map' instruction.

Our current thinking on this subject is that the RIMMF 'Create MARC' option can make a rudimentary MARC record, and then that MARC record can be upgraded manually (perhaps with some assistance of some macros, scripts, XSLT, etc., can be run on the MARC end).

We considered adding local 'MARC' elements to special RIMMF templates to make the initial mapping to MARC cleaner, but RDA is not burdened with punctuation, fixed fields, subfields within fields, fixed-length control subfields, etc., and we think it is probably best to keep the RIMMF templates as RDA would have them³⁾.

And yet, at present, MARC is what we have to work with. So, within these constraints, it may be worth improving⁴⁾ the MARC mapping to make the RDA2MARC records as complete as possible, leaving as little as possible for manual upgrading. That way, you can create the data, thinking RDA, and convert that data to MARC for your ILS, for now.

Note that you can open the MARC record in MARC Report and you will be given all sorts of hints and helps to ensure that you make that 'rudimentary' MARC record into something that your ILS system can work with. Just find your record in your 'data' folder, double click on it, and (as long as you have a MARC Report subscription) you will be able to edit the record with our hints for things to remember. And if you have MARC Global, you will be able to set up Auto Reviews to do macro-type things to each record, to save yourself even more time. Click here for more information on MARC Report and MARC Global.