Building a knowledge graph in Logseq →
#
>

Proposal for a knowledge graph plugin

→
#
>

Suggested Principles

→
#
>

Use the above queries to track relationships, and keep all the relationship data in the notes.

→
#
>

Be mainly a layer for surfacing, browsing, and querying the relationships that are built in the notes.

→
#
>

Keep the grammar non-restrictive and let users create relationships between any two notes by default. The plugin can still make it possible to create a more restrictive grammar as well, and you can see in this section how I suggest doing so: # How and when to add restrictive grammar

→
#
>

For one, a non-restrictive grammar allows users to not have to create prefix links in the front of every linked note like in Discourse Graph. This will be beneficial for use cases that want to connect a large volume of notes in their knowledge graph but don’t want to be restricted to a specific note naming system.

→
#
>

This also enables including blocks in the knowledge graph

→
#
>

This allows for more dynamic use of the knowledge graph with less “pre-planning”. This can have some downsides too, as it could create less clear ideas for what relationships mean if you’re using support to mean slightly different things in different contexts.

→
#
>

Downside, it would be harder to add inline CSS for links like Discourse Graph does

→
#
>

Implementation priorities

→
#
>

Make relationships visible on any page that has them.

→
#
>

From what I can tell plugins can’t integrate into pages yet, but I think ideally there would be a section above “Linked References” that shows “Relationships” and all the pages with relationships to this page grouped by relationship type (Supports ->, <- Supports, etc)

→
#
>

Create a query interface.

→
#
>

First basic single queries (all notes that support note x)

→
#
>

Supports chained queries

→
#
>

Return all blocks that support any blocks that have author)

→
#
>

Support AND and OR on pages (all notes that support block x OR block y)

→
#
>

Create a graph interface

→
#
>

See a visual graph of all the pages (and blocks) with their labeled connections

→
#
>

I believe this would be more valuable than the existing global graph

→
#
>

Option to change the syntax for identifying directionality

→
#
>

Users may not want to use ->

→
#
>

Users may prefer to use semantic complements like in Discourse Graph (supports and supported by)

→
#
>

This could be done by creating a special reserved relationship called complements, and allowing a user to create a complement as follows

→
#
> 
- [[supports]]
	- [[complements]] ->
    	- [[supported by]]
→
#
>

and now the plugin can treat the following two aspects as equivalent

→
#
> 
- [[some evidence]]
	- [[supports]] ->
    	- [[a claim]]
→
#
> 
- [[a claim]]
	- [[supported by]] ->
    	- [[some evidence]]
→
#
>

Allow for blocks to be part of the knowledge graph like pages

→
#
>

Requires updating the query

→
#
>

Requires figuring out how to handle when a block contains text and page references, both the block and the page references will be considered part of the relationship? Not sure.

→