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

880 Support #109

Open
bbusenius opened this issue Mar 10, 2021 · 0 comments
Open

880 Support #109

bbusenius opened this issue Mar 10, 2021 · 0 comments

Comments

@bbusenius
Copy link
Member

Need

We have many records with 880 linking fields for vernacular data and we want this data to display on the full record and results pages for fields that we index. We are currently achieving this with custom code that will not be used when we migrate to Folio. We should find a more sustainable way to achieve this and possibly contribute the code back to the VuFind community.

  • Required: In our current implementation 880s only display for fields that already exist. For example, an 880 for a 100a would only display if there was a 100a linking to it. As I understand it, this is wrong. 880s should always display even if they don't have a corresponding linked field. However we implement this, it should respect this requirement.

Full Record Page

image

Results Page

image

Possible approaches

There are likely many ways to achieve this in VuFind. We must choose an approach. Possibilities that come to mind include:

  • Index parallel fields for every VuFind data point using the LNK syntax in marc.properties. This would create fields such as title_short_lnk and title_full_lnk in addition to title_short and title_full. We could then write corresponding methods to pull and use this data. This would still require some rearranging of the code. For example, since the display title is currently created by concatenating title_sub and title_sort, we would likely need to make a method such as getDisplayTitle and possibly a second method of getLinkedDisplayTitle (unless they were combined) where these could be concatenated prior to being handed off to the templates. Note, this is just one example. Other fields would likely have similar or different requirements.
  • Using the LNK syntax in marc.properties, 880s could just be added to every field where they are needed. This would require us to update the schema and all support methods to always except multivalue arrays. The title case would still be weird in this scenario and would require some rethinking.
  • All 880s could be indexed into an 880 vernacular field and we could write a support method to pull this data for display purposes in the templates.
  • Parse the MARC directly for display purposes. This is what we're currently and I'm pretty sure we do not want to do this anymore. But I suppose it could be revisited and done more elegantly if there was a good reason to do it this way.
  • Some other way?

Related

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 a pull request may close this issue.

1 participant