You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Results Page
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
It looks like this was discussed in 2016 and somebody was going to open a PR for displaying 880s. As far as I can tell this wasn't done though.
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.
Full Record Page
Results Page
Possible approaches
There are likely many ways to achieve this in VuFind. We must choose an approach. Possibilities that come to mind include:
LNK
syntax inmarc.properties
. This would create fields such astitle_short_lnk
andtitle_full_lnk
in addition totitle_short
andtitle_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 concatenatingtitle_sub
andtitle_sort
, we would likely need to make a method such asgetDisplayTitle
and possibly a second method ofgetLinkedDisplayTitle
(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.LNK
syntax inmarc.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.vernacular
field and we could write a support method to pull this data for display purposes in the templates.Related
LNK
syntax.The text was updated successfully, but these errors were encountered: