Winko Erades

It started with my daughter going to university this year.

Like every student, she suddenly had a lot of information coming her way. Lectures, tutorials, books, articles, presentations, assignments, and conversations. One subject refers to another subject, an author refers to another author, a theory builds on an earlier theory, and something mentioned briefly in a lecture suddenly turns out to be important three weeks later.

Watching this happen made me think about the way we humans learn.

We are given information mostly in a linear form.

A lecture has a beginning and an end. A book has chapters. An article has paragraphs. Notes usually become pages in a notebook or documents in a folder.

But knowledge itself isn’t really linear.

One concept is related to another concept. A researcher developed a theory. That theory influenced another researcher. An event happened at a certain place. An argument contradicts another argument. A course covers several subjects, and those subjects connect to things you have already learned somewhere else.

The more you learn, the more these connections matter.

And that gave me an idea.

What if you could see the connections?

I was raised working with mind maps, visual representations of things I learned, so I have many of them on different subjects. So I started wondering what it would look like if, instead of only writing notes or mind maps underneath or next to each other, you could also describe the relationships between the things you learn.

Something simple like:

Edward Hall
    |
    +-- ASSOCIATED_WITH --> High-context communication
    |
    +-- WORKED_WITH ------> Navajo and Hopi tribes

Or:

Culture
    |
    +-- INFLUENCES -------> Communication
    +-- SHAPED_BY --------> Lived experiences
    +-- IS_SHARED_BY -----> Groups of people

Suddenly you are not only storing facts.

You are building a map of what you know.

This is, of course, not a new concept. Knowledge graphs have been around for quite some time. There are very powerful graph databases and graph visualisation tools available.

But that was also where I ran into the next question…

Why should somebody who simply wants to organise knowledge have to install and maintain a database?

I wanted something simpler

I wasn’t looking for an enterprise graph platform.

I wanted something closer to a document editor.

Open a file.

Look at the knowledge.

Add something.

Change something.

Create a relationship.

Save the file.

Send it to somebody else.

Done.

No database server. No account. No cloud environment. No query language required just to get started.

The graph itself should simply be the document.

So I started building a small Knowledge Graph Viewer.

The data format was deliberately simple. A relationship is described with five fields:

{
  "head": "Culture",
  "head_type": "Concept",
  "relation": "INFLUENCES",
  "tail": "Communication",
  "tail_type": "Concept"
}

That is almost readable without knowing anything about knowledge graphs.

Culture, which is a Concept, INFLUENCES Communication, which is also a Concept.

A collection of those statements becomes a graph.

From viewer to editor

The first version was just that: a viewer.

You could load a JSON file, see the nodes and relationships, and navigate through them.

But once you can see a graph, the obvious next question is:

Why can’t I edit it?

So the viewer gradually became an editor.

Nodes can now be created, changed, and deleted.

Relationships can be created, changed, and deleted.

Node types and relationship types can be managed.

You can click directly on a node to edit it, click a relationship to edit that, or create a relationship visually between two nodes.

There is undo and redo.

There is validation.

There are warnings for things such as duplicate relationships, isolated nodes, and unused relation types.

And because I still wanted the original format to stay simple, there are now two different concepts.

Save Project stores everything needed to continue editing, including things such as node positions and editor information.

Export Viewer JSON produces the simple five-field format again.

That separation turned out to be important.

The project file is for working.

The Viewer JSON is for sharing the knowledge.

Knowledge graphs that work like documents

While working on it, I slowly realised that this was probably the most important idea behind the project.

I don’t want to build another graph database.

There are already excellent graph databases.

I don’t want to build another general-purpose diagram editor either.

There are excellent tools for that too.

What interests me is the space in between.

A knowledge graph editor that creates, inspects, validates, and shares structured knowledge visually, like a document editor, without a database.

That means the workflow should feel familiar:

Open
  ↓
Read
  ↓
Edit
  ↓
Validate
  ↓
Save
  ↓
Share

The application itself is also deliberately simple.

It is one HTML file.

You can open it in a browser.

It works locally.

The knowledge doesn’t have to be uploaded somewhere first.

That also means it works perfectly well on Linux, Windows, or macOS as long as there is a modern browser available.

Validation became more important than I expected

While building the editor, I discovered something else.

Creating a graph is easy.

Creating a good graph is harder.

For example, you can easily end up with:

Person
person
Persons

as three different node types.

Or:

Geert Hofstede
Hofstede
Hofsteed

as three different nodes while they may actually refer to the same person.

You can create the same relationship twice.

You can create a node and forget to connect it to anything.

You can define a relationship type and never use it.

A database will happily store most of this.

But storing something isn’t the same as having good structured knowledge.

So validation became an increasingly important part of the editor.

The editor now tries to point out these kinds of structural problems before you share the graph.

I think this could eventually become one of the more interesting parts of the project.

Not only:

Here is your graph.

But also:

Here are some things in your graph you may want to look at.

The graph as a learning tool

Coming back to where this started, I think this way of representing information could be useful while learning.

Imagine following a course for several months.

After each lecture, you add the concepts that seem important.

While reading an article, you add the authors, theories, and arguments.

While reading a book, you connect new concepts to things you already know.

Over time, instead of having twenty disconnected documents, you get something that starts to resemble a map of the subject.

You may even start seeing connections that weren’t obvious when you first encountered the information.

And perhaps that is one of the interesting things about knowledge graphs.

They don’t necessarily contain more information than your notes.

They represent the information differently.

The relationships become visible.

And then I did what I usually do

At some point I had a working tool.

So naturally I started changing it.

Then improving it.

Then finding another thing that could be better.

Then breaking something that worked perfectly well before.

Then fixing that.

Then adding validation.

Then adding project files.

Then adding SVG export (you know me ;-).

Then adding context menus.

And eventually I thought:

Perhaps this is useful to somebody other than me.

So I decided to turn it into an open-source project.

The intention is to keep the basic principles intact:

• the graph should remain understandable;
• the data should remain portable;
• you shouldn’t need a database to use it;
• it should work offline;
• the application should remain easy to share;
• and the simple JSON format should stay simple.

There are many things that could still be added.

Properties on nodes and relationships.

Sources and provenance.

Graph comparison.

Duplicate detection and merging.

Different layouts.

Better support for larger graphs.

Import and export formats such as GraphML and CSV.

But I don’t want the project to become complicated simply because it can.

The interesting challenge will be adding capability without losing the simplicity that made me start building it in the first place.

From learning to structured knowledge

What started with watching my daughter learn new things at university turned into a question about how we store knowledge.

And that question turned into a small piece of software.

That happens quite often with projects like this.

You notice something.

You start wondering.

You build a small experiment.

And then the experiment starts asking new questions.

For now, the idea is simple:

Knowledge graphs that work like documents.

Create structured knowledge visually.

See how things are connected.

Validate what you have created.

Save it locally.

And share it without requiring the person on the other side to first install a graph database.

Let’s see where it goes.

---

Knowledge Graph Editor is open source and available on GitHub.

https://github.com/WinkoErades/knowledge-graph-editor

The editor runs locally in a modern browser and does not require a database or installation.