...
Call-In Info: https://zoom.us/j/211033358?pwd=WERUdnBWeHRqRVBRMmlOVWU3SlN0QT09
Community Notes: https://docs.google.com/document/d/15Cot2yFtYaQHmuzI2eauejS15N22-gnRQ0yoVoPFHrs/edit?usp=sharing
Moderator(s): Nora Z.
Notetaker: Julie Hardesty
Attendees:
Julie Hardesty (Indiana University)
Anna Goslen (UNC-Chapel Hill)
Nora (Egloff) Zimmerman (Lafayette College)
Cara Key (Oregon State University)
Annamarie Klose (Ohio State University)
Ryan Wick (Oregon State University)
Agenda:
Subgroup Reports
URI Selection Working Group Group - no update
Roadmaps Alignment Group Update (Julie H.)
Have been reaching out to partner institutions and other implementers, with the intention of sharing back to partners about roadmap planning. Specifically are trying to identify code reclamation opportunities and strategies for increasing that.
Repository Managers IG have a spreadsheet they’ve made of implementations and the Roadmaps Group has been reviewing this as well.
Issues/Questions
Anyone’s institution implement ASpace and do crosswalk activity between EAD and ASpace?
Annamarie Klose - OhioSU using Archivists Toolkit; using EAD metadata for Hyrax info on digital objects
Julie Hardesty - IU using Archives’ Space; Use ArcLight for digital objects
Anna Goslen - UNC Chapel Hill getting metadata from EAD for digital objects, this is in non-Hyrax applications. Difficulty keeping the repository and ASpace in sync
Balance between trying to describe digital object based on what is available (or not) in EAD - more discussions would be helpful!
Ryan Wick - U of Oregon using Aspace; OregonSU going to ASpace and Arclight probably as well
Keeping data in sync between Aspace/EAD and digital object description
Bulkrax - Lafayette and IU both using this in Hyrax app; not good for updating right now
OhioSU doesn’t use Bulkrax, has own tool for bulk import
What is most useful metadata for digital object vs finding aid description?
Discussion Topics
Continued from last month’s meeting, Hyrax issue review: help prioritize open issues that are labeled ‘metadata’
Work through the remaining 4 open 3.x issues labeled ‘metadata’
https://github.com/samvera/hyrax/issues/1461
Can get around this issue with a local change but sometimes admin set IDs will show up in views
Could change predicate being used but has to be applicable to already existing content - would need upgrade path
Long conversation on issue, might need to investigate
Creating new repository, can change this predicate without problem
Upgrade path can be hard at scale for repositories that already exist
Need to determine current status of issue in existing Hyrax codebase - still using isPartOf?
What is recommended predicate? There are many suggested but nothing seems to be settled. WG will evaluate possibilities in order to make a recommendation.
Could use comment in config file to make recommendation
Admin Set IDs will show on edit form and sometimes in public view if this problem is still in place
Isn’t part of Hyrax fields by default at this point
https://github.com/samvera/hyrax/issues/395
Stopped here, continue next meeting!
Return to question of Collection-level Rights Statements/ rights metadata, to make a recommendation
Can add license to collection but not rights statement
Adding rights statement at collection level does not auto apply that statement to each work in collection
Maybe rights statement should list rights statements used by Works in collection? Not sure how this would be implemented or viewed
If collection has license or rights statement, how is exception handled for work?
Could cause confusion if there is conflicting statements
If goal is to show makeup of works within, that is an available facet at collection level
Out of the box, Hyrax doesn’t supply facet for license or rights
Collection landing pages don’t have any facets either
Issue that reported this (https://github.com/samvera/hyrax/issues/3889) is for specific use case of mass digitization project
Collection editing form might need to explain that collection metadata doesn’t apply to Work metadata
Setting defaults and those can be changed, but for majority of use cases having a collection level rights statement doesn’t make sense
Bulkrax being able to update works would be better route to take to apply same rights statement to multiple works
Nora will respond to issue with this info
For each issue: is this still needed? Comments/context needed? Priority?
Are there any issues labeled ‘Backlog’ that should actually be 3.x?
Start with https://github.com/samvera/hyrax/issues/395 next meeting
Next call: June 22nd, 2-3pm EST
...