Semantic File Systems: A Survey

• Semantic file systems are architectures that organize files based on semantic information, such as concepts, relationships, and context, rather than solely on file names and directories.
• They integrate techniques like rule-based inference, ontology mapping, and vector embeddings to support semantic queries and dynamic file management.
• Empirical studies of systems like LSFS and SPAR report improved retrieval accuracy, reduced query times, and more efficient semantic indexing compared to traditional methods.

A semantic file system is a file-management architecture in which files are organized, retrieved, and manipulated through semantic information—concepts, relationships, logical structure, or learned similarity—rather than through hierarchical directories and file names alone. In the literature, the term encompasses ontology-based desktop file managers, rule-based semantic retrieval backends, prompt-driven LLM layers over conventional file systems, vector-database systems with first-class directory semantics, typed transactional views over filestores, and preservation pipelines that extract XML and RDF structure from files [1307.2018][2410.11843][2606.16903][0910.3152][0106016].

1. Early formulations and the expansion of scope

An early line of work framed semantic file management as semantic information retrieval over structured representations of text-like data. The 2001 rule-based DBMS work describes “storage, extract and processing of information structured similarly to the natural language,” uses rules “having the same representation, as the data” for recursive inference, and places storage in the operating system’s File Mapping (SHM) mechanism; it also presents an application for “semantic information retrieval on the natural language” [0106016]. In strict architectural terms, that system is better characterized as a rule-based, file-mapped DBMS usable as a backend for semantic retrieval than as a mounted filesystem.

A more explicit desktop-oriented formulation appears in OntoFM. There, a personal ontology is an explicit, formal representation of a user’s personal information space, and a semantic file system uses “semantic information—meaning, concepts, relationships—to organize and retrieve files, instead of relying strictly on hierarchical directories and file names.” OntoFM overlays such a semantic layer on top of the operating system’s file system and treats files as ontology instances linked to concepts such as Paper, Project, User, and Date [1307.2018].

These formulations already establish a central point that remains valid across later work: semantic file systems are not defined by a single implementation locus. Some systems are storage engines, some are user interfaces, some are retrieval layers, and some are agent-memory substrates. A plausible implication is that “semantic file system” is best understood as a family of semantic access models over file-backed data, rather than as a single kernel-level design.

2. Semantic representations and indexing substrates

The literature uses several distinct semantic substrates. In the rule-based DBMS line, facts and inference rules share one representation, which allows recursive inference over data structured similarly to natural language and keeps data and rules within the same file-mapped memory environment [0106016]. This suggests a symbolic substrate in which retrieval is mediated by logical form and rule application.

OntoFM adopts an ontology substrate. Its personal ontology is written in OWL through Protégé; File is itself a concept, and concrete files are individuals linked to other concepts via object and data properties such as hasAuthor, belongsToProject, createdOn, and path-related properties. The system therefore maintains a two-level representation: the actual OS hierarchy and a high-level ontology of concepts and relations [1307.2018].

A structurally different substrate appears in semantic preservation systems. DFDL describes existing ASCII or binary file formats as an XML Schema logical model plus DFDL annotations, and Defuddle uses those descriptions to parse raw bytes into an XML infoset. GRDDL and XSLT then transform the XML into RDF, so the pipeline becomes bytes (\rightarrow) XML (\rightarrow) RDF. In that formulation, semantic file management rests on a clean separation among bits, formats, logical content, and graph semantics [0910.3152].

Modern semantic file systems frequently adopt vector representations. LSFS stores files by constructing semantic indexes with embeddings and a vector database, while preserving conventional file data and metadata in the underlying file system. Semantic retrieval, grouping, joining, monitoring, summarization, and rollback are then exposed as semantic syscalls and higher-level APIs [2410.11843]. SPAR similarly separates a semantic Metadata Index from session-specific vector databases, using tags, metadata, and embeddings to retrofit semantic retrieval onto legacy file systems [2512.12938]. FileGram extends the notion further: its semantic layer is not only content-derived but also behavior-derived, encoding procedural, semantic, and episodic channels from file-system behavioral traces and content deltas [2604.04901].

Other work contributes structural semantics rather than content semantics. TxForest provides declarative specifications, dependent pairs, comprehensions, options, and predicates over ad hoc collections of files and directories, yielding a typed structural view of filestores above conventional APIs [1908.10273]. ObjectFS, although not itself a semantic file system, isolates file semantics in an independent metadata store and decouples object identity from pathname via inode-number naming, which is a useful substrate for richer semantic metadata and alternate views [1908.11780].

3. Query models, retrieval semantics, and scope control

Semantic file systems differ most visibly in their query models. OntoFM uses concept-driven search rather than pathname lookup. As a user types in the search box, the system searches the ontology for matching instances and proposes candidate terms. The file list then shows file instances directly related to the selected ontology concepts, and “Files displayed have at least one direct relation to a concept entered by the user.” Files related to more of the selected concepts are ranked higher, while folder selection can restrict the semantic search scope to selected directories [1307.2018].

LSFS replaces shell-style command invocation with prompt-driven operation. Its LLM-based parser maps natural-language prompts to APIs and then to underlying semantic syscalls such as semantic_retrieve(), keywords_retrieve(), integrated_retrieve(), group_semantic(), and file_join(). The semantic index is embedding-based, while hybrid retrieval combines keyword filtering with semantic ranking inside the filtered subset [2410.11843].

SPAR formalizes a two-stage retrieval design for legacy enterprise repositories. A semantic Metadata Index is represented with relational tables,
Files(File_ID, File_Path, Tag_ID, Metadata) and Tags(Tag_ID, Tag_Value, Parent_Tag_ID, Children_Tag_ID), and only after metadata- and tag-based filtering does the system build a temporary workspace-specific vector database for the active task. The resulting query model combines metadata predicates, hierarchical tag expansion, and vector similarity inside a task-local candidate set [2512.12938].

Directory-aware vector search makes scope itself a first-class operator. The DSQ formulation models a directory node (v) with local entries (Local(v)), child directories (Child(v)), and an inclusive subtree entry set (Inc(v)), maintained by the invariant
[
Inc(v) = Local(v) \cup \bigcup_{w \in Child(v)} Inc(w).
]
Recursive DSQ uses (Inc(v)) as the candidate set for k-NN search, while non-recursive DSQ uses
[
Local(v) = Inc(v) \setminus \bigcup_{w \in Child(v)} Inc(w).
]
This turns directory scope, recursion, inclusion, and exclusion into native retrieval operators rather than application-layer workarounds over flat path strings [2606.16903].

FileGram introduces a different query abstraction. It does not retrieve files only by topical similarity; instead, query-time abstraction composes “Procedural Clues,” “Semantic Clues,” and “Episodic Clues” from behavioral statistics, content descriptors, embeddings, and drift markers. As a result, the system supports high-level questions such as typical organization pattern, editing style, or anomalous sessions, grounded in file-system traces rather than directory names alone [2604.04901].

4. Update semantics, maintenance, and consistency

A semantic file system must preserve semantic invariants under update, not merely under read. TxForest addresses this at the level of typed filestores. It uses Huet’s zippers to navigate and update structured specifications over files and directories, records read/write logs, and implements optimistic concurrency control with serializable transactions. The core result is a serializability theorem: if a concurrent execution reaches completion, then there exists a permutation of the transactions whose serial denotational semantics yields the same final filesystem [1908.10273]. In this line of work, semanticity lies in the typed structural API and explicit invariants, not in content embeddings.

Directory-aware vector search generalizes maintenance to semantic directory operations. DSM defines MOVE and MERGE over directory trees while preserving inclusive subtree sets. In TrieHI, subtree relocation is performed by parent-pointer changes plus updates to affected ancestor aggregates, so maintenance scales with path depth and merge conflicts rather than with the number of descendant path strings. This is the vector-database analogue of efficient directory rename and merge in a semantic file system [2606.16903].

LSFS emphasizes content-level maintenance. A Supervisor watches the traditional file system and keeps the semantic index in sync; a version recorder stores pre-modification content; rollback is supported both by time expressions and by version count; and change-summary uses an LLM to compare old and new contents. The design therefore couples semantic indexing to continuous file monitoring and version-aware recovery [2410.11843].

Object-backed file systems raise a related but lower-level issue: semantic layers require cheap namespace and metadata mutation. ObjectFS argues for a 1⇒1 file-to-object mapping, inode-number naming, an independent metadata service, and write-back caching. Inode-number naming makes file and directory renames metadata-only operations, and the independent metadata layer provides a natural place to add richer semantic attributes or alternate semantic namespaces without rewriting object data [1908.11780].

5. Major application forms

In personal information management, the dominant form is ontology-guided search and exploration. OntoFM integrates a folder hierarchy pane, file list, search box, and ontology visualization pane; it uses an OWL personal ontology, Protégé, and an OntoGraf-based mind-map view to help users explore files associated with concepts, related people, tasks, projects, and dates [1307.2018].

In enterprise environments, semantic file systems often appear as semantic sidecars over legacy repositories rather than as replacements for POSIX. SPAR is explicit on this point: it does not alter the OS-level filesystem, but adds a semantic namespace through metadata, hierarchical tags, and task-scoped workspaces for retrieval-augmented generation over historical enterprise files [2512.12938].

In LLM-centered systems and agent operating systems, prompt-driven semantic management becomes central. LSFS presents a layer above the traditional filesystem in which users or agents can retrieve, summarize, monitor, roll back, and share files through natural-language prompts, while the underlying semantic work is carried out by vector retrieval and semantic syscalls [2410.11843]. Directory-aware vector search pushes this further into an agent-memory setting: TrieHI has been integrated into OpenViking, where viking:// URIs, directory-recursive retrieval, and directory-scoped context organization provide filesystem-style semantic scope for AI agents [2606.16903].

FileGram represents another agent-oriented form. It does not replace the filesystem namespace, but it treats file reads, writes, edits, searches, moves, deletions, context switches, and content deltas as a dense semantic signal for personalization. Its memory architecture builds user profiles directly from atomic actions and content changes, making file-system behavior itself the semantic object [2604.04901].

In digital preservation, semantic file systems appear as semantic extraction environments. Defuddle wrapped as an iRODS microservice can parse uploaded files according to DFDL, emit XML, apply GRDDL transforms, and place RDF triples into semantic middleware such as Tupelo. In that setting, semantic navigation is grounded in the internal logical structure of files rather than only in external tags or filenames [0910.3152].

A persistent misconception is that a semantic file system must be a kernel-resident replacement for the ordinary filesystem. The surveyed systems show otherwise. Many are overlays, sidecars, or metadata services above conventional storage; others are transactional DSLs or vector-database backends. What unifies them is not mount-point implementation but semantic mediation of naming, retrieval, or update.

6. Evaluation, limitations, and research directions

The empirical record shows both gains and unresolved costs. LSFS reports an overall parser accuracy of approximately (90\%); for semantic retrieval with 40 files, Gemini‑1.5‑Flash improves from (70.9\%) without LSFS to (93.4\%) with LSFS, with retrieval time dropping from about (312) seconds to about (123.9) seconds, while GPT‑4o‑mini improves from (69.2\%) to (93.4\%) and from (239.5) seconds to (57.1) seconds. In non-semantic keyword retrieval, LSFS reaches F1 values around (0.82)–(0.84), better than the reported traditional baselines, and its Link API achieves (100\%) final success on the reported evaluation [2410.11843].

SPAR reports that, on a synthesized biomedical corpus, Retrieval Accuracy rises from (80.3\%) to (89.5\%), Average Retrieval Time falls from (0.039) s/query to (0.015) s/query, and Answer Accuracy rises from (65.1\%) to (68.1\%). Its complexity analysis formalizes the condition under which a semantic metadata layer plus on-demand workspaces is advantageous: if session selectivity is (p = N_{\text{filtered}}/N), then the rule of thumb is (W \cdot p \ll 1) [2512.12938].

FileGramBench shows that file-system traces are semantically informative but difficult to model. FileGramOS reaches (59.6\%) average, with channel-level scores of (60.1) for Procedural, (54.6) for Semantic, and (58.9) for Episodic memory. Removing the Procedural channel causes a (-11.1) percentage-point overall drop, larger than removing Semantic ((-5.5) pp) or Episodic ((-4.2) pp), and in the Real-World setting based on screen recordings, accuracy drops to single digits for all methods [2604.04901]. This indicates that semantic file systems for agents cannot rely only on narrative summaries or pixel-level perception; they benefit from atomic OS-level traces and structured statistics.

Directory-aware vector search provides a clear systems-level comparison. On WIKI-Dir, mean directory-only latency for recursive DSQ is about (365{,}000\ \mu s) for PE-Online, about (235\ \mu s) for PE-Offline, and about (273\ \mu s) for TrieHI. The study concludes that query-time path expansion incurs high recursive-query latency, while expansion-based maintenance suffers from write amplification under structural updates; TrieHI keeps directory topology as a native prefix tree and thereby reduces both recursive-query latency and maintenance cost [2606.16903].

Several limitations recur across the literature. OntoFM presents a prototype demonstration without a user study or quantitative evaluation, and it explicitly does not solve ontology population and maintenance [1307.2018]. SPAR depends heavily on metadata quality, pays overhead for on-demand workspace construction, and may lose its advantage when (W \cdot p) is not small [2512.12938]. LSFS acknowledges dependence on LLM quality, limited deep semantic support for non-text modalities, and unresolved security and privacy issues [2410.11843]. FileGram is constrained by synthetic data, limited behavioral coverage, and sim-to-real difficulties [2604.04901]. Directory-semantic vector search identifies open problems in ACL integration, richer path predicates, distributed consistency, and hybrid semantic-keyword planning [2606.16903]. Defuddle, in turn, is memory-bound: XML output can be about (8\times) input size, and the JVM heap required can be about (50\times) file size for the reported CSV example, which limits naive whole-file semantic extraction for large objects [0910.3152].

Taken together, these works show that semantic file systems now span symbolic inference, ontology engineering, structural schemas, vector retrieval, transactional semantics, and agent memory. The field has moved from concept-based desktop search toward broader semantic mediation of storage, scope, update, and personalization, but it has not converged on a single dominant architecture. The strongest common pattern is layered design: an underlying filesystem or object store remains intact, while semantic indexes, ontologies, typed specifications, or directory-aware vector structures provide higher-level meaning and control.