Building a knowledge graph in Logseq →
#
>

How and when to add restrictive grammar

1
#
>

Keep all the information encoded in the notes

→
#
>

I suggest continuing to use the existing simple syntax convention for relationships to add any grammar. This feels more in line with the outliner DNA of Logseq, as it uses the block hierarchies to encode information, and keeps everything visible in the markdown (rather than in an extra layer of data that only exists within the plugin).

→
#
>

How a user could add their own types

→
#
>

Use the existing syntax and create a new relationship (calling them whatever they want, here I use type)

→
#
> 
- [[I looked up today and saw a blue sky]]
	- [[type]] ->
		- [[evidence]]
→
#
>

Side note, since any note can have a relationship, including relationships, you can create interesting layers…

→
#
> 
- [[empirical]]
	- <- [[type]]
		- [[evidence]]
        - [[experiment]]
→
#
>

and we can go all sorts of places…

→
#
> 
- [[type]]
	- [[type]] ->
		- [[relationship]]
→
#
>

A user might prefer to use a page-property here instead, since

→
#
>

Then to actually restrict relationships, the plugin could reserve a special relationship (e.g. grammar) for declaring the grammar of a relationship:

→
#
> 
- [[supports]]
	- [[grammar]] ->
    	- ([[type]] -> [[evidence]]) -> ([[type]] -> [[claim]])
→
#
>

This would be parsed by the plugin as:

→
#
>

“supports is a relationship from a block whose relationship type is evidence to a block whose relationship type is claim”

→
#
>

If desired, the plugin could also automatically add the required relationship when it is missing

→
#
>

There are a lot of tricky details to this, and certainly some plugin-side caching will be required eventually since the queries could get messy, so I’m happy to discuss more.

→
#
>

If preferred, the plugin could allow the user to provide Logseq page and block properties to create a grammar. This could still be done in the notes like so:

→
#
> 
- [[supports]]
	- [[grammar]] ->
    	- (tags:evidence) -> (tags:claim)
→
#
>

It’s possible there is never a need to actually enforce a restricted grammar inside of one’s personal knowledge graph. This is something to be considered.

→
#
>

When to restrict grammar

→
#
>

Provide more information when exporting one’s knowledge graph

→
#
>

In order to translate your knowledge graph to be integrated into someone else’s, the more detail around how your relationships work, the better.

→
#
>

By default, any block can have a relationship with any other block. But if more detail is added, then it will be easier to make sense of how the relationships in your knowledge graph match up with the relationships in my knowledge graph.

→
#
>

Future theoretical consideration: Ideally one would create a category out of their knowledge graph, and this way they a functor to translate their knowledge graph to another knowledge graph would be guaranteed to have proper composition and matched types.

→
#
>

See # Resources for more info

→
#
>

(Maybe) Guide the user if they’re trying to do something that isn’t supposed to work

→
#
>

if they’re trying to create a relationship they’ve declared as restrictive between unmatched block types, the plugin can warn them.

→
#
>

This can be tricky, so I would consider this a secondary priority

→