Core Concepts

Workflow Overview

DRS3 introduces a new framework for preservation activity. The fundamental elements of that framework are the Workspace and the Archive.

The Workspace acts as a staging area for the Archive. The primary goal of the DRS is preservation, but the advent of the Workspace increases the flexibility and usability of the system. Users can stage digital objects, reorganize files, edit or apply metadata, and preview an extensive array of file types in the browser-based UI. Once satisfied with a digital object, users will push that object to the Archive. Users can choose to remove the Workspace copy of the object or retain it in the Workspace, as suits their workflows. Content in the Workspace does not receive any versioning, meaning that all edits made in the Workspace are immediate and irreversible; you cannot undo edits.

In many cases, users may wish to stage digital objects locally before moving them to the DRS. In such cases, particularly for high-volume depositors, the Workspace to Archive push can be automated, eliminating the need to interact with the objects in the Workspace interface. This is achieved by application of particular metadata values (see Required Global Metadata Elements for more details).

Once in the Archive, the object metadata is viewable and the files are downloadable, but no edits can be made. If edits are needed, users may reinstate a copy of the object to the Workspace, update it as necessary, and resubmit the object to the Archive, thereby replacing the old version of the object with the new version.

Pushing objects to the Archive will also initiate delivery functionality for the object, if desired. When an object moves to the Archive, DRS tooling will examine the metadata, looking for specific elements that will indicate that delivery is desired (again, see Required Global Metadata Elements for details). If those indicators are present, a delivery file and a copy of the associated metadata will be sent on to the appropriate delivery service (see the Delivery Services Guide for details; see also delivery information for specific resource types).

IMPORTANT It is critical to note that in the DRS3 Initial Release (April 28, 2026) is a partial release only. This initial release will not have full Archive functionality implemented. This means that instead of pushing objects from the Workspace to the Archive, users will instead flag objects as ready for the Archive. This action will initiate delivery in the same way as pushing objects to the Archive will in later releases, but the object will remain in the Workspace. Once the Archive is fully implemented (in a later release), all objects in the Workspace which are flagged as ready for the Archive will be pushed to the Archive automatically. This has two meaningful consequences:

1. Edits that impact delivery will not take effect until:

   1. the object is again flagged as ready for the Archive, or

   2. the Archive is implemented and the object is automatically pushed to the Archive.

2. Because the Workspace has no versioning, edits made after the object has been flagged will persist in the Archive regardless of whether or not the object has been flagged again.

During this interim period before the Archive is implemented, deletions from the Workspace will be restricted. This is to avoid any accidental deletion of objects which have been flagged as ready for the Archive. If deletion is necessary, users are encouraged to create a “Trash” folder within their container(s), which can be cleaned up and removed after the Archive is in place. Once the Archive is implemented, users will be more freely able to delete from the Workspace, enhancing its usefulness as a pre-deposit staging area.

Object Structure

Within the DRS system, the primary unit of preservation management is an Object, a content item which consists of one or more digital Files and which is documented with administrative, technical, and descriptive metadata.¹ The DRS data model for digital Objects makes use of two entity types: Object and File. An Object is represented by a top-level folder, within which are the preservation content Files and any (optional) accompanying Files. Within the Object, Files can be organized into subfolders if desired by the depositor, but internal structure will have no impact on preservation outcomes and is for depositor convenience only. The capitalization of the terms “Object” and “File” aligns with the terminology used to define the structure of digital content in the LIBSAFE Advanced platform.

Each Object must contain a minimum of one primary data File. Primary data Files are the digital content being preserved. Objects may include a single primary data File (such as a still image File) or a group of primary data Files (such as a group of still image Files which make up a Page-turned Object). Objects may also include additional Files that accompany the primary data File(s) (such as the Optical Character Recognition, or OCR, text file for a page of a book) or Sidecar Metadata Files, which include metadata that is not otherwise captured in the DRS metadata schema. The metadata within Sidecar Files is not processed by the DRS, meaning that it is not indexed or available for fielded searching, but the content of Sidecar Files is included in free text searching.

The complexity of each Object and the degree to which it is described are subject to curatorial discretion and depositor implementation. Object structure may be as simple as an Object folder containing a single File or as complex as an Object folder containing nested subfolders and Files.

File pathnames should not exceed 300 characters. The pathname is the file name plus the full location of the file within its hierarchical folder structure (such as “/MyObj/SubfolderA/SubfolderB/MyFile.pdf”). For this reason, depositors are advised to limit their use of hierarchical folder structure within Objects.

Depositors are encouraged to use the following ASCII characters in file names, if possible (although the system can accept any character from the full Unicode character set):

• Upper case Latin alphabetical characters (U+0041 – U+005A)

• Lower case Latin alphabetical characters (U+0061 – U+007A)

• Numerals zero through nine (U+0030 – U+0039)

• Hyphens “-” (U+002D) and underscores “_” (U+005F)

Use of the period “.” (U+002E) should be restricted to marking the boundary between the file name and the file extension (such as in “MyPhoto.jpg”) or marking component parts of the file extension (such as in “MyContainer.tar.gz”).

Resource Types

The DRS3 can provide bit-level preservation for Files of any format. However, to optimize preservation outcomes and to facilitate delivery, depositors should categorize Objects by their technical form, or Resource Type. Resource Type classification is concerned with what a digital Object is (its form), not what it is about (its subject).² This manner of classification is necessary because it provides the means to identify groups of like Objects for various purposes, such as:

• Mode of expression - the form of the Object, such as audio or still image, which informs risk analysis and remediation by DPS

• Mode of retrieval - the means of delivering the Object for reuse via HL delivery services

• Intellectual nature - the purpose of the Object, which enables summary categorization and reporting

Resource Type is quintessential to a digital Object and in turn defines the rest of the mandatory and recommended metadata elements for an Object and its File(s). The possible types are:

An Object submitted without a Resource Type explicitly specified will automatically be assigned the value “Unspecified.” Although use of the Unspecified type does not disqualify an Object for preservation in the DRS system, and although it will receive, at minimum, the same bit-level preservation as any other Object, it is highly recommended that depositors assign Resource Type with intention. As noted in the DRS Policy Guide, preservation outcomes depend directly on the nature of the preserved Object, including not only the format(s) of the File(s) in the Object but also the purpose of the Object. Selection of an appropriate Resource Type and alignment with type-specific structure and metadata guidance will maximize opportunities for the highest level of preservation assurance.³

Required & Recommended Global Metadata Elements

Efficient and effective preservation management, analysis, and remediation rely upon metadata to document preserved digital content. Two distinct forms of metadata are supported by the DRS:

1. Indexed metadata. Defined metadata elements are indexed for fielded search in DRS3.¹
   Indexed metadata is classified into two categories:

   1. O-metadata. Object- and File-level metadata supplied by depositors or generated by the DRS system (including administrative, descriptive, structural, rights, and technical metadata). The full set of O-metadata elements is defined and described in the DRS3 Data Dictionary.

   2. E-metadata. File-level technical metadata automatically generated by the DRS system through examination of data embedded in the Files themselves.

2. Sidecar metadata. Any additional metadata beyond the indexed elements can be included as component Files of an Object. The metadata within these files is not further processed by the DRS, which means it is not indexed and is not searchable on a fielded basis. However, the content of these files is included in free-text search results.

Although metadata requirements and recommendations are largely influenced by the Resource Type of an Object, some elements are mandatory for all Objects or Files. The number of mandatory, depositor-supplied metadata elements is intentionally limited (to facilitate ease of deposit), while the majority of elements are recommended or optional.

PLEASE NOTE Required metadata elements have default values that will be automatically applied unless explicitly supplied by the depositor (defaults noted below).

For Resource Type-specific guidance, see Guidelines by Resource Type.

Jump to: