Time: 2:00pm-3:00pm Eastern

Call-In Info: https://zoom.us/j/211033358?pwd=WERUdnBWeHRqRVBRMmlOVWU3SlN0QT09

Community Notes: https://docs.google.com/document/d/1ZW2dA-RczYhbf1SAN0yyd-wFDxg0efFEq-8xKy9wPAM/edit#heading=h.cw1lmwgqc33q

Moderator(s): Anna Goslen
Notetaker: Nora Egloff

Attendees: 

• Jen Young (Northwestern University)

• Anna Goslen (UNC-Chapel Hill)

• Nora Egloff (Lafayette College)

• Ryan Wick (Oregon State University)

• Cara Key (Oregon State University)

• Julie Hardesty (Indiana University)

• Annamarie Klose (Ohio State University)

Agenda:

• Subgroup Reports

  • URI Selection Working Group 

    • Ryan: no updates

  • 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

• Issues/Questions

• Discussion Topics

  • Hyrax metadata ordering for fields containing multiple values:

    • Ordering metadata fields with multiple values · Issue #4781 · samvera/hyrax

    • 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

      • For the M3 spec as well: https://github.com/samvera-labs/houndstooth/blob/master/examples/hyrax_3_0.yaml

    • 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.
      

  • Hyrax issue review: help prioritize open issues that are labeled ‘metadata’

    • For each issue: is this still needed? Comments/context needed? Priority?

      • Confirmed that #4286 Add alternative_title to the form can be closed. Alternative Title has been added to the form and both it and Title are 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.

• Next call: May 25th, 2021, 2-3pm EST