\uD83D\uDDD3 Date
10:00 AM EDT
\uD83D\uDC65 Participants
\uD83E\uDD45 Goals
Review the Use Cases completed by Stakeholders
\uD83D\uDDE3 Discussion topics
Time | Item | Facilitator |
|---|---|---|
5 minutes | Welcome | All |
10 minutes | Update on Hyrax work | |
45 mins | Review Use Cases
|
Notes
Valkyrization update
Brad and Ayoub have been helping and finding issues to fix in Hyrax and Valkyrie, big thanks to them! Another release candidate coming today or tomorrow. Need to get Koppie tests green, because they are looking for activefedora objects. Writing duplicate tests or migrating the tests when appropriate.
Brad got RDF predicates linked up. A few to assign for internal IDs form Fedora 4, on the whole should match closely. A few things at file set level are new to Valkyrie, but on the whole Fedora 6 was easy to get up and going. Daniel opened issues for two difficulties.
Daniel is feeling confident and is able to say that Fedora 6 really does work, not just should work, on a clean install of Hyrax 5. Migration of customized data will need customized migration, but we want to work for a basic set of migration guidance.
Use cases and determining pre-work
Need to come to an agreement about the pre-work needed, so the use cases document was the place to start. https://docs.google.com/spreadsheets/d/1Jxq2w8f_RjOBZwjXPen5Gx37lhn-MleJdeMKZfH4dk8/edit?usp=sharing
What should of Hyrax should be stored in Fedora 6? To make sure a repository should be rebuildable from scratch, but Oxford wants to choose what is okay to lose (admin and user data, templates). But what do others want to do? Store the binaries. One case of storing access controls, but not clear if that needs to be its own metadata object. Curious to see what OCFL through Valkyrie would look like. Access controls as they relate to what its public or not would be pretty important for us to retain when having to rebuild the application, so we wouldn’t lose what items are embargoed, etc
Assumptions around binaries and derivatives? Emory has customized to store up to five primary and 4 derivative accessible through Hyrax. Bring them in via ingest, and store via same file system (Fedora 4 with S3 config). But the same front ends interact with all those files so might be different use case than others. One fileset with many files.
Valk has 2 locations, metadata adapter and storage adapter, can be configured individually. Can have multiple storage adapters. 4 out of the box: disk, versioned disk, fedora, memory (for quicker tests). Separate gem for S3 directly.
Want to take a look at performance issues for storage of large files that we know exist now. Storing triples metadata on the Fedora object – is this something that is problem for everyone?
The RDF stored by fedora is in an n-triples file right next to binaries for the same object in the ocfl directory
Postgres metatdata adapter uses a JSON file, the same would be possible for Fedora.
Does Hyrax use the triples for anything but storage in Fedora? No.
Separate metadata adapters would be useful to meet identified issues.
not sure that there are a huge number of users really taking full advantage of the LDP side of Fedora
Don’t see a migration path from fcrepo 4 to 6 without activefedora. Because of that we have the option of not taking advantage of LDP. In order to understand an object in Fedora 4, you need activefedora to make sense of relationships.
✅ Action items
- Ask Rob Kaufman about what he has discovered re: migration
- Emory, IU, UNC, Bodleian: Gather use cases for the institutions in the room for Fedora and Hyrax.
- Arran Griffith to share the use cases with the institutions not here that would be impacted.
- Heather Greer Klein to let the group know if there will be time for working group meetings at Samvera Connect
- Arran Griffith to schedule a meeting for two weeks from now (the week of October 9th)