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

Should we index and display <archref> ? #1461

Open
marlo-longley opened this issue Dec 8, 2023 · 1 comment
Open

Should we index and display <archref> ? #1461

marlo-longley opened this issue Dec 8, 2023 · 1 comment

Comments

@marlo-longley
Copy link
Contributor

marlo-longley commented Dec 8, 2023

archref

Duke has some formatting / code for reference -- is this solution applicable to core?

This ticket is broken out from #898

@seanaery
Copy link
Contributor

seanaery commented Dec 8, 2023

We would be happy to PR our Duke solution for archref elements if applicable/agreeable to the community. See format_archrefs:

https://gitlab.oit.duke.edu/dul-its/dul-arclight/-/blob/main/app/helpers/ead_format_helpers.rb#L35
https://gitlab.oit.duke.edu/dul-its/dul-arclight/-/blob/main/app/helpers/ead_format_helpers.rb#L42-65

As @mmmmcode noted, we commonly use <archref> to wrap references to other finding aids, especially within <relatedmaterial>, whether at Duke or elsewhere. Within the tag, there can be additional EAD formatting like <extref> with URLs (see related ticket #1449 ).

<archref>s can technically appear a lot of places -- e.g., one might be isolated within a random note field on a component or there might be several listed consecutively, especially in a collection's <relatedmaterial> section.

Examples in action:
https://archives.lib.duke.edu/catalog/harrisrencher#related
https://archives.lib.duke.edu/catalog/bingham#related
https://archives.lib.duke.edu/catalog/behindtheveil#related

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants