 Hi everyone. Thanks so much for joining us today. My name is Erin Griffith and I'm the Program Coordinator at Fedora. Today I'm joined by Tim Shear from the University of North Carolina at Chapel Hill and current chair-elect of our Steering Governance Group, as well as Robin Regaber from the University of Virginia and Amy Blau from Whitman College, our two pilot partner institutions from the IMLS grant that we're here to talk about today. So to get started, I'm going to pass it over to Tim who's going to give you a brief rundown of Fedora and what you can expect with the latest version of our software, Fedora 6.0. Thanks Erin. Fedora is simply a flexible modular open source repository platform with native link data support. I'd like to emphasize that it is flexible. It's agnostic about what you put in it, the relationships between those objects and the metadata used to describe it. And it's brought us since it's focused on digital preservation and file management and dissemination of digital content. It's especially suited for digital libraries and archives, both for access and preservation. Fedora's been around for quite a while now. It's one of the first repository systems, open source repository systems out there since 1997 and it's gone through some changes over that time. A couple years ago, we were stepping back and looking at the current landscape and thinking about how to build our resources to make things better and as you can see from the screen. We realized that most Fedora installations are unsupported they're on versions of three earlier at the time we were at four and five content and systems is at risk, and migrations are costly. So that let us chart a roadmap forward and our goal, both with the software and the grant that we're talking about today is to reduce barriers to migrations and to build a bridge forward. What's exciting is we've gotten a Fedora six which came out this summer, and we feel like it really did a great job of meeting some of these goals. So here are some of the features. We've adopted Oxford common file layout, which is part of a digital preservation program. It's an attempt to abstract the storage of items away from their repository systems. At the same time we were able to let go of a tool that was no longer working for us called mode shape. We were able to build as you'll hear soon some robust migration tooling and documentation. We created a metrics dashboard, which lets you monitor the, the, how your repositories doing. We built in a simple search because we found that people in the community really liked that affordance, and we made minimal API changes with the idea that if you're already plugged into Fedora you wouldn't have to do much to migrate forward. The benefits that you'll see enhance digital preservation support again through OCFL improve performance and scale. That was one of our goals to was to make sure that Fedora is a solid piece of your platform and easier and lower migrations, but that I'm going to pass it back. Awesome. So thanks for that Tim. Now I just want to take a quick minute and talk about the grant itself and its purpose and goal. So in September 2020 Fedora was awarded an IMLS grant totaling approximately $250,000 to be used over 18 months with the sole purpose of providing much needed documentation and migration tooling necessary to bring older versions of Fedora forward to the most current version Fedora six like Tim just spoke about. So the community had identified the need for these migration tools and documentation as crucial resources to support Fedora three upgrades. There are hundreds of libraries and archives in the US alone that are using older versions of Fedora to preserve and deliver resources to its users. So this continued reliance on Fedora three puts the stability security and accessibility to these repositories at risk, and much more concerning than that is the potential threat that this poses to the digital preservation of the unique and valuable content that's contained within them. So the purpose of the grant was to lower barriers to migration by creating a toolkit and providing resources that will be shared with the community and users around the world, so that we can collectively prevent this content from being lost. As part of the grant we're also going to administer training programs and webinars to aid in the overall adoption of Fedora 6.0. So this is an overview of the process so our great partners were the University of Virginia who is running an older version of Fedora three with a custom front end, as well as Whitman College who was also running a version of Fedora three with an island or seven front end. We then worked with the pilot partners to identify and develop appropriate tooling and documentation to assist with the migrations. Then we began to test iterate and refine the tools that were created. Once complete they were compiled into a toolkit document which is in the final stages of iteration now. And once this is all finalized it's going to be distributed to the community for feedback before being published for general usage. So in the spring we're planning to hold a workshop slash training event that's going to be focused on helping institutions work through a migration using the tools and documents created throughout the entire grant process. So as per the grant outline the work was divided into three phases. So phase one was actually piloting the migrations themselves. So much of this work and the lessons learned during this phase are going to be spoken about in just a moment here by our partner institutions. But during this phase the teams also began to work on the creation of several components of this toolkit that we speak that we're speaking about. So phase two was focused on the toolkit itself. Much of the work has already been done and been completed throughout the process but there's still work going on right now, iterating pieces and tweaking some of the tooling that's been created. Once the final changes have been made as I was explaining we're going to be releasing it to the community for general feedback before releasing the finalized version. And the last phase which we're hoping to host in person in the spring would be the migration training workshop. So this is intended to bring users together for an intensive two and a half day workshop that's going to be free to attend, thanks to the grant, where we're going to present all of our findings and walk attendees through the migration process using everything that was created. And with that I'm going to hand it over to Robin who's going to talk about the University of Virginia is contribution to the grant process. So our initial goal for the pilot was to fold primarily we wanted to reduce risk of losing content stored in a fedora three instance on obsolete server. And I want to emphasize that we knew very little about the content, but we also understood that many community members have content fedora three repositories some with custom front ends like ours. We had experienced migration pains with migrating to the door for. So this pilot gave us a real opportunity to do something we needed, and to help the community move forward by providing a demonstrated migration and validation of content from an older fedora three to fedora six. Throughout our migration, we were able to inform feature development and performance enhancements of the migration and validation tools, such as progress reporting, which greatly helped us during the testing. Most of our infrastructure is based in Amazon web services. So we worked with lyricist to build out a doctorized fedora AWS installation process. Initially, our configuration was not perform it. And we knew this because we had existing numbers from other people testing fedora six. So we had to return to the drawing board and completely reconfigured AWS resulting in us having far more confidence in how to resource fedora six and AWS. In the end, we were able to successfully migrate several prioritized collections from fedora three to fedora six. I began this discussion by sharing that we knew little about the contents of that repository, but in the end only migrated a few collections. This is a nice place to start discussing the challenges we faced. First of all, we had no staff who had worked in recent history with fedora three, and we had no one who really knew the content due to staff turnover. We underestimated the time for ramping up work for the repository and the value of involving content owners early in the pilot. The pandemic also had an impact as it forced people to work remotely which impeded communication, but also introduced infrastructure hurdles throughout the early stages. But I would say our largest issue came from initially taking an all or nothing approach to the migration. We were able to migrate everything in that repository at every change at every step was a huge time sink. In the end, we found that identifying collections of content and prioritizing a collection on which to iterate was far more successful. Our recommendation is plan well up front, understand the content, understand what skills your staff need, understand the infrastructure requirements within your environment. And finally, divide and conquer the migration by identifying a small portion of your repository for migration and testing until you have the configuration migration and validation setup that you need. We have identified a lot from this pilot. Our staff now understand how to work with the old repository and we know a lot more about the contents. We have identified what we do not need to migrate, such as derivatives which we had already reformatted and we're storing in triple I have. So now understand the AWS configuration we want for for door six, which we, which can support the remaining digital collections, audio visual materials and scholarly content, which we need to eventually migrate from for four. And with that I'm going to pass it over to Amy Blau from Whitman College. Thanks Robin. The Whitman College Island or repository contains around 30,000 digital objects, including undergraduate honors theses other student and faculty works archival collections of digitized photographs and documents and student newspapers from 1896 to 2015, representing almost every island or a content type. So all in the grant has been to migrate all of our repository content into a new island or a site, preserving the key functionality of our island or a legacy site. The successes our team has achieved include the site development and configuration, including the creation of a new theme that would be supported in Drupal mine. Our site is hosted on Amazon Web Services, Docker as using aisle. We're using Fedora six on Amazon as three for object storage. The repository contents to the new site was accomplished via the island or a workbench tool by Mark Jordan, which uses the command line to ingest content via spreadsheet in our case Google Sheets. We had worked with born digital, who is also our repository vendor to establish all of the metadata fields that would be needed for our objects, including a number of custom fields. And to ensure that the site was configured so these fields would be appropriately viewable and brief record metadata object metadata and facets. The preparation of metadata for ingest included coordinating the spreadsheet column headers with the machine field names, ensuring that taxonomy terms and linked agents were formatted correctly, and providing URLs or file paths to bring in the objects. Open access objects were retrieved from our island or a seven site, while restricted access objects were manually put on an Amazon server and retrieved from there. We also encountered included some delays. A year ago Fedora was preparing version six for release and the timeline for Drupal eight end of life meant that island or had to be completely compatible with Drupal mine. These platform dependencies in the island or a stack delayed the site build and theming, which in turn delayed site configuration and the ingest schedule. We had a lot of iterative work to optimize the ingest process. At one point in the process we discovered some serious errors and how files were being stored and we started over from scratch. The sheer number of in size of our files for our newspaper collection in particular also meant that ingest and we ingest of these objects took a while. Alan developed and ran some cleanup scripts for ingest to handle problems like derivatives that hadn't been generated, and in particular to bring over OCR derivatives from our old site. Though the ingest process using island or workbench was very successful. The other main challenges that we face had to do with support for the broad range of content types in our collections. Page content and island or a currently uses the open C dragon viewer by default, but this viewer does not have a page turning view or use H OCR to let you highlight your search term on a page or indicate where search terms appear in the issue as a whole. We're currently using a PDF viewer for the newspaper issues. And to highlight search terms you need to enter them a second time in that PDF viewer. This is a temporary solution until a book viewer with H OCR functionality is ready to go in island or a We also miss the functionality of the oral history module in island or a seven in island or a eight, we can display VTT transcripts as captions but we can't do an entire transcript and click from one portion of the text, the corresponding audio. So these, these viewing options for certain island or content types are something that isn't quite as complete in the current system. Access control has been a significant issue for us in a couple of ways island or eight not use fedora access control and Drupal access control possibilities are less granular than the exact mole of older versions of Fedora. As a result we've changed the structure of our limited access objects so that we can display metadata openly but still restrict access to the object itself to authenticated users. We've also run into some issues with the implementation of access control at scale. After there are a certain number of objects in the repository access controlled by taxonomy terms slows down the site for unauthenticated users. So we'll need to transition to a different way of living access, which we hope will improve site performance at scale for search and browse as well. Many of the plan fixes for access control are due for implementation this month. And as soon as these are done we should be able to schedule our cut over. For people who are preparing for a migration to island or eight and truly any repository migration. We recommend preparing your metadata as much as possible ahead of the migration timeline itself. Mapping, remediating and streamlining metadata can help in making decisions about the site structure and configuration and post ingest cleanup in the new system is often more difficult than pre ingest changes. Evaluate the platform's capabilities for your needs, while island or really can support a wide range of use cases, not all of the functionality of legacy island or is completely built out yet in the new version. Depending on your migration timeline and development budget, this may mean compromising on some functionality. So repository administrators developers and vendors should be very clear about what requirements must be met immediately and where there's room for temporary solutions that can be improved on later. Communicating frequently with your team and documenting questions decisions and procedures are always wise and I sign on to all of Robin's recommendations as well. We're excited about the S3 capabilities of Fedora. And we hope that the new OCFL file layout for Fedora storage may give us more options in future migrations. We're working to prepare our site for cut over and our documentation to share with the grant toolkit and Aaron's going to talk a little bit more about that now. Perfect thank you both to Amy and Robin for sharing your, you know your work through the grant process that is some very valuable information that has come from it. I wanted to just take a moment here and highlight some of the most important resources that can be found within the migration toolkit that we've been speaking about today. We have the migration utils which is a framework to support migration of data from Fedora three to four six repositories. Then we also have a key one here which is the migration validator so this is a command line tool for validating that your migration from Fedora three has successfully moved over to Fedora six. This is like I mentioned a key tool that will be involved in the toolkit and has proven useful on numerous occasions through migrations that we've seen. There's also a metadata remediation guide. And the last link there is the migration guide so this is a link to our wiki where you can find an extensive list of resources tools, as well as all of the migration paths that you will need to move from all older versions of Fedora to Fedora 6.0. There's also a YouTube video that was done by Scott Prater from the University of Wisconsin Madison where he walks you through the migration of a small Fedora three repository to Fedora six. This has been a great resource for people looking at what that migration process will actually look like from start to finish, and the link to that video will be at the end of this slide deck so I definitely encourage you to check that out. And with that I'm going to pass it back to Tim. Thanks Aaron. We keep using the word community to describe Fedora and it is a community. We have an organizational home in lyricists lyricists did the leadership to secure the I am less funding that supported this grant. And here we wanted to acknowledge some of the Fedora members who help support through in kind software development and through finances. And I should make these the slide deck available and I wanted to leave you with some additional resources. So stepping back up from the migration toolkit to the grant project landing page back to the guide. We have monthly Bob coasts, and we are community with real people that answer questions and talk and put their brains together to solve problems and a lot of that happens on slack. So we'd welcome you to join us over in slack to learn more about the, the, the project and how to move forward. There's the migration videos the workshop videos. And we can't be a successful community without membership. So if you're interested, please feel free to reach out to any of us to talk about how you can become a member. And just a quick reminder, when we were looking several years ago at the landscape. Our goal was to see what we could do to reduce barriers to migrate repositories forward so that we did not leave objects and content at risk. And that's been the driving factor between Fedora six and this grant. And I feel like we're getting there. So we're really excited that you were able to watch this. Please, again, feel free to reach out to us. And we didn't want to leave without acknowledging some of the people that really did some of the heavy lifting with the grant, and you'll see their names on the slide. So we just wanted to thank CNI for hosting us and you for watching us. And I think we'll close now.