Atomspace plays a central role in OpenCog as a (hyper/meta)graph knowledge representation and storage that mediates communications between different AI algorithms. There is a general consensus that Atomspace in Hyperon should have the same basic structure and role. However, some details can be quite different. Two main related topics of former discussions about Atomspace are 1) A scalable distributed Atomspace implementation 2) Implementation of (distributed) episodic memory that stores subgraphs of knowledge heavily mixed with data (numeric/textual/etc.) that requires combined retrieval.
The high level reasons for wanting a (hyper/meta)graph as the core knowledge meta-representation mechanism here are the same for Hyperon as they have been throughout the history of OpenCog development; some of these have been summarized in an elegant and practical way by Linas Vepstas in [Graphs, Metagraphs, RAM, CPU]
Requirements for the distributed Atomspace File:Distributed Atom Space - Requirements.pdf and its possible architecture File:Distributed Atom Space - Architecture.pdf were analyzed some time ago (the draft version File:Distributed Atom Space - Requirements and Ideas - DRAFT.pdf dates from 2017).
A number of documents discussed episodic memory as well, especially focused on the virtual assistant use case:
- File:Episodic Memory Design for Virtual Assistant.pdf
- File:Episodic memory for OpenCog.pdf
- File:Episodic storage design.pdf
- File:Use Case Episodic Memory for Virtual Assistant.pdf
Since episodic memory has its specifics (additional indexes besides subgraph indexing; more focus on retrieval instead of in-memory reasoning), there was no consensus if we need only distributed atomspace, or only distributed episodic memory, or both. Subsequent refined vision emphasizes separation of interfaces from implementations. The latter can differ, and, in fact, even deduplication of subgraphs resulting in hypergraphs instead of plain graphs can be treated as a very important, but particular implementation detail. Atomspaces appear to be a certain type of containers endowed with pattern matching. Atomspaces with richer functionality are necessary, but they can differ (although some default implementation of a distributed Atomspace and/or episodic memory is of high value). What pattern matching should do depends on some aspects of overall Hyperon design including Atomese and reasoning. Current vision supposes static pattern matching with free variables both in queries and in knowledge base entries explicitly dealing with grounded atoms that considerably differs from the current Pattern Matcher. Static pattern matching gives hope for efficient distributed implementation. Explicitly dealing with grounded atoms can provide a standard way for dealing with data retrieval, in particular, for episodic memory. While free variables on both sides is the requirement from Atomese/reasoning side.
Some of these aspects are taken into account in analyzing differences between graph DBs and Atomspace for Hyperon File:Distributed Atomspace 2.0 and graph DBs differences.pdf. Document File:Pattern Mining, Indexing and Generalized Hypergraph Representation.pdf discusses generalized atoms as possible entities in Atomspace for native Pattern Mining. However, both interface and implementation details of Atomspace for Hyperon are still to be determined.