This page describes mapping in RIMMF1; it needs to be rewritten for RIMMF2!
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:
This will have put you at the start of the element list for Person.
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 treatment1).
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)
2).
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.
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 them3).
And yet, at present, MARC is what we have to work with. So, within these constraints, it may be worth improving4) 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.