Encapsulated Search Paradigms

• Encapsulated search is a framework where the search object bundles query data with context, policies, and extraction rules to support nuanced retrieval.
• It spans various modes—including contextual, extractive, visibility-scoped, and cryptographic—that address reproducibility, state reconstruction, and personalized access.
• This approach fuses search state, policy enforcement, and output schema, leading to improved accuracy, secure indexing, and advanced metadata handling.

Searching arXiv for papers relevant to "encapsulated search" and adjacent search paradigms.

“Encapsulated search” (Editor’s term) denotes search architectures in which the operative search unit is not a bare query–document match, but a richer object that bundles additional structure with retrieval: a reconstructable search context, an extraction schema embedded in the query, a user-specific visibility scope, or a cryptographically protected corpus and index. In the arXiv literature, the phrase is not standardized as a single formal paradigm; instead, several adjacent lines of work instantiate different kinds of encapsulation. Search-context systems preserve the full state surrounding a query for reproducibility and revisitation (Fernando, 2015). Neural extractive systems package retrieval intent and output slots into one query object (Ravfogel et al., 2021). Decentralized Solid-based systems bind search to per-user visibility scopes and WebID-scoped metadata (Ragab et al., 23 Apr 2026). Searchable-encryption systems make the encrypted representation itself the searchable substrate (Pham et al., 2018).

1. Modes of encapsulation

Across these literatures, the shared design move is to treat search as a bounded computational object whose surrounding constraints remain part of the retrieval semantics. That object may be temporal and interactional, as in search-history reconstruction; structural, as in extractive queries with capture slots; authorization-scoped, as in decentralized search over Solid pods; or cryptographic, as in searchable encryption and secure indexing (Fernando, 2015).

Mode	Encapsulated unit	Representative work
Contextual	Query, displayed results, clicks, saves, dwell time, annotations, session metadata	LearnWeb2.0 search-context tracking (Fernando, 2015)
Extractive	Retrieval pattern plus capture slots for spans to be extracted	Neural Extractive Search / SPIKE (Ravfogel et al., 2021)
Visibility-scoped	Query execution restricted to $V(U)$ and WebID-scoped indexes/metadata	ESPRESSO for Solid pods (Ragab et al., 23 Apr 2026)
Cryptographic	Encrypted documents, encrypted index, encrypted query trapdoor	Secure search / searchable encryption (Pham et al., 2018)

A central consequence is that the boundary between “search,” “state,” and “policy” is moved inward. In a conventional IR pipeline, annotations, access control, and output schemas are often external subsystems. In encapsulated designs, they become first-class components of the searchable representation itself. This suggests that “encapsulation” is less a single algorithm than a family of architectural commitments about what must remain attached to a search operation.

2. Search context as a reconstructable object

In multimedia corpus building, search is often longitudinal, multi-query, and multi-source. The LearnWeb2.0 work models this explicitly by treating a search process as a persistent context rather than an isolated query-click event. The captured package includes query text, search type, user ID, group ID, session ID, timestamps, the entire displayed result set, clicked and saved resources, viewing time, comments, and tags, all linked by resultsetid (Fernando, 2015).

The system architecture reflects that choice. A RESTful tracking service persists query logs, result sets, resource actions, viewing-time logs, comments, tags, and shared-result relationships. The visualization layer then reconstructs historical search states through interfaces such as “Similar Queries,” “Complete History,” and “View Result Set.” The last of these is especially characteristic of contextual encapsulation: it recreates a previous result set in a layout resembling the original search page, exposes a timeline of clicks, saves, viewing times, and comments, and allows filtering by clicked, not clicked, saved, or all resources (Fernando, 2015).

What is preserved is therefore not only behavior, but the candidate set from which later selections were made. This is crucial for reproducibility in social-science corpus construction. The system’s notion of “ignored results” is not inferred abstractly; it is computed from the preserved displayed result set minus later interactions. A saved image or video can thus be traced back to the precise ranked context in which it originally appeared. In this sense, the encapsulated object is a search episode with full interactional state, not merely a log entry.

The same design also supports comparison over time. Similar-query views compare current top-$n$ resources with those from previous result sets, while date-grouped history and result-set sharing turn search into a revisitable collaborative artifact. A plausible implication is that contextual encapsulation is best understood as stateful provenance for search rather than ranking alone.

3. Query encapsulation in extractive and neural extractive search

A different form of encapsulation appears in extractive search. Here the query itself carries not only topical intent but an output schema. In SPIKE-style syntax, the user writes a sentence-like pattern and marks spans as captures, such as ARG_1 and ARG_2; the system must retrieve matching sentences and return the aligned spans rather than only the sentence list (Ravfogel et al., 2021).

The paper “Neural Extractive Search” formalizes this as a hybrid symbolic–neural workflow. First, a structured SPIKE query yields a small, high-precision seed set. Second, those seed results are encoded with SciBERT, averaged into a single query-results vector, and used for neural nearest-neighbor retrieval over a Faiss index. Third, because the neural matches do not inherently preserve the original slot boundaries, a span-alignment model predicts the corresponding ARG_1 and ARG_2 spans in the retrieved sentences (Ravfogel et al., 2021).

This is an encapsulated query because retrieval intent and extraction constraints are fused. A query such as “Something is a drug extracted from plants” does not merely ask for topical similarity; it asks for relation instances and for the arguments filling that relation. The system’s evaluation supports the utility of this packaging. On 240 manually judged test sentences from 11 unseen relation types, 72.2% of neural-augmented results were relevant overall, with 75.0% relevance in the top 10 and 69.5% in ranks 90–100; the alignment model reached 58% under a lenient span-overlap criterion (Ravfogel et al., 2021).

The approach preserves the precision advantages of syntactic search while using neural retrieval to recover paraphrastic or structurally different expressions. It is therefore not a single end-to-end learned search algebra, but a staged architecture in which the query object already specifies what counts as a relevant match and what parts of that match must be output. Relative to ordinary semantic search, this is a strong form of query-side encapsulation.

4. Visibility-scoped encapsulation in decentralized search

In decentralized personal-data settings, encapsulation takes the form of policy-bounded execution. ESPRESSO, designed for Solid pods, defines search over distributed resources owned by multiple pod owners and constrained by WebID-specific access policies. For a query $Q$ issued by a search party $U$, the intended result set is restricted to the visibility scopes $\mathcal{V}_i(U)$ of that user, with global visibility $V(U)=\bigcup_i \mathcal{V}_i(U)$; the paper states the core guarantee as $R(Q,U)\subseteq V(U)$ (Ragab et al., 23 Apr 2026).

This design propagates visibility into every search layer. The Indexing App builds not one shared pod index, but separate WebID-scoped local inverted indexes $\mathcal{I}_{ij}=Index(V_i(U))$ and a separate public index. Above these, the Metadata Manager constructs server-level and system-level metadata that are also WebID-scoped. Thus source selection is already authorization-filtered before any document-level retrieval occurs (Ragab et al., 23 Apr 2026).

The same encapsulation appears in the metadata definitions. Server-level metadata maps a WebID and keyword to a set of visible pod URLs and associated statistics; system-level metadata maps a WebID and keyword to visible servers and network-level statistics. The design goal is “privacy-aware metadata” sufficient for source selection and ranking, without centralizing raw content or building a global plaintext index. The paper also introduces “metadata conservativity and separability”: metadata should not reveal more than an authorized user could reconstruct from legitimate query results, and metadata is partitioned by WebID to prevent cross-user leakage (Ragab et al., 23 Apr 2026).

This architecture is explicitly not cryptographically private in the stronger searchable-encryption sense. The paper states “No Cryptographic Query Processing,” “No Differential Privacy,” and “No Query Obfuscation,” and it relies on compliant Solid infrastructure and non-colluding honest-but-curious adversaries (Ragab et al., 23 Apr 2026). Even so, it exemplifies access-bounded encapsulation: the searchable representation is inseparable from the authenticated identity and its visibility scope.

5. Cryptographic encapsulation: searchable encryption and secure semantic indexing

A fourth meaning of encapsulated search arises when the searchable corpus is itself wrapped by encryption. The secure-search survey characterizes this problem as searchable encryption over outsourced cloud data and identifies a common architecture of Keygen, Build-Index, Trapdoor generation, and Search, with goals of controlled searching, hidden query, and query isolation (Pham et al., 2018). In this formulation, the index and the query trapdoor are the searchable surrogates for plaintext content.

The survey organizes the field into keyword search, regular-expression search, and semantic search. Sequential-scan schemes and PEKS support secure matching but scale poorly; index-based schemes, including Bloom-filter and inverted-index variants, improve practicality but often leak search patterns and access patterns (Pham et al., 2018). The tradeoff is explicit: the more secure the scheme, the less efficient it tends to be, while richer functionality often requires more metadata.

The dissertation “Semantic, Efficient, and Secure Search over Encrypted Cloud Data” pushes this cryptographic encapsulation toward semantics and systems performance. Its first contribution maps documents and queries into a Wikipedia-derived concept space, then encrypts concept vectors with secure $k$NN. The core ranking innovation is the double score weighting rule, which orders concepts lexicographically by a primary score and a secondary score rather than by a single accumulated concept weight (Boucenna, 2020). The thesis reports that its semantic encrypted scheme improved over MRSE by about 60%, and that with an added document-length filter the improvement reached 84% over MRSE (Boucenna, 2020).

The same dissertation then addresses efficiency. For vector-based searchable encryption, it accelerates similarity computation and ranking with multicore CPU, GPU, hybrid CPU–GPU, and cluster implementations. In the strongest reported result, the cluster solution on 200,000 documents and 20 simultaneous queries achieved about $46\times$ speedup relative to the sequential baseline (Boucenna, 2020). This is important because cryptographic encapsulation often relocates the main bottleneck from plaintext indexing to encrypted vector arithmetic.

Its final contribution, SIIS, returns to secure inverted indexes. SIIS combines a concept-based inverted index, a second inverted index for access-right management, leveled homomorphic encryption for scores, CP-ABE for document access, dummy documents, and an access-pattern-hiding subsystem. The thesis reports that SIIS reached about 38.76% accuracy versus about 43.46% for semantic plaintext search and less than 23% for MRSE, while remaining about $n$0 faster than the extrapolated MRSE baseline on the full Yahoo! Answers collection (Boucenna, 2020). In this line of work, encapsulation means that documents, scores, access rights, and even some retrieval metadata are protected objects over which search must still remain executable.

6. Ambiguities, homonyms, and open questions

The literature does not yet offer a single canonical theory of encapsulated search. The phrase appears in different senses, and some uses are only homonymous. In nanoscience, “encapsulated search” can describe non-IR tasks such as locating buried graphene and assessing its local electronic quality with electrostatic force microscopy and Kelvin probe force microscopy, where the “search” target is a hidden conductor rather than a document collection (Altvater et al., 2019). In machine learning, “A Capsule Network-based Embedding Model for Search Personalization” uses capsules in the deep-learning sense to model query–user–document triples for reranking, which is distinct again from contextual, scoped, or cryptographic encapsulation (Nguyen et al., 2018).

This conceptual spread produces several recurrent misconceptions. One is that encapsulation is purely about privacy. The corpus-building and extractive-search literatures show instead that encapsulation can be about preserving search state or output schema. Another is that a single query interface suffices to unify these strands. In practice, each strand carries its own failure modes: contextual systems preserve history but do not provide end-to-end semantic generalization (Fernando, 2015); neural extractive systems improve recall but still require post-hoc alignment (Ravfogel et al., 2021); Solid-based scoped systems enforce visibility but explicitly forgo cryptographic query privacy (Ragab et al., 23 Apr 2026); encrypted semantic systems improve relevance yet still leave forward and backward privacy unresolved (Boucenna, 2020).

A plausible synthesis is therefore that encapsulated search names a family of search designs in which the search object is deliberately enlarged. The enlargement may include provenance, extraction variables, access policy, or ciphertext structure; what unifies the family is the refusal to treat those components as merely external metadata. Current work suggests three persistent research axes: richer state reconstruction, tighter scope enforcement, and stronger protected retrieval. None has yet subsumed the others into a single formalism.