Analysis to track imprint field data

[amyehodge]

Track how the data in the imprint field gets from the original data to:

• PURL, example https://purl.stanford.edu/xk755gc8675
• SearchWorks search results, example https://searchworks.stanford.edu/?search_field=search&q=Bunsei+kaisei (for me the image is search result 1)
• SearchWorks item show page, example https://searchworks.stanford.edu/view/11702723
• exhibits show page, example https://exhibits.stanford.edu/tokyomaps/catalog/xk755gc8675
• exhibits more details view, example -- click on "More details" button at the bottom of the above page
• exhibits search results, example https://exhibits.stanford.edu/tokyomaps/catalog?exhibit_id=tokyomaps&search_field=search&q=

For context, we are interested in doing the work in this proposal from Arcadia, but it's important to understand where the changes would propagate out to in order to make sure we aren't introducing undesirable effects anywhere. This analysis is a prerequisite for doing this work.

[peetucket]

PURL:

The process for creating and displaying MODs as shown on PURL is below:

1. During the publish step of common-accessioning workflow of the accessioning process, a web service call is made to dor-services-app (DSA) via dor-services-client gem, which in turn starts PublishJob in DSA. See https://github.com/sul-dlss/dor-services-app/blob/main/app/controllers/objects_controller.rb#L111-L116 and https://github.com/sul-dlss/dor-services-app/blob/main/app/jobs/publish_job.rb
2. The PublishJob calls the Publish::MetadataTransferService in DSA, which is responsible for generating all of the XML to send to the PURL document cache, see: https://github.com/sul-dlss/dor-services-app/blob/main/app/services/publish/metadata_transfer_service.rb
3. In particular, the PublishJob calls the Publish::PublicDescMetadataService, see: https://github.com/sul-dlss/dor-services-app/blob/main/app/services/publish/public_desc_metadata_service.rb#L16
4. This maps the object cocina to MODs via the cocina-models gem, see: https://github.com/sul-dlss/cocina-models/blob/main/lib/cocina/models/mapping/to_mods/description.rb
5. Once generated, the MODs (and other public XML) is sent to the PURL document cache as part of the Publish::MetadataTransferService (as noted above).
6. When a PURL page is displayed. it reads the MODs file from the PURL document cache and passes it to the mods_display gem, which, with the help of the stanford-mods gem, parses the MODs XML and creates fields for display. "Imprint" is one such field, which collects the relevant bits of metadata from the MODs and generates an array of potential "imprint" values for display. See https://github.com/sul-dlss/mods_display/blob/main/lib/mods_display/fields/imprint.rb
7. This fields are then displayed on the PURL page here: https://github.com/sul-dlss/purl/blob/main/app/views/purl/_mods_metadata_sections.html.erb and in particular, the imprint field is rendered in this partial: https://github.com/sul-dlss/purl/blob/main/app/views/purl/_mods_description.html.erb

Conclusion...for PURL display:

1. We could add additional helper methods as needed to mods_display and possibly stanford-mods to parse and extract more specific date fields as described in Arcadia's plan
2. Make small changes to the PURL display partials to use those fields instead of the existing imprint field. No need to remove the imprint methods from mods_display to ensure compatibility with other apps.

[amyehodge]

@arcadia seems satisfied with this. I have filed a follow-on ticket for the work at https://github.com/sul-dlss/mods_display/issues/153. We can close this as far as I'm concerned.

[peetucket]

Should I continue looking into how Searchworks and Exhibits work or is PURL the main concern? I suspect they operate fairly differently since they probably only look at indexed data and the the public MODs that PURL uses.

[amyehodge]

@peetucket Yes, please continue. Thanks. I hadn't realized that work was not yet done when I made the comment above.

[peetucket]

Searchworks:

The process for creating and displaying MODs as shown on Searchworks is below:

1. The searchworks indexer creates solr documents, and as part of this, it pulls in MODs from the PURL public XML or Marc from Folio. See https://github.com/sul-dlss/searchworks_traject_indexer/blob/main/lib/folio_record.rb and https://github.com/sul-dlss/searchworks_traject_indexer/blob/main/lib/public_xml_record.rb
2. Searchworks parses the MODs via the mods_display gem, see https://github.com/sul-dlss/SearchWorks/blob/master/app/models/solr_document.rb#L66-L68 and https://github.com/sul-dlss/SearchWorks/blob/master/app/models/mods_export.rb and https://github.com/sul-dlss/SearchWorks/blob/master/app/models/concerns/mods_data.rb
3. The mods_display record is then used by the various detail views (and associated partials) in Searchworks for rendering the data. See https://github.com/sul-dlss/SearchWorks/blob/master/app/views/catalog/record/_mods_metadata_sections.html.erb and other partials referenced.

Conclusion...for Searchworks display:

Same as above for PURL...any additional helper methods added to mods_display and possibly stanford-mods to parse and extract more specific date fields as described in Arcadia's plan can be used by Searchworks as well to change how the record is shown.

[peetucket]

Exhibits:

The process for creating and displaying MODs as shown on Exhibits is very similar to Searchworks noted above. They key difference is that the indexing code is embedded in the Exhibits app and not a separate codebase. In addition, exhibit curators are able to select specific items/collections for indexing, so control over what appears/indexed is up to each exhibit curator. However, otherwise, the process is similar, in that the data is fetched from PURL before being indexed into an exhibits solr, and then parsed by the same gems for display on exhibits details pages. There does not appear to be any connection to Folio to fetch MARC however. The same conclusions as for Searchworks noted above apply.