OpenCog

The OpenCog AtomSpace is an in-RAM knowledge representation (KR) database with an associated query engine and graph-re-writing system. It is a kind of in-RAM generalized hypergraph (metagraph) database. Metagraphs offer more efficient, more flexible and more powerful ways of representing graphs: a metagraph store is literally just-plain better than a graph store. On top of this, the Atomspace provides a large variety of advanced features not available anywhere else. There are several dozen modules built on top of the AtomSpace. Notable ones include: What it Isn't Newcomers often struggle with the AtomSpace, because they bring preconceived notions of what they think it should be, and its not that. So, a few things it is not. It's not JSON. So JSON is a perfectly good way of representing structured data. JSON records data as key:value pairs, arranged hierarchically, with braces, or as lists, with square brackets. The AtomSpace is similar, except that there are no keys! The AtomSpace still organizes data hierarchically, and provides lists, but all entries are anonymous, nameless. Why? There are performance (CPU and RAM usage) and other design benefits in not using explicit named keys in the data structure. You can still have named values; it is just that they are not required. There are several different ways of importing JSON data into the AtomSpace. If your mental model of "data" is JSON, then you will be confused by the AtomSpace. It's not SQL. It's also not noSQL . Databases from 50 years ago organized structured data into tables, where the key is the label of a column, and different values sit in different rows. This is more efficient than JSON, when you have many rows: you don't have to store the same key over and over again, for each row. Of course, tabular data is impractical if you have zillions of tables, each with only one or two rows. That's one reason why JSON was invented. The AtomSpace was designed to store unstructured data. You can still store structured data in it; there are several different ways of importing tabular data into the AtomSpace. If your mental model of "data" is structured data, then you will be confused by the AtomSpace. What is it, then? Most simply, the AtomSpace stores immutable, globally unique, typed s-expressions. The types can be thought of as being like object-oriented classes, and many (not all) Atom types do have a corresponding C++ class. Each s-expression is called "an Atom". Each Atom is globally unique: there is only one copy, ever, of any given s-expression (Atom). It's almost just that simple, with only one little twist: a (mutable) key-value database is attached to each Atom. Now, "ordinary" graph databases do this too: every vertex or edge can have "attributes" on it. The AtomSpace allows these attributes to be dynamic: to change in time or to "flow". The flow itself is described by a graph; thus, graphs can be thought of as "plumbing"; whereas the Values are like the "fluid" in these pipes. This is much like the distinction between "software" and "data": software describes algos, data is what moves through them. In the AtomSpace, the algos are explicit graphs. The Values are the data. The "special extra twist" of immutable graphs decorated with mutable values resembles a corresponding idea in logic: the split between logical statements, and the truth values (valuations) attached to them. This is useful not only for logic, but also for specifying data processing pipelines: the graph specifies the pipeline; the values are what flow through that pipeline. The graph is the "code"; the values are the data that the code acts on. All this means that the AtomSpace is different and unusual. It might be a bit outside of the comfort zone for most programmers. It doesn't have API's that are instantly recognizable to users of these other systems. There is a challenging learning curve involved. We're sorry about that: if you have ideas for better API's that would allow the AtomSpace to