As our work on the transfer application portion of Project Electron nears its completion, I’ve started to think more seriously about modeling our data that we are bringing into our systems. We’ve actually been prepping for this stage of the project for months, going all the way back to the Data Model Bibliography I put together in February 2017. Now that the D-Team was in the thick of data modeling, we thought it was time to bring the rest of the Archive Center on board as well. I’m just a single archivist, and even though I’ve done a lot of reading about data models, I’m no expert on the entirety of our collection or its materials. We knew that we’d need more eyes on our initial data model draft once we made it to make sure we weren’t forgetting an important component of our collections. Continue reading
It has been a busy month for Project Electron as we near the end of the first phase of development, which focused on building an application to enable the secure transfer and validation of digital records and their metadata according to the Rockefeller Archive Center BagIt specification. In addition to the transfer application development, much of our work this month has been about planning for the next phase of the project. In this post I will share a few activities and strategies we undertook to prepare for development and to keep users at the center of the design process. Continue reading
This month has been all about developing the Project Electron transfer application. The work is based on our defined specifications and the development decisions we made last month with our Marist College partners at the hackathon. We are really excited about testing transfers in the coming month.
In this post I am going to briefly discuss Gherkin, which in addition to being a delightful little cucumber, is a language that is used to define the requirements of software in order to document and test the software’s behavior as part of Behavior Driven Development (BDD). We have been using Gherkin to write Quality Assurance (QA) tests for the functions of our Project Electron transfer application. The language is human-readable, so it can enable communication between teams working in different domains across a project.
We kicked off this past month with a hackathon, hosted by our Marist College partners, to plan and start developing the part of Project Electron that enables the transfer of digital records from donor/depositor organizations to the RAC over a secure network connection. We worked with the Marist College team, including Marist students, to diagram the transfer structure and dependencies, building from the transfer specifications that we released in June and discussed in our last blog update. These specify the metadata and structural requirements for transfer and provide a bag profile to validate bags from donors. Additionally, we created wireframes and started building out the user interfaces (UIs) to view and track transfer information, view error messages, and manage user and organizational accounts. Continue reading
This month, we launched a system called Virtual Vault, which allows us to deliver digitized content to any user within the RAC network. It’s a temporary solution that we hope will help us better understand responsible access to digital archival records. Our thinking around this solution is motivated by one central question: given the limitations of copyright and donor agreement restrictions, what is the most and best access we can provide? Continue reading
This month we’re excited to announce the release of the first version of a specification for transferring digital records to the RAC over a network connection. In line with our project value of supporting archival practices and standards, we’ve built many parts of this specification on existing standards and frameworks such as BagIt, BagIt Profiles, Activity Streams, and OAIS. We believe this approach will make the products we come up with more easily reproducible at other institutions, which is another one of our project values. Continue reading
Our major news for this month is that, after evaluating a number of existing solutions against our requirements for archival storage, we have decided to use Fedora as the repository solution for Project Electron. Although there were other systems that met many of our requirements – DSpace for example – in the end we felt that Fedora was the closest match for our needs both in terms of feature coverage and scope. It does what we want it to do without requiring us to support a lot of extra functionality or complexity. Continue reading
As I mentioned last month, we’re moving forward with Project Electron on two fronts: defining the process by which digital records are transferred to the Rockefeller Archive Center and selecting a solution to provide archival storage for those records once they are in our custody. Continue reading
March was a busy month for the Project Electron team, with conference presentations at Code4Lib, attendance at LDCX, Born Digital Archiving eXchange and Personal Digital Archiving, and participation in the DACS Principles revision process. Despite this, we managed to make significant progress on Project Electron, specifically in developing requirements for archival storage as well as transfer of records from donor organizations to the Rockefeller Archive Center. Continue reading