Search 2.0: Architecture and Information Retrieval Strategy for the Archival Reconstruction

Full report

On this page

Executive Summary

The reconstruction of the deterministic archival environment presents a unique information retrieval challenge. The architecture must deploy state-of-the-art search capabilities over a bounded corpus while rigidly adhering to a nostalgic, retro user interface paradigm reminiscent of the late 1990s and early 2000s. The current baseline features highly functional but isolated search environments—including archive search, book-library search, global Virtual File System (VFS) metadata indexes, and a read-only RSCON search interface. This environment encompasses 425 immutable VFS nodes, four verified book sources with 350 page derivatives, and 14 preserved research sources. This comprehensive analysis designs "Search 2.0," an exhaustive search architecture that brings modern information retrieval concepts—such as Reciprocal Rank Fusion, Key Word In Context concordance algorithms, and WebAssembly-based local indexing—to the user workspace. Crucially, this immense computational power remains completely hidden beneath classic visual paradigms, utilizing tabbed property dialogs, classic sidebars, and dense list views. Furthermore, the architecture enforces an absolute boundary between server-side immutable public records and client-side private research notes, guaranteeing zero telemetry, zero server-side analytics, and total user-work privacy.

Conceptual System Architecture

The overarching design of Search 2.0 relies on a bifurcated indexing and execution model. This structural separation prevents the contamination of pristine archival records with transient user data while simultaneously providing a unified, seamless querying interface at the presentation layer. Modern information retrieval is achieved via a dual-pipeline system merged dynamically by the client. The server-side pipeline manages the immutable archival corpus. Because the 425 VFS nodes, book derivatives, and preserved research sources form a strictly deterministic and static collection, the server does not require a heavy, highly dynamic runtime search cluster. Instead, it utilizes a pre-computed inverted index. A read-only RESTful API serves search requests against this global index, returning structured JSON payloads. This architectural choice eliminates complex server-side application logic, drastically reduces query latency, and minimizes the network attack surface by exposing only highly cacheable, read-only endpoints. Conversely, the client-side pipeline is designed to support search functionality over user-created notes, saved searches, and imported temporary files without violating the strict privacy requirements. To achieve this, Search 2.0 deploys a local WebAssembly (WASM) implementation of SQLite featuring the FTS5 (Full-Text Search) extension1. The SQLite WASM binary runs entirely within a Web Worker thread. This ensures that complex, resource-intensive full-text queries do not block the browser's main thread, preserving the fluid rendering of the retro user interface1. The index itself is persisted using the Origin Private File System (OPFS) or, as a fallback, standard IndexedDB1. This guarantees fast local read and write capabilities entirely within the secure browser sandbox, effectively turning the client into its own robust search engine. When a user executes a global query, the client-side Query Router manages the asynchronous execution. It dispatches simultaneous requests to the server API for archival nodes and to the local Web Worker for personal workspace materials. A dedicated Aggregator module then receives the disparate asynchronous responses, normalizes them, and mathematically merges the heterogeneous result sets for a unified graphical display. This bifurcated approach ensures that user data never traverses the network layer, strictly preserving privacy while delivering a comprehensive search experience3.

Query Language Specification and Syntax

A highly effective query grammar must provide advanced researchers with surgical precision without alienating standard users who expect simple, intuitive search behaviors. The Search 2.0 query syntax is heavily inspired by the Contextual Query Language (CQL), maintained by the Library of Congress as part of the Z39.50 standard successor framework5. CQL is strategically selected because its primary design objective is to remain highly human-readable and writable while maintaining the rigorous expressiveness of complex database query languages5. The implemented query grammar supports a wide array of advanced operators. Boolean logic is fully integrated, requiring the operators AND, OR, and NOT to be capitalized to distinguish them structurally from standard search terms. Exact phrase searches are enforced by enclosing terms in double quotation marks, which instructs the tokenizer to bypass standard stemming algorithms and evaluate exact token adjacency. Grouping is accomplished using standard parentheses to control operator precedence, allowing for highly complex conditional logic. Furthermore, the grammar supports granular field-specific queries structured explicitly as index \= term. This allows researchers to target specific metadata parameters. Finally, the system supports advanced proximity querying derived from the formal CQL specification. A query formatted as logistics prox/distance\<=5 strategy will retrieve documents where the two targeted terms appear within five words of one another, significantly increasing the contextual relevance of the retrieved documents5.

Fallback Behavior for Natural Keywords

When a user types ordinary, natural keywords without explicit operators or field designations, the system must gracefully handle the input without generating syntax errors or returning zero results. The fallback behavior relies on a transparent natural language translation pipeline. Spaces between unquoted terms are automatically treated as implicit AND operators, which drastically increases relevance precision compared to a default OR behavior. Once tokenized, the query undergoes light morphological stemming, such as removing basic pluralization, and standard normalization, which strips punctuation and forces lowercase evaluation. To ensure the most relevant documents appear first, the engine applies cross-field boosting. While the normalized terms are searched across all available fields, hits found within the title or subject metadata fields receive algorithmic weight multipliers, scoring them significantly higher than documents containing only deep-text content hits.

Metadata Provenance and Faceted Filtering

To maintain the rigorous academic integrity of the reconstruction, the search system must only expose facets and filters that are backed by verifiable archival facts. Exposing a generic, modern facet list would risk implying the existence of unsupported metadata. Given the historical and archival nature of the corpus, the metadata schema conforms to a precise fusion of the Dublin Core Metadata Element Set9 and the Encoded Archival Description (EAD3) standard10. The deterministic archive supports a highly specific subset of metadata. The user interface will strictly expose only these verified fields. The primary identifier is the Title, mapped to dc:title or the EAD3 unittitle, representing the formal or derived name of the node9. The Creator field (dc:creator) designates the verified author or organizational origin, populated only where historically verifiable. For temporal filtering, the Date field relies on dc:date or the EAD3 unitdate, utilizing ISO 8601 standardized temporal metadata to allow precise filtering by exact year or bounded historical ranges9. Source Type categorization (dc:type) allows users to filter by "Preserved Research," "Book Derivative," "VFS Node," or "Local Note." Finally, the Subject and Tags dimensions (dc:subject) rely on a strictly controlled vocabulary of historical markers. This explicitly avoids the utilization of generative artificial intelligence for tag creation, thereby eliminating the risk of hallucinatory or anachronistic metadata classification. By restricting facets to this verifiable list, the system guarantees that every filter applied by the user corresponds to a tangible, documented attribute of the archival material.

Preventing Hallucinated Metadata and Implied Dimensions

A critical challenge in archival search interfaces is preventing the user interface from suggesting that certain types of data exist when they do not. If a filter for "Geographic Location" is presented in the UI, but only three out of 425 documents possess verified geographic coordinates, the user experience degrades into frustration. Search 2.0 dynamically builds its available filter lists based solely on populated metadata dimensions within the current query scope. If a particular subset of documents lacks dc:creator data entirely, the author facet is visibly disabled or hidden from the classic UI, ensuring users are never led down empty investigative paths.

Information Retrieval Theory: Scoring and Ranking

Ranking search results appropriately is a complex mathematical challenge, particularly when combining text from highly disparate sources, such as a one-page metadata stub versus a 350-page historical book. The system must evaluate relevance without allowing document length to artificially skew the results.

Term Frequency and Length Normalization

For the static archival text, the core engine relies on the BM25 (Best Matching 25\) algorithm, widely considered the industry standard for probabilistic information retrieval. BM25 natively handles term frequency saturation and document length normalization. As a term appears more frequently in a document, its contribution to the final score approaches an asymptotic limit, preventing keyword stuffing or naturally repetitive long texts from overwhelming the scoring model. Furthermore, BM25 penalizes excessively long documents that happen to contain the search term, mathematically ensuring that a single, highly relevant mention of a keyword in a concise two-line intelligence cable is correctly weighted against fifty incidental mentions of the same keyword scattered throughout a 500-page book. This precise balancing act prevents lengthy documents from unfairly dominating the top ranks of the result set.

Normalization Tradeoffs and Equivalence Classes

Historical archives pose unique constraints regarding text manipulation, optical character recognition (OCR) artifacts, and preservation mandates. Documents derived from raw historical scans or poorly digitized books often contain structural OCR errors. Additionally, historical figures and locations frequently feature multiple valid transliterations and alternate spellings across different sources. Applying an aggressive algorithmic stemmer, such as the Porter Stemmer, risks destroying the exactness required for granular historical research. Therefore, the engine disables aggressive morphological stemming by default. A researcher searching for the precise term "correspondence" will not automatically match "correspondent" unless they explicitly append a wildcard operator. However, to account for historical realities, the indexing pipeline utilizes an explicit, human-verified equivalence class dictionary. This dictionary maps known transliteration variances and common OCR artifacts to a normalized root token at index time. Capitalization and standard punctuation are stripped during this indexing phase to facilitate matching, but users utilizing the exact phrase operator bypass this normalization entirely, ensuring the system can support absolute character-perfect retrieval when demanded by the researcher.

Cross-Collection Ranking via Reciprocal Rank Fusion

Merging BM25 results generated by the server's global index with the local SQLite FTS5 index presents a profound mathematical discrepancy. Because BM25 relies on corpus-wide statistics—specifically inverse document frequency (IDF)—scores calculated against the massive global archive cannot be directly compared to scores calculated against a user's small, personal workspace. The raw scores reside on entirely different numerical scales11. To resolve this without sacrificing accuracy, Search 2.0 implements Reciprocal Rank Fusion (RRF), a state-of-the-art non-metric fusion technique designed for hybrid search pipelines12. RRF combines multiple ranked lists based purely on their ordinal positions, completely ignoring the incompatible raw BM25 scores12. The fusion score for any given document [Figure omitted from source export] is calculated mathematically as: [Figure omitted from source export] In this equation, [Figure omitted from source export] represents the number of distinct search pipelines (in this architecture, two: the Server Index and the Local Index). The variable [Figure omitted from source export] represents the 1-based rank of the document in the [Figure omitted from source export]\-th result list12. Finally, [Figure omitted from source export] acts as a damping constant, typically set to 60 as per industry best practices, to mitigate the volatile impact of low-ranked outliers12. RRF ensures that a highly relevant local user note ranking first locally, and a highly relevant VFS node ranking first globally, will appear intelligently interleaved at the absolute top of the combined user interface, providing a defensible, mathematically sound hybrid search experience11.

Result Presentation, Snippets, and Highlighting

Retrieving a document successfully is only the first step; the user must immediately understand why the document was retrieved without the system destroying the visual integrity of the archival source material.

Concordance Views and Digital Humanities

Rather than relying on abstract, machine-generated summaries, the search results implement Key Word In Context (KWIC) concordance views. This methodology has been long established as a standard in digital humanities, corpus linguistics, and advanced archival research15. The KWIC algorithm computationally extracts a fixed window of tokens—typically seven words preceding and seven words following the matched term15. In the user interface, these extracted snippets are not presented as a flowing paragraph but rather in a highly structured, classic list view format utilizing three distinct columns: a right-aligned Left Context, a centrally aligned and bolded Keyword, and a left-aligned Right Context. This systematic visual lens allows researchers to rapidly scan patterns of language use down a vertical column, accurately evaluating document relevance before committing to opening a file15.

Non-Destructive Search Hit Highlighting

A primary directive of this project is the preservation of source integrity. Therefore, the system must highlight search hits within the actual document viewer without altering the source text's Document Object Model (DOM) structure. Historically, search highlighting involved injecting \<mark\> or \<span\> tags directly into the text. This destructive approach modifies the original DOM, compromises source integrity, frequently breaks modern reactive state models, and interferes drastically with user text selection. Search 2.0 resolves this historical limitation by leveraging the modern W3C CSS Custom Highlight API working in tandem with the W3C Selection API19. The search algorithm first identifies the precise start and end character offsets of the matched term within the text node. A standard DOM Range object is then instantiated for these exact coordinates21. This Range is appended to a Highlight object, which is subsequently registered to the browser's native CSS.highlights registry19. Finally, a CSS pseudo-element, specifically ::highlight(search-hit), applies the visual styling—such as a classic Windows 95 blue selection background or a high-contrast yellow marker effect20. This sophisticated process is entirely non-destructive; the source DOM remains completely untouched and mathematically identical to its original state, preserving archival formatting flawlessly19.

Provenance and Relevance Explanation

Every search result must maintain an unbroken, visually obvious chain of custody. The result list incorporates a dedicated "Location" or "Source" column. Archival VFS nodes feature authoritative system iconography, book page derivatives visually link back to their parent manifest, and local user files feature distinct local-drive icons. To satisfy the requirement for relevance explanation, users can right-click any result and select "Properties." This opens a classic tabbed dialog box. The "Relevance" tab displays the exact token matches, the fields in which they were found, and a human-readable breakdown of the BM25 and RRF scoring mechanics, completely demystifying the search engine's decision-making process.

Local Workspace Search and the Privacy Model

Modern researchers require robust search functionality over their own imported documents, reading notes, and workspace materials. Given the sensitivity of the research subject matter, privacy is an absolute, non-negotiable requirement.

The Absolute Local Boundary

All user-generated queries, personal metadata filters, imported local documents, and saved searches reside strictly behind a cryptographic and architectural local work boundary. When a user imports an external PDF or text file into their workspace for analysis, the client-side JavaScript extracts the text entirely locally. This text is indexed directly into the Web Worker's SQLite FTS5 database, safely stored within the IndexedDB or OPFS1. The network layer is bypassed entirely for this operation. No telemetry, user analytics, or behavioral tracking scripts are deployed. Server-side personalization based on search history is strictly prohibited, ensuring that the user's research trajectory remains mathematically invisible to the host server.

Search History and Saved Searches as Physical Objects

Search history and saved queries are modeled not as abstract cloud configurations, but as local file objects. Opening the Search pane reveals a "Recent Searches" drop-down, which simply reads from a local IndexedDB store. Saved searches are materialized as physical .cql (Contextual Query Language) or .osdx (OpenSearch Description) XML files. These files are saved directly into the user's local Virtual File System directory tree, for example, under C:\\Workspace\\Saved Searches\\. Clicking one of these files triggers the query locally. This grounds the complex feature within a highly recognizable retro computing paradigm while simultaneously ensuring complete user data sovereignty.

Retro User Interface and Wireframe Descriptions

The visual presentation rigorously adheres to the overarching aesthetic rule of the project: maintaining a nostalgic interface while delivering modern capability. The UI is completely devoid of modern faceted e-commerce dashboards.

The Explorer Search Pane

When navigating the Virtual File System, users invoke the Search capability via an Explorer-style sidebar, heavily inspired by Internet Explorer and Windows Desktop Search paradigms. The layout consists of a resizable left-hand sidebar containing classic, vertically grouped task panels. Visually, the interface utilizes standard hex values for grey button faces (\#D4D0C8), strict inset 3D borders (border: 2px inset), and system fonts rendering at an exact 8-point size (MS Sans Serif or Tahoma). The primary controls feature a text input for "Search for files or folders named," a secondary text input for "Containing text," and a classic combo box for "Look in," allowing the user to seamlessly pivot the search scope between the root VFS, specific archival folders, or the Local Workspace. An expandable accordion labeled "Search Options \>\>" provides simple checkboxes for filtering by Date, Type, and Size.

The Advanced Search Dialog

For exhaustive, granular research, a standalone dialog box replicates the layout and functionality of the Windows 95/NT "Find" utility, providing immense power through a familiar, non-threatening interface. The dialog features three primary tabbed property pages: Name & Location, Date Modified, and Advanced. The Advanced tab layout is a direct homage to classic database query builders. It contains a combo box for document type selection (Archival Node, Book Derivative, Research Note) and a text input for specific string matching. Below this is a group box titled "Search Criteria." This group box houses three inline combo boxes—Field, Condition, and Value—and a prominent "Add" button. Users construct complex Boolean queries line-by-line, which populate a classic multi-column List View directly below the controls.

The Result View and Status Paradigms

Search results are presented as a dense, standard file list, explicitly rejecting modern card-based UI trends. The List View features sortable columns for Name, In Folder, Relevance, Size, Type, and Date Modified. Relevance is visualized using a classic, segmented progress bar graphic or a raw integer percentage. The results can be visually grouped by 'Type' using collapsible list view headers reminiscent of later classic operating systems (e.g., an indented header reading "Archival Documents (12)" followed by the specific items). Selecting an item in the upper list view immediately populates a read-only preview pane docked at the bottom of the window. This pane displays the KWIC concordance snippet, complete with the non-destructive CSS Highlight API styling applied to the matched terms. The absolute bottom edge of the window features a classic, visually sunken status bar relaying system feedback, such as 45 object(s) found and Search completed in 0.12s.

Deep System Integration Workflows

Search is not an isolated activity; it is the fundamental entry point for archival synthesis. The Search 2.0 architecture seamlessly integrates its outputs with all other system utilities to create a cohesive research environment.

Explorer and Browser Integration

The VFS Explorer features immediate type-ahead indexing. As a user types into a folder view, the local client instantly filters the visible nodes using a fast, in-memory string matching algorithm, completely bypassing the heavy search engine for local navigation tasks. For the integrated Browser tool, search functionality extends deep into user-generated data. The user's Favorites and local Browser History are automatically indexed by the SQLite FTS5 worker. This allows a user to run a query that searches not only the archival documents but also the titles and metadata of every external web page they have bookmarked or visited within the workspace environment, creating a unified knowledge retrieval system.

RSCON Command-Line Integration

The RSCON (Remote System Console) provides a read-only, command-line interface for the search engine, catering to power users who prefer terminal environments. RSCON commands map directly to the CQL backend. A user can type \> FIND /VFS /AUTHOR="SMITH" /TEXT="LOGISTICS" directly into the console. The RSCON parser translates this proprietary syntax into a standard CQL string, dispatches it to the Query Router, and returns the results formatted as raw text output directly within the terminal window, maintaining the illusion of a remote mainframe connection.

Atlas and Book Reader Connectivity

If a search query triggers hits on geographic metadata (coverage), the results integrate directly with the Atlas component. Users can highlight search results, right-click, and select "Map Locations." The Atlas will render these documents as spatial pins, allowing for geographic analysis of search results. Within the Book Reader, search queries are hyper-granular. When a user clicks a search result that points to a specific book derivative, the Book Reader opens exactly to that page. The exact search phrase is highlighted over the derived page using the CSS Custom Highlight API. If the page contains ALTO XML coordinates from a historical OCR pass, the system draws precise bounding boxes around the words on the scanned image, providing an unparalleled research experience.

Collections, Citation Desk, and The Research Trail

Search results must be easily converted into actionable research outputs. Users can select multiple search results using standard keyboard modifiers (Ctrl+Click, Shift+Click) in the List View. Right-clicking opens a context menu with options such as Send to Citation Desk or Add to Collection. A "Collection" generates a local playlist-style file containing pointers to the underlying documents, allowing the user to construct custom comparison sets that can be reloaded at any time. The user's navigation through the search interface is logged locally into a comprehensive "Research Trail." This highly advanced feature utilizes the W3C Web Annotation Data Model23. When a user executes a query, views a specific result, and selects a passage of text, the client generates a JSON-LD annotation object. This object targets that specific URI and utilizes a precise text quote selector to ensure the annotation survives any subsequent file structure changes23. These discrete annotations are appended to a chronological Trail.json file securely stored in the local workspace, providing an auditable history of the user's analytical process.

Virtualization, Performance, and Accessibility

Rendering a search result set with thousands of hits can easily crash a browser if handled improperly. The system mandates strict performance optimizations.

List Virtualization over Pagination

While the server-side archival corpus is relatively small, a local user workspace might eventually contain thousands of notes, logs, and imported documents. Modern web applications solve this via pagination controls at the bottom of the screen. However, this breaks the desktop UI illusion. Instead, the UI relies on a deeply optimized Virtualized List View. The browser renders a standard Windows scrollbar whose height mathematically represents the entire massive result set, but the actual DOM contains only the 25 to 30 row elements currently visible within the viewport. As the user scrolls up or down, the off-screen rows are dynamically recycled and repopulated with new data. This precisely mimics the instant scrolling performance and low memory footprint of native Win32 SysListView32 controls, allowing the browser to render 10,000 search results with zero performance degradation.

Keyboard-First Workflows

Archival researchers and data analysts frequently operate at high speed using primarily keyboard inputs. The user interface meticulously maps standard desktop accessibility paradigms to browser DOM events. Pressing Ctrl+F or F3 globally focuses the primary search input field. The Tab key strictly navigates focus through input fields, combo boxes, and search buttons in a logical reading order. Pressing Enter executes the query immediately. Utilizing the Down Arrow moves focus from the search inputs directly into the Result List View, allowing rapid vertical navigation through the results. Pressing Alt+Enter invokes the properties and metadata view of the currently selected search result, while the Menu Key or Shift+F10 opens the context menu, allowing entirely mouse-free operation.

ARIA Accessibility Standards

To bridge the visual retro aesthetic with modern assistive technologies, standard ARIA roles are rigorously implemented. A custom HTML structure built specifically to mimic the appearance of a Windows 95 tab control is decorated with role="tablist", role="tab", and role="tabpanel". The primary List View utilizes role="grid" or role="treegrid", ensuring that screen readers can accurately parse the multi-column data and read out rows correctly to visually impaired researchers, ensuring the system is highly accessible despite its nostalgic styling.

Competitive Search System Benchmarking

To validate the architectural decisions underpinning Search 2.0, six distinct information retrieval systems were evaluated against the project's unique operational constraints.

Prioritization and Acceptance Criteria

To ensure a systematic and manageable deployment schedule, development efforts are prioritized according to the MoSCoW methodology.

Must Have (Phase 1: Core Functionality)

• Implementation of the global VFS search executing against the pre-computed JSON inverted index.
• Deployment of the Local Workspace search utilizing SQLite FTS5 operating inside a Web Worker/WASM boundary1.
• Support for fundamental Boolean querying (AND, OR) and exact phrase matching ("...").
• Pixel-perfect UI implementation of the Windows 95/98 "Find" dialog paradigm and virtualized List View.
• Integration of BM25 scoring and basic Reciprocal Rank Fusion merging of server and local results12.
• Comprehensive keyboard navigation mapping (F3, Tab, Enter, Arrows).

Should Have (Phase 2: Advanced Features)

• CQL-style field filtering (title=, date=) seamlessly mapped to the classic tabbed property pages5.
• Implementation of KWIC (Key Word In Context) concordance snippets rendering in a dedicated preview pane15.
• Integration of the CSS Custom Highlight API ensuring non-destructive DOM search highlighting within the Book Reader and document viewer19.
• Materialization of saved searches as physical, local XML/CQL files.
• Context menu integrations allowing rapid transitions from search results to the Citation Desk or custom Collections.

Experimental (Phase 3: Cutting-Edge Integrations)

• Full W3C Web Annotation Data Model implementation to power the automated Research Trail outputs23.
• Advanced query parsing for complex proximity queries (e.g., prox/distance\<=5).
• Deployment of customized equivalence class dictionaries for extensive, automated OCR artifact correction and historical transliteration matching.

Acceptance Criteria

The system will only be considered complete when it successfully passes the following rigorous acceptance thresholds:

1. Integrity and Latency: A query executed against the server index must return a valid JSON payload in under 200 milliseconds without triggering any dynamic server-side database compute. Furthermore, absolutely no DOM node within the Document Reader may be structurally altered by the search highlighting process.

2. Privacy Guarantee: Disconnecting the client machine completely from the network during a local-workspace search must result in successful query execution and zero data loss. Local files, query strings, and search history must never be transmitted via HTTP payload under any circumstances.

3. Aesthetic Compliance: The user interface must contain no modern rounded corners, no soft drop shadows (other than hard 1px black/white Windows 95 borders), no modern web-fonts, and no visible elements of modern CSS frameworks.

4. Relevance Accuracy: A known, specific keyword present identically in a two-page local text note and a 350-page VFS book derivative must result in both documents being returned to the user, intelligently interleaved at the top of the list view using the mathematically verified RRF algorithm.

Works cited

1. subframe7536/sqlite-wasm \- GitHub, https://github.com/subframe7536/sqlite-wasm

2. sqlite-wasm-http vs wa-sqlite \- compare differences and reviews?, https://www.libhunt.com/compare-sqlite-wasm-http-vs-wa-sqlite

3. TextAgent \- Write with AI Agents \- GitHub, https://github.com/Textagent/textagent.github.io

4. New Project Megathread \- Week of 23 Apr 2026 : r/selfhosted \- Reddit, https://www.reddit.com/r/selfhosted/comments/1stwv5b/new\_project\_megathread\_week\_of\_23\_apr\_2026/

5. Contextual Query Language \- Wikipedia, https://en.wikipedia.org/wiki/Contextual\_Query\_Language

6. Z39.50 Maintenance Agency Page \- Library of Congress, https://www.loc.gov/z3950/agency/

7. Reference | FOLIO Glossary \- FOLIO Developers, https://dev.folio.org/reference/glossary/

8. Multitarget/multiprotocol client application for search and retrieval of, https://www.emerald.com/el/article/30/3/351/95157/Multitarget-multiprotocol-client-application-for

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

10. EAD3 in Archives Portal Europe, https://www.archivesportaleurope.net/tools/for-content-providers/standards/ead3-in-archives-portal-europe/

11. Reciprocal Rank Fusion \- Apache Doris, https://doris.apache.org/docs/dev/key-features/reciprocal-rank-fusion/

12. Reciprocal Rank Fusion (RRF) Overview \- Emergent Mind, https://www.emergentmind.com/topics/reciprocal-rank-fusion-rrf

13. Hybrid RAG: Dense and Sparse Retrieval for Better AI Answers \- Atlan, https://atlan.com/know/hybrid-rag/

14. Hybrid Search: BM25, Vector & Reranking 2026 \- Digital Applied, https://www.digitalapplied.com/blog/hybrid-search-bm25-vector-reranking-reference-2026

15. CL2025 Pre-conference workshops \- Corpus Linguistics 2025, https://www.cl2025.co.uk/programme/workshops

16. Course | CLARIN ERIC \- Common Language Resources and, https://www.clarin.eu/learning-resource-type/course

17. KWIC Concordance View from AntConc 3.3.5 (Anthony, 2012), https://www.researchgate.net/figure/KWIC-Concordance-View-from-AntConc-335-Anthony-2012\_fig1\_267631312

18. DSC \#4: AntConc Saves the Day \- The Data-Sitters Club, https://datasittersclub.github.io/site/dsc4.html

19. \[css-pseudo-4\] Proposal: Highlight API · Issue \#4307 \- GitHub, https://github.com/w3c/csswg-drafts/issues/4307

20. CSS Pseudo-Elements Module Level 4 \- W3C, https://www.w3.org/TR/css-pseudo-4/

21. How to Use the JavaScript Selection API: Build a Rich Text Editor, https://www.freecodecamp.org/news/use-the-javascript-selection-api-to-build-a-rich-text-editor/

22. Selection \- Web APIs \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/API/Selection

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

24. Annotation-based enrichment of Digital Objects using open-source, https://journal.code4lib.org/articles/12582

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

26. Z39.50 \- Wikipedia, https://en.wikipedia.org/wiki/Z39.50

27. Introducing reciprocal rank fusion for hybrid search \- OpenSearch, https://opensearch.org/blog/introducing-reciprocal-rank-fusion-hybrid-search/

28. MCP Agent Mail \- GitHub, https://github.com/dicklesworthstone/mcp\_agent\_mail

29. ADR-OSpipe-screenpipe-integration.md \- RuVector \- GitHub, https://github.com/ruvnet/RuVector/blob/main/examples/OSpipe/ADR-OSpipe-screenpipe-integration.md