Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Index mhld_display as a json field #1247

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Index mhld_display as a json field #1247

wants to merge 3 commits into from

Conversation

jcoyne
Copy link
Contributor

@jcoyne jcoyne commented Sep 14, 2023

This makes it easier to work with

end

to_field 'mhld_display_struct' do |record, accumulator, _context|
record.mhld.each { |holding| accumulator << holding.to_h }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're starting something new, do we really want/need to replicate the old structure here, or is it worth mirroring either the FOLIO data structures or how Searchworks actually uses this data?

Back in https://github.com/sul-dlss/searchworks_traject_indexer/pull/876/files, I suggested one possible structure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cbeer I added a second commit to this PR. Is this more like what you have envisioned?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it were me (and it was, in #876), I'd go a little further. At the very least, latest is always the same value for a location, so there's no reason to keep duplicating it for each holdings note.

In #876, you'll see I proposed a data structure that Searchworks should be happy to consume and requires less processing in the indexer:

library:
  location:
    holdings: []
    index: []
    supplements: []
    latest_received: ''
    note: ''

It's not clear to me how the FOLIO model changes that general approach, but:

  • I think note could be multivalued?
  • in MARC, the 866, 867, and 868 (e.g. holdings, index, supplements) could be freely interleaved and maybe order was important. In FOLIO, they're separate fields so I feel even better about breaking them apart as above.

Maybe there's other things; I'd encourage you to look at the FOLIO data model, what Searchworks is actually doing this this data, and the backlog of MHLD-adjacent tickets in order to figure out what we should do:

Copy link
Contributor Author

@jcoyne jcoyne Sep 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cbeer I'm not seeing where searchworks needs to differentiate between regular holding statements, index holding statements and supplement holding statements. Can you explain more about why you chose to take the data model in that direction?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is essentially FOLIO's data model. We currently differentiate between them here in the indexer:

https://github.com/sul-dlss/searchworks_traject_indexer/blob/main/lib/folio/mhld_builder.rb#L67-L73

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but Searchworks needs them merged together, so is there any reason not to just have one set?

@jcoyne jcoyne force-pushed the mhld-display-struct branch from 350c6cd to 4311df3 Compare September 14, 2023 22:05
@jcoyne jcoyne force-pushed the mhld-display-struct branch 2 times, most recently from 7ba6489 to d92ee35 Compare September 15, 2023 17:03
@jcoyne jcoyne force-pushed the mhld-display-struct branch from d92ee35 to 873dd5d Compare September 15, 2023 17:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants