Building a knowledge graph in Logseq →
#
>

More notes

→
#
>

Relationships as functions

→
#
>

I think of these relationships as functions, and that will inform how some of you who know about functional programming may see where I’m coming from.

→
#
>

I also think about this knowledge graph as eventually being a category, but that’s beyond the scope of this spec.

→
#
>

Many to many

→
#
>

Relationships support one to one and one to many using the native block hierarchies (parent to child or parent to many children)

→
#
>

Could extend this by letting users put a list in the parent block like so

→
#
> 
- [[some evidence 1]], [[some evidence 2]], [[some evidence 3]]
	- [[supports]] ->
    	- [[claim A]]
        - [[claim B]]
→
#
>

Plugin practicality

→
#
>

Some of these proposals might be impractical for a plugin to implement, as I’ve approached most of this thinking from a theoretical side more than a software practical side. However, assuming the queries can be made reasonably fast (either in place or through caching), I don’t think anything here is unfeasible.

→
#
>

Relationships vs properties

→
#
>

This has some similarities to the already richly supported properties in Logseq. I would suggest that making it possible to create rich relationships in line in one’s writing makes a huge difference (when I tried to use properties to do this, I ended up writing a lot of my notes in the properties, making my notes look more like a database table than an outliner or writing tool). I’m happy to discuss this more as I think the difference between this proposed functionality and properties is a subtle but important one.

→
#
>

This difference will be even more important if relationships are also supported between blocks and not just pages

→
#
>

World Knowledge Graph

1
#
>

I’m not sure how Logseq is planning to build their stated World Knowledge Graph, but this seems like a reasonable way to begin letting users add structure to their personal knowledge graphs that could eventually be integrated with other knowledge graphs.

→
#
>

If this were to become central to Logseq’s direction, it would make sense to store these relationships in the Logseq database. That would solve any latency concerns and create a very strong foundation for building tools to interface with your knowledge graph.

→