Implementations

help edit space_dashboard

Four-Layer AtomSpace Taxonomy (Cluster-Pilot Lock-In, 2026-04-29)

"AtomSpace" at this point in time is not a single coherent backend — the ecosystem spans four distinct implementation layers with different repos, runtime characteristics, and Decko-integration suitability. Future agents reading "AtomSpace" without qualification should resolve which layer is meant before drawing conclusions.

# Layer Repos / Evidence Decko relevance
1 Classical AtomSpace StorageNode opencog/atomspace+ atomspace-storage+ atomspace-pgres+ atomspace-rocks+ atomspace-cog+ atomspace-bridge Best read-side SQL import ancestor; not Decko-write-ready
2 Hyperon Space trueagi-io/hyperon-experimental:lib_spaces.metta GroundingSpace / SpaceMut / DynSpace; MeTTa-facing demos; not primary Decko backend
3 DAS AtomDB + services singnet/das: AtomDB + Query Engine + AttentionBroker + agents; MorkDB Candidate later query/deployment layer; delete + server-pin caveats
4 MORK native substrate trueagi-io/MORK+mork_ffi PathMap + + SDK + server branch Performance substrate; requires adapter layer for Decko semantics

Source: AtomSpace Backend Integration Cluster Pilot (2026-04-29) — R4.J1 lock-in across Sources 1-4; cluster archive at scripts/archive/atomspace_pilot/. The H4 sections that follow give per-layer detail (Classical → Layer 1; Hyperon Experimental → Layer 2). Layer 3 (DAS) is detailed at DAS Full; Layer 4 (MORK native) is detailed at MORK Full.

Classical AtomSpace Architecture (C++)

The opencog/atomspaceC++ implementation provides the mature, battle-tested realization:

  • Atom type hierarchy: ~150 predefined types (Node, Link, ConceptNode, PredicateNode, EvaluationLink, etc.) organized in a class hierarchy. New types can be defined at runtime.
  • Pattern matching engine: Two-phase execution — compilation extracts variables and builds connectivity maps; execution via PatternMatchEngine with callback mixins for custom match semantics. Type checking and pattern matching are theoretically identical operations — "there is absolutely zero theoretical difference" for first-order types, though higher-order types require additional logical deduction (Linas Vepstas, 2014). This equivalence directly influenced Hyperon's approach of unifying type checking and matching. (mailing-list-backed: Atomspace-type-checking, 2014)
  • PLN/PM semantic duality: PLN link types and Pattern Matcher link types form a Kripke semantics pair: "BindLink is the Kripke equivalent of ImplicationLink." PLN links operate on truth values (probabilistic), while PM links check for structural presence. (mailing-list-backed: IfElseLink, 2015)
  • Language bindings: Deep integration with GNU Guile (Scheme) and Python. Scheme is the primary scripting interface for legacy OpenCog; Python via the opencog.atomspace module.
  • Sheaf-theoretic foundations: The opencog/sheaf/ module provides formal mathematical foundations (sheaf axioms, tensor algebra, mereological structures). The intellectual genealogy traces to Link Grammar: Linas argued that LG's connector/section formalism replaces production rules, inference, and deduction with "assembly" — a more general, symmetric operation that eliminates forced directionality. (mailing-list-backed: Link-Grammar-influence-on-AtomSpace-design, 2016) The formal bridge from metatrees to sheaves runs through the jigsaw puzzle piece metaphor (Vepstas 2023, §10.4): beta-reduction is jigsaw-puzzle assembly — connecting a slot variable to a tab value. Connectors have typed slots and tabs that must match types but have opposite "sexes" (directions). Partially assembled jigsaws obey the sheaf axioms. This is not merely an analogy: the ArrowLink (function type) is a special case of a general ConnectorSeq with typed directional connectors, and Link Grammar's connector formalism makes this explicit. The conclusion: "metatrees are naturally typed; those types are naturally reified; the reifications are recursive, and the level of recursion is limited by the imagination." (Provenance: publication, Vepstas — "Graphs, Metagraphs, RAM, CPU" v2.1.1, 2023; also TODS 2024 submission)
  • Persistence layer: Pluggable via StorageNode/BackingStore API — backends include atomspace-rocks(RocksDB), atomspace-cog(network), and atomspace-bridge(SQL(mailing-list-backed: bridge). The BackingStore abstraction is deliberately narrow: developers only implement 3 table structures and 4-5 query methods, estimated at 1-5 weeks of work. PostgreSQL was chosen over Neo4j (10× slower) and NoSQL databases ("absolutely terrible performance" for 50-100 byte atoms). Why-Postgresql-Used, ArangoDB-as-backend-for-atomspace, 2014)

Hyperon Experimental (Rust Reimplementation)

The trueagi-io/hyperon-experimentalRust implementation is the reference for Hyperon's MeTTa:

  • Multi-crate workspace: lib (core MeTTa interpreter), c (C API for Python/foreign bindings), python (hyperon Python package)
  • Four atom variants: Symbol, Variable, Expression, Grounded — a cleaner, more minimal type system than the C++ hierarchy
  • Grounded atoms: Foreign objects (Python callables, tensors, file handles) wrapped as first-class atoms queryable through the Space API. This resolves the classical ExecutionLink limitation where do_execute could only return Handles, not TruthValues or arbitrary types. (mailing-list-backed: Semantics of ExecutionLink and GroundedSchemaNode, 2014)
  • Module system: Each module encapsulates a unique Space and Tokenizer, forming a hierarchical namespace. Three import modes and a catalog-based name resolution system manage dependencies. See MeTTa Full for details.
  • Prioritizes flexibility and semantic correctness over raw performance — PeTTa/MORK provides the high-performance path
  • First-class DAS support (default feature): lib/Cargo.toml declares metta-bus-client from singnet/das tag 1.0.2 with a default-enabled das feature; new-das! constructs a DistributedAtomSpace and returns a DynSpace (das.rs:156-199). DAS Layer 3 is wired in, not doc-only.

System Interfaces

  • MeTTa: AtomSpace is the execution environment — MeTTa programs are graph transformations over AtomSpaces via the Space API.
  • MORK: High-performance backend implementing the Space API with PathMap triemaps, content addressing, and ZAM execution.
  • DAS: Distributed backend implementing the Space API with Redis/MongoDB sharding and Attention Broker.
  • Python: The hyperon Python library provides bidirectional MeTTa-Python interop. Grounded atoms can wrap Python objects and callable code.
  • All PRIMUS components: PLN, MOSES, ECAN, pattern mining, MetaMo — everything operates over AtomSpace as the shared substrate.

Implementation Anchors