|
OpenCog Framework
Branch: master, revision 6f0b7fc776b08468cf1b74aa9db028f387b4f0c0
|
|
OpenCog Framework
Branch: master, revision 6f0b7fc776b08468cf1b74aa9db028f387b4f0c0
|
This library (opencog/atomspace) is the backbone of the project
This page is a high level overview of the library; to dig into the details read the comprehensive overview.
Dependencies:
The atom is a basic entity used in OpenCog as an element for building representations. Some atoms directly represent patterns in the world or mind, others are components of representations. There are two kinds of atoms: nodes and links. Atoms have Type and Arity, a Handle (see below), link to parent AtomTable and to a TruthValue (see below).
A relized atom is one that exists in RAM at a certain point in time. Atoms may be serialized for transmission from one software process to another, or for saving to disk using a BackingStore (an atom is called frozen when is present only on disk). The type of an atom cannot be changed after the atom has been inserted into the AtomSpace: OpenCog atoms are immutable.
Each Atom is an AttentionValueHolder, and, thus, has an AttentionValue that has three components: short term, long term and very long term importance. The attention is the process of focusing mental activity (actions) on some particular subset of a mind. Attention is the process of bringing content to consciousness. Guiding which aspects of the system's memory & functionality gets more computational resources at a certain point in time is the job of an AttentionBank associated with an AtomSpace.
See also:
A Node is an Atom with name (that may be empty string). It represents the most basic kind of pattern known to the OpenCog system. The name and the type of a Node together determine a unique key.
See also:
Nodes in OpenCog are connected to each other by links. Each Link embodies one of the basic inter-node relationships. They may describe relationships between more than two entities at once and may describe higher-order relationships between links, and between nodes and links.
A Link is uniquely defined by its type and its outgoing set, i.e., the set of Atoms linked by it. It also stores a Trail.
FollowLink provides methods for looking at the end of a link. The methods store the result inside (functor): follow_binary_link(), backtrack_binary_link(), follow_binary_link().
foreach_outgoing_handle() and foreach_incoming_handle() invoke the callback argument on each atom in the outgoing/incoming set of a handle. foreach_atom_pair() is typically useful for making comparisons between atoms. It invokes the callback on each pair of corresponding atoms in the two input vectors. Other usefull functions: foreach_binary_link(), foreach_reverse_binary_link(), foreach_link(), foreach_unordered_binary_link().
See also:
There are two main types of atoms, nodes and links, and atoms can have further sub-types, such as being directed or undirected links and representing specific types of relationships and entities. The Type of an atom is an unique identificator assigned by a ClassServer. This class keeps track of the complete atom class hierarchy. The current implementation is hardwired. Future versions may include different structures based on run-time type identification.
Atoms are uniquely identified by a Handle. Pointers to Atoms should never be kept in any data structure other than the AtomTable. All references to atoms should proceed through handles via the AtomSpace API.
A Handle stores an unique identifier. Lists are called HandleSeq and HandleSeqSeq. HandleMap ia a red-black tree where keys are Handle's and values are templated. It acts as an adapter to stl's HashMap. HandleSeqIndex associates a list of Handle's with one other Handle using standard AtomIndex interface. HandleSetIndex does the opposite. Lists of UnorderedHandleSet may be intersected.
There are several types of truth values that all inherit TruthValue:
Inheritants of TruthValue are invited to implement methods like: isDefaultTV, isNullTv, clone, merge, getMean, getCount, getConfidence, toFloat, toString, getType and various operators.
See also:
AtomTable class provides mechanisms to store atoms and keep indices for efficient lookups. It implements the local storage data structure of OpenCog. It contains methods to add and remove atoms, as well as to retrieve specific sets according to different criteria.
The atoms inside the table are indexed. OpenCog provides AtomIndex as a common interface to be used by indexes.
(note that <- symbol above simply means related somehow, not necesarly inherit)
See also:
The access to inner atom space is done either synchronously (via AtomSpace) or asynchronously (via AtomSpaceAsync).
The AtomSpace is an interface for the manipulation and storage of hypergraphs, and is the central knowledge representation system provided by the OpenCog Framework. The AtomSpace provides a generic interface for creating and deleting hypergraphs of Atom's (the superclass for Node's and Link's). Requests are ASRequest derivates; here is a comprehensive list of ASRequests.
An AttentionBank is associated with each atom space. Also, a TLB translates between handles and actual memory address for the atom in the local process address space. StatisticsMonitor collects several statistics values from many parts of the system and makes them available through its API.
See also:
To support ZeroMQ the library provides ZMQServer and ZMQClient, and uses ProtocolBufferSerializer together with protocol buffers to serialize/deserialize.
The class only supports one function - ZMQgetAtom - to request an atom from the server; ZMQClient::getAtom() will use it and will block waiting for a response.
See also:
| Previous | Next |
1.8.6 
