Values and Space API

help edit space_dashboard

The Atom / Value Distinction

Atoms are the graph structure — immutable, globally unique, typed, and indexed. They represent relationships, categories, rules, and long-term stable knowledge. Atoms are heavy-weight objects designed for structural queries and pattern matching. Think of them as the "plumbing." Atom creation costs ~tens of microseconds (indexed).

Values are mutable vectors attached to Atoms via a key-value store. They are not indexed, not globally unique, and designed to be small, fast, and fleeting. Values hold truth values, probabilities, streaming sensor data, attention weights, and any other rapidly-changing metadata. Think of them as the "fluid in the pipes." Values have no indexing overhead.

This separation is a deliberate performance decision: the graph structure changes slowly (adding a new concept or relationship), while valuations change rapidly (updating a confidence score after new evidence). Indexing only the structure keeps the pattern matcher fast even as values churn. For DNN integration, this means tensor data (activations, weights) should use custom Value classes (e.g., TensorFlowValue), while the Pattern Matcher accesses Values indirectly through predicates rather than direct search. The conceptual bridge: "conscious processes over Atoms, subconscious processes over Values." (mailing-list-backed: OpenCog-DNNs-PPLs-Atoms-vs-Values, 2018)

The TruthValue to FloatValue Transition

Original design: Every atom carried a SimpleTruthValue \(\langle s, c \rangle \in [0,1]^2\) — strength and confidence — central to PLN reasoning. This led to proliferating specialized types: FuzzyTruthValue, DistributionalTruthValue, IndefiniteTruthValue.

Problem identified: "Complex multiple inheritance relations" among proliferating TV types, plus most AtomSpace calculations needing crisp boolean operations, not probabilistic truth values. Mandatory TruthValues "hurt performance and cluttered the API." The transition was blocked for years by unsolved serialization: without a serialize/deserialize proposal, PropertyMaps were "a non-starter." (mailing-list-backed: Replacing-TV-and-AV-objects-with-property-maps, 2015)

Resolution: TruthValues were generalized to FloatValue — generic vectors \(\mathbf{v} \in \mathbb{R}^n\) of arbitrary dimension. Update formulas moved out of C++ into Atomese arithmetic, making the value algebra programmable rather than hardcoded. In Hyperon, the PLN truth value algebra is implemented in MeTTa rather than baked into the storage layer.

The Space API

Hyperon abstracts AtomSpace behind the Space API — a universal interface that any backend can implement. Core operations:

  • match(pattern, space): Find all substitutions \(\sigma\) such that \(\sigma(\text{pattern})\) exists in the space.
  • add(atom, space) / remove(atom, space): Modify the space contents.
  • rewrite: Match a pattern and replace with a template under the computed substitution — the fundamental MeTTa evaluation step.

Multiple Space implementations coexist:

  • MORK-backed: High-performance in-RAM triemap for local reasoning
  • DAS-backed: Distributed storage across Redis/MongoDB clusters
  • Neural Spaces: DNNs wrapped as queryable AtomSpaces — matching returns approximate nearest neighbors in embedding space
  • Rholang AtomSpace: Capability-secured execution on ASI Chain for decentralized cognitive processes
  • In-memory (reference): Simple implementation in Hyperon Experimental for development and testing

MeTTa code is largely Space-independent — the same program can target different backends by naming different Spaces.