# OpenCogPrime:AtomFormalization

## A Formalization of the Atom Concept

This page presents one among many possible mathematical formalizations of the Atom concept as used in OCP. Furthermore it's not presented in a totally mathematically rigorous style. However it's presented here in case it may provide someone with useful clarification of the concept.

### Spaces

In abstract discussions on this page and others, we'll often use the word *space* in a generic sense. All *spaces* mentioned here are finite in any particular example system; the reader, if not inclined toward a finitist philosophy of mathematics, may consider them as countably infinite.

Sometimes in defining spaces we will use the Union_k operator, which should be understood as shorthand for k=0,1,2,, K for some relevant large K (sometimes the K is specified, sometimes not).

Finally, we will often have need here to refer to function spaces. Where A and B are two spaces, we will use the notation [ A → B ] to denote the space of functions mapping A into B. This notation may be nested, e.g. [[A → B] → C ] denotes the space of functions that map *functions mapping A into B* into C.

### Weighted, Labeled Hypergraphs

In this section we introduce the formalism of weighted, labeled hypergraphs on which both OCP and SMEPH are based. The *hypergraph* concept in mathematics is a fairly broad one — generically the term is used to refer to graphs (of the node-and-link kind, not the curve-in-a-space kind) in which edges may join multiple vertices (Bollobas, 1998). The weighted, labeled hypergraphs we use here have some peculiarities, which we'll describe here, but they do fit within the general purvey of mathematical hypergraph theory.

Our formalization begins with the concept of an Atom. Atoms are the basic entities of which a hypergraph is composed. Both edges and vertices are to be considered as particular types of Atoms.

Atoms are *weighted*, which means formally that they are objects that are associated with sub-objects called Values, where we define a Value as a finite structure that is either a basic value object, or an ordered list of Values. The basic value objects we're working with at the moment are characters, integers and floating-point numbers. There are different types of Values, exemplified by TruthValue and AttentionValue, the two Value types that all Atoms mandatorily contain.

Each Value type comes along with a *get* mapping that maps each Atom into the Value of that type that it contains; these *get* mappings are called Valuators and live in the space

Valuator = [Atom → Val]

So for instance the Valuator called GetTruthValue is defined by

GetTruthValue (A) = A.TruthValue

The next basic concept we need to introduce is that of a tuple. Tuples may be ordered or unordered. The space of Atoms may be partitioned into two initial categories: Atoms that are tuples, and Atoms that are not. As noted above, in a SMEPH *derived hypergraph,* the Atoms that are tuples we will call Edges, and the other ones we will call Vertices. On the other hand, in OCP's concrete knowledge representation, we will refer to Links and Nodes instead.

As noted above, in the particular case of the hypergraph explicitly used for knowledge representation in OCP, we will shift to the alternate terminology (Node, Link) instead of (Edge, Vertex). We will retain the latter generic terms when discussing the *derived hypergraphs* associated with a complex system such as OCP.

Summing up so far, we have defined the spaces:

- Atom — the space of all Atoms
- Vertex — the space of all Vertices
- Edge — the space of all Edges
- Atom = Edge Vertex
- Unordered-Edge = Union_k (the set of unordered k-tuples of elements of Atom)
- Ordered-Edge = Union_k (the set of ordered k-tuples of elements of Atom)
- Edge = (Ordered-Edge Union (Unordered-Edge)

We have mentioned TruthValue and AttentionValue objects. These are described by defining valuator functions:

Truth-Valuator = [ Atom → Truth-Value ] Attention-Valuator = [ Atom → Attention-Value ]

Furthermore, we will burden our Atoms with additional values.

Firstly, each atom has a type,

Atom-Type = the space of atom types Atom-Type = Node-TypeUnionEdge-Type

Pragmatically, the atom type values we use in OCP are invariably strings, i.e. lists of characters.

Atom types are used in each particular OCP by the definition of particular associated valuator functions:

Type-Valuator = [ Atom → Atom-Type ]

Atom-Type = Vertex-Type ∪ Edge-Type

Many of OCP's dynamics are Vertex and Edge type dependent.

In the Introduction we have given a detailed list of the actual Node and Link types used in a real OCP. For now, we will stay a bit more abstract, and look at the general sorts of things we will need to do with Nodes and Links.

In addition to the Type, TruthValue and AttentionValue valuators defined above, there are also valuators associated with particular Vertex types, such as:

Boolean-Valuator = [ BooleanNode → Boolean ] Number-Valuator = [ NumberNode → Number ] Character-Valuator = [ CharacterNode → Character ] Time-Valuator = [ Atom → Time] Schema-Valuator = [ Atom → Schema] Predicate-Valuator = [ Atom → Predicate]

The spaces of Schema and Predicates will be defined a little later.

It may be worth reiterating how our notation works, in the definition of these abstract spaces of valuators. The idea is that, e.g., Schema-Valuator stands for the class of all possible mappings from sets of Atoms into Schema. Each particular OCP instance, at each point in time, is then associated with a specific SchemaValue encapsulating a mapping that takes Atoms into Schema (this mapping lies in the space called Schema-Valuator). This mapping is not defined on all Atoms on the system; it is only defined on SchemaNodes, they are its domain.