RIMMF2: MARC Mapping Notes

[RIMMF2 is currently under development]

Most of the notes here are written from the perspective of RDA2MARC rather than MARC2RDA.

There are two components of a MARC mapping in RIMMF:

• The mapping context
• The mapping instruction

RIMMF supports five mapping contexts for each element:

• R2M/B (RDA to MARC Bibliographic)
• R2M/A (RDA to MARC Authorities)
• As AAP ('As Authorized Access Point', or Composite Key)
• M2R/B (MARC Bibliographic to RDA)
• M2R/A (MARC Authorities to RDA)

The current mapping context is always highlighted. In the above example, the current context is R2M/B.

The mapping instruction contains the code (presented in a human-readable table) that the program will use to place RDA element data in a MARC record. RIMMF supports one mapping instruction for each context. Thus there may conceivably be five different mapping instructions for an RDA element.

The 'AsAAP' context is used in two situations

1. First, this context contains the mapping instruction for authority headings when they are used in bibliographic records (example, Creator Of A Work)
2. Second, this context contains the punctuation used during the auto-composition of an entity's AAP or CK

[this explanation needs to be improved]

The fields available in the mapping instruction form should be self-explanatory, with the following exceptions.

Condition

The first column, the one without a label, is called 'Condition'.

If the mapping for an element requires only one row, this column is blank.

If the mapping for an element requires two rows, the condition will be one of the following:

• and
• or
• 2+

'and' and 'or' are unlikely to be used in the RDA2MARC mappings (they are more useful in the MARC2RDA mappings).

'2+' indicates that the first row of the mapping is to be applied only to the first occurrence of an element, and that the second row should be applied to all subsequent occurrences of an element. For example:

The purpose of '2+' is to make it possible for RIMMF to correctly handle repeating elements in a MARC subfield, via a default mapping (as opposed to the user needing to customize a mapping whenever an element repeats).

'2+'

Note: In the event there are more than two rows in a mapping, all subsequent rows after the first must have the same 'condition' value.

Tag

The Tag column must contain one of the following:

• A three-digit tag (Note: Do not use 'XX' tags in RDA2MARC mappings)
• One of the following directives: 'no', 'same', 'new', 'bib', 'auth'

The directive 'no' means that the element is not to be mapped in the current context.

Note: when the 'no' directive is entered into the Tag column, all other columns, except Punct, are ignored. The reason for this exception is to give us a place to specify the punctuation that precedes an RDA Element when it is used as an AAP component¹⁾; in such cases, the MARC tag is determined elsewhere (from the mapping instruction for the AAP element itself).

The directives 'same' and 'new' are valid only with the condition '2+'²⁾; 'same' means that the subsequent occurrence is placed in the same tag; 'new' means that a new tag should be created for the subsequent occurrence. In either case, 'Tag' should be taken from the first row of the mapping.

On the contrary, the 'bib' and 'auth' directives are valid only in the first row of a mapping. These directives are intended to be used only with the identifiers for relationships; their purpose is to tell RIMMF whether or not it should 'follow a link' to a relationship and map the relevant data from that relationship back into the current record.

Note: when a 'bib' or 'auth' directive is entered into the Tag column, all other columns are ignored.

In the example above, we see the 'bib' directive used as the RDA2MARC/B mapping for an Expression Manifested element: RIMMF will follow the link from the manifestation into the expression (qpq00000059), and then process any elements in the expression that contain mapping instructions for the R2M/B context (just as if they were in the manifestation record themselves).

Indicators

These columns should contain the values to be placed in the corresponding MARC Tag; if no indicators are entered, the program will save them as undefined (As opposed to blank)

Punct

This column should contain the ISBD punctuation for the element.

Subf

This column should contain the subfield for the element in the corresponding MARC Tag. If the MARC Tag indicates a fixed field, this column should contain the position of the data element in the field (eg. Language of the work might map to 008 35, and '35' would be entered as the subfield value).

Constant Data

Any text entered into thee ConstData column is prepended to the user text in mapped record, with the following exceptions:

• If the text ends with '$', the '$' is removed and the ConstData is appended to the user text

This goes at the end of my field$

• If the text begins with '$' (to indicate the beginning of a subfield), the '$' is preserved and the ConstData is appended to whatever text is mapped for the element:

$2rdamedia 

• To force a complete subfield to be prepended to the mapped text, prefix it with '^':

^$6880-01

• To specify a literal '$' at the end of the ConstData, escape it with '\':

\$

In RIMMF2 we have a new table called customProperties, which is a mirror of the default Properties table; customProperties contains user values for all user-customizable fields. This new design makes it possible for user customizations to persist during an update without any special action by either the program or the user.

When a record is displayed in RIMMF2, the mapping data for each element is populated in the following order of precedence:

1. from any mapping for that element explicitly specified in the record; or, if none, then
2. from any mapping for that element defined by the user as a default (customProperties); or, if none, then
3. whatever mapping is present for that element in the TMQ default table (Properties)

While editing a record in RIMMF2, if the user changes a mapping, that change will be written to the record; in addition, if they press 'Make default', that change is also written to the customProperties table.

When a record is saved in RIMMF2, the program fetches the mapping value for each element (based on the current context; eg. for manifestation, the context is bib; for work, the context is auth; etc.) using the hierarchy specified above (1, 2, 3).

If a fetched mapping matches the TMQ default (from the Properties table), no mapping is output for that element; but if the fetched mapping comes from the customProperties tables (ie. a user default), or from the mapping form itself (because the user manually entered a mapping), that mapping is written to the record.

Problem: Sometimes we want Element B to be mapped to the same Tag/Subfield as Element A, without creating a new Tag/Subfield occurrence, but with a piece of punctuation between Element A and Element B in the mapping.

Example:

Place of Publication: Atlanta
Place of Publication: Chicago
Publisher's Name: American Library Association
Publisher's Name: Grossett

Solution: Use the '2+' mapping condition to create an alternate mapping for the repeated 264 $a (and do the same for $b):

    264\.1\a\/\\
2+ same\.1\a\;\\

The use of 'same' in the Tag column says that a second (or greater) occurrence of 264 .1 a goes in the same Tag/Subfield as the preceding element, but with punctuation of ';'. The result is:

264  1 $aChicago ;$aAtlanta :$bAmerican Library Association ...

Note: If we do not want to repeat the subfield, but simply insert the punctuation, then omit the subfield from the 'same' mapping. For example:

Statement of Responsibility Relating to Title Proper: Deborah A. Fritz
Statement of Responsibility Relating to Title Proper: Richard J. Fritz

Omit the 'c' from the 'same' row:

    245\..\c\/\\
2+ same\..\\;\\

to get:

/$cDeborah A.Fritz ; Richard J. Fritz

In the second case, the mapper always adds a blank space in the position where the missing subfield normally would be found.

Implementation Issues: the mapper must watch out for differing element occurences in these 'same' mappings, because occurences are a potential a trigger for the 'tag grouper' to generate a new occurrence of a tag.

For example, the raw record for the above looks something³⁾ like this:

  rName=placeOfPublicationManifestation_1 ; rMap="264\.1\a\\\ 2+ same\.1\a\;\\" ; rText="Chicago"
  rName=placeOfPublicationManifestation_2 ; rMap="264\.1\a\\\ 2+ same\.1\a\;\\" ; rText="Atlanta"

A cleanup routine (normalizeMappedElements) must change the occurrence of the second element from _2 to _1 ; if it does not, the tag grouper will generate a new tag because of the differing occurrence

Dependencies: The elements in the RIMMF document will be mapped (with a few exceptions) in the order that they appear;

in the case of a '2+ same' mapping, an element order like the following

Place of Publication: Atlanta
Name of Publisher: ALA
Place of Publication: Chicago
Name of Publisher: Grossett

will change the above mapping from

264  1 $aChicago ;$aAtlanta :$bAmerican Library Association ;$bGrossett,$c2003.

to

264  1 $aChicago :$bAmerican Library Association ;$aAtlanta ;$bGrossett,$c2003.

Although this works in the 26X, it may not work in other fields, so be careful

As noted above, with two elements like this:

Statement of Responsibility Relating to Title Proper: Deborah A. Fritz
Statement of Responsibility Relating to Title Proper: Richard J. Fritz

We omit the 'c' from the 'same' row:

    245\..\c\/\\
2+ same\..\\;\\

and get:

/$cDeborah A.Fritz ; Richard J. Fritz

In the second element, the mapper:

1) knows that a semi-colon is preceded with a blank space (the isbdify subroutine), and
2) always adds a blank space in the position where the missing subfield normally would be found.

Perhaps the second blank space could be specified more explicitly? (by typing the blank where the subfield would go in the mapping form)?

A related problem is found when mapping Birth and Death dates in a Person. For example, a raw record like this:

  rName=dateOfBirthDateAssociated_1 ; rMap="100\..\d\,\- $\@<^(\d{4}).*$@>" ; rText="1775"
  rName=dateOfDeathDateAssociated_1 ; rMap="100\..\\-\\@<^(\d{4}).*$@>" ; rText="1817"

maps (literally) to:

  100 .. ,$d1775- - 1817

In the Birth date, we specify a comma as preceding punct, and add the trailing dash as ConstData. We also add a blank after the trailing dash so that the default (People with birthdates and not deathdates) will format correctly in headings. But if there is a Death date then the default mapping adds another dash as preceding punct, plus the blank space BECAUSE NO SUBFIELD WAS SPECIFIED, resulting in '- - '.

This is fixed by a hard-coded cleanup routine in rimmfRda2Marc.postProcessRdaToMarc

'XX' is permitted in Tag for the following relationships (FID and R/D): Creator, OtherPfcAssocWithWork, Contributor, Distributor, Manufacturer, Publisher, Producer, OtherPfcAssocWithManifestation, Owner, Custodian, OtherPfcAssocWithItem

When the mapper reaches a FID for one of these relationships, it opens the linked-to document to fetch the needed elements; on return, if the mapping Tag for the FID contains 'XX', it will be revised to match the entity of the linked-to doc.

Problem: the tag grouper joins RDA elements mapped to the same MARC tag, but still needs to respect the need for repeated elements to be

mapped to new tags.

Example:

rName=preferredNameForThePerson_1 ; rMap="500\1.\a\\\" ; rText="Wong, James"
rName=preferredNameForTheFamily_1 ; rMap="500\3.\a\\\" ; rText="Preferred Name for the Family"

All of these elements map to the same MARC Tag/Subf, 500$a.

Current solution (may need refinement): Check the indicators for certain tags in the procedure that searches for repeated $a. Thus, in the above example, we look for repeated $a in either 500\1. or 500\3., but not simply in 500\.. To avoid needlessly joining tags (which happens if we implement this indy approach willy-nilly), only 500 and 264 are thus treated so far.

Problem: mapping uses element order in the RIMMF document.

Example 1: If user has a Work template with Title before Creator (as it is in the default element set), the AAP will come out as:

Marc21 for everyone. Fritz, Deborah.

Solution: Whenever an AAP component is a link to another document, it should go first in the AAP being composed. The autofiller will now check each element, and if it find one that is a link, it will insert it (rather than append it) to the list being composed.

Example 2: In a manifestation, conflicts with “parallel” elements in the Title and S/of/R groups arise because of the lack of a unique subfield to map these elements to in MARC. They are strung together in $b and $c, with an importance being placed on the order of entry.

Solution: The user may now 'move' S/of/R elements into the Title element group in order to achieve the desired order of data in the 245. This was accomplished by adding an exception to the OnMoveTo method in rimmfDoc: the rimmfId's of the two group parent elements, titleManifestationID and statementOfResponsibilityId, were hardcoded, and the program will now recognize and permit children of these parents to be dragged and dropped into one another's group.