When mapping a MARC field to the nature of contents term and provided value doesn’t match existing values, an empty value is created in the JSON and interferes with OAI-PMH harvests for discovery layers. it's creating a junk empty { } in the JSON when it shouldn't be.

Wellesley College was notified that there were errors in harvests for EDS by hosting. Soon after, staff found that records weren't being harvested by OAI-PMH to our VuFind catalog. Hosting said it's possibly related to https://folio-org.atlassian.net/browse/MODOAIPMH-513 and resolved in Poppy, but that doesn't help us while we are on Orchid CSP-6 in production.

Wellesley College maps the nature of contents field to 949$n without a fallback default value. Nature of content terms are used locally to identify ebooks, theses, music recordings, and non-music recordings where it might be difficult to find using other search methods.

Expected behavior: The import profile should populate the nature of contents term when present in a 949$n in the incoming MARC record. If no 949$n is present or the value doesn’t match accepted in the incoming MARC record, nothing is created or populated. OAI-PMH harvests process as normal, adding new and changed records to discovery layers.

Actual behavior: An empty value is created in the JSON for nature of contents when there is a value in 949$n present that doesn’t match accepted. OAI-PMH harvests fail and no records sent to discovery layers. Empty value isn’t visible in Inventory Instance records using the UI.

Affected Institutions: Wellesley College, ALL

Affected Release: Orchid CSP-6, Poppy

Related Job Profile Created in Poppy BugFest: https://bugfest-poppy.int.aws.folio.org/settings/data-import/job-profiles/view/6b695d7c-9c6c-40c6-8688-ed260534f994