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.

→