Building a knowledge graph in Logseq →

How and when to add restrictive grammar

 →
#
>

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

→