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.