Hyrax Metadata Application Profile Documentation Working Group
Work completed, no longer meeting. Julie H. has made the PR to update Samvera Knowledge Base pages to reflect Hyrax v.3 and link out to M3 example and Google Doc MAP, just waiting on PR review in order to merge.
Roadmaps Alignment Group Update (jen young)
Working on making code reclamation process more clear, as well as analyzing the community roadmaps that have been provided by the Repository Managers WG
Hyrax metadata ordering for fields containing multiple values:
Julie: Specifically, Hyrax Maintenance WG is trying to determine if there is a way to use Resource Type to flexibly define if there are instances when there should be multiple versus single values for a given field
Ryan: Assuming ordering is possible, does Maintenance want to set multiple value ordering parameters based on a given Resource Type? (yes)
For example, making multiple creator values manually order-able for all scholarly articles
In Valkyrie sets, ordering of multiple values is by default
Conceivably it may be simpler to have ordering for all multiple value fields
Currently, multi-valued fields e.g. creator loads in different orders every time and this is causing issues with Google scholar indexing
Creator, Contributor, and Title are the fields where ordering is most important, when those fields contain multiple values
Ordering Subject and Keyword values are less important
It could be a source of confusion to only have ordering a specific fields for limited Resource Types; it also isn’t necessarily dependent on Resource Type.
Multi-value ordering as a toggle-able on/off feature is not probably something that would be accomplished during the first phase of setting up this feature
This will have implications for batch ingest and legacy content migration
Action item: Add comment to the effect that SMIG recommends that Creator, Contributor, and Title are the fields where ordering is most important, when those fields contain multiple values - across all Resource Types. Also, that this would be applied to all multi-value fields.
Several issues pertain to the use of controlled vocabularies at the Collection level (#3889, #3819,#3725). All of these issues date from 2019.
Re #3889: The original rationale for this issue presumes that adding a Rights Statement at the Collection level would auto-populate all the works contained therein with that Rights Statement, which is NOT accurate.
Consensus that it doesn’t really make sense to have a License field at the Collection level, but not a Rights Statement field.
A way to address this could be adding a faceted component to the Collection Details list on the Collection page, to reflect what Rights Statements are present in the Collection. This would help users to see sets of Works based on what their use Rights are, and would prevent confusion or misalignment between Rights Statements at the Collection level and what is at the Work level.
There is still broad agreement that Rights Statement should be optional at the Collection level.
Group will consider this further and hold off on making a recommendation until our next meeting.
Are there any issues labeled ‘Backlog’ that should actually be 3.x?
Will work through the remaining 4 open 3.x issues labeled ‘metadata’ at the next SMIG meeting.