Archival Reconstruction: Specification for a Scholar-Grade Local Annotation System

Full report

On this page

The transformation of the Al.Qaeda.net Archival Reconstruction workstation from a basic reading environment into a rigorous, scholar-grade analytical tool requires an architecture that carefully bridges the immutable permanence of historical records with the fluid, interpretative nature of personal research. The workstation currently hosts stable Archive Virtual File System (VFS) records, cryptographically verified canonical PDFs, and preserved Markdown documents. These sources must remain structurally uncorrupted and mathematically pristine. Conversely, researchers require the ability to aggressively interrogate these texts—highlighting passages, extracting clippings, scribbling margin notes, establishing cross-references, and generating complex thematic taxonomies. This tension between the read-only archive and the read-write researcher demands a standoff annotation architecture. Furthermore, strict privacy constraints mandate that all derivative user data remain entirely isolated within the local browser environment, requiring resilient local storage mechanisms and highly portable export formats. Public-facing terminology must mask this technical complexity; users should interact with familiar commands like "Highlight," "Add Note," and "Backup Notes." Finally, the user experience must remain strictly confined to the recovered late-1990s and early-2000s visual paradigm, utilizing classic menu structures, property sheets, and list panes rather than contemporary floating toolbars or translucent overlays. This comprehensive research specification defines the conceptual models, storage paradigms, nostalgic user interface conventions, and accessibility frameworks necessary to deploy a robust local annotation system that honors both archival integrity and historical software design.

Benchmark Study: Historical Precedents in Annotation

To construct a system that feels authentic to early computing while delivering modern scholarly power, the architecture must draw heavily on historical precedents that pioneered hypertext, personal information management, and document annotation. Analyzing these systems provides deep second-order insights into how researchers naturally structure unstructured data, guiding the design of the new workstation capabilities.

Xerox PARC NoteCards (1984)

Developed by Frank G. Halasz and his team at Xerox PARC, NoteCards was an early hypermedia system designed specifically to help intellectual laborers transform chaotic collections of thoughts into orderly, structural interpretations1. The system introduced the concept of "Fileboxes" for hierarchical nesting and, crucially, "typed links" to explicitly label the semantic relationship between a source card and a destination card1. The insight derived from NoteCards is that annotations are not merely marginalia attached to a page; they are independent nodes within a larger semantic network. The proposed archival workstation will adopt typed links to facilitate cross-source references and note-to-note linking, allowing researchers to build visual knowledge graphs out of isolated clippings.

Lotus Agenda (1988)

Designed by Mitch Kapor, Lotus Agenda operated as a free-form personal information manager built around three core primitives: items, categories, and views4. Agenda's foundational philosophy was "write first, declare meaning later"4. It allowed users to dump text fragments, tasks, and raw notes into the system and dynamically route them into overlapping categories using keyword extraction and query-driven views4. This architecture demonstrates that a rigid, mutually exclusive folder structure is vastly inferior to query-driven views for active qualitative research. The proposed Notebook application will heavily emulate Agenda’s view-driven approach, allowing users to filter clippings and notes by source, date, and user-defined tags simultaneously without duplicating the underlying data4.

Folio Views

Folio Views, widely used in the 1990s for distributing large textbases like legal archives and encyclopedias, introduced the concept of "shadow files" (using the .sdw extension)7. This mechanism allowed users to overlay custom notes, highlighters, bookmarks, and jump links onto a read-only, published Infobase (.nfo) without modifying the original binary file8. Shadow files provided a personalized layer of rights management and commentary that remained perfectly decoupled from the source8. This is the exact conceptual precedent required for the Archival Reconstruction workstation: the canonical PDFs and Markdown documents act as the read-only Infobase, while the browser's local IndexedDB acts as the user's private shadow file.

EndNote (1989)

Since its introduction as a "Reference Database and Bibliography Maker," EndNote has defined reference management by treating citations as highly structured database records rather than mere text strings10. By enforcing strict fields (author, title, year) and facilitating the extraction of metadata from external databases or PDFs, EndNote drastically reduces the cognitive load of citation tracking for complex writing projects10. The critical takeaway for the archival workstation is that every annotation, highlight, or clipping created must automatically capture its provenance—specifically the source URI, document title, and pagination—to ensure that derivative notes never lose their evidentiary context when viewed outside the document reader.

Adobe Acrobat 5.0 (2001)

Acrobat 5.0 formalized the separation of PDF content from user annotations through the introduction of the Forms Data Format (FDF)12. This architectural split allowed user comments, highlights, and markup vectors to be exported, shared, and imported entirely independently of the heavy, canonical PDF binary12. The specification for the archival workstation will adopt a similar decoupled export model, packaging the user's annotations in a lightweight, machine-readable JSON format that acts precisely like an FDF file, capable of being re-applied to the canonical documents upon import.

Microsoft Reader (LIT format)

Microsoft Reader introduced early digital highlighting and bookmarking for the proprietary LIT ebook format on PDA devices and Windows environments13. While the format itself was closed and proprietary, the user interface popularized a highly intuitive interaction pattern: selecting text with a cursor to immediately summon a context menu for highlighting or adding a side note13. The archival workstation will replicate this instantaneous, selection-based workflow, ensuring that the friction between reading and annotating remains as low as it was in early digital reader applications.

Conceptual Annotation Object Model and Source Integrity

To satisfy the absolute requirement that user notes must never alter canonical source text, the system must utilize "standoff markup" rather than "inline markup"15. Inline markup, such as embedding HTML \<span\> tags directly into the source document's text flow, corrupts cryptographic hashes, alters file sizes, and violates fundamental archival integrity. Standoff markup, by contrast, stores assertions completely outside the document, allowing multiple overlapping claims, diverse opinions, and non-destructive visual overlays to coexist17. The architecture will implement a profile of the W3C Web Annotation Data Model, a JSON-LD standard that provides a highly interoperable vocabulary for defining relationships between a personal note and a canonical archive record19. By adhering to the W3C model, the system aligns with modern ANSI/NISO Z39.105-2023 standards for scholarly publishing while operating under the hood of a retro user interface22.

The W3C Data Model Primitives

The conceptual model dictates that every interaction—whether a highlight, a clipping, or a TODO—is represented as an Annotation object consisting of specific nodes23.

Mapping the Annotation Typology

The system must support a vast array of research paradigms. The object model elegantly handles these variations by modulating the Target, Body, and Motivation properties. A Text Highlight is the simplest object; it possesses a Target defining the text bounds but omits the Body node entirely, driven by the highlighting motivation23. A Margin Note or Quotation builds upon the highlight by appending a TextualBody containing the user's typed commentary and setting the motivation to commenting. Page Notes and Document Notes are annotations where the Target points to a page-level URI or a document-level URI, but completely omits the spatial or text-based selector23. This indicates the note applies to the resource as a whole. Conversely, Free-Standing Notes are records generated directly in the Research Notebook; they possess a Body but entirely omit the Target node, as they are not attached to any canonical source23. Specialized qualitative codes such as Paraphrase Notes, Questions, TODOs, and Source Flags are differentiated via the Motivation field combined with user-defined labels. The system supports Colored or Symbolic Note Categories by injecting a Tag body into the annotation, mapping specific text strings (e.g., "Critical", "To Read") to specific icon indices in the nostalgic Win32 tree view. The distinction between Private Comments versus Source Quotations is strictly enforced by the object model. The exact string extracted from the archive is perpetually locked inside the Target's selector context, while the user's private interpretation resides exclusively in the Body19. This structural separation guarantees that users never accidentally misattribute their own thoughts as historical archival text during export.

Anchoring Strategy Comparison and Resolution

The most computationally critical challenge in standoff annotation is "the anchor problem"—ensuring that an annotation remains attached to the correct sentence or image region even if the underlying document's rendering, font size, viewport, or structural layout changes21.

Evaluation of Anchor Types

The Hybrid Anchoring Solution

To guarantee stable anchors across both text and image paradigms, the workstation will utilize a layered selector chain. For text-based Markdown documents and derived journal records, the Target will contain a TextQuoteSelector capturing up to 32 characters of prefix, the exact selected text, and 32 characters of suffix26. When the user opens a document, the application's layout engine will attempt to locate the exact string match. If the document rendering has altered whitespace or line breaks, the system falls back to a fuzzy-matching algorithm (such as Myers diff or Levenshtein distance) weighted by the prefix and suffix overlap21. If the text appears multiple times in the document (the "duplicate quote" edge case, such as highlighting the single word "Report"), the prefix and suffix act as mathematically unique disambiguation keys to lock the anchor to the correct instance28. For image-based records, such as scanned book pages in the Book Reader, Page-level anchors versus exact text-range anchors presents a specific UX challenge. The system will utilize the IIIF Presentation API 3.027. When a user highlights text on a scanned page, the system pairs the TextQuoteSelector (targeting the invisible, extracted OCR text layer) with an SvgSelector mapping the spatial bounding box31. This allows the workstation to draw a classic red bounding box over the image while simultaneously populating the user's Notebook with the actual searchable text of the quote.

Local-Only Storage Architecture and Privacy Rules

Strict privacy and ownership rules dictate that all user work must remain on the user's local hardware. The application must operate entirely client-side without transmitting personal notes, search queries, or workspace states to a central server. This local-first architecture eliminates centralized privacy risks and protects the researcher's intellectual property35.

IndexedDB as the Local Engine

The system will rely on IndexedDB, the browser's native asynchronous, transactional NoSQL database, to store the JSON-LD annotation objects37. IndexedDB is explicitly designed for significant amounts of structured data and supports multiple secondary indexes36. This allows the workstation to instantly query and retrieve notes by source, date, tag, or motivation without scanning the entire dataset. While the Origin Private File System (OPFS) offers superior synchronous read/write speeds for massive binary files (like local SQLite databases), IndexedDB provides a more native, cross-browser-compatible API for managing individual JSON document stores38. IndexedDB's atomic transactions ensure that if an annotation save fails mid-process, the database rolls back, preventing corrupted state files37.

Eviction Prevention and Data Resilience

By default, modern browsers treat IndexedDB and other local storage APIs as "best-effort" storage42. Under severe storage pressure—when the user's hard drive runs low on space—or after periods of prolonged inactivity (such as Safari's aggressive 7-day Intelligent Tracking Prevention rule), the browser may silently evict the user's research database to reclaim disk space36. To prevent catastrophic loss of scholarly work, the archival workstation must automatically invoke the navigator.storage.persist() API upon initial workspace creation42. This upgrades the IndexedDB storage from best-effort to persistent, explicitly instructing the browser to shield the annotations from background eviction algorithms unless the user actively clears their site data42.

Handling Storage Failures and Quotas

Furthermore, the application must actively monitor quota limits via the navigator.storage.estimate() API41. If a user attempts to import a massive legacy workspace that exceeds the browser's dynamic disk allocation (e.g., Chrome's 60% disk limit per origin), the system must proactively catch the QuotaExceededError42. The UI must intercept this error and present a classic Windows-style warning dialog, gracefully alerting the user to clear disk space or export older projects, rather than failing silently and corrupting the IndexedDB transaction42.

Schema Versioning and Upgrades

As the annotation system evolves over time, modifications to the IndexedDB schema will be required. The architecture must utilize the onupgradeneeded event listener to handle safe, non-destructive database migrations46. For example, if a future update adds a new object store for "Pinned Notes," the migration script must increment the database version, detect the old version, and add the new indexes without deleting existing "Highlight" records46.

Nostalgic Visual Rule and UI Translation

The visual integrity of the Al.Qaeda.net Archival Reconstruction workstation relies on strict adherence to a late-1990s/early-2000s Windows GUI paradigm. Modern interaction patterns—such as translucent floating toolbars, Notion-style dynamic blocks, modern colored cards, or mobile-first sliding side panels—are strictly prohibited. The interface must evoke the feeling of utilizing professional enterprise software from the era, relying heavily on gray 3D borders, bitmap icons, and rigid window layouts.

Win32 Common Controls Simulation

The HTML/CSS framework will meticulously simulate classic Win32 common controls to present the annotation data48.

• SysListView32: This will serve as the primary control for displaying lists of annotations in the Notebook and Search interfaces. It will feature rigid, clickable column headers (SysHeader32), optional gridlines, and full-row selection behavior50.
• SysTreeView32: Used for the hierarchical navigation of Tags, Categories, and Document structures. It will feature dotted hierarchy lines connecting child nodes to parents, tiny \[+\] and \[-\] bitmap expansion buttons (TVS\_HASBUTTONS), and support for direct label editing (TVS\_EDITLABELS)52.
• SysTabControl32: Employed in "Property Sheets" to separate configuration panes for individual notes. A user inspecting an annotation will see tabs for "General", "Excerpt", "Links", and "Advanced"49.
• Status Bars: A sunken, multi-part status bar at the bottom of the main window and Notebook application will display contextual system information (e.g., "3 Annotations found", "Storage: Persistent", "Selection: 142 characters").

Menu, Toolbar, and Context Menu Design

Interactions with the annotation system will be routed through a traditional dropdown menu bar, a global 16x16 pixel icon toolbar with a raised 3D border, and right-click context menus.

Exact UI Workflows and Feature Mechanics

1. Selection-Based Text Highlighting without Corruption

To apply a highlight, the user selects text within the Book Reader, a Markdown document, or a Search result. The user triggers the action via the context menu (Right-Click \-\> "Highlight") or the Ctrl+H accelerator. Technical execution: Historically, web annotation tools injected HTML \<span\> tags with inline styles around the selected text to apply background colors. This approach aggressively mutates the Document Object Model (DOM), breaking structural integrity, disrupting screen readers, and complicating subsequent overlapping selections53. In a cryptographic archive where DOM manipulation could theoretically invalidate a client-side verification hash, this is unacceptable. Instead, the workstation will utilize the modern CSS Custom Highlight API (HighlightRegistry)53. This API allows the JavaScript engine to pass the user's ephemeral Range object directly to the browser's CSS styling engine. The browser paints a yellow background over the text visually without inserting any wrapper elements into the DOM tree54. This ensures extraordinarily high performance for rendering thousands of highlights, prevents DOM bloat, and maintains completely stable anchors for overlapping annotations53.

2. Creating Margin Notes and Paraphrasing

When a user selects text and chooses "Add Margin Note" or "Add Paraphrase", a modal "Property Sheet" dialog box appears, perfectly styled like a Windows 98 properties window.

• The dialog features a sunken, non-editable text area displaying the quoted source text to provide immediate context.
• A multi-line text input (simulating RICHEDIT) allows the user to type their commentary or paraphrased translation.
• A dropdown menu (styled as a Win32 ComboBox) allows the user to select an existing note category, assign a color, or label the note as a Question or TODO.
• Clicking "OK" serializes the data into a JSON-LD W3C Annotation and commits it asynchronously to IndexedDB.
• In the document view, a small, classic dog-ear, paperclip, or sticky-note bitmap icon appears in the left margin next to the highlighted text, serving as a visual indicator.

3. Cross-Context Clipping and Scrapbook Generation

Clippings are standalone knowledge records derived from source text but divorced from the immediate document reading experience. The prompt specifies clipping creation from book pages, research documents, derived journal records, search results, and Atlas records. When a user triggers "Create Clipping" from any of these contexts, the system extracts the selected text, generates the exact bibliographic citation, captures the canonical URI, and routes this payload directly to the "Scrapbook" section of the Research Notebook. This workflow supports rigorous qualitative coding, where researchers gather dozens of disconnected paragraphs, search snippets, or Atlas node descriptions into a centralized workspace for thematic sorting, strongly resembling traditional physical index-card methodologies2.

4. Note-to-Note Links and Backlink Generation

To support the development of complex, interconnected knowledge graphs, users must be able to link their personal thoughts together. In the text body of any margin note or free-standing note, users can create "Note Links." These are hyperlinks embedded in the text that jump directly to another annotation's UUID. Visually, these links mimic classic Windows Help (.hlp) green underlined jumps, preserving the nostalgic aesthetic. Backlinks showing where a source has been referenced are dynamically generated by the system. When a user inspects a document or a specific annotation, the system queries the IndexedDB secondary indexes for any annotation whose Target source matches the current URI, or whose Target matches the current annotation's ID. These backlinks are presented in a dedicated "References" list pane, allowing the researcher to instantly see every personal note that has cited the current document.

The Dedicated Research Notebook Application

The central hub of the annotation experience is the "Research Notebook"—a dedicated desktop-style application window spawned within the workstation that aggregates all local annotations, clippings, and bookmarks into a unified command center. Proposed Layout Architecture:

• Left Pane (SysTreeView32): Displays a hierarchical tree of organizational vectors. Root nodes include:
• By Source (Expandable by canonical Book, Markdown Document, PDF, or Search Query)
• By Category (Colored labels, user-defined taxonomies)
• By Tag (Alphabetical listing of all user-created tags)
• Scrapbook (Free-standing notes and clippings)
• Pinned Notes (High-priority notes manually pinned by the user)
• Right Pane \- Top (SysListView32): Displays a detailed list of notes corresponding to the selection in the left pane. Columns include: Icon (Highlight, Note, Clipping), Excerpt, Source Title, Date Modified, and Tags. Clicking a column header triggers native ascending/descending sorting algorithms.
• Right Pane \- Bottom (Preview Pane): When a note is selected in the list view, this sunken panel displays the full text of the user's personal note, the highlighted source quote, and a clickable hyperlink back to the exact anchor in the Archive VFS.

Full-Text Search and Note Links

A plain text input box positioned above the List View allows real-time full-text search across all personal notes. Because IndexedDB lacks native full-text search capabilities, the workstation will utilize a fast, browser-based Web Worker search index (such as a local implementation of FlexSearch or MiniSearch) that syncs with the IndexedDB records56. This allows instantaneous filtering of the List View as the user types, bringing rapid retrieval to large personal datasets.

Cross-Application Appearance and Integration

Annotations must not be siloed in the Notebook; their presence must manifest contextually across the entire workstation to provide continuous spatial awareness for the researcher.

• Archive Explorer: When viewing a directory of files, an extra column titled "Notes" displays a paperclip or sticky-note icon if the local IndexedDB contains annotations targeting that specific file URI.
• Book Reader: Leverages the IIIF Presentation API 3.0. Annotations targeting specific spatial coordinates (Canvas regions) are drawn as classic red or blue bounding boxes over the scanned pages, mimicking analog markup27.
• Record Inspector: A new tab titled "My Annotations" is added to the Record Inspector property sheet, listing all notes attached to the currently inspected metadata record.
• Research Trail: Personal comments can be attached directly to chronological history nodes in the Research Trail. The Target of these annotations is a ResearchTrailRecord URI. This allows users to explicitly annotate their own search history (e.g., "This query string led to a dead end, try alternating keywords").
• Cognitive Atlas: User-defined tags and heavily annotated documents inject new nodes into the visual Atlas graph, rendering personal semantic connections alongside the system's canonical archive ontology.

Printing, Export, and Restoration Behavior

Because the data is strictly local, the user bears complete responsibility for long-term preservation and external sharing. The system will map export routines to the conceptual framework of the Open Archival Information System (OAIS)58.

The Export Mechanism

When the user selects "Export Notes", the system generates a Dissemination Information Package (DIP)59. This package is a standardized .zip file containing a "Portable Workspace." Inside the archive, all IndexedDB records are serialized into a single annotations.jsonld file conforming strictly to the W3C Web Annotation Collection standard24. To support interoperability with other tools, the export dialogue allows users to select alternative formats:

• CSV Export: Flattens the annotations into a spreadsheet format, highly useful for qualitative researchers executing coding and thematic analysis outside the workstation.
• Markdown Export: Translates notes into Markdown files with embedded standard HTML comments representing the annotation metadata, preserving thread states and document integrity26.
• Plain Text: A highly readable, simplified text dump of excerpts and notes for archival printing.

Printing Sources with Annotations

The requirement to print a source with or without personal annotations requires dynamic generation of a print view. When a user issues a print command, a dialog prompts them to include annotations. If accepted, the system clones the canonical DOM into a hidden print-only CSS media query document, injecting the shadow file text as block-level insertions (styled as classic footnotes or endnotes) before calling the browser's window.print() method. This ensures the physical printout contains the integrated knowledge without ever modifying the digital source file.

Restoration and Imported Annotation Compatibility

If a user imports a Portable Workspace from a previous session or a colleague, the system parses the JSON-LD. Because W3C annotations utilize globally unique URIs (UUIDs) for IDs, the system can confidently merge imported notes without risk of duplication23.

Undo, Recovery, and Edge Cases

A robust scholarly system must account for the reality of human error and shifting data landscapes.

• Undo/Recovery and Deleted Local Notes: A strict "soft-deletion" paradigm will be employed. When a user deletes a note, it is flagged as deleted: true in IndexedDB rather than purged. This allows for a reliable, instantaneous Undo (Ctrl+Z) buffer. Hard purges of the database occur only upon explicit, confirmed user command (e.g., "Empty Trash").
• Changed Route Metadata: If the underlying archive alters a document's URI over time, traditional bookmarks instantly break. Because the standoff annotations store a cryptographic hash of the document alongside robust text quotes, a future "Re-link Orphaned Notes" utility can scan the archive, find the matching content hash, and update the Target URI in the IndexedDB automatically.
• Huge Note Sets: To prevent UI thread blocking when loading 10,000+ notes in the Notebook, the SysListView32 implementation will utilize virtualized scrolling and IndexedDB cursor pagination. Only the DOM nodes currently visible in the scroll viewport are rendered, maintaining the snappy performance expected of native 1990s desktop applications.

Accessibility Framework

The annotation UI must accommodate keyboard-only and screen-reader users, adhering to modern Web Content Accessibility Guidelines (WCAG) and WAI-ARIA standards while presenting a retro aesthetic62.

• Tree Navigation: The left pane of the Notebook will meticulously implement the ARIA role="tree", role="treeitem", and role="group" patterns62. Focus will be managed via a roving tabindex. Users can navigate vertically with the Up/Down arrow keys, expand categories with the Right arrow, and collapse them with the Left arrow64.
• Grid Navigation: The right pane list view will implement role="grid" for comprehensive cell-based navigation66.
• Context Details: Interactive UI elements will utilize aria-expanded (to denote open/closed states of folders), aria-selected (for active items), aria-level (for tree depth), and aria-setsize (for total items) to announce hierarchical depth and selection states to screen readers seamlessly62.

Phased Implementation Plan and Acceptance Criteria

Deploying a system of this complexity requires a staggered integration approach to ensure data safety and UI stability.

Phase 1: Storage Foundation and Core Data Model

• Implementation: Establish the IndexedDB schema, define secondary indexes, and implement persistence handlers (navigator.storage.persist()). Build the JSON-LD serialization/deserialization logic for W3C Annotation objects.
• Acceptance Criteria: The system can programmatically create, read, update, and delete well-formed Web Annotation records in local browser storage across sessions without any network requests.

Phase 2: Anchoring and Highlighting Engine

• Implementation: Develop the DOM range extraction scripts to generate accurate TextQuoteSelector and TextPositionSelector data blocks. Implement the CSS Custom Highlight API to render highlights over text non-destructively.
• Acceptance Criteria: A user can highlight a complex paragraph, close the browser, reload the page, and observe the exact highlight re-render correctly via fuzzy matching, even if minor HTML spacing changes have occurred.

Phase 3: Classic UI Workflows and Notebook App

• Implementation: Build the context menus, property sheets, and dialog boxes, adhering strictly to the Win32 nostalgic visual rules. Construct the standalone Research Notebook interface featuring the Tree view, List view, and Preview panes.
• Acceptance Criteria: A user can create a margin note, open the Notebook, sort the list by "Date", and view the note in the split-pane layout utilizing full ARIA keyboard navigation.

Phase 4: Integration, Search, and Portability

• Implementation: Wire annotation status indicators into the Archive Explorer, Record Inspector, and Book Reader. Deploy the local Web Worker for full-text search. Implement OAIS DIP ZIP export and import logic.
• Acceptance Criteria: A user can execute a full-text search across 5,000 notes instantly, export the results to a ZIP file, clear their browser data, re-import the ZIP, and find all notes flawlessly restored and re-anchored to the correct canonical documents.

Works cited

1. Hypertext tools from the 80s \- Fibery, https://fibery.com/blog/gems/hypertext-tools-from-the-80s/

2. Zettelkasten \- Wikipedia, https://en.wikipedia.org/wiki/Zettelkasten

3. History of Hypertext: Article by Jakob Nielsen \- NN/G, https://www.nngroup.com/articles/hypertext-history/

4. Hidden Agendas, Lost Cities \- System Stack, https://systemstack.dev/2025/08/lotus-agenda/

5. The Semantic Desktop \- CEUR-WS.org, https://ceur-ws.org/Vol-175/SemanticDesktop2005Proceedings.pdf

6. Too Much Documentation \- C2 Wiki, https://wiki.c2.com/?TooMuchDocumentation

7. LDS Collectors Edition CD-ROM \- Scripture Central, https://scripturecentral.org/archive/periodicals/journal-article/lds-collectors-edition-cd-rom

8. Folio Infobase \- Just Solve the File Format Problem, http://justsolve.archiveteam.org/wiki/Folio\_Infobase

9. Advanced Instructions \- The LDS Info Base, http://www.ldsinfobase.net/advanced.html

10. EndNote \- Wikipedia, https://en.wikipedia.org/wiki/EndNote

11. How to Use EndNote 21: The Scholar's Essential Toolkit for, https://soporte.colineal.com/article/how-to-use-endnote-21-the-scholar-s-essential-toolkit-for-seamless-research

12. Annotated CRF | PDF | File Format | Information Science \- Scribd, https://www.scribd.com/doc/46067309/Annotated-CRF

13. Digital Libraries and the Need for a Universal Digital Publication, https://doi.org/10.3998/3336451.0009.203

14. IPAQ H3000 POCKET PC \- Arvutimuuseum, https://arvutimuuseum.ee/pdas/download/009/iPAQ\_3630.pdf

15. Balisage 2019 Program, https://www.balisage.net/2019/Program.html

16. The Shape of Data in the Digital Humanities: Modeling Texts and, https://dokumen.pub/the-shape-of-data-in-the-digital-humanities-modeling-texts-and-text-based-resources-1472443241-9781472443243.html

17. Graph Data-Models and Semantic Web Technologies in Scholarly, https://kups.ub.uni-koeln.de/54577/1/side15.pdf

18. True but Irrelevant | Rob Schrauwen, TUG 2025, https://sanand0.github.io/talks/2025-07-18-tug-true-but-irrelevant-rob-schrauwen/

19. A Digital Highlight Needs an Anchor, Not Just a Colour \- Eklavya.io, https://www.eklavya.io/blog/digital-highlights-portable-annotations-textbook-updates

20. Web Annotation Vocabulary \- W3C, https://www.w3.org/TR/annotation-vocab/

21. Annotation Systems for Evolving Documents \- wal.sh, https://wal.sh/research/annotation-systems/

22. Semantic Standards for Scholarly Publishing | PDF | Html \- Scribd, https://www.scribd.com/document/860366692/Ansi-Niso-z39-105-2023-cpld

23. GitHub \- readium/annotations: Model and JSON serialization of, https://github.com/readium/annotations

24. MeshNotes Annotation Format Specification — Version 1.0, https://meshnotes.org/spec/annotation/v1/

25. The Web Has Margins Again: W3C Annotations for the Developer, https://devreal.ai/posts/w3c-annotations-for-the-developer-community-graph

26. margin/COMMENT\_PROTOCOL.md at main \- GitHub, https://github.com/openprose/margin/blob/main/COMMENT\_PROTOCOL.md

27. Presentation API 4.0 — IIIF, https://iiif.io/api/presentation/4.0/

28. justmytwospence/ifs-journal \- GitHub, https://github.com/justmytwospence/ifs-journal

29. README.md \- readium/annotations \- GitHub, https://github.com/readium/annotations/blob/main/README.md

30. Annotation with a Non-Rectangular Polygon — IIIF, https://iiif.io/api/cookbook/recipe/0261-non-rectangular-commenting/

31. Geolocating with IIIF Presentation API 3.0: Part 2, https://blog.rerum.io/geolocating-with-iiif-presentation-api-3-0-part-2/

32. pub.layers.defs | Layers Documentation, https://docs.layers.pub/lexicons/defs/

33. Leveraging the Power of the Crowd to Save the Web, https://vpattanaik.github.io/slides/Vishwajeet\_DWSympo-2020.pdf

34. GhentCDH/Cune-iiif-orm-IIIF-Manifest-Builder \- GitHub, https://github.com/GhentCDH/Cune-iiif-orm-IIIF-Manifest-Builder

35. arXiv:2309.10531v1 \[cs.DL\] 19 Sep 2023, https://arxiv.org/pdf/2309.10531

36. Local Browser Storage for AI Chats: IndexedDB & OPFS, https://secret-chat.ai/blog/local-browser-storage-ai-chats-indexeddb-opfs/

37. IndexedDB: Browser Support, Storage Limits, Known Issues, https://www.testmuai.com/learning-hub/indexeddb-browser-support/

38. Storage Test \- TheTest, https://thetest.com/tests/storage

39. Storage for the web | Articles, https://web.dev/articles/storage-for-the-web

40. PGlite vs SQLite Wasm vs DuckDB Wasm: Browser Databases in 2026, https://kanopylabs.com/blog/pglite-vs-sqlite-wasm-vs-duckdb-wasm

41. Dive into IndexedDB — Browser Internals Course | Flavio Copes, https://flaviocopes.com/courses/browser-internals/indexeddb/

42. Storage quotas and eviction criteria \- Web APIs \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/API/Storage\_API/Storage\_quotas\_and\_eviction\_criteria

43. Storage API \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/API/Storage\_API

44. What are common reasons for 'QuotaExceededError' in IndexedDB, https://www.mindstick.com/interview/34333/what-are-common-reasons-for-quotaexceedederror-in-indexeddb-and-how-do-you-handle-it

45. How To Handle JavaScript Local Storage Quota Errors? \- YouTube, https://www.youtube.com/watch?v=HfTor3-09UU

46. IndexedDB \- The Modern JavaScript Tutorial, https://javascript.info/indexeddb

47. How do you handle schema migrations in IndexedDB (e.g., adding a, https://www.mindstick.com/interview/34320/how-do-you-handle-schema-migrations-in-indexeddb-e-g-adding-a-new-field-or-object-store

48. Win32 Assembly Language Tutorials by Iczelion \- Studylib, https://studylib.net/doc/25522674/182588970-052-iczelions-win32-assembly-tutorials-pdf

49. UI Automation Overview for Developers | PDF \- Scribd, https://www.scribd.com/document/362700696/UI-Automation

50. ListView Control \- Win32 apps | Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/msi/listview-control

51. Visual C++ Windows Shell Programming \[PDF\] \- VDOC.PUB, https://vdoc.pub/documents/visual-c-windows-shell-programming-1jeva952hjoo

52. About Tree-View Controls \- Win32 apps \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/controls/tree-view-controls

53. javascript user selection highlighting \- Stack Overflow, https://stackoverflow.com/questions/304837/javascript-user-selection-highlighting

54. Author page for OpenReplay Team, https://blog.openreplay.com/authors/openreplay-team/

55. svelte-highlight by @github-repos \- vite \- Codeshare, https://codeshare.me/c/d8be3a2b-ea88-4431-9e3c-1a3e264ef625/languages/examples/vite

56. FlexSearch.js: Next-Generation full-text search library for Browser, https://github.com/nextapps-de/flexsearch

57. Libsearch: Simple index-free full-text search for JavaScript, https://news.ycombinator.com/item?id=42537665

58. Community Standards for 3D Data Preservation, https://www.ala.org/sites/default/files/acrl/content/publications/booksanddigitalresources/digital/9780838939147\_3D\_OA.pdf

59. 3D Data Repository Features, Best Practices, and Implications for, https://crl.acrl.org/index.php/crl/article/view/24512/32346

60. Digital Preservation For Libraries, Archives, And Museums \[PDF\], https://vdoc.pub/documents/digital-preservation-for-libraries-archives-and-museums-76aoe9rpeto0

61. Annotate \- Omeka S, https://omeka.org/s/modules/Annotate/

62. Angular TreeView Accessibility Wai-Aria Support \- Telerik.com, https://www.telerik.com/kendo-angular-ui/components/treeview/accessibility/aria-support\_treeview

63. Accessible Rich Internet Applications (WAI-ARIA) 1.3 \- W3C on GitHub, https://w3c.github.io/aria/

64. ARIA: tree role \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/tree\_role

65. Tree View Pattern | APG | WAI \- W3C, https://www.w3.org/WAI/ARIA/apg/patterns/treeview/

66. Patterns | APG | WAI \- W3C, https://www.w3.org/WAI/ARIA/apg/patterns/

67. ARIA Practices Guide | Web Accessibility Initiative (WAI) | W3C, https://wai-aria-practices.netlify.app/aria-practices/

68. Building an Accessible Tree View in React \- azukiazusa.dev, https://azukiazusa.dev/en/blog/react-accessible-tree-view