Data Import MARC Field Protections Settings

Owned by Jennifer Eustis
Last updated: Sep 17, 2024
7 min read

Background

This information is current as of the Morning Glory release

What are MARC field protections? MARC field protections in Settings is a list of MARC fields, subfields, and/or specific values that need to be preserved and not removed when a MARC record is changed. Users can add and manage this list with the appropriate permissions. MARC field protections refer to MARC fields, subfields, and specific values in the Instance and underlying MARC source record storage bibliographic record and MARC authority records as of Nolana flower release.

Background: MARC field protections were first introduced in the flower release called Morning Glory. See Jira issue: MODDATAIMP-137. The first iteration did not take into account repeatable and non-repeatable fields. Work was done to enhance functionality. Behavior is documented on the developer page called MARC field protections. The enhancement included work on how to override field protections.

See MODDICORE-146 SPIKE: Instance & SRS record updates need to honor MARC field protections for additional technical information.

MARC Field Protections Scope 

  1. Before Morning Glory, MARC field protections were only invoked if a MARC Update action is included in the job profile. As of Morning Glory, field protections will also be invoked automatically/implicitly when the job profile includes an Update Instance action.

  2. When evaluating data in a subfield, MARC field protections are not case-sensitive. For example $a NcD, $a NCD, $a Ncd, $a ncd, $a ncD would all be considered equivalent and duplicates of each other.

  3. For data in a subfield, the field protection is based on the entire data string.

  4. One master list of MARC field protections is maintained in Settings/Data import.

  5. MARC field protections are controlled at the tenant level, though field protections can be overridden by using an update MARC Bibliographic or Authority record action with appropriate field mapping for MARC bibliographic or Authority record.

MARC Repeatable and Non-repeatable fields

MARC field protections work differently for repeatable and non-repeatable fields. Here is a list of those fields (spanning all three MARC record types):

  • Non-repeatable: LDR, 001, 002, 003, 004, 005, 008, 009, 010, 018, 036, 038, 040, 042, 044, 045, 066, 073, all 1xx fields, 240, 243, 245, 254, 256, 263, 306, 357, 378, 384, 507, 514, 663, 664, 665, 666, 675, 682, 788, 841, 842, 844, 882, and 999 with indicators = ff

    • Note that the fields 001  and 999 ff are restricted for FOLIO use and automatically protected by the system

    • The following non-repeatable control fields are disallowed from field protection: LDR, 002, 003, 004, 005, 009

  • Repeatable: all other MARC fields

  • Control fields:

    • The following control fields are disallowed from Field protection: LDR, 002, 003, 004, 005, 009

    • The following control fields are allowed for Field protection, but no indicators or subfields are permitted: 006 (R), 007 (R), 008 (NR)

Use of Wildcards (asterisk)

Within the field protection settings, wildcards are currently allowed for for all fields:

  • Field

  • Indicator 1

  • Indicator 2

  • Subfield

  • Data

But with the following restrictions: 

  • All 5 FOLIO fields cannot be wildcards

  • For the Data field, the entire data string may be wildcarded, but no wildcard is allowed within a data string (e.g. wom*n is disallowed)

  • Control fields (006, 007, 008) are not governed by any wildcard logic

  • For field 999, wildcards in Ind 1 and/or Ind 2 are not honored (since 999 ff is protected)

Sample Field Protection Settings

*

*

*

5

NcD

035

*

*

b

MiAaHDL

050

9

7

*

*

590

*

*

*

*

982

*

*

*

*

Field Protection Examples and Expected Actions

Behavior for repeatable fields: Retain existing field. If incoming record has one or more different fields (varying by field, indicator 1 or 2, subfield, or data), add the incoming field(s); if incoming record has a field that is an exact match to an existing field, do not add a duplicate field (if possible).

Behavior for non-repeatable fields: Retain existing field. Discard incoming field.

  • Example 1

    • Existing: 950 1 2 $a 325167 $5 NcD

    • Incoming: 950 1 2 $a 325168 $5 NcD

    • Retain existing 950; add incoming 950 (since the $a data is different)

  • Example 2

    • Existing: 950 1 2 $a 325167 $5 NcD

    • Incoming: 950 3 4 $a 325168

    • Retain existing 950; add incoming 950 (since the indicators and the $a value are different)

  • Example 3

    • Existing: 950 1 2 $a 325167 $5 NcD

    • Incoming:

      • 950 1 2 $a 325167 $5 NcD

      • 950 1 2 $a 325167 $5 NcA

      • 950 1 2 $a 325168

      • 950 1 2 $a 325169 $5 NcD

    • Retain existing 950; add all incoming 950s except the first one (since the first one duplicates an existing field, and the rest do not)

  • Example 4

    • Existing: 950 1 2 $a 325167 $5 NcD

    • Incoming:

      • 950 1 2 $a 325167 $5 NcD

      • 950 1 2 $a 325167 $5 NcD

      • 950 1 2 $a 325167 $5 NcA

      • 950 1 2 $a 325168

      • 950 1 2 $a 325169 $5 NcD

    • Retain existing 950; add all incoming 950s except the first and second ones (since they duplicate an existing field, and the rest do not)

  • Example 5

    • Existing: 950 1 2 $a 325167 $5 NcD

    • Incoming: no 950

    • Retain existing 950

  • Example 6

    • Existing: 010    $a 12345678 $5 NcD

    • Incoming: 010     $a 657453647 $5 NcD

    • Retain existing 010 ; discard incoming 010 (since 010 is a non-repeatable field)

  • Example 7

    • Existing field: 010    $a 12345678 $5 NcD

    • Incoming: 010     $a 12345678

    • Retain existing 010; discard incoming 010 (since 010 is a non-repeatable field)

  • Example 8

    • Existing field: 010    $a 12345678 

    • Incoming: 010     $a 12345678 $5 NcD

    • Replace existing 010 with the incoming 010 (since 010 is a non-repeatable field, but the existing one is not protected)

  • Example 9

    • Existing field: 010    $a 12345678 

    • Incoming: no 010 field

    • Existing 010 will be discarded when SRS record is replaced, since it was not protected. Updated SRS record will not have an 010

MARC field protection scenarios 

From Olamide Kolawole 

Scenario 1: MARC Field Entry Is Protected

  • Given 5 qualifiers: [Field Number], [Indicator 1], [Indicator 2], [Subfield], [Data]

  • And each qualifier can have a wildcard(*) as its value to denote a criteria match of any value

  • # definition of each qualifier should be added here

  • When a MARC Field entry components matches all 5 qualifiers

  • Then the MARC Field is protected

Scenario 2: MARC Update When an entry already exists exactly, NON-REPEATING

  • Given a MARC field entry that is exists and is protected and is non-repeating

  • And a collection of incoming MARC field entries that intend to overwrite the existing MARC field entry

  • When any incoming MARC field entry is exactly the same as the protected existing entry

  • Then the incoming MARC field will be discarded

Scenario 3: MARC Update When an entry already exists exactly, REPEATING

  • Given a MARC field entry that is exists and is protected and is repeating

  • And a collection of incoming MARC field entries that intend to overwrite the existing MARC field entry

  • When any incoming MARC field entry is exactly the same as the protected existing entry

  • Then the incoming MARC field will be discarded

Scenario 4: MARC Update when no entries are the same, NON-REPEATING

  • Given a MARC field entry that is exists and is protected and is non-repeating

  • And a collection of incoming MARC field entries that intend to overwrite the existing MARC field entry

  • When no MARC entry in the collection is the same as the existing MARC field entry

  • Then the end state will include the existing protected MARC field entry and the collection of incoming MARC field entries

Scenario 5: MARC Update when no entries are the same, REPEATING

  • Given a MARC field entry that is exists and is protected and is repeating

  • And a collection of incoming MARC field entries that intend to overwrite the existing MARC field entry

  • When no MARC entry in the collection is the same as the existing MARC field entry

  • Then the end state will include the existing protected MARC field entry and the collection of incoming MARC field entries

Scenario 6: MARC Update when the one incoming is the same, NON-REPEATING

  • Given a MARC field entry that is exists and is protected and is non-repeating

  • And a collection of incoming MARC field entries that intend to overwrite the existing MARC field entry

  • When at least one field entry in the collection has the same field number as the existing MARC field entry but the whole field entry is not the same

  • Then the end state will include the existing protected MARC field entry and field entries in the collection that do not have the same field number as the existing protected MARC field

Scenario 7: MARC Update when at least one incoming is the same, REPEATING

  • Given a MARC field entry that is exists and is protected and is repeating

  • And a collection of incoming MARC field entries that intend to overwrite the existing MARC field entry

  • When at least one field entry in the collection has the same field number as the existing MARC field entry but the whole field entry is not the same

  • Then the end state will include the existing protected MARC field entry and the collection of the incoming MARC field entries

Scenario 8: MARC Update when there are no existing records

  • Given no MARC field entry exists

  • And a collection of incoming MARC field entries that intend to overwrite the existing MARC field entry

  • Then the end state will include the collection of the incoming MARC field entries

Overriding MARC Field Protections

  • As with applying MARC field protections, overriding those protections are somewhat limited in releases prior to Morning Glory, in that they cannot be used without an Update MARC action in the job profile, and do not distinguish the handling for repeatable and non-repeatable fields properly.

  • As of the Morning Glory release, all of the details in the above MARC field protections scope section also apply to overriding MARC field protections.

  • Field protection override behavior:

    • Field is non-repeatable, and the field protection for the existing field is overridden in the job profile

      • Existing field's will be replaced by the incoming field's data in the updated record, regardless of whether that data is the same or different from the existing data

    • Field is repeatable, and the field protection for the existing field is overridden in the job profile

      • Existing field also is in the incoming record:

        • The field will be retained in the updated record (actually replaced by the incoming version of the field, which is an exact duplicate to the existing field)

      • Existing field is not in the incoming record:

        • The field will not be retained in the updated record (since its protection was overridden)