Unsuppress local subject headings from item display and facets

[tclayton33]

User Story: As a user, I would like to see locally applied subject/genre headings displayed in Library Search, so that I can benefit from the added description that librarians have added to records for Emory’s special collections materials.

Full details: Currently, locally created subject/genre headings are not displaying in the item records or facets, as they are not present in the list of included specific vocabularies.

Example: see attached image for MMSID 990024992080302486

These are formatted as 6XX _7 |a text. |2 local |5 GEU For example, 655 _7 |a African American author. |2 local |5 GEU

CATACOM would like for all 6XX headings ending in “|2 local |5 GEU” to display in the item records and facets. According to the Metadata and Indexing – Blacklight spreadsheet, the following Solr fieldnames contain a list of specified vocabularies in their Marc mapping, and will need the “local” vocabulary added: subject_display_ssim subject_ssim subject_geo_ssim subject_era_ssim genre_ssim

This issue is linked to CATACOM's original enhancement request for this, E23.

Acceptance criteria: 9936577615102486 – will display genre heading and facet: African American author 9936561597502486 – will display genre heading and facet: African American illustrator 9936575112302486 – will display genre heading and facet: African American publisher 990000879730302486 – will display genre headings and facets: African American author; African American pamphlet

[abelemlih]

@tclayton33 I have started working on this ticket, and noticed some inconsistencies in the way the local subject heading data is stored in the MARC records. The following are examples of data for field 655 for three different works, notice how each have the local subheading subfields $2 and $5 stored differently:

# Document ID: 9936577615102486

#<MARC::DataField:0x00007f7a4455fc10
 @indicator1=" ",
 @indicator2="7",
 @subfields=[#<MARC::Subfield:0x00007f7a4455f9b8 @code="a", @value="African American author. |2 local |5 GEU.">],
 @tag="655">

# Document ID: 9936561597502486

#<MARC::DataField:0x00007f822c1c78b0
 @indicator1=" ",
 @indicator2="7",
 @subfields=[#<MARC::Subfield:0x00007f822c1c7630 @code="a", @value="African American illustrator. $2 local $5 GEU.">],
 @tag="655">

# Document ID: 9936575112302486

#<MARC::DataField:0x00007fe7e628d9c8
 @indicator1=" ",
 @indicator2="7",
 @subfields=
  [#<MARC::Subfield:0x00007fe7e628d798 @code="a", @value="African American author.">,
   #<MARC::Subfield:0x00007fe7e628d478 @code="2", @value="local">,
   #<MARC::Subfield:0x00007fe7e628d158 @code="5", @value="GEU">],
 @tag="655">

Notice how some of them have the subfield $2 and $5 stored within the value of subfield $a, while the last example has subfields $2 and $5 stored separately. For our application to handle these use cases consistently, we need the subfields $2 and $5 to be stored separetely, as is the case for document 9936575112302486. Locally, when I run my current indexing changes on document 9936575112302486, I am able to get the local subject heading to display under Genre:

Private Zenhub Image

I would appreciate it if you could help with the following:

• Determine whether any changes are needed in the way the local subject heading data is recorded, to ensure the subfields are stored separately
• Review the acceptance testing examples above, since some of them require facets to be displayed even though the facet data does not include local subject headings in the documents tested.

[tclayton33]

@abelemlih I talked to Sofia about this. She said you should base your application coding on your last example (9936575112302486). The others are errors probably resulting from typos while cataloging or copy/pasting from OCLC into Alma when the two systems have different delimiter symbols. She is going to run a report to catch these errors and have someone work to resolve them in the next few days.

We also want to make sure that the work you are doing for this applies to all headings with the "6XX _7 |a text. |2 local |5 GEU" criteria and not just the 655. Currently, I only included examples for 655 fields because we don't have any others. However, it is conceivable that we could end up with a local 650 or other 6xx heading in the future.

[abelemlih]

@tclayton33 this ticket is ready for testing

[tclayton33]

@abelemlih This looks good, and is ready for deployment.

[tclayton33]

deployed 10/12/23