(October 2025)
This project is a broad-based exploration of structural learning. It has been fashionable to call this "neuro-symbolic learning". An earlier incarnation of this project called it "Natural Language Learning." The vision and goals have broadened: the goal is to learn any kind of structure that can appear in nature, in the noosphere. The relationships between things, in full abstraction.
This is possible in part because the first version, confined to natural language, was more-or-less a success. Not a roaring success like deep learning; there was no chatbot that held the sum-knowledge of all things that you could converse with. But it did show that you could use a frequentist approach of "counting things" to obtain vector representations that were comparable to early NN models, such as Word2Vec or Glove. Comparable in what way? Well, all the party tricks you could play with those could be done here as well. The representation here, though, is radically different: it is graphs. Symbolic graphs. Hypergraphs. Structures that have explicit interpretations as symbols and relations. That can be crawled over. That can be queried, using an explicit query language. And yet, at the same time, can also be understood as a collection of very high-dimensional vector spaces (and not just one, but many!) layered on top of these graphs. Or intertwined with these graphs; take your pick.
The Version One code is in the version-one directory. It is mostly frozen in amber, now. The multiple README files there talk about language learning and structure learning in a very explicit fashion. However, rather than migrating them to fit the times, it seems easier to start over; so here we are: Version Two.
The underlying technologies are these. The representational system is called Atomese. This is a hypergraph representation system where both the symbols and relations as well as the query language, are on equal footing: they're all (hyper-)graphs. These graphs are not just passive representations, but are also active: most graphs can be executed, and perform some action when executed. Thus, it vaguely resembles a programming language. But, unlike a programming language, it is also a graph. Imagine, if you wish, a function with inputs and outputs, but now we have those inputs and outputs connected with graph edges, going to wherever they are connected. So, a large collection of Abstract Syntax Trees (AST). Not just low-level graphs representing (Plus 2 2) but also high level graphs, like (Rewrite (A (Variable X) B) (D B A (Variable X))) Think, perhaps regex-as-a-graph, or perhaps SQL-as-a-graph, but far more powerful and sophisticated than SQL. But also, not all graphs have to be executable: words and sentences aren't, for example. More typically, vectors are attached to words and sentences. But you can also attach vectors to AST's and to rewrite rules and to queries... Its a generic symbolic representation system that is interlayered with vectors and weights.
If it helps, then think, maybe, Ising model but on a network graph, not a grid. With many states, not just up/down. With many interactions, not just one. And fluid, liquid, changing. Or perhaps you'd be happier visualizing an electronic circuit, with current flowing through it. Or perhaps a petroleum refinery: pipes everywhere, with stuff happening in them. These are all valid abstractions that give some insight into the intended interpretation. They're all symbolic graphical networks with stuff that flows and transforms.
Version one had multiple serious problems. The worst was perhaps that it was a batch processing system. A text corpus is downloaded from somewhere (Project Gutenberg, Wikipedia), shoved through a pipeline, sliced and diced, with the AtomSpace accumulating the results. The experience of running this was like doing laundry: lots of work interleaved with lots of waiting and the occasional emergency when you put in too much soap and the washing machine is spilling out onto the floor. Batch processing is not fun.
This prompted exploration of a more autonomous design; the processing would be done by agents, each having considerable independence and decision-making authority. This required a sensori-motor subsystem, so that the agents could grab and manipulate data, work with it, move and read and copy. The current alpha (version-0.5) sensorimotor Atomese is located in the sensory git repo.
Together with basic work on a sensori-motor system is work on a
stream processing system. Prototypical parts are the
FilterLink and the
RuleLink.
There are an assortment of example demos that can be found in the
AtomSpace examples directory
and also, for example, the
parse-pipeline
demo in the sensory project. These demos are alarmingly complicated!!
No joke, this is not for the faint of heart. A few words on stream
processing are due. Of course, this is an ancient idea: Apache Flink,
Apache Storm, RabbitMQ Streams, and on and on. These are popular and
production-ready. The Atomese streams are the exact opposite of that.
Why? The Atomese streams are an attempt to create a graph programming
system for data processing. Why? you might ask. Why not just use Java
or Python? Answer: Java and Python aren't graphs. You can't run a query
on them, except perhaps with grep and find and sed and awk.
Poor-mans tools. You certainly can't slap a 1024-dimensional
floating-point weight vector onto the 3rd variable on the 42nd line
of foobar.py. You can ask your LLM to do that, but its not the same
thing. Thus, Atomese streams are written in ... Atomese. For these
reasons. Its a bit brutish and nasty, at the moment, but this is a
science research project, not a software engineering project.
Object-Oriented Programming. Don't laugh. Version One used the matrix tensor processing library. This became quite large, sophisticated and very well debugged. Its a jewel of what you'd want for matrix and tensor analysis, wrapped in a pretty polymorphic object oriented API. So ... what's the problem? Well, its written in an ordinary human-readable programming language. Guile scheme, as it happens, but it could have been Python or Gnu R. Same complaint: it's not written in Atomese. And this turns out to be a huge burden and bottleneck for stream processing and sensori-motor interfaces.
Why was it written in scheme, you say, and not in Atomese from the beginning? Well, because, it so happens, we could not figure out how to have OO interfaces in Atomese until very recently. It was simply just plain not clear, not obvious. After a decade of attempts and false starts, it was just ... opaque. But now there is an experimental OO interface, which just happens to look almost identical to the sensori-motor interface. As such, it looks like it will be capable of manipulating and controlling GPU's, for example, but also not just concrete devices, but also abstract things: controlling tensors and vectors, combining them and rewiring them and re-jiggering any which way. A motor system that controls not just devices, but controls algorithms. Not just controls algorithms, but writes them too. Well, sure ChatGPT and Microsoft CoPilot and Claude can all write algorithms too, but, err, how should I say it ... that's not the point. See above. And see below.
Work on Version Two has barely begun: this README, and the README in the stream directory are almost the only public content.
I (now speaking personally, "I" am Linas Vepstas) anticipate that most of the Version Two code will be written by Anthropic Claude. I will keep it on a short leash, but I expect some fair amount of LLM slop. I'll try to control it, as best as my patience allows. There will be scaffolding, cruft and broken-ness interwoven with a reasonable architecture and fairly clear design goals. This code will be confined to the stream directory, to avoid polluting some of the currently functioning systems.
The proximal motivation for this is an attempt to endow Claude, or any LLM, with "offline" memory (long-term memory) and reasoning skills that operate outside of the LLM itself, not on the cloud, but locally, acting to direct and steer and enhance the capabilities of the LLM, acting as some sort of meta-control layer, some harness or reins or bridle, or perhaps a prefrontal cortex. Pick your analogy. The project is perhaps foolish, or perhaps interesting; at any rate, it is an attempt to interface a rather sophisticated LLM to a rather meagre symbolic system. Is it doomed to fail? Well, straight out of the gate, its clear that Claude's ADHD and utter inability to remember anything unless it is jammed into some prompt, and even then, its utter unwillingness to RTFM whether written by itself, or anyone else, well this is all a fine challenge. I'm up for fine challenges.
More will be posted when there's more to post.
The End.