System Architecture and Human Interface Specification for the Archival Research Workspace

Full report

On this page

The structural evolution of the Al.Qaeda.net Archival Reconstruction from a rudimentary system of bookmarks and temporal research trails into a comprehensive, robust organizational ecosystem demands a rigorous architectural framework. Operating within a nostalgic browser workstation, this environment must support prolonged, complex investigative workflows without compromising the absolute immutability of the underlying archival repository. The objective is to engineer a localized, highly performant research workspace that allows users to seamlessly aggregate, annotate, and synthesize data points extracted from the primary archive, facilitating month-long research projects while avoiding the visual and operational bloat of contemporary project-management software. This architectural blueprint establishes the parameters for a system governed strictly by the Open Archival Information System (OAIS) reference model (ISO 14721:2012)1. In accordance with OAIS principles, the canonical archive operates as a locked entity, preserving the original provenance, context, and structural integrity of the historical records. The user's organizational activities constitute a separate, parallel layer, manipulating localized references rather than canonical data. Furthermore, the visual and interactive paradigms are deliberately constrained to the Human Interface Guidelines (HIG) of the mid-1990s, specifically those defining the early Windows Explorer environment. This visual rule mandates the use of hierarchical trees, standard list controls, property sheets, and context menus, categorically rejecting modern software-as-a-service (SaaS) aesthetics such as Kanban boards, colorful visual cards, and cloud-synchronized workspaces3.

Historical Precedents and System Benchmarking

To conceptualize an organizational overlay that remains performant and legible under the weight of extensive research, historical software precedents offer critical architectural blueprints. The design philosophy of the 1990s prioritized document-centric workflows, logical file hierarchies, and high information density. This contrasts sharply with contemporary paradigms that rely on spaced-out visual components that quickly become unwieldy when managing thousands of archival records. The analysis evaluates six historical and domain-specific software products to extract functional paradigms suitable for an offline, local-first archival workspace.

The synthesis of these historical precedents dictates an architectural model where the user interacts exclusively with standard folders, familiar icons, and tree views. The underlying complexity of metadata mapping, cryptographic hashing, and provenance protection is entirely abstracted, hidden behind familiar operating system interactions such as right-clicking to access property sheets or executing a drag-and-drop maneuver3.

Taxonomy and Organizational Vocabulary

A paramount challenge in engineering a knowledge-organization system is the prevention of conceptual bloat. When users are presented with overlapping organizational paradigms—such as Collections, Cases, Folders, and Citation Sets—the cognitive load increases exponentially, leading to decision paralysis and degraded information retrieval. The architecture must distill these concepts into a mutually exclusive, collectively exhaustive vocabulary that integrates seamlessly within the rigid aesthetics of early-Windows interfaces. The Electronic Discovery Reference Model (EDRM) provides a foundational workflow structure, segmenting the investigative process into stages such as Identification, Preservation, Collection, Review, and Analysis10. Applying the EDRM framework to the user's workspace necessitates an information hierarchy that scales from a broad investigative mandate down to granular document triage. The system evaluates the requested organizational concepts, determining which must exist as structural elements and which represent unnecessary systemic overlap.

The resulting vocabulary ensures a linear, logical user experience. An investigator initiates a project by establishing a named "Research Case." The necessity of multiple named projects is critical; it allows a researcher to maintain disparate investigations (e.g., one focusing on financial logistics, another on communications infrastructure) without intermingling customized tags or reading states, thus preserving the analytical integrity of each inquiry. Within that case, the user curates "Collections" and standard "Folders" for manual organization, deploys "Smart Folders" for automated metadata aggregation, and relies on "Favorites" for immediate global access to pivotal documents.

Information Hierarchy and Local Data Storage

The integration of a mutable workspace over an immutable archive necessitates a physical and logical separation of data. The OAIS reference model explicitly distinguishes between the Archival Information Package (AIP)—the canonical, preserved data—and the Dissemination Information Package (DIP), which is the version delivered to the consumer2. In this architecture, the user's localized workspace operates strictly on the principles of the DIP, manipulating localized references rather than the canonical records themselves. To enforce this absolute separation, all user-created organization, metadata, and structural hierarchies are serialized and stored in a localized, user-controlled directory structure on the local disk. This structure operates entirely independently of the read-only virtual file system (VFS) that hosts the historical archive. The local information hierarchy mirrors standard operating system file structures:

• C:\\Local Workspace\\ (The application's local state directory)
• Favorites\\ (Contains global .ref shortcut files)
• Cases\\
• \[Case Name\]\\
• desktop.ini (Stores serialized Case-level notes, creation dates, and cover summaries)
• Collections\\
• \[Collection Name\]\\
• desktop.ini (Collection-specific metadata)
• \[Folder Name\]\\
• 001293.ref (A binary pointer to an archive record)
• 004511.ref
• Smart Folders\\ (Contains serialized XML/JSON query rules mapped to the UI)
• Trails\\ (Temporal session histories stored as localized SQLite tables)

Within these local directories, the system generates custom extension files (designated here as .ref files) that act analogously to classic Windows Shell links (.lnk). A Shell link is a binary file containing location-independent paths and working directories, allowing it to serve as a universal identifier for a target object without physically copying the target5. The .ref file stores a persistent Uniform Resource Identifier (URI) pointing to the immutable VFS path of the canonical archival record, alongside a payload of subjective, user-generated local metadata. This strict local directory structure guarantees the privacy and security of the user's investigation. All organizational effort remains confined to the user's local disk, inherently included in standard operating system backups, and isolated from network transmission. The architecture absolutely forbids local imports or workspace synchronization from transmitting subjective research structures to a centralized server.

Provenance Protections and the Reference Model

Maintaining the absolute integrity of archival provenance is a paramount security and operational requirement. Dictated by archival description standards such as ISAD(G) (General International Standard Archival Description), the principle of provenance mandates that the original order, context, and structural integrity of the records must remain inviolate14. The subjective categorization applied by a contemporary researcher must never bleed into or alter the historical reality of the archive. When a user executes a command to add an archival record to a local Collection, the system must not alter the canonical metadata, database entries, or file attributes of that record to reflect the new association. Instead, the system relies exclusively on the local reference model. Generating a .ref file in the local workspace establishes a one-way pointer. Because these are merely lightweight pointers, the system inherently and seamlessly supports duplicate references. A user can drag the exact same archival record into five different Folders across three different Research Cases. The system simply generates five separate .ref files in the respective local directories. The canonical archive remains entirely unpolluted and unaware of these subjective organizational associations. This one-way pointer architecture dictates how collection statistics are calculated to ensure they do not imply source facts. When a user right-clicks a Collection folder and selects "Properties," the system must generate summary statistics—such as the total number of referenced documents, the distribution of file types, or the chronological span of the materials. To accomplish this, the local system iterates through all .ref files contained within the target folder, reads their URIs, performs rapid queries against the read-only VFS to retrieve the canonical metadata for those specific URIs, and calculates the statistics on the fly. The resulting property sheet explicitly titles this data "Local Collection Statistics," providing a visual and semantic safeguard that reinforces the distinction between the user's subjective aggregation and the archive's objective reality. Despite the one-way nature of the reference files, complex investigations require bi-directional context. To provide this without violating provenance, the architecture implements a localized backlink mechanism. When a user opens an immutable archival record in the "Record Inspector" application, the system spawns a background thread that performs a rapid local directory traversal of the C:\\Local Workspace\\ path. It reads the internal URIs of all .ref files, identifying any that match the currently viewed record. The Record Inspector then populates a local "Referenced By" tab, displaying all personal Collections, Cases, and Folders that contain a shortcut to the record. This allows the user to see exactly where they have previously triaged the document within their private session, without the canonical archive ever storing a relational backlink.

Local Metadata Fields and User Annotation

The OAIS model distinguishes between Preservation Description Information (which guarantees origin and integrity) and subjective annotations1. To enrich the investigative process without violating the provenance rule, the system stores all subjective metadata directly within the payload of the localized .ref shortcut files or within an adjacent localized SQLite indexing database designed to accelerate workspace searches. The application utilizes a constrained subset of the Dublin Core metadata element set (ISO 15836\) to map canonical data from the VFS to the "Details" view columns, ensuring standardized representation of fields such as Title, Creator, Date, Identifier, and Format18. The user's local metadata fields are appended to this structure as subjective, mutable properties. The authorized local metadata fields comprise:

1. Reading State: A discrete variable tracking the analytical status of a specific reference. The allowed values are strictly defined: Unread, Reading, Reviewed, Revisit, and Done. Visually, this is represented in the "Details" list view by a small, classic status icon (e.g., an empty circle for Unread, a half-filled circle for Reading, a green checkmark for Done) alongside a corresponding text string in a dedicated "Status" column.

2. Priority: A numerical or categorical flag (e.g., High, Medium, Low) indicating the urgency of review. This is visually represented by a classic star or flag icon column, toggleable via a single mouse click directly within the list view.

3. Custom Local Tags: A comma-separated string of user-defined keywords. These tags are stored locally within the .ref file and apply only to that specific instance of the reference within that specific Collection.

4. User Notes: A rich-text or plain-text field attached directly to the reference file, distinct from the overarching notes applied to the Collection folder itself.

Because this metadata is inextricably bound to the local .ref file rather than the canonical record, the architecture prevents investigative cross-contamination. A user can possess two references to the same canonical archive record in entirely different Collections. In "Case A," the reference can be tagged as "Financial Logistics" and marked as "Reviewed." In "Case B," the identical document can be tagged as "Communications" and marked as "Unread." The two states exist independently on the local disk, reflecting the compartmentalized nature of complex research.

Human Interface Guidelines and Visual Representation

The visual and interactive paradigms of the archival workspace strictly adhere to mid-1990s Human Interface Guidelines (HIG). This specific design era emphasized discoverability, deep hierarchical navigation, high information density, and standardized system controls3. The interface purposefully eschews modern SaaS trends—such as expansive white space, Kanban boards, and flat, borderless cards—in favor of a utilitarian, data-dense environment that respects the cognitive load of a professional investigator. The primary navigation interface relies on a classic split-pane layout mimicking the Windows 95 Explorer. The left pane features a collapsible tree view detailing the workspace hierarchy (Cases, Collections, Folders). The right pane displays the contents of the selected node in a "Details" view. This view is characterized by dense, sortable list columns with classic, 3D-beveled column headers. Toolbars utilize small, 16x16 pixel unambiguous icons accompanied by explicit text labels, avoiding the ambiguity of minimalist modern iconography. Managing Collection cover information, high-level summaries, and attached structural notes requires a mechanism that avoids modern visual "cards." In classic Windows architecture, a folder's appearance, customized tooltip, and behavioral properties are governed by a hidden desktop.ini file using variables within the \[.ShellClassInfo\] section, such as InfoTip and IconResource6. The archival workspace implements a highly secure, localized equivalent of this mechanism. When a user attaches notes or a descriptive summary to a Collection, this data is serialized into the hidden initialization file within that Collection's directory. Instead of deploying a bulky visual card that breaks the list-view density, the user accesses this summary information through two classic operating system paradigms:

1. InfoTips: Hovering the cursor over a Collection folder in the tree view or list view triggers a standard system tooltip (InfoTip) that temporarily displays the summary text and attached notes in a small overlay box, exactly as defined by the desktop.ini specification6.

2. Property Sheets: Right-clicking the folder and selecting "Properties" from the context menu opens a classic, tabbed dialog box. The "General" tab displays the calculated collection statistics, while a "Notes" tab contains a standard multi-line text box allowing for extensive markdown or plain-text summaries9.

This methodology preserves the high-density list view necessary for bulk analysis while providing immediate, standardized access to subjective user notes. Crucially, the parsing engine for the desktop.ini equivalent is heavily sanitized. Historically, Windows Explorer's blind trust in presentation-related metadata within desktop.ini files led to severe arbitrary code execution vulnerabilities, such as those exploited by the OceanLotus threat group24. The reconstructed environment mitigates this by restricting the parser strictly to designated, plaintext metadata fields, neutralizing any risk of execution payloads.

Workflow Diagrams in Prose: Orchestrating the Investigation

The integration of the archival workspace across existing applications—such as the Archive Explorer, Cognitive Atlas, Browser, and Citation Desk—relies heavily on standardized, system-level inter-process communication metaphors. The most critical of these is the implementation of Object Linking and Embedding (OLE) drag-and-drop mechanics26. Consider the workflow of an investigator locating crucial documents and organizing them into a new Research Case. The user executes a complex query within the Archive Explorer, yielding 150 relevant records. Utilizing standard Win32 list-view behaviors, the user clicks the first record, holds the Shift key, and clicks the last record, executing a bulk multi-select3. The user clicks and holds the left mouse button on the highlighted block, initiating a drag operation. The source application (Archive Explorer) implements the IDropSource and IDataObject COM interfaces, packaging the canonical URIs of the 150 selected records into the data payload26. As the cursor drags the payload across the screen toward the Research Workspace window (which has implemented the IDropTarget interface and registered its window handle via the RegisterDragDrop API28), the system provides visual pointer feedback. Because this is a reference-creation action, the cursor appends a small shortcut arrow overlay5. When the user releases the mouse button over a specific Collection folder in the workspace tree, the IDropTarget::Drop method executes30. The application rapidly generates 150 discrete .ref shortcut files within the local directory corresponding to that Collection, inherently supporting bulk operations. For users who prefer keyboard navigation or contextual menus over drag-and-drop, the system provides deep "Send To" integration. Highlighting records in the Archive Explorer, the Cognitive Atlas, or the Citation Desk and executing a right-click invokes a standard context menu. The exact menu command structure is defined as follows:

• Open
• Open in New Window
• \--- (Separator)
• Add to Favorites
• Send To \>
• \[Recent Collection 1\]
• \[Recent Collection 2\]
• \---
• Choose Collection...
• New Research Case...
• \---
• Properties

Selecting Choose Collection... invokes a modal dialog box featuring a simplified, collapsible tree view of the user's workspace, allowing precise placement of the references. Selecting New Research Case... invokes a classic wizard dialog, guiding the user through naming the case and establishing an initial folder structure before depositing the selected records. Once the references populate the Details view of a Collection, the user leverages standard list-control interactions for sorting and grouping3. Clicking any column header (e.g., "Date," "Author," "Status") instantly sorts the view based on that metadata field, whether it is mapped from the canonical archive or stored locally in the .ref file. Right-clicking the column header area provides an "Arrange By" cascading menu, allowing the user to group records by custom local tags or reading states, visually segmenting the list view into distinct, collapsible categories without altering the underlying folder structure.

Smart Folders and Rule-Based Organization

To manage extensive, months-long research projects, manual sorting is insufficient. The architecture augments manual curation with Smart Folders. A Smart Folder is visually represented in the tree view as a standard folder icon bearing a distinct overlay, such as a small magnifying glass or a gear. Functionally, it does not act as a storage container for .ref files; instead, it stores a serialized, continuous query definition. A user configures a Smart Folder through a classic query-builder dialog, utilizing AND/OR logical operators and standard drop-down menus. Crucially, the Smart Folder engine is capable of interrogating both the canonical archive metadata (by dynamically querying the VFS) and the subjective local user metadata stored within the workspace directory. Appropriate Smart-Folder rules include complex, cross-domain interrogations:

• \[Archive: Date Created\] \[is between\] \[1998-01-01\] AND \[2001-12-31\]
• \[Local: Reading State\] \[equals\] \[Unread\]
• \[Archive: Author\] \[contains\] \[Bin Laden\]
• \[Local: Custom Tag\] \[includes\] \[Financial\]
• \[Archive: Format\] \[equals\] \[application/pdf\]

The reevaluation of Smart Folders requires a delicate balance between data accuracy and system performance. Continuous, real-time reevaluation of dozens of complex queries against a massive archival database introduces unacceptable latency, violating the responsive, snappy behavior characteristic of classic Win32 applications. Therefore, the architecture dictates a hybrid, lazy-evaluation caching model. The contents of a Smart Folder are evaluated and cached in memory only when the folder is explicitly opened or selected in the navigation tree. Automatic background reevaluation is triggered strictly under two conditions: when a user actively modifies local metadata (e.g., changing a reading state from "Unread" to "Reviewed," immediately dropping the record from an "Unread Items" Smart Folder), or upon the initialization of the application session following a background update to the underlying archive database. To complement rule-based folders, the interface provides a dedicated workspace search field in the main toolbar. Unlike the global Archive Explorer search, which queries millions of canonical records, the workspace search restricts its scope entirely to the C:\\Local Workspace\\ directory structure. It rapidly queries the names of Collections, the local tags, user notes, and the cached canonical metadata associated with the local .ref files. Results are presented in a temporary list view, allowing investigators to instantly locate previously triaged materials without executing expensive global searches.

Export, Import, and Research Portability

Investigations frequently require collaboration, peer review, or archival preservation of the investigative process itself. The ability to export a Collection or a complete Research Case as a portable package is critical. However, exporting user organization must strictly avoid duplicating the massive canonical archival records. Embedding high-resolution video files, forensic images, or raw database dumps into a user's export package would violate local storage constraints and create prohibitively large, unmanageable files. To solve this, the architecture adopts the BagIt File Packaging Format (RFC 8493), a standard specification widely utilized in the digital preservation and archival communities for the reliable transfer of arbitrary digital content31. When a user right-clicks a Research Case and selects "Export as Research Package," the system generates a BagIt-compliant directory structure, subsequently wrapping it in a standard ZIP archive for portability. The internal structure of the exported package relies heavily on the BagIt fetch.txt mechanism. This mechanism allows a package to maintain verifiable references to external files without actually containing the payload, perfectly aligning with the local reference model33. The exported BagIt package structure is strictly defined:

• bagit.txt: A required tag file that declares the package as a valid BagIt format and specifies the character encoding32.
• bag-info.txt: Contains Research Case metadata, including the Case Title, Creator, Export Date, and high-level notes33.
• manifest-sha256.txt: Provides cryptographic hashes for all local files (e.g., the .ref files and SQLite databases) to ensure the integrity of the user's organizational structure during transfer32.
• data/: The payload directory. In this architecture, it contains the localized workspace directory structure, all .ref shortcut files, the serialized desktop.ini equivalents, and the user's localized metadata databases32.
• fetch.txt: This file is dynamically generated during the export process. It acts as a manifest, listing the canonical URIs of every archival record referenced in the Research Case, alongside placeholder local paths33.

Upon importing a Research Package on a secondary workstation, the local system unpacks the BagIt structure. It reads the manifest-sha256.txt to verify the integrity of the organizational files, then parses the fetch.txt file. The system cross-references the URIs listed in the fetch.txt against the secondary user's local, immutable VFS archive. If the referenced records exist in the local archive, the import succeeds seamlessly; the local .ref files are populated into the workspace tree and re-linked to the local VFS. If specific records are missing, the system generates a standard warning dialog, informing the user that the imported Research Case references archival records not present in their local dataset. At no point does the import or export process connect to a remote server; the entire verification and reconciliation process occurs offline against the local VFS. This provides highly portable, incredibly lightweight research packages that respect both user privacy and canonical archive boundaries.

Accessibility and Edge Cases

Designing within the rigorous constraints of mid-1990s HIG inherently addresses multiple modern accessibility challenges. The interface entirely avoids low-contrast text, hidden hover-states, and non-standard interactive elements. Accessibility is guaranteed by ensuring all interface elements map strictly to standard operating system controls. This allows native screen readers and assistive technologies to parse the logical tree structures and list views accurately and predictably36. Furthermore, all workflows are executable entirely via the keyboard. Standard Win32 access keys (e.g., Alt+F for the File menu, Ctrl+C/Ctrl+V for copy/pasting references, and standard Tab navigation through property sheets) are strictly enforced4. The architecture must gracefully handle several anticipated edge cases:

1. Dangling References: If the underlying immutable archive is subjected to a rare structural update, or if an import package relies on a different archive version, the URIs within the .ref files may become invalid. The system must not crash when attempting to resolve a broken link. Instead, it must gracefully handle the failure by displaying a visual indicator in the list view (e.g., a standard red 'X' overlay on the icon or a faded text state). Double-clicking a dangling reference invokes a dialog prompting the user to resolve the link manually, functionally identical to the classic Windows shortcut resolution behavior5.

2. Circular Folder Dependencies: Dragging a Collection folder into one of its own subfolders creates an infinite recursion loop within the directory structure. The OLE drop target must validate the drop destination during the DragOver event, changing the pointer feedback to a "not allowed" symbol and canceling the operation if a circular dependency is detected27.

3. Massive Bulk Operations: Dragging 50,000 search results from the Archive Explorer into a Collection simultaneously may freeze the main application thread if executed synchronously. The architecture must offload the generation of the .ref files to a background worker thread. To prevent the application from appearing unresponsive, the system must immediately present a classic Windows progress dialog—incorporating a dynamic progress bar, an estimated time remaining, and a functional "Cancel" button—until the bulk operation completes38.

Implementation Priorities and Acceptance Criteria

To ensure a structured, risk-mitigated implementation phase, features are prioritized based on their direct impact on core investigative capabilities and architectural stability.

The following strict acceptance criteria govern the successful deployment of the Archival Research Workspace:

1. Provenance Integrity Criterion: The creation, modification, movement, or deletion of any Research Case, Collection, or individual reference file must result in absolutely zero byte-level modifications to the canonical archival database, metadata index, or VFS.

2. Privacy and Offline Criterion: All local metadata, notes, and organizational structures must be stored exclusively on the user's local disk. Disabling all network adapters must not impede the investigator's ability to organize, annotate, or search the local workspace, nor can exports trigger external transmission.

3. Aesthetic Adherence Criterion: The interface must rely exclusively on classic UI metaphors (TreeViews, ListViews with sortable column headers, Tabbed Dialogs, toolbars with explicit text labels). The presence of Kanban boards, endless scrolling, minimalist flat-design cards, or non-standard visual pop-overs constitutes a systemic failure condition.

4. Performance Criterion: Navigating into a localized Collection containing 10,000 discrete .ref shortcuts must fully render the "Details" view—including the dynamic retrieval of canonical metadata—in under 500 milliseconds, demonstrating parity with the performance expectations of native Win32 localized file explorers.

5. Interoperability Criterion: An exported Research Case (packaged as a BagIt zip file) must be successfully imported by a secondary, completely offline workstation. The import process must correctly parse the fetch.txt manifest and resolve all references against the secondary workstation's identical VFS archive without creating duplicate canonical data.

This architectural specification provides a highly robust, performant, and historically grounded framework. It enables exhaustive, highly complex research operations while maintaining strict adherence to archival provenance, rigorous local privacy paradigms, and optimized human-computer interaction standards.

Works cited

1. RM-Open Archival Information System (Information Packages), https://nhqc3s.hq.nato.int/apps/DCRA\_Report/id-29d4122b072148f5aaf4882ecc5d963c/views/id-2f367aea01044e19aca9577ea4294714.html

2. OAIS Reference Model and the Dataverse Software, https://dataverse.org/book/oais-reference-model-and-dataverse-software

3. The Windows 95 User Interface \- dFPUG, https://www.dfpug.de/loseblattsammlung%5Cmigration%5Cwhitepapers/Win95UI.htm

4. The Windows Interface Guidelines for Software Design, https://guidebookgallery.org/books/thewindowsinterfaceguidelinesforsoftwaredesign

5. Shell Links \- Win32 apps \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/shell/links

6. How to Customize Folders with Desktop.ini \- Win32 apps, https://learn.microsoft.com/en-us/windows/win32/shell/how-to-customize-folders-with-desktop-ini

7. Export | Zotero Documentation, https://www.zotero.org/support/preferences/export

8. Bibliographic Data Formats | Zotero Documentation, https://www.zotero.org/support/dev/data\_formats

9. Property Sheets: UI Text Guidelines | Microsoft Learn, https://learn.microsoft.com/en-us/previous-versions/windows/desktop/bb246458(v=vs.85)

10. The EDRM Lifecycle Explained: A Practical Guide to Modern, https://tasconlegal.com/the-edrm-lifecycle-explained-a-practical-guide-to-modern-ediscovery/

11. What is the EDRM? Electronic Discovery Reference Model, https://www.digitalwarroom.com/blog/what-is-edrm-electronic-discovery-reference-model

12. Open Archival Information System \- Wikipedia, https://en.wikipedia.org/wiki/Open\_Archival\_Information\_System

13. What is the internal structure of a Windows shortcut? \- Stack Overflow, https://stackoverflow.com/questions/30629914/what-is-the-internal-structure-of-a-windows-shortcut

14. ISAD(G) explained: the UK standard for archival description, https://archivers.ai/blog/isad-g-explained-uk-archival-description-standard/

15. ISAD(G) \- Wikipedia, https://en.wikipedia.org/wiki/ISAD(G)

16. International Standard Archival Description (General) \[ISAD(G)\], https://www2.archivists.org/groups/standards-committee/international-standard-archival-description-general-isadg

17. Reference Model for an Open Archival Information System (OAIS), https://ccsds.org/Pubs/650x0b1s.pdf

18. Dublin Core Metadata Standards Explained \- Sourcely, https://www.sourcely.net/resources/dublin-core-metadata-standards-explained

19. Dublin Core \- Metadata Standards Catalog, https://rdamsc.bath.ac.uk/msc/m15

20. ISO 15836-1 Information and Documentation \- Part 1: Core Elements, https://www.asist.org/2022/08/14/iso-15836-1-information-and-documentation-the-dublin-core-metadata-element-set-part-1-core-elements/

21. Designing Windows 95's User Interface \- Socket 3, https://socket3.wordpress.com/2018/02/03/designing-windows-95s-user-interface/

22. What Are Desktop.ini Files, and How Do I Get Rid of Them? \- Ask Leo\!, https://askleo.com/what-are-desktop-ini-files-and-how-do-i-get-rid-of-them/

23. Self-created desktop.ini does not work \- Super User, https://superuser.com/questions/882442/self-created-desktop-ini-does-not-work

24. Microsoft just broke custom folder icons in Windows, and the reason, https://www.xda-developers.com/microsoft-just-broke-custom-folder-icons-in-windows-because-of-a-2003-bug/

25. Desktop.ini as a post-exploitation tool \- SANS ISC, https://isc.sans.edu/diary/25912

26. Drag and Drop Introduction \- Catch22.net, https://www.catch22.net/tuts/ole/drag-and-drop-introduction/

27. Drag and Drop \- Win32 apps \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/com/drag-and-drop

28. RegisterDragDrop \- Techs Helps, https://techshelps.github.io/MSDN/COM/devdoc/live/com/api3\_9eeo.htm

29. RegisterDragDrop function (ole2.h) \- Win32 apps \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/api/ole2/nf-ole2-registerdragdrop

30. IDropTarget (oleidl.h) \- Win32 apps \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/api/oleidl/nn-oleidl-idroptarget

31. The BagIt file package format | PDF \- Slideshare, https://www.slideshare.net/slideshow/dcc-bag-posterppt/11805746

32. RFC 8493 \- The BagIt File Packaging Format (V1.0) \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc8493

33. BagIt \- Wikipedia, https://en.wikipedia.org/wiki/BagIt

34. RFC 8493: The BagIt File Packaging Format (V1.0), https://www.rfc-editor.org/info/rfc8493/

35. How Veridian Uses BagIt in the Data Preservation Process, https://veridiansoftware.com/knowledge-base/how-we-use-bagit-as-part-of-our-data-preservation-process

36. Human interface guidelines, https://p.janouch.name/text/human-interface-guidelines.html

37. Windows: Interface Guidelines (1995) \[pdf\] \- Hacker News, https://news.ycombinator.com/item?id=22475521

38. User Interface Principles \- Win32 apps | Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/appuistart/-user-interface-principles