Gellish Knowledge Management

Meta
1

Hi
first of all congratulations for this great active community.

I am working in a project where we have to document

  • process,
  • assets
    like hw, networks, services, systems, doc software libs. products sites.floors.rooms.racks
    down to source libaries and
  • organisiation with departments roles

And as you know everything is interconnected in a graph.
A great amount of effort goes into identifying and labeling things that different actors name differently but mean the same. So this very fast becomes a taxonomy and dictionary problem.
I believe the problem is actually a knowledge graph that is common to any company

So I started checking out this field of Taxonomies, Smart Dictionaries and Knowledge Management.

I stumbled over a very interesting idea. The idea is to have a database format that is universal. All information stored in one flat table that actually represents a graph that starts with the root node anything.

and comes with a “normed” world with IDs for a lot of things

Its pretty proprietary but the idea is impressive since it seems to be so flexible that you can even describe queries in this format.

It takes a while to dig through the meta meta bla bla on their website
but still I found the concept much more convincing than alternatives like rdf, owl or some xml-mof frameworks.

Gellish Concept reminds me of the homoiconic features of lisp.

Why am I writing this?

First org-roam is a graph that just links things.
Gellish is a way of linking with meaning.
Also as you saw allready when migrating to org-roam V2 the unique nameing problem on file level, topic level … will never stop until you have something like a gellish approach with IDs for things and their relations and a numberspace for your own things mapped.

Also we life in a time where we have graph databases and graph query languages like the cypher query language.

The only question I have is

  1. What do you thing of the gellish approach
  2. Do you think it might be worth trying to implement it in a versionable org plain text way.

A query interface could also implemented in lisp and query a sql database.
There exists a gelish browser that implemented something like this in python. however i didnt get the webversion to work.

Also downloading the excel files from the gellish download area give a understanding of the format.

2

@zentr1c

One of the most engaged posts of all time in this forum is about adding meaning to links in Org-roam. The thread itself has been dormant in this year for now, but I believe that many people are still interested in the topic. As far as I can see, the Gellish approach is one of many ways to add a meaning to links and does not look to be unique in design.

For implementation, I think it is do-able and worth the efforts if someone is keen to drive this.

Below is some rough ideas that I could come up with of what the implementation with Org-roam and Org Mode might look like. I’m pretty sure there are better ideas; my two cents only.

The data structure that Org-roam has implemented so far is pretty much in line with the Gellish approach. You can inspect the database schema by looking at variable org-roam-db--table-schemata; look at the table links. I’ll illustrate.

If you execute this query in Emacs…

    (org-roam-db-query [:select [source dest properties]
				:from links
				:where (= type "id")])

You will get something like this below. I have added a column heading to make it easier to read.

#+RESULTS:
|   SOURCE (ID)    |   DEST (ID)      | PROPERTIES             
| 2021-01-18T130000| 2021-01-27T165658| (:outline nil)|
| 2021-01-18T152100| 2021-01-27T173744| (:outline nil)|
| 2021-01-18T152100| 2021-01-27T154809| (:outline nil)|
| 2021-01-18T165223| 2021-01-25T203301| (:outline nil)|

As far as I can inspect, Org-roam at the moment uses PROPERTIES only for the information of the headline under which links are placed (:outline property). But it leaves the possibility to enrich data with different properties (it’s a property list).

… So to implement a way to add a meaning to links, the data structure is mostly ready. As a very rough sketch, the following elements would need to be added to Org-roam and Org Mode (as an extension, or part of the core):

  1. Extend Org Mode’s grammar for org-id
    [[id:uuid]] syntax does not have a way for users to add property to the link
  2. Add a function to extract a property from an ID link; insert it in the database
  3. Add a display feature for Org-roam to show (back)links with the new property / properties
  4. Add a way for users to add property to links in their note-taking workflow
1 Like