Versions Compared

Old Version 5

changes.mady.by.user Ann-Marie Breaux

Saved on

compared with

New Version Current

changes.mady.by.user Ann-Marie Breaux

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Background

...

...

Current constraints:

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

MARC Field Protections Scope: 

(updated as of the Morning Glory release)

  1. Before Morning Glory, MARC field protections are only invoked if a MARC Update action is included in the job profile.
    1. Based on feedback from the community, consider changing the behavior so that the field protections are invoked automaticallyas 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 $aNcD$a NcD, $aNCD$a NCD, $a Ncd, $a ncd, $a ncD would all be considered equivalent and duplicates of each other.
    1. After testing and early substantial usage, if the community decides that the field protections must take upper and lower case into account for data in subfields, consider changing the behavior so that the field protections are case-sensitive rather than case-insensitive
  3. For data in a subfield, the field protection is based on the entire data string.
    1. Consider supporting wildcards, begins, ends, contains in the future.
  4. One master list of MARC field protections is maintained in Settings/Data import.
    1. Unless/until a future use case is identified that necessitates differentiation, this same list of field protections will be used for MARC Bibliographic
    , Authority, and Holdings record imports
    1. and MARC Authority records. 
    2. Per conversation with the currently-known MARC Holdings libraries, MARC field protections will NOT be applied to MARC Holdings records.
  5. MARC field protections are controlled at the tenant level, though field protections can be overridden for a particular action profile/job profile.
    1. Based on feedback from the community, consider adding the ability to include additional field protections in individual job profiles, for MARC fields that are used infrequently or do not normally need to be protected.
  6. For data in a subfield, the field protection is based on the entire data string.Consider supporting wildcards, begins, ends, contains in the future.Question for librarians: can we assume that LDR, 002-009 fields do not need field protection? Per MM SIG and DI subgroup, March 2022: fields 006 and 007 should allow field protection, but none of the other control fields (LDR, 002, 003, 004, 005, 008, 009)

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
  • Repeatable: all other MARC fields

...

FieldInd 1Ind 2SubfieldData
***5NcD

Add behavior for 006 and 007

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).

...

  • 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 3 4 $a 325168 
    • Incoming: 950 1 2 $a 325167 $5 NcD
    • Replace the existing 950 with the incoming 950 (which would be protected in future updates of the record)
  • Example 4
    • Existing: 950 12 $a325167 $5NcD1 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)
    • NOTE TO DEVELOPERS: if incoming duplicate is hard to identify and exclude, then add all incoming for now; and we'll refine to remove duplicates in the future
    Example 4
    • Existing field
  • Example 5
    • 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 6
    • Existing: 950 1 2 $a 325167 $5 NcD
    • Incoming: no 950
    • Retain existing 950
  • Example 7
    • Existing: 010    $a 12345678 $5 NcD
    • Incoming: 010     $a 657453647 $5 NcD
    • Retain existing 950 010 ; discard incoming 950 010 (since 010 is a non-repeatable field)
  • Example 58
    • Existing field: 010    $a 12345678 $5 NcD
    • Incoming: 010     $a 12345678
    • Retain existing 950010; discard incoming 950 010 (since 010 is a non-repeatable field)
  • Example
    • 6
  • 9
    • Existing field:
    • 950 1 2 $a 325167 $5 NcD
  • Incoming: no 950
    • Retain existing 950
    • 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 10
    • 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


FieldInd 1Ind 2SubfieldData
035**bMiAaHDL

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

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

035 is a repeatable field.

  • Example 1
    • Existing: 035    035 12 $a 12345 $b MiAaHDL
    • Incoming: 035    035 34 $a 4327842 $b MiAaHDL
    • Retain existing 035; add incoming 035 (since the $a value is different)
  • Example 2
    • Existing: 035    $a 12345 
    • Incoming: 035    $a 4327842 $b MiAaHDL
    • Discard existing 035 (since it is not protected); add incoming 035
  • Example 3
    • Existing: 035    $a 12345 $b MiAaHDL
    • Incoming: 035    $a 12345 $b MiBaHDL
    • Retain existing 035; add incoming 035 (since the $b value is different)
  • Example 34
    • Existing: 035    $a 12345 $b MiAaHDL
    • Incoming:
      • 035    $a 12345 $b MiAaHDL
      • 035    $a 12345
      • 035    035 92 $a 6582634 $b MiAaHDL
      • 035    035 33 $a (OCoLC)743256132
    • Retain existing 035; discard first incoming 035 (since it is a duplicate); add all other incoming 035s
  • Example 45
    • Existing: 
      • 035    $a 12345 $b MiAaHDL
      • 035    $a 12345
      • 035    $a 6582634 $b MiAaHDL
      • 035    $a (OCoLC)743256132
    • Incoming:
      • 035    $a 6582636 $b MiAaHDL
      • 035    $a (OCoLC)467815642
    • Retain the existing 035s with $b MiAaHDL; discard existing 035s without $b MiAaHDL (since they are not protected); add all incoming 035s.
  • Example 56
    • Existing: 
      • 035    $a 12345 $b MiAaHDL
      • 035    $a 12345
      • 035    $a 6582634 $b MiAaHDL
      • 035    $a (OCoLC)743256132
    • Incoming: no 035s
    • Retain the existing 035s with $b MiAaHDL; discard existing 035s without $b MiAaHDL (since they are not protected)

...

  • Example 1
    • Existing: 590 1 1 $a Some important note
    • Incoming: 590 2 2 $a Another important note
    • Retain existing 590; add incoming 590
    • NOTE TO DEVELOPERS: Existing 590s would always be retained, and incoming 590s would always be added, since the indicators, subfields, and data do not matter. An incoming 590 would only be discarded if it duplicates an existing 590.
  • Example 2
    • Existing:
      • 590 1 1 $a Some important note
      • 590 2 2 $a Another important note
    • Incoming: 590 1 1 $b Some other kind of note
    • Retain all existing 590s; add incoming 590
  • Example 3
    •  Existing:
      • 590 1 1 $a Some important note
      • 590 2 2 $a Another important note
      • 590 1 1 $b Some other kind of note
    •  Incoming:
      • 590 1 1 $a Some important note
      • 590 2 1 $c Some important note
      • 590 1 1 $d Some important note
    • Retain all existing 590s; discard first incoming 590 (since it duplicates an existing one); add all other incoming 590s
  • Example 4
    •  Existing:
      • 590 1 1 $a Some important note
      • 590 2 2 $a Another important note
      • 590 1 1 $b Some other kind of note
      • 590 2 1 $c Some important note
      • 590 1 1 $d Some important note
      • 591 1 1 $a Some important note
    • Incoming: no 590s
    • Retain all existing 590s; discard the existing 591 (since it is not protected)

...

  • Example 1
    • Existing: 982    $a 20210531 $a 20210602 $5 NcD
    • Incoming: 982 1 1 $a 20210531 $a 20210602
    • Retain existing 982; add incoming 982 (since indicators are different)
  • Example 2
    • Existing:
      • 050    $a MT123 $b .T68 2021 $5 NcD
      • 050    $a MT123 $b .T68 2022
      • 982    $a 20210531 $a 20210602 $5 NcD
      • 982 2 2 $z 20210531
    • Incoming: no 050 or 982
      • Retain existing 050 with $5 NcD; discard existing 050 without $5 NcD; retain both 982s

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)