Time: 2:00pm-3:00pm Eastern / 1-2 pm Central / 11 am-12 pm Pacific

Community Notes: https://docs.google.com/document/d/1G8wmi9R3q1uHatQLa3JfmlVr1-laTO5vgYzUZz-B7QU/edit?tab=t.0

2026-05-26

Moderator(s): Annamarie Klose

Notetaker: Emma Beck

Attendees: 

• Heather Greer Klein, Samvera

• Annamarie Klose, Ohio State University

• Rachel Howard, University of Louisville

• Julie Hardesty, Indiana University

• Nic Don Stanton-Roark, PALNI

• Emma Beck, University of Louisville - she/her

• Dolsy Smith, GWU

• Jessica McMillen, West Virginia University

• Benjamin Riesenberg (they/them), U. of Oregon

• Morgan McKeehan (she/her/hers), Oregon State University Libraries & Press

• Rachel Jacobson (she/her/hers), Georgetown University

• Margaret Kibi, UC Santa Barbara

Agenda: 

• Samvera updates

  • Samvera Roadmaps Working Group

    • Code contribution policy around AI, taking it to the Samvera tech group meeting to get some feedback from developers in the community. Sometimes called “human in the loop” policies

    • Hyku release process 

  • Second AI working group meeting tomorrow. 

    • A variety of perspectives is welcome and encouraged to attend

    • Running meeting notes for AI WG https://docs.google.com/document/d/1NrEKKB6QlkoqHpELjLC6203ccDDJsrVKohhVHBj6mmg/edit?tab=t.0#heading=h.pjcejm49udzv  

• Repository for YAML file examples and related documentation (Hyrax issue 7144) - Morgan McKeehan

  • On behalf of documentation interest group

  • overall: Yes, this sounds worth having

  • Julie - good idea to have. Samvera labs could be a good starting point. Samvera labs is an experimental area where things can be tried out

  • project: houndstooth - https://github.com/samvera-labs/houndstooth/tree/main/examples  

    • note: the examples in Houndstooth are old at this point.

  • section in Hyku main code that has default YAML file 

    • https://github.com/samvera/hyku/blob/main/spec/fixtures/files/m3_profile.yaml  

    • doesn’t include the full scope of possibilities - room for expanding

  • UC Santa Barbara has a different type of YAML usage of houndstooth so be very clear about what type of sample it is

    • https://gitlab.com/surfliner/surfliner/-/blob/trunk/comet/config/metadata/ucsb-metadata.yml?ref_type=heads

  • To make this useful - provide enough context for the examples. Helpful context to Include: 

    • how it’s used, how it fits in to the overall

  • Good to establish a sharing-examples practice overall!!

    • Save others from having to start from scratch 

  • Some conversations around tenant portability in Hyku which could then be put into Hyrax

• Hierarchical metadata (see #metadata Slack discussion)

  • Related discussion point: If ORCID API support was added to Hyrax and Hyku, a metadata consideration would be how to support ORCID metadata, e.g., ORCID ids, in those platforms. UNC’s Carolina Digital Repository, for instance, has created a custom way of supporting ORCID information.

  • For example - in Fedora if you enter authors, it doesn’t always order them. 

  • Ordering is part of what people are after here – https://github.com/gwu-libraries/scholarspace-5-test/issues/77

    • ^ this issue contains a mockup for what that nested structure might look like

    • https://github.com/samvera/hyrax/issues/4781  

      • ^ this issue points to other hierarchical considerations besides ordering.

  • It is very possible to do nested/hierarchical metadata in the backend, but it is very hard to make an edit form for it in the UI. If you only care about automated processes/bulk edit, it is feasible with Valkyrie.

  • Working group years ago tried to offer up options and no one could agree

  • Would ordering the authors meet 95% of the use cases? Creator/contributor would likely be the priority

  • Would just ordering things fix this?

  • (possible challenge?) bc in Fedora: 

    • the hashed URI’s are not fully separate objects in Fedora, though Fedora does display them as “Related resources” when looking at the main (un-hashed) URIs.

  • An ideal scenario would be: Ordering would carry over to an associated field

  • From RDF background - able to look back at predicates, more transparent

  • considerations for representing Roles and persons

    • for example: multiple roles for one person

  • example use case: a folklorist went around a state collecting folk songs 100 years ago:

    • https://folkmusic.lib.wvu.edu/

  • Takeaways: 

    • “hierarchical metadata” means different things to diff folks/in diff contexts. Bringing up this question demonstrates that we’re all coming to it with diff use cases. Very helpful to discuss it as a group, to make all these variations explicit and start to clarify them. 

    • would like to gather & document more use cases

    • Now that we have more backend options than just Fedora - has this opened up possibilities for how we could approach this? Maybe this is a good time to revisit this issue for this reason. 

    • Is there a “design page” for this issue? 

      • Nick/Notch8 will check, will create if not yet exists. Into this area in Hyku confluence “Proposed Features and Needs”: Proposed Features and Needs

      •  

  • In UCSD comet: [check rolling notes for screenshot]

• Open discussion

  • Oregon digital question about alt-text. Morgan would love examples. Slack or email morgan.mckeehan@oregonstate.edu 

    • The field is in Hyku and being added to Hyrax. More challenging for compound objects. UofL has some development work 

    • Lots of interest in this, will be added to the agenda for next month