by Seth Shaw

Current notions of “Digital Repositories”

Once I heard an archivist describe their institution’s existing digital infrastructure, a respectable setup with network-based storage and well-organized metadata files, as “not a real repository.” Why not? What does it mean to be a “real repository?” Are there set qualifications a digital repository must meet before it can be “real”, much like Pinocchio’s quest (in the Disney retelling) of proving himself brave, truthful, and unselfish, to become a “real boy”? How many archivists wish their repository infrastructure was a real repository much as Geppetto wished his wooden puppet was a real boy? “A very lovely thought… but not at all practical,” Geppetto lamented. Are archivists waiting for an information technology department or third-party provider, a Blue Fairy, to turn their repository into a real one? They do not need a Blue Fairy, their repository is already “real,” if immature. This article discusses what it means to be a “real” digital repository and advocates shifting the discussion from realness to trustworthiness and maturity.

Digital Archival Repositories as Organization, Practices, and Infrastructure

In the most basic sense a repository is “a place where things can be stored and maintained; a storehouse” [1] and, thus, a digital repository is a place to store and maintain digital “things.” If being “real” only requires fulfilling this definition then, in its simplest form, a digital repository could be any digital storage media, such as a USB flash-drive, which an archivist uses to maintain digital content. Yet this will not satisfy most, if any, archivists’ definition of a digital repository. What other qualifications must be met?

John Mark Ockerbloom notes while discussing the fundamental nature of a repository that, at the level of individual consumer devices, “new kinds of repositories that have little or no connection to traditional libraries… [are] on their users’ own computers… [and] on Internet sites.” He continues by qualifying “personal digital repositories.” They cannot simply be a “glorified filesystem or website;” they must support “managing metadata, supporting discovery, provid[e] for access control [… ]and [support] long-term access and use of the content.” Although these attributes appear reasonable and might fit the mental model some archivists have of a digital repository, I imagine that many, if not most, archivists would not consider Ockerbloom’s examples of personal digital repositories, such as iTunes or GoogleDocs, appropriate applications to use for their digital repository. [2]

When archivists discuss repositories, generally speaking, they are referring to either “the building (or portion thereof) housing archival collections” (the repository is an infrastructure) and/or organizations that collect archival materials and administer them according to archival principles and practices (the repository is a function). [3] By extension, when one discusses digital repositories, they could be referring either to the software and hardware storing digital archival content (infrastructure) and/or the organization collecting it (function). Digital repository infrastructure (storing digital material) should therefore incorporate as much of the archival repository function as possible (administering content according to archival principles and practices) something which none of our previous examples, necessarily, do. As Adrian Cunningham warned the profession: “digital archives are at risk of being managed just like vanilla digital libraries, thus dumbing down the peculiar challenges and complexities of preserving records.” [4] When discussing ‘digital archives’ the emphasis should be on ‘archives’ rather than on ‘digital.’

Joanne Kaczmarek, et. al., in their article on evaluating repository software applications, notes that:

These implementations have at their core software applications that are often called “repositories.” Yet, the traditional notion of a repository is one that conjures up images of well known institutions such as the British Library, the National Archives of the Netherlands, the Library of Congress or the Getty Museum. This notion of a repository implies a larger organizational commitment to the trustworthy oversight of valued and valuable resources that goes far beyond specific software implementations and underlying hardware and software architectures[…] [5]

We have spent much time reiterating for ourselves places of overlap and distinction between these two generalized notions of a repository. As a clarification aid, we have coined the terms ‘Big R’ and ‘little r,’ and applied them in project meetings to distinguish between a repository at the institutional level (‘Big R’) and an actual repository software application (‘little r’).

Here then is the essential point: a “real” digital repository is the archival institution (‘Big R’) managing digital materials within their digital repository infrastructure (‘little r’), regardless of implementation, according to archival principles and practices. An archival institution does not require complex software for their digital repository infrastructure. Archivists need not feel that their digital archival repository is not “real” because it is simple.

OAIS, as a Reference Model

The “Reference Model for an Open Archival Information System (OAIS)” [6] is well known to the archival community and is commonly used to describe what it means to be a digital repository. [7] The OAIS reference model is often used in the literature as the standard for describing digital repositories even if only as a brief reference. [8] Many articles that describe implementing an OAIS generally focus on the repository software architecture rather than the repository as an institution, and even these may consider only a subset of the standard such as the ingest function or the information packages. [9] One of the few exceptions is Muma, Dingwall, and Bigelow’s article which describes their use of Archivematica and ICA-AtoM in terms of the reference model but also describes aspects of institutional policy such as migration strategy implications, an aspect of the preservation planning function. [10] The general emphasis in the literature on software systems obscures the fact that complying with the standard requires having appropriate policies and procedures in place to govern repository functions, not necessarily having complex software to automate them. This can lead to the impression that an OAIS-conformant repository requires complex software environments, seemingly out of reach for smaller archival institutions, which is not the case.

OAIS specifies six essential responsibilities [11] (paraphrased):

1. Negotiating and accepting content from producers [12]
2. Gaining the necessary control for long term preservation (legal right to preserve, permission to migrate formats, and collaborative agreements with other archives for preservation expertise)
3. Identifying primary user groups (designated communities) to whom services are tailored
4. Ensuring these designated communities have what they need to understand the content (i.e. documented access copies)
5. Ensuring policies and procedures are documented and followed and materials are, accordingly, preserved
6. Ensuring users have access to preservation metadata so they can trace derivative files to the originals.

These responsibilities are familiar to archivists who have a long tradition of meeting them for their analog collections. OAIS defines models for information packages (content and their metadata) and the functions necessary to fulfill these responsibilities. Notably, as a reference model, OAIS “does not define or require any particular method of implementation of these concepts.” [13]

The following sections describe the OAIS information packages and functions to illustrate that their “requirements” for compliance, although they may appear very technical, can be implemented using simple methods, and can often employ existing archival practices, workflows, and tools.

Packaging Information

Archivists are familiar with collecting and maintaining metadata to administrate and provide access to archival materials. Archival metadata and documentation have taken many forms over the years including inventories, collection control files, shelf lists, and finding aids. In the past few decades metadata and documentation have migrated to digital forms including spreadsheets, custom databases, encoded files, and archival data management systems such as AtoM and ArchivesSpace. [14]

OAIS sets standards for packaging information that can be implemented without substantial additional effort. For example, a Package Description is descriptive metadata that “enables the Consumer to locate information of potential interest, analyze that information, and order desired information,” for example, a finding aid or catalog record. An archives can store package descriptions in their existing archival management systems whether they be spreadsheets, ArchivesSpace, or something else.

Similarly, a Content Object is the combination of the Data Object [15] and Representation Information. Representation Information is “the information that maps a Data Object into more meaningful concepts,” i.e. what someone needs to know to render the object and make it comprehensible. A basic method to record Representation Information is to note a file’s format. There are a number of relatively easy-to-use tools available today for this purpose such as Droid and FITS. [16] Therefore, to fulfill these requirements, all an archives needs to do is acquire the data, run a format identification tool such as Droid, and save the results in a consistent location. Ideally an archives would also acquire a copy of the format’s specification and/or software capable of interpreting the file format. An archives would also document the data’s semantic structure for datasets as needed, such as the meanings of spreadsheet columns. [17]

OAIS also specifies five categories of Preservation Description Information (PDI): provenance, reference, fixity, context, and access rights information. PDI is administrative metadata, and all of the categories save one (fixity) are common to archival practice for analog materials. Archivists document the provenance of their materials as well as context and access rights in collection control files and finding aids. Archivists use reference information to identify collections, series, boxes, folders, and even individual items and link our metadata to our materials. Archivists can use these existing descriptive tools to fulfill the requirements of an OAIS digital repository.

Fixity is the one preservation description information category that does not fit well into existing practices. As with representation information, there are a number of readily available tools such as RapidCRC [18] and DataAccessioner [19] that produce manifests which record the objects identifier (usually the current file path) and the checksum digest. At a minimal level for fixity, all an archives needs to do is run a checksum generation tool (or validation tool if fixity information was provided by the donor) and store the checksums in a consistent location.

Packaging Information, “either actually or logically, binds or relates the components of the package into an identifiable entity.” [20] This can be done by specifying which parts of the information package are stored in which files in a directory structure using a consistent naming scheme. Archivematica’s AIP specification serves as their Packaging Information by describing how they store their Archival Information Package components (a directory and naming scheme and METS file within a Bag-It bag within a 7-Zip file). [21] In most cases the various components will be stored in different systems. This is true not only of simple repositories that keep digital objects and manifests on external media with other preservation description information in a tool like ArchivesSpace but also the complex digital repositories. The important point is that an archives needs to document this packaging information, however it is implemented.

Digital Repository Functions

Section 4.2 of the OAIS reference model describes the six digital repository functional entities: ingest, archival storage, data management, access, preservation planning, and administration. Each of these entities represent someone or something (e.g. software) which performs the functions associated with it.

The first subsection describing these functional entities in detail (4.2.3.2) discusses common services, a section that is usually omitted in conversations of the standard because it underlies and supports everything else, thus it is not explicitly listed as a functional area. The common services section recognizes that a technological baseline of computing capability is required for working with digital records, such as operating systems, networking, and system security. An archives must identify the hardware and software infrastructure necessary to meet their own digital repository needs. As OAIS states in their section on security, “the appropriate level of protection [or any capability] is determined based upon the value of the information to the application end-users and the perception of threats to it.” [22] Acquiring technical infrastructure is as much about cost-benefit and risk analysis as it is functional requirements. Digital archiving can be done simply and relatively inexpensively or in a very sophisticated and costly manner. What are the risks, what are the benefits, and how much do the stakeholders care to spend on it? Infrastructure and security requirements for local history centers will differ from requirements for corporate and government archives holding restricted but commercially valuable records attractive to attackers.

The ingest functional entity [23] has five functions: receive submissions, quality assurance, generate archival information packages, generate descriptive information, and coordinate updates. Receiving submissions and quality assurance require copying the data and ensuring it is what the archives expected to receive—either by paging through the files to verify content, much as one would do with boxes of paper records received, or validating checksums if they are provided. Generating the archival information package involves gathering the representation information and preservation description information and recording them according to the structure determined by the repository’s packaging information. This could be a basic checksum manifest, a list of identified formats, and a text file recording everything else in a few file directories. Generating descriptive information is similar to creating archival finding aids for analog collections: record a title, dates, and extents along with any other appropriate fields in whatever archival information management system the archives currently uses. Coordinating updates involves moving the archival information package into long-term storage and making the descriptive information available with all the other collection descriptions. In other words, the ingest is the same as traditional archival accessioning and baseline processing, only with digital materials.

The archival storage functional entity [24] is much like managing archival stacks, although in a digital context. The first function, receive data, ensures the archival information package is stored on appropriate media which is much like finding a shelf in the stacks for a collection’s boxes and recording their locations. The second, managing storage hierarchy, ensures that the storage used meets the organization’s storage policy requirements, left open to the organization’s discretion. Are the digital stacks large enough, close enough to users, and secure enough to protect the materials they house? The third function, replace media, is the least like physical stacks as archivists do not throw out and build new stacks when the existing ones wear out (very often, at least), but most digital media is inherently unstable and so will need to be replaced on a regular basis according to institutional policy, which is left to the institution to determine. The fourth function, error checking, monitors data/media for errors. Similar to how an archives monitors heat and humidity levels, and examines records for signs of mold, mildew, red rot, pests, and other signs of deterioration, archivists must regularly check for digital degradation. This section of OAIS does include a rare case of recommending specific technologies, in this case for fixity checking (it suggests Cyclic Redundancy Checks and Solomon Reed encoding), although different ones are often used by most archives (previously MD5 and now more commonly SHA-256). What matters is that the task gets done, no matter which specific technology is used. [25] The disaster recovery function requires an archives to plan for the unfortunate reality that disasters occur by placing at least one copy in a physically separate facility (however it gets there). Finally, the provide data function requires the archive to provide data to the requester if the requester is authorized to access it. An archives retrieves boxes from the stacks for researchers and needs to get data from digital storage when necessary as well. As per the standard, the details of how this is done are left for the archives to determine.

The data management functional entity [26] maintains a “data management database” which stores descriptive information (finding aids, catalog records, accession records, etc.) and system information (administrative metadata). Descriptive information for digital materials can be maintained in the same descriptive systems an archives already uses, be it a library catalog, a collection of EAD finding aids, a home-grown relational database, or an Archival Description Management System such as ArchivesSpace. [27] Similarly, system information can be stored in a series of text files, eXtensible Markup Language (XML) files, a relational database, a triple-store, or any other sort of datastore the archives deems appropriate for maintaining administrative metadata. Each system will have their own affordances for management and querying. An archives administers the database (by ensuring it is working properly and meets the archives’ needs), performs queries (either by manually looking through records or preset queries), generates reports as needed (such as summaries of holdings or usage statistics by, again, either manual or programmatic means), and receives updates (loading new or updating existing collection descriptions and administrative metadata).

The administration and preservation planning functional entities [28] , naturally, deal with administrative and planning, not technical tasks. An archives administration needs to negotiate submissions of materials, set policies, ensure policies are being followed, manage requests, and so on. Preservation planning monitors technology, tracks user needs, develops strategies, and plans implementation.

The access functional entity [29] allows for the discovery and delivery of digital archival materials. Although the language used to describe coordinating access activities appears complex, it is actually a very abstract way of describing reference requests archivists get day-to-day: receiving a request for information, answering the request, receiving a request to access content, and then coordinating that access. Generating the DIP (dissemination information package) involves gathering the necessary data and metadata necessary to fulfill the reference request and any necessary conversions. For example, if the researcher only needs a meeting minutes series that are all PDFs, generating the DIP only requires gathering the PDFs and a copy of, or link, to the relevant finding aid. The deliver response function could be accomplished by sending an email (assuming the archives has the right to distribute copies) with the PDFs and a link to the finding aid. If the minutes are in an older document format the requester can not open then the generate DIP function can include making access versions. The challenges of providing effective access to digital materials, including rights issues and systems obsolescence, are significant, but OAIS “compliance” is not one of them.

Being a functionally complete, “real repository”, does not necessarily mean that it is effective or scalable. It may be better than nothing but still not enough to satisfy an archivist’s desires. What then can an archives do to ascertain the quality of their repository?

Trustworthy Digital Repositories

Rather than asking what makes a digital repository “real,” archivists may ask what makes a digital repository trustworthy? Being a real repository is, in the stricter sense, relatively simple, being a trustworthy repository of digital materials is much more difficult. Archives commit to being trustworthy custodians of archival materials, but born-digital materials require additional reassurances due to their high degree of mutability and their relative lack of artifactual qualities suitable for traditional diplomatic analysis. Heather MacNeil states that “for the preservers of electronic records to function effectively as trusted custodians […]it is not sufficient that they simply declare that the records in their custody are presumptively authentic; they also provide grounds for such declaration.” [30] Matthew Kirschenbaum, et. al., also state than “an institution that has a proven track record with regard to conserving, processing, and making available paper manuscripts—in other words, is trusted to handle traditional archival materials—is not necessarily a trustworthy custodian of digital objects.” [31] What then makes a repository “a trustworthy custodian of digital objects”?

In 2002 RLG and OCLC provided seven recommendations to help repositories ensure their trustworthiness. They focus primarily on good management practices including institutional stability and careful documentation of policies and digital holdings. Like the OAIS reference model, there is no requirement for a certain degree of technological sophistication. The closest it gets to a technical requirement is the declaration that systems must include routine integrity checking and data redundancy, both of which can be managed using external media and fixity checking software. [32]

The first recommendation in the RLG/OCLC report is to “develop a framework and process to support the certification of digital repositories” [33] which lead to the development of the “Trusted Repositories Audit & Certification: Criteria and Checklist” (TRAC) [34] which served as the basis for ISO 16363:2012 “Audit and certification of trustworthy digital repositories.” [35] ISO 16363 includes three main areas of interest: organizational infrastructure, digital object management, and technical infrastructure and security. All three sections are policy-centric and focus on managing and documenting implementation rather than dictating complex technology infrastructure. Marks notes in “Becoming a Trusted Digital Repository” that “ISO 16363 is not a blueprint […]but it does provide a set of useful requirements to keep in mind during the design process.” [36]

ISO 16363:2012 and its predecessors are not the only standards to establish requirements for digital repository trustworthiness. The Data Seal of Approval has sixteen core requirements, [37] the Nestor Seal of Approval extended self-assessment (also related to TRAC) has thirty-four criteria, [38] and the Center for Research Libraries attempted to summarize the various requirements in 2007 into their “Ten Principles”. [39] Again, the fundamental requirements across all of these systems are that policies, procedures, and documentation are all in place rather than specific or complex systems. A repository’s consideration for effective policy, procedure, and documentation is the driving factor in these standards for trustworthiness, not the sophistication of their hardware or software.

The bar for certifiable trustworthiness these standards are set quite high. This can be rather disheartening to those developing repositories. Certifiable trustworthiness is a laudable goal to strive for but it takes a great deal of work. It can seem unattainable given the competing demands for an archivist’s attention, but certifiable trustworthiness is not necessarily required.

Heather MacNeil states in Trust and Professional Identity: Narratives, Counter-Narratives and Lingering Ambiguities “that the trustworthiness of records is socially negotiated.” [40] Some parts of society will trust almost anyone while others will trust almost no one, regardless of the efforts to prove themselves. By extension, a repository’s trustworthiness is also socially negotiated. Greg Bak in his article “Trusted by whom? TDRs, standards culture and the nature of trust” illustrates how the existing standards of trust rely on a technocratic view of trust rather than one based on building relationships. [41] Thus, it isn’t even clear how much influence these standards will have on the trust a repository will receive from their user community. Some research has been done on users’ perception of trust in scientific data repositories, [42] academic institutional repositories, [43] and government archives [44] but not in other institutional archives nor manuscript repositories.

At one archive a potential donor asked them to describe their capabilities for preserving electronic records. A relatively brief statement (a few paragraphs) was prepared in response to the request which outlined current policies, an admission of gaps, and plans for improvement. Despite an admission of imperfection this honest and open response engendered sufficient trust for the donor to deposit their records with the repository. Although this example is anecdotal, it illustrates that, perhaps, a good faith effort at forward progression can, for some communities, be sufficient to engender trust in the archives within their producers and consumers.

An archives may decide not to formally pursue certified trustworthiness, but trustworthy digital repository standards, such as ISO 16363, can serve as guides for improvement. A repository can perform a self-audit to identify gaps. For example, The University Archives at University of Illinois at Urbana-Champaign performed a self-assessment based on ISO 16363 guided by Steve Marks’ “Module 8: Becoming a Trustworthy Digital Repository” and concluded that

“conducting an informal self-assessment not only helped us to better understand our own preservation operations, it also provided significant insight into the frameworks, policies, and practices that UA and DP will need to put in place if we wish to be successful and trustworthy.” [45]

Self-assessments are useful exercises, but they may still leave the archivist wondering which of their many gaps they should address first.

Where to From Here? Developing Repository Maturity

Digital repositories mature through multiple stages of development. All digital repositories begin with the inclination that something needs to be done. Capability grows gradually until a robust digital repository, in terms of both organizational and technical infrastructure, has matured into a full digital preservation program. The three main repository maturity models used to describe the process of becoming a mature digital repository are Kenney and McGovern’s Five Organizational Stages, [46] the Digital Preservation Coalition’s Rapid Assessment Model (DPC RAM), [47] and the National Digital Stewardship Alliance’s (NDSA) Levels of Preservation. [48]

Five Organizational Stages of Digital Preservation

Kenny and McGovern’s Five Organizational Stages focus squarely on the maturity of a repository’s organizational infrastructure. They note “a real key in assessing digital preservation is to understand the organizational impediments to digital preservation practice” and that “technology is not the solution, only part of it.” As the name indicates, their maturity model is divided into five stages of organizational development: Acknowledge, Act, Consolidate, Institutionalize, and Externalize. In addition to defining these stages McGovern and Kenny provide key indicators to help repositories recognize when they have reached a particular stage, including policy and planning, technological infrastructure (again, as principles rather than specific technologies), and the content and use being supported.

A repository reaches the Acknowledge stage when they openly and honestly accept that digital preservation is not only a theoretical concern, but a practical concern that their repository must address. This stage reflects a repository’s acceptance of their responsibility for the digital materials within their stewardship. How many readers have received digital media with a records transfer or accession and then turned a blind eye? Or been asked about capturing a website or social media account and then simply decline capability and/or quickly change the subject? In 2008, Susan Davis quoted a survey respondent who stated “We are passively accepting born-digital materials […] All planning, policy, etc. take a back seat to day-to-day efforts to keep up with basic activities.” [49] Although this repository accepted digital materials, they ignored them. Kenny and McGovern wrote “ownership by itself […]is insufficient.” This repository had not yet acknowledged a responsibility for preservation. A repository can acknowledge their responsibility by having an honest conversation among staff and with donors about the implications of accepting born-digital materials, either in a theoretical overview or as a specific case study, and then commit resources (for example, staff time for drafting policy, if nothing else) to move forward.

The Act stage, doing something to address digital preservation challenges, naturally flows from acknowledgement. McGovern and Kenny describe this stage as being project-oriented. An institution could start with an inventory project (where are all the media? what websites or social media accounts need to be captured?) and then move on to projects such as acquiring adequate storage, migrating media, and web-capture, as appropriate. This is the bootstrapping stage where the initial policies and infrastructure are being developed. At least two Presidents of the Society of American Archivists issued calls-to-action which embody this stage. The first came from Richard Pearce-Moses in 2006 who stated “many [archivists] feel paralyzed because they don’t know what to do. The key is: We cannot let the perfect be the enemy of the possible. Ask yourself, What can I do today? No matter how small, do something.” [50] Helen Tibbo reiterated the challenge in 2011 to “take some steps and do something to preserve digital content important to your collection and your users.” [51]

The Consolidate stage is where the dust of initial project-based development begins to settle and ad-hoc activities transition into programmatic policies and workflows built on now-established infrastructure. The institution has transitioned from “we should be doing this” and “we are doing something about it” to “this is a regular part of what we do.” It does not mean everything is perfect, ideal, or sophisticated. It may (and initially, probably will) be terribly insufficient compared to where an archives wants to be. That is fine, for now. The point is that digital preservation activities are now regular operations rather than exceptional projects. Improvement at this stage often comes from small progressive enhancements to existing operations. An archives may still engage in large projects, but there is the expectation that the project results will be integrated with current infrastructure and workflows, not a stand-alone proof-of-concept.

In the Institutionalize stage digital preservation grows beyond the archives and incorporates the parent institution as well. The metaphorical airplane has lost cabin pressure (digital preservation is a problem for everyone now), the archives has put on their oxygen mask (digital preservation in the archive is programmatic), and now it can help others. For archives situated inside academic libraries, such as the McGovern and Kenney’s Cornell example, this involves engaging the larger library in digital repository efforts to support a broader range of content such as electronic theses and dissertations, scholarly publications, and research data. For corporate, government, and other archives this stage may be characterized as digital preservation outreach to the organization’s constituent parts to encourage good digital preservation practices. [52] McGovern and Kenny also include in this stage aligning local digital preservation policies with external standards and guidelines such as OAIS and TDR and gap-analysis; although gap analysis, at least informally, may be introduced as early as the Act stage as it can inform first steps.

The Externalize stage focuses on building partnerships with other like-minded institutions and consortia. McGovern and Kenny cite a number of consortia as examples such as LOCKSS and the California Digital Library. This stage reflects a confidence in a repository’s organizational and technical capability and a trust that their partners are sufficiently capable to cooperate with them. [53] Although McGovern and Kenny place these collaborations in the last stage of maturity, an archives may choose to find a consortium early on in their development in order to leverage their members’ experience and capabilities. In either case, the organization is making a commitment to abide by the standards and expectations of those consortia. An archivist must ensure the repository understands the implications of any such association before committing to it.

McGovern and Kenney’s Levels describe an archive’s administrative capacity to accept their responsibility for born-digital content, take action, systematize, expand, and collaborate. The focus is on institutional readiness and maturity. An archivist should consider their own repository in light of these stages, and review the key indicators McGovern and Kenney provide in their chapter.

National Digital Stewardship Alliance Levels of Digital Preservation

In 2012 the National Digital Stewardship Alliance Levels team concluded that none of the existing repository assessment models “specifically addressed the need for practical technical guidance when a preservationist takes preliminary first steps or builds on steps already taken.” They then determined to produce a non-judgmental “matrix of activities that were detailed enough to be meaningful, while still being succinct enough to fit on a single page”. [54] The goal was to emphasize steps a practitioner can take, today if possible, to improve their digital repository, “not the social or legal structure that would be in place to sustain those activities,” a departure from other policy and workflow-heavy models. [55]

As with the other models, the NDSA Levels are “agnostic towards both content type and technology” while setting “a community-approved minimum level of prerequisites.” [56] The first level [57] can be implemented with simple infrastructure. More sophisticated technology environments may be necessary for the higher levels which focus on automation, but a lack of technical resources should not prevent an archive from doing something beneficial now.

The Levels of Preservation matrix describes four numbered levels (or tiers) [58] that “progressively reduce various risks to digital materials” [59] across five functional areas (or categories): Storage and Geographic Location, File Fixity and Data Integrity, Information Security, Metadata and File Formats.

The first functional area, Storage and Geographic Location, begins with migrating data off the original media into a consistent storage system. The levels progress by increasing copies and geographic diversity along with long-term planning and system monitoring. While no specific storage technology is recommended, nor a particular infrastructure required, a “nearline or online system using … some combination of spinning disk and magnetic tape” is suggested as an appropriate option. A repository can effectively make use of offline storage at these earlier stages but require some manual administration, whereas the nearline and online systems enable the automation described by the more advanced stages.

The File Fixity and Data Integrity functional area addresses data fixity. Keeping data fixed (i.e. immutable) helps to ensure record authenticity. Fixity in current repositories is usually achieved with checksums. The first stage of this functional area requires verifying any donor-provided checksums if provided; otherwise an archives generates their own checksums. The levels progress by adding other related activities such as write blockers, virus checking, automation, logging, and ensuring no one person can modify all the copies (either intentionally or unintentionally). For example, an archives may begin by creating checksums using a tool like RapidCRC, then setting a regular schedule for validating those checksums, then progress to automated checking on a regular basis using a tool like AV Preserve’s Fixity, [60] before adopting a more comprehensive repository software that includes regular fixity auditing as a feature.

In line with the data integrity section, the Information Security functional area secures materials from human harm (again, either intentional or unintentional). Knowing who has access and preventing unnecessary access are the first step. Levels progress by increasing logging and automation.

The Metadata functional area focuses on managing administrative, technical, and descriptive metadata. The first stage starts with inventories that are safely stored. The levels progress by including additional types of preservation metadata. “In most systems nearly all of this metadata … can and should be generated and processed computationally and not manually.” [61] Not all the metadata need to be of the same format or in the same location and most of the day-to-day tools in use (beyond commercial or Fedora-based repository systems), do not use common schema or consistent locations. Simple repositories will likely begin using several stand-alone tools that generate or record metadata in their own fashion. For example, format migration tools for creating access copies may not produce any logging metadata, so an archivist will have to record them manually somewhere. Manual, non-standard, or stand-alone metadata files are less desirable because they can increase administrative overhead and make auditing more complex, but they are still acceptable. It is better to have metadata in a non-standard format, in a stand-alone file, or manually recorded than none at all. Ideally a system could manage these metadata holistically, but that is a sign of program maturity, not a requirement.

The File Formats functional area addresses format obsolescence by addressing the degree of programmatic emphasis rather than format endangerment (risk of obsolescence). The first level encourages archivists to advocate when possible for donors to use open formats as this advocacy can reduce the degree of format complexity and diversity the archive will have to work with later. The levels progress as an archives turns their attention to inventorying file formats in their collections, monitoring format endangerment, [62] and then attending to format migrations or emulation solutions in the last level.

NDSA plans to update the Levels document as the needs of the digital preservation community change. For example, Shira Peltzman proposed an additional Access Functional Area. [63] This new functional area would begin by ensuring the materials are secured from harm during access (such as a write-protected media or workstation) and matures as the access mechanism automates and provides richer access environments. This proposal was taken up by the Digital Libraries Federation (DLF) Born-Digital Access Working Group resulting in their own Five-Levels report. [64]

The NDSA report lists several uses for the Levels document including community consensus building and communicating with stakeholders. [65] The fifth use, “assess compliance with preservation best practices and identify key areas to improve,” is in line with the other models this paper has discussed. The NDSA Levels’ authors emphasize that this is not intended to give a single score; an archives is free to investigate a single functional area of interest or review all of them, as the archives sees fit, resulting in “broad areas to improve, identify areas of service excellence and pinpoint specific enhancements… and to track progress over time.” [66] All of this from a single-page maturity model. An archivist could consider this a “quick start” digital repository maturity assessment.

Digital Preservation Coalition Rapid Assessment Model

The Digital Preservation Coalition’s Rapid Assessment Model (DPC RAM) was designed “to enable a rapid assessment of an organization’s digital preservation capability whilst remaining agnostic to solutions and strategy.” [67] It was primarily based on the Digital Preservation Maturity Model found in Adrian Brown’s book “Practical Digital Preservation: A How-to Guide for Organizations of Any Size” and informed by other maturity models, including the NDSA model discussed in the previous section. [68] It has received two updates since its first publication in 2019 based on community feedback and “evolving digital preservation good practice.” [69]

DPC RAM uses five levels of maturity which balance the semantic scaling of the McGovern and Kenney model and the purely numerical progressive nature of the NDSA model. Accordingly, it doesn’t scale the same way as either. DPC RAM begins with a zero level, “Minimal Awareness” which essentially translates to “I’ve heard of it” or “I’m just now hearing about this.” At this level the DPC RAM may be the organization’s realization that this capability needs to be addressed. This pre-level leads naturally into level one, “Awareness” which translates to an educated understanding of the basic principles and why it is necessary. This level matches McGovern and Kenney’s first level, Acknowledge, as it represents an understanding that this capability is the organization’s responsibility and the need to act. The following levels are less tightly coupled. DPC RAM focuses on increased capability from two to four, labeled “Basic,” “Managed,” and “Optimized”. The “Basic” and “Managed” levels could loosely be compared to McGovern and Kenney’s “Act” and “Consolidate” stages where the actions taken establish those basic capabilities and the consolidation process creates the capabilities for managing them. Beyond that the “Optimized” level takes on aspects of both McGovern and Kenney’s “Institutionalization” and “Externalization” stages but emphasizes proactive management of the capability: focusing future capabilities and challenges and building in continuous improvement.

While McGovern and Kenney’s model addresses an organization’s digital preservation program as a whole, the DPC RAM (like the other models that influenced it, such as the NDSA model) recognizes that an organization’s maturity is multi-dimensional. Different aspects of the organization’s capabilities will mature at different times and rates depending on the organization’s current priorities and most pressing needs. DPC RAM even builds this on-going evaluation and continuous improvement into their model as one of the assessment areas. These capabilities are divided into two primary sections: Organizational capabilities and Service Capabilities. The Organizational capabilities focus on the ability to manage the digital preservation endeavor, for example policy, legal compliance, and information technology resourcing. These capabilities cover most of the areas in which McGovern and Kenney’s model are concerned: policy, strategy, and community. Service capabilities focus on the processes used, such as acquisition, preservation actions, and metadata management. These capabilities are more closely aligned with the “hands-on” digital preservation concerns highlighted by the NDSA model.

As complex or as detailed as the model may sound, the model is laid out so that a relatively quick self-assessment can be performed in an afternoon, depending on how familiar one is with the capabilities and organization being assessed and still result in a rough idea of where a repository stands and where effort will be best spent moving forward. Moving forward is the critical part. One of the driving principles of the DPC RAM is continuous improvement. The instructions explicitly suggest that organizations take the assessment results and consider what “level they would like to achieve in the future” to “increase [their] understanding of gaps and priorities for moving forward.” [70] This is, perhaps, the most important aspect: helping an archives reach informed discussions about their repository’s maturity, where they need to prioritize development, and making plans to do so.

Conclusion

While the labels, emphases, and details vary between all three maturity models, they are all useful in helping an archives consider where their digital repository stands and what can be done next to grow and develop. The Center for Research Libraries’ “Ten Principles” note that “for repositories of all types and sizes preservation activities must be scaled to the needs and means of their respective designated community or communities.” [71] No two archives are the same. Policies and procedures should be adapted to meet local needs. As Williams and Berilla stated when documenting their repository’s journey to implement digital archiving:

“practicality often trumps theory, and a middle ground of digital content management must be contemplated. Because of their own idiosyncrasies, institutions must cherry pick among best practices for what works for them. In essence, every institution must develop a unique plan.”

[72]

When we consider “young” analog archives they may be very simple: a few boxes of materials in a closet with a simple inventory. Most archives have humble beginnings. Over the years, through much advocacy, planning, and resourcefulness these archives grow in size and capability. Professionals do not (or should not) disparage the work of an archivist following archival principles by saying they do not have a “real” archives, because their nascent repository is immature. They have a real archives, one that we hope will succeed and become more mature over time through the archivist’s diligent effort.

Simple digital repositories are still “real” even if, perhaps, immature. They can mature if given the proper attention and resources. Chris Prom describes his own digital preservation journey and the steps he took toward repository development in a keynote address for the 2011 Society of Georgia Archivists annual meeting. [73] The address describes a “Do-it-Yourself Trusted Digital Repository” for which “most repositories already have what they need” and which his repository used while a more sophisticated repository application was in development. [74] Prom’s experience, though not framed within the maturity models this article discussed, does follow the same patterns: accepting responsibility, identifying needs, finding solutions to meet those needs, and making improvements as capability and resources increase.

In 2013 the “Jump In Initiative” hosted by the Society of American Archivists’ Manuscripts Repositories Section encouraged archivists to “Jump In to managing born-digital content,” [75] spurring repositories to shift from the Acknowledge stage of Kenny and McGovern’s model to the Act stage. The participation rules stated that “participants must be from an institution without an electronic records program in place” to target repositories that had not yet reached the Consolidate stage. Twenty-three repositories reported back on their efforts to survey their born-digital content. [76] None of these repositories began with the technical infrastructure typically associated with digital repositories. Nevertheless, they were digital repositories in the process of maturing.

Archivists want their digital repositories to be mature now, but maturity only comes through dedicated effort, not with the wave of a Blue Fairy’s wand. Digital repositories can, and should, start with simple infrastructure and simple processes. What matters right now is that repositories make progress. Describing a digital repository’s status in terms of a maturity model allows them to be honest in where they stand while still being respectful of our small and simple, but very real, digital repositories.

Notes

[1] Pearce-Moses, Richard. “Repository.” A Glossary of Archival and Records Terminology. Chicago, IL: The Society of American Archivists, 2005. https://www2.archivists.org/glossary/terms/r/repository.

[2] Ockerbloom, John Mark. “Everybody’s Repositories (First of a Series).” Everybody’s Libraries, May 7, 2008. https://everybodyslibraries.com/2008/05/07/everybodys-repositories-first-of-a-series/.

[3] Pearce-Moses, Richard. “Archives.” A Glossary of Archival and Records Terminology. Chicago, IL: The Society of American Archivists, 2005. https://www2.archivists.org/glossary/terms/a/archives.

[4] Adrian Cunningham. “Digital Curation/Digital Archiving: A View from the National Archives of Australia.” The American Archivist, Fall/Winter 2008, Vol. 71, No. 2, p. 533. https://doi.org/10.17723/aarc.71.2.p0h0t68547385507.

[5] Joanne Kaczmarek et al., “Using the Audit Checklist for the Certification of a Trusted Digital Repository as a Framework for Evaluating Repository Software Applications: A Progress Report,” D-Lib Magazine 12, no. 12 (December 2006), https://doi.org/10.1045/december2006-kaczmarek.

[6] Consultative Committee for Space Data Systems. Reference Model for an Open Archival Information System (OAIS). CCSDS, 650.0-M-3. Washington, DC: CCSDS Secretariat, 2024. https://ccsds.org/wp-content/uploads/gravity_forms/5-448e85c647331d9cbaf66c096458bdd5/2025/01//650x0m3.pdf. An earlier version was adopted as ISO Standard 14721:2012.

[7] If, however, the reader is not familiar with the model, there are many existing resources that summarize or explain OAIS including both: Brian Lavoie. “The Open Archival Information System (OAIS) Reference Model: Introductory Guide (2nd Edition).” Digital Preservation Coalition, October 1, 2014. https://doi.org/10.7207/twr14-02. and Ockerbloom, John Mark. “What Repositories Do: The OAIS Model.” Everybody’s Libraries, October 13, 2008. http://everybodyslibraries.com/2008/10/13/what-repositories-do-the-oais-model/.

[8] The author counted over one-hundred articles across several journals, including American Archivist, Archivaria, D-Lib, and Archival Science, that referenced OAIS, with many of them falling into this category.

[9] For example, Ronald Jantz and Michael J. Giarlo, “Digital Preservation: Architecture and Technology for Trusted Digital Repositories,” D-Lib Magazine 11, no. 06 (June 2005), https://doi.org/10.1045/june2005-jantz briefly discusses the OAIS object models in regards to submitting METS-based submission information packages to their Fedora-based repository; Mary Vardigan and Cole Whiteman, “ICPSR meets OAIS: Applying the OAIS reference model to the social science archive context,” Archival Science 7, (2007), 73-87, http://hdl.handle.net/2027.42/60440 does a good job describing OAIS in general terms for context and then compares the ICPSR’s system to OAIS; and Timothy Arnold and Walker Sampson, “Preserving the Voices of Revolution: Examining the Creation and Preservation of a Subject-Centered Collection of Tweets from the Eighteen Days in Egypt,” American Archivist vol. 77, vo. 2 (Fall/Winter 2014), pp. 510-533. https://doi.org/10.17723/aarc.77.2.794404552m67024n describes a Twitter tweet in terms of the OAIS information package.

[10] Courtney C. Mumma, Glenn Dingwall, Sue Bigelow, “A First Look at the Acquisition and Appraisal of the 2010 Olympic and Paralympic Winter Games Fonds: or, SELECT * FROM VANOC_Records AS Archives WHERE Value=“true”;”, Archivaria 72 (Fall 2011).

[11] OAIS, pg 3-1.

[12] See also: Consultative Committee for Space Data Systems. Producer-Archive Interface Methodology Abstract Standard (PAIMAS). CCSDS, 651.0-M-1. Washington, DC: CCSDS Secretariat, 2004. https://public.ccsds.org/Pubs/651x0m1.pdf. Adopted as ISO Standard 20652:2006.

[13] OAIS, pg 1-3.

[14] AtoM and ArchivesSpace can be found at https://www.accesstomemory.org and http://archivesspace.org/, respectively.

[15] In the case of digital materials, this refers to the bits that make the digital object; although OAIS allows physical objects to be classified as data objects, too.

[16] Droid <http://www.nationalarchives.gov.uk/information-management/manage-information/preserving-digital-records/droid/> and FITS <http://fitstool.org>.

[17] Many of the records archives collect are either unstructured (e.g. images, audio, office documents) or include semantics as part of the format (e.g. email headers, XML-based documents, Twitter Tweet objects) and do not require additional documentation of semantic information. Other formats, such as spreadsheets or databases, structure data but do not inherently carry semantic information with them. E.g. it is not always clear what the values in a spreadsheet column is supposed to mean. These should be documented somewhere, e.g. an associated README file and a DACS (Describing Archives, A Content Standard) Technical Access Note.

[18] https://www.ov2.eu/programs/rapidcrc-unicode

[19] https://github.com/digitalpowrr/DataAccessioner

[20] OAIS, Section 4.3.2.4.4 (pg 4-37).

[21] https://wiki.archivematica.org/AIP_structure

[22] OAIS, pg 4-4.

[23] OAIS, section 4.2.3.3.

[24] OAIS, section 4.2.3.4.

[25] For good introduction to fixity checking see: Paula De Stefano et al., “Checking Your Digital Content: What Is Fixity, and When Should I Be Checking It?” (National Digital Stewardship Alliance, 2014), http://hdl.loc.gov/loc.gdc/lcpub.2013655117.1.

[26] OAIS, section 4.2.3.5.

[27] http://www.archivesspace.org

[28] OAIS, sections 4.2.3.6 and 4.2.3.7.

[29] OAIS, section 4.2.3.8.

[30] Heather MacNeil, “Providing Grounds for Trust: Developing Conceptual Requirements for the Long-Term Preservation of Authentic Electronic Records,” Archivaria 50 (January 1, 2000), http://archivaria.ca/index.php/archivaria/article/view/12765, pg. 72. See also MacNeil, Heather. “Trust and Professional Identity: Narratives, Counter-Narratives and Lingering Ambiguities.” Archival Science 11 (October 12, 2011): 175–92. https://doi.org/10.1007/s10502-011-9150-5.

[31] Kirschenbaum, Matthew G., Richard Ovenden, Gabriela Redwine, and Rachel Donahue. Digital Forensics and Born-Digital Content in Cultural Heritage Collections. CLIR Publication 149. Washington, D.C: Council on Library and Information Resources, 2010. pg 29.

[32] For example, a repository could wrap content in a Bag-It bag and place copies on at least two external hard drives which could periodically be retrieved and validated using Bagger or another command-line tool according to a set schedule and tracked using a spreadsheet. See the discussion of OAIS and fixity earlier in this article.

[33] Research Libraries Group. “Trusted Digital Repositories: Attributes and Responsibilities.” Mountain View, California: RLG, Inc., 2002. http://www.oclc.org/content/dam/research/activities/trustedrep/repositories.pdf. pg 35.

[34] Center for Research Libraries (CRL), Online Computer Library Center (OCLC), and National Archives and Records Administration. “Trustworthy Repositories Audit & Certification: Criteria and Checklist.” OCLC and CRL, February 2007. http://www.crl.edu/sites/default/files/attachments/pages/trac_0.pdf.

[35] International Organization for Standardization. “Space Data and Information Transfer Systems – Audit and Certification of Trustworthy Digital Repositories.” ISO 16363:2012. Geneva, Switzerland: ISO, 2012. https://www.iso.org/standard/56510.html. Also available as CCSDS 652.0-M-1 at https://public.ccsds.org/Pubs/652x0m1.pdf.

[36] Steve Marks, Becoming a Trusted Digital Repository (Society of American Archivists, 2015), p 4.

[37] Data Seal of Approval and ICSU World Data System. “Core Trustworthy Data Repositories Requirements.” Data Seal of Approval, November 2016. https://drive.google.com/file/d/0B4qnUFYMgSc-eDRSTE53bDUwd28/view. See also the Data Seal of Approval website https://www.datasealofapproval.org/en/.

[38] Nestor. “Assessment Form for Obtaining the Nestor Seal for Trustworthy Digital Archives.” Nestor, 2017. http://files.dnb.de/nestor/zertifizierung/Einreichungsformular_EN.docx. See also Nestor. “Nestor Seal for Trustworthy Digital Archives.” Nestor, March 8, 2017. http://www.langzeitarchivierung.de/Subsites/nestor/EN/Siegel/siegel_node.html. Based on DIN 31644: “Criteria for for trustworthy digital archives.”

[39] Center for Research Libraries (CRL). “Ten Principles.” Center for Research Libraries Global Resources Network, 2007. https://www.crl.edu/archiving-preservation/digital-archives/metrics-assessing-and-certifying/core-re.

[40] MacNeil, Heather. “Trust and Professional Identity: Narratives, Counter-Narratives and Lingering Ambiguities.” Archival Science 11 (October 12, 2011): 175–92. https://doi.org/10.1007/s10502-011-9150-5, pg. 187.

[41] Greg Bak, “Trusted by Whom? TDRs, Standards Culture and the Nature of Trust,” Archival Science 16, no. 4 (December 1, 2016): 373–402, https://doi.org/10.1007/s10502-015-9257-1.

[42] Kathleen Fear and Devan Ray Donaldson, “Provenance and Credibility in Scientific Data Repositories,” Archival Science 12, no. 3 (September 1, 2012): 319–39, https://doi.org/10.1007/s10502-012-9172-7; Elizabeth Yakel et al., “Trust in Digital Repositories,” International Journal of Digital Curation 8, no. 1 (June 20, 2013): 143–56, https://doi.org/10.2218/ijdc.v8i1.251; Ayoung Yoon, “End Users’ Trust in Data Repositories: Definition and Influences on Trust Development,” Archival Science 14, no. 1 (March 1, 2014): 17–34, https://doi.org/10.1007/s10502-013-9207-8.

[43] Adolfo G. Prieto, “From Conceptual to Perceptual Reality: Trust in Digital Repositories,” Library Review 58, no. 8 (September 4, 2009): 593–606, https://doi.org/10.1108/00242530910987082.

[44] Dara M. Price and Johanna J. Smith, “The Trust Continuum in the Information Age: A Canadian Perspective,” Archival Science 11, no. 3–4 (November 1, 2011): 253–76, https://doi.org/10.1007/s10502-011-9148-z; Sue Childs and Julie McLeod, “A Case Example of Public Trust in Online Records – The UK Care.Data Programme” (InterPARES Trust Project, February 8, 2015), https://interparestrust.org/assets/public/dissemination/EU17_20150802_UKCareDataProgramme_FinalReport_Final.pdf; Michelle Spelay, “Trusted Online Access to Distributed Holdings of Digital Public Records,” Literature Review (InterPARES Trust, September 2016), https://interparestrust.org/assets/public/dissemination/AA05_20160915_TrustedOnlineAccessPublicRecords_LiteratureReview_FINAL.pdf.

[45] Bethany Anderson, “Appendix A: Case Study: University Archives, University of Illinois at Urbana-Champaign,” in Module 8: Becoming a Trusted Digital Repository, by Steve Marks, Trends in Archival Practice (Chicago, Il: Society of American Archivists, 2015), 60–64, https://www2.archivists.org/sites/all/files/Module_8_CaseStudy_BethanyAnderson.pdf. See also their earlier article: Joanne Kaczmarek et al., “Using the Audit Checklist for the Certification of a Trusted Digital Repository as a Framework for Evaluating Repository Software Applications: A Progress Report,” D-Lib Magazine 12, no. 12 (December 2006), https://doi.org/10.1045/december2006-kaczmarek.

[46] Kenney, Anne R., and Nancy Y. McGovern. “The Five Organizational Stages of Digital Preservation.” In Digital Libraries: A Vision for the 21st Century: A Festschrift in Honor of Wendy Lougee on the Occasion of Her Departure from the University of Michigan, edited by Patricia Hodges. Michigan Publishing, University of Michigan Library, 2003. https://doi.org/10.3998/spobooks.bbv9812.0001.001.

[47] Digital Preservation Coalition Rapid Assessment Model (version 3 – March 2024) http://doi.org/10.7207/dpcram24-03.

[48] See Phillips, Megan, Jefferson Bailey, Andrea Goethals, and Trevor Owens. “The NDSA Levels of Digital Preservation: An Explanation and Uses.” National Digital Stewardship Alliance, 2013. http://ndsa.org/documents/NDSA_Levels_Archiving_2013.pdf. See also http://ndsa.org/activities/levels-of-digital-preservation/.

[49] Davis, Susan. “Electronic Records Planning in ‘Collecting’ Repositories.” The American Archivist 71, no. 1 (April 1, 2008): 167–89. https://doi.org/10.17723/aarc.71.1.024q2020828t7332, pg 180.

[50] Richard Pearce-Moses, “Janus in Cyberspace: Archives on the Threshold of the Digital Era,” The American Archivist 70, no. 1 (January 1, 2007): 13–22, https://doi.org/10.17723/aarc.70.1.n7121165223j6t83.

[51] Helen Tibbo, “On the Occasion of SAA’s Diamond Jubilee: A Profession Coming of Age in the Digital Era (with an Introduction by Jane Kenamore),” The American Archivist 75, no. 1 (April 1, 2012): 16–34, https://doi.org/10.17723/aarc.75.1.a054u0t82478x41v.

[52] For example, reaching out to offices of origin to discuss the items listed in the InterPares 2 Project’s “Creator Guidelines” http://www.interpares.org/public_documents/ip2(pub)creator_guidelines_booklet.pdf.

[53] For more on formalizing trust between collaborative partners see F. Berman, A. Kozbial, R. H. McDonald, and B. Schottlaender, “The Need for Formalized Trust in Digital Repository Collaborative Infrastructure,” Proceedings of the NSF/JISC Repository Workshop (2007). https://libraries.ucsd.edu/chronopolis/_files/publications/berman_schottlaender.pdf.

[54] NDSA, pg 2.

[55] NDSA, pg 3-4.

[56] NDSA, pg 1, 2.

[57] “Levels” in the NDSA model are equivalent to “stages” in the other models.

[58] Each level also includes a label providing a rough characterization of the stage’s goal. For example, the first stage is labeled “Protect your data” and includes activities such as ensuring two copies are not collocated, fixity information is gathered or created, inventories are created, and restricting who has access to the copies. The fourth stage is labeled “Repair your data” and includes activities such as replacing/repairing corrupted data and performing format migrations or providing emulated environments.

[59] NDSA, pg 2.

[60] https://www.avpreserve.com/products/fixity/

[61] Phillips, Bailey, Goethals, and Owens, pg 5.

[62] For more on format endangerment see Library of Congress, “Sustainability of Digital Formats: Planning for Library of Congress Collections,” webpage, March 10, 2017, http://www.loc.gov/preservation/digital/formats/index.html and Heather Ryan, “Occam’s Razor and File Format Endangerment Factors,” Proceedings of the 11th International Conference on Digital Preservation (iPres), October 6-10, 2014: Melbourne, Australia. https://ipres-conference.org/ipres14/sites/default/files/upload/iPres-Proceedings-final.pdf.

[63] Shira Peltzman, “Expanding NDSA Levels of Preservation,” The Signal, April 12, 2016, https://blogs.loc.gov/thesignal/2016/04/expanding-ndsa-levels-of-preservation/.

[64] “Levels of Born-Digital Access,” Digital Libraries Federation, February 5, 2020. https://doi.org/10.17605/OSF.IO/R5F78.

[65] Phillips, Bailey, Goethals, and Owens, pgs 5-6.

[66] Phillips, Bailey, Goethals, and Owens, pg 5.

[67] DPC RAM, pg 2.

[68] Brown, A (2013). Practical Digital Preservation: a how-to guide for organizations of any size, Facet Publishing: London.

[69] DPC RAM, pg 3.

[70] DPC RAM, pg 4.

[71] Center for Research Libraries. “Ten Principles,” n.d. https://www.crl.edu/archiving-preservation/digital-archives/metrics-assessing-and-certifying/core-re.

[72] Joseph A. Williams and Elizabeth M. Berilla. “Minutes, Migration, and Migraines: Establishing a Digital Archives at a Small Institution.” The American Archivist, Spring/Summer 2015, Vol. 78, No. 1, p. 88. https://doi.org/10.17723/0360-9081.78.1.84.

[73] Prom, Christopher. “Making Digital Preservation Practical: A Personal Odyssey.” Provenance, Journal of the Society of Georgia Archivists 29, no. 1 (2011). http://digitalcommons.kennesaw.edu/provenance/vol29/iss1/2/.

[74] Prom, 13.

[75] “Jump In Initiative.” Society of American Archivists. https://www2.archivists.org/groups/manuscript-repositories-section/jump-in-initiative.

[76] “Jump In Initiative 2013 Results.” Society of American Archivists. https://www2.archivists.org/groups/manuscript-repositories-section/jump-in-initiative-2013-results.

About the authors

Seth Shaw is the Digital Library Software Engineer for the Arizona State University Library and an Islandora Core Committer. He previously served as a Developer for Special Collections and Archives for the University of Nevada, Las Vegas, an Assistant Professor of Archival Studies at Clayton State University, and the Electronic Records Archivist for the Duke University Archives. He earned his Master of Science in Information, Archives and Records Management from the University of Michigan, School of Information, and his Bachelor of Science in Information Systems at Brigham Young University – Idaho.