Noodle - Knowledge Base

Noodle is my take on something like a super-ultra-mega-meta-mind-map. Basically, it’s a variation on applications like Obsidian and LoqSeq. These are note-taking apps that allow the user to form links between their ideas. The principle difference in noodle is that the focus is shifted off of the markdown notes and onto the associations in the knowledge base. Noodle associates the files of a working directory in a multiplex graph and features powerful functions for manipulating the structure of the knowledge base.

My initial implementation of noodle is a linux command line tool written in C++. Here’s a quick look.

… What Am I Looking At?

The demo above shows me opening up a knowledge base. The interface indicates the working directory, a list of labels, and the active layers. Each listed label is a node, or “doodle”. When I switch to the tree view, the left most doodle has an arrow pointing at it from the left. The other doodles are shifted to the right depending on how many hops away they are in the multiplex graph. This gives the user some indication of how the doodles are connected.

Noodly Thoughts

Rather than dealing with markdown files, in noodle you deal with labels called “doodles” and the way they are connected. Many doodles correspond to a file in the working directory. But they may also be abstract and exist exclusively in noodle. Abstract doodles are indicated with square brackets.

Because noodle is all about manipulating connections, the user has to be able to think about how a set of doodles ought to be connected. Rather than having to try to figure it all out at once, a multiplex graph allows the same set of doodles to be associated in more than one way simultaneously. You can think of each layer of the multiplex graph as a way of associating the doodles. Each layer is a graph. Any doodle can be linked on any layer.

Lots of terminology here. Let’s look at an example.

Multiplex Linking Example

To show why you might want a multiplex graph, I’ll be comparing a knowledge base in Obsidian and its equivalent in noodle.

Here I’ve put together an Obsidian vault for defining the functionality I want out of my computers. And another for what specific technologies I’m using.

Desired Functionality:

Devices:

I could put all this information in one vault and give the two graphs different colours. But going further becomes combersome. For example, I could add connections between technologies and the functionality requirements they fulfill. But what if I also wanted to use a particular technology, say browser, in another setup? Or what if I wanted to link the concept of a browser to some other cloud of ideas about personal computing or IT security? How do I create a different combination of apps and hardware to fulfill the functionality requirements to see if I want to switch over? How would I use links to describe upgrade paths between the setup I have now and some desired ideal?

Here’s what it looks like if I link devices and functionality and try to add new device configurations which partially include some of the technologies I’ve already used in my previous configuration.

One Vault:

Yellow = Functionality, Blue = Devices, Red = New Configurations

You don’t get to look at the new configurations in a nice grouping. Many of the blue nodes actually also belong to the red configuration. But they can’t be two colours at once. Now imagine many more links for upgrade paths, security analysis, alternative functionality requirements etc. The nodes simply have a bunch of links with all sorts of different meanings. The purpose for any one link becomes lost. You might try more colours, complex tagging schemes, or consider new nodes for grouping configurations together. More likely you’ll wish you had duplicate nodes for different purposes. You might be tempted to create a new vault with a similar set of nodes. But now you have redundancy in your file system. You could create a filesystem link. But now you have more than one type of link, at least one of which you can’t work with from within the app / UI context. By the way more than one type of link — is a multiplex graph. Noodle makes this all very simple. Just create a layer for each new purpose as it comes up.

Of course creating explicit coherence in the links is not the purpose of Obsidian. In Obsidian, the graph structure is meant to be emergent rather than intentional. But that’s why we have noodle.

Another advantage of noodle beyond the multiplex linking is the ability to create links between any kind of file. In Obsidian you can link images and such from a markdown file. But noodle let’s you make that link between two binaries or an image and a spreadsheet, a script and a torrent file, a video and an FBX — anything.

In this computer setup example I’m basically using noodle layers as subgraphs. I think there are many more use-cases for noodle I haven’t thought of yet because noodle is actually more than a simple multiplex graph.

Going Deeper

The power of noodle comes from its conceptual uniformity and resulting flexibility as a medium for expressing ideas. What I mean by conceptual uniformity is that entities in noodle exist at the same level. The doodle labels, files in the working directory, and layers in the multiplex graph are all really the same kind of thing from noodle’s point of view. All of them can and do play eachother’s roles so-to-speak.

In noodle, each layer is actually also a doodle. You can think of each layer as having a corresponding doodle. The [base] and [meta] layers are present by default. You’ll see them as doodles on the [meta] layer which loads in when opening the commandline tool. The [meta] layer contains all the doodles which are also layers (meta-doodles). [meta] is itself a layer so [meta] contains itself on its layer. Such so-called meta-doodles can be instanciated in the file system as a file at which point they stop being abstract. Just as any doodle they can be linked to other doodles on any layer, again, even within their own layer. Conversely, you can generate a layer based on an existing doodle and make links between any doodles there. So doodles can be files and/or layers. Layers are doodles, but can also be a file. Files are always doodles.

Let’s run through that again in summary.

Noodle is a multiplex graph over a file system. A doodle is conceptually also a layer in the multiplex graph and may or may not correspond to an actual file. This lets you represent recursive self-referential concepts, deliniate subgraphs, represent alternative perspectives, or the same concept at different levels of detail, all in a uniform medium with minimal redundancy.

I believe noodle is particularly useful in contexts where concepts have a certain degree of transience or where conceptual flexibility is needed. For instance, when you’re trying to understand something with no reference material, when brainstorming designs, or thinking of new ways to organize established ideas. Once the thoughts are sufficiently structured, it probably makes sense to convert them into a more constrained format which is likely to be more efficient to compute with.

The Philosophy of Noodle

The inspiration for noodle comes from a thought that occured to me while considering topics in metaphysics. The idea was something like a structuralist ontology. If the world were made of a set of indifferentiable entities, where might the structure of reality emerge from? The idea is that the entities that make up reality are only differentiable in the sense that their relative “perspectives” on the rest of reality are different. The roles of the entities in the structure of things is different, nothing about them inherently. The way they associate to the rest of existence is what defines them as themselves. I started doodling graphs and coming up with ways of collapsing their symmetries until I ended up with asymmetric graphs where no two nodes had the same “perspective” on the rest of the structure.

On the one hand noodle was motivated by this attempt to represent reality canonically. On the other hand I was confronted with difficulties around expressing different accounts of reality, agency, and truth. Different perspectives leads to a lot of repetition which might be fine for presenting information to someone coming to it for the first time, but not as a conceptual map. It’s also hard to settle on primitives for certain philosophical concepts, some kind of ground to stand on. You end up in loopy thoughts. For instance when you’re thinking about the nature of axioms, or mechanisms of epistemology where an agent is embedded in the very reality it tries to understand. It seamed that something like noodle could neatly express partially formulated ideas, reduce redundancy, and work with this loopiness rather than be at odds with it.

Give It a Try!

Note: As a rule, don’t run random binaries given by strangers on the internet. This is for the daring, the trusting, the foolish, and those who know what a container or hypervisor is.

1. You can download the linux amd64 build here.
2. Put it in a $PATH directory so you can run it anywhere. For instance:

mv ~/Downloads/noodle ~/.local/bin/

Don’t forget to make it executable.

chmod +x ~/.local/bin/noodle

3. Create a working directory. You can paste in a bunch of files from an existing knowledge base or create some new ones from scratch.

mkdir /path/to/your/working/directory

4. Run noodle init in your chosen working directory.

cd /path/to/your/working/directory && noodle init

5. Then run noodle to use the interactive interface.

noodle

Use one of the methods on my contact page to let me know how it went! Bug reports, feature requests, and opinions are appreciated. If you did everything right your shell should be looking something like this.

dannycarey@linux-os:~$ mv ~/Downloads/noodle ~/.local/bin/
dannycarey@linux-os:~$ chmod +x ~/.local/bin/noodle
dannycarey@linux-os:~$ mkdir TOOdLe/ && cd TOOdLe/
dannycarey@linux-os:~/TOOdLe$ noodle init
Initialized.
dannycarey@linux-os:~/TOOdLe$ noodle
------- N O O D L E -------
Copyright (C) 2023 Francisco J. Garcia-Gonzalez
https://franciscogg.site/contact/
             
Refreshed.
Enter 'help' for more information.

/home/dannycarey/TOOdLe
   [base]
   [origin]
   [meta]
layermask: **meta** ...
<noodle> _

Project Notes

Tooling

I started the project using VisualStudio building for Windows for no other reason than that’s what I knew at the time. Since I switched to Linux on my personal machines some time after starting the project I ended up making a commandline tool with CMake and GDB. I’ll likely talk about my big computer-setup-migration in a future post.

Managing Scope

The most significant challenge with this project was actually defining it. I knew from the start that I needed something for organizing ideas and that I wanted something that could let me work with graphs, given the philosophical motivations for the project. The original vision was something much closer to MS OneNote in terms of the interface. I wanted EMR pen input to create ink strokes much like in the windows ink API. Those would then be saved as SVG files to represent individual “doodles”. Doodles would then be atomized or grouped together as needed and associated in the knowledge base which I called “noodle”. I also wanted intuitive, physics-based manipulations in the editor. All this quickly became a mission to implement a rendering loop with OpenGL and creating an event system to handle user inputs. Although the interface I was picturing would likely be a lot of fun to use, I realized the core concept of the project is really the multiplex graph as a medium for representing ideas. I deferred the fancy bells and whistles and focused in on the data structure.

Point of Attack

Once I identified the core of the project I had to decide what level I wanted to implement it at. I originally conceptualized noodle to be a canonical representation of information. If I had thought of a way to implement it in hardware, I might have tried it. But instead I considered implementing the project as a new kind of filesystem altogether, then as a service other programs would dynamically interact with. Finally I settled on noodle as metadata in an existing filesystem.

Although tackling a problem at a lower level gives you more control, it’s better to find the quickest path to the functionality you’re looking for by leveraging existing technologies. This might mean compromising on an idealised version of the project. But at least you’ll have a version of it. And you can always make improvements later.

Software Design

When I first designed the multiplex graph I implemented it as a node pool which I used to dynamically build adjacency lists. I realized that although memory usage was extremely efficient, the algorithmic execution was slow which could become a problem with larger knowledge bases. Now the multiplex graph uses C++ unordered maps from the standard library. I have yet to stress test it.

What’s Next?

I’ll definitely be adding and removing features as I use noodle based on what I find useful and fixing problems as they pop up. The UI needs some streamlining and the only way to find out what works best is by using it.

If I can find the time, I’d like a nice interactive visualizer for the multiplex graph. Something like Obsidian’s graph view with simple physics and vector graphics. Touch, mouse, or even EMR pen input would help with making selections. Although I still think I’ll need some way to input commands, the minimal visual feedback of the commandline interface is a sore spot.

A tool to import Obsidian vaults into noodle. Shouldn’t be hard to make, just have to parse the markdown files and create connections on a new_obsidian_import layer.

A tool to export/import a noodle layer to a graphml file. This would be useful for post-processing a noodle with python scripts.