Logseq Functional Notes Plugin


Syntax and Queries

Any of the following syntaxes to describe an aspect are usable

- [[evidence]]
    - [[supports]] ->
        - [[claim]]

id:: 982d69f8-96fc-4b31-a6b5-9fae1ff8acaf

- [[claim]]
    - <- [[supports]]
        - [[evidence]]

Need these queries for when the syntax is on the page directly (not via page reference)

Let’s try building these queries

query-table:: false
:title [“supports ->”]
:query [
:find ?result-page
:in $ ?current-page ?function
[?page :block/name ?current-page]
[?referring-blocks :block/refs ?page]
[?child :block/parent ?referring-blocks]
[?child :block/refs ?child-refs]
[?grandchild :block/parent ?child]
[?child :block/content ?child-content]
[(clojure.string/includes? ?child-content “->”)]
(page-ref ?child ?function)

        [?grandchild :block/refs ?grandchild-page]
        [?grandchild-page :block/name ?result-page]

:inputs [:current-page, “relationship/supports”]
:view (fn [result]
(for [page result]
[:a {:href (str “#/page/” page)} (clojure.string/capitalize page)])])}



strict vs not strict

does the following syntax work

- this is pretty interesting: [[evidence]]
	- [[supports]] ->
    	- [[claim]] idk.. 

Support blocks that aren’t links to pages

how to support AND and OR (products and coproducts) of pages?

Initial write up

Function Pages

Any page that ends with a ->

I choose to also start my function pages with a ->, but that’s a personal choice to make it easy to find all my function pages

When created, will automatically create a page property:

This should make it easy to filter out function pages

Can have a special css for function pages when they are displayed inline

Function Pages Second Option

Any page can be a function

Just add -> after the link to use that link as a description of the edge

[[supports]]  -> [[claim a]]

What do function pages do?

Filter results based on whether it is connected via a specific relationship

if supported by -> Deniz Aydemir, then Deniz Aydemir will show up when searching by relationship supported by ->

Why not use page or block properties?

I wanted to use properties more…

supported-by: [[Observation 1]]
creator: [[Deniz Aydemir]]
equals: [[My Note Taking System]]
certainty: [[Medium]]

This provides a quality “typed” connection where I can filter by supported-by or see a list of all the creator fields I have across all pages

The problem is that these meaningful connections I want to make are not really metadata, they are actually the content of the notes themselves.

If I’m saying “observation 1 supports claim a”, that’s not really metadata. That’s exactly the kind of content that should be in the content of the notes.

I want to add structure to common types of relationships even when they are made on the fly in the content of a note.

The more I put information into block or page properties, the more it felt like I wasn’t really using the note linking in the meaningful “inline” kind of way that feels more natural in a tool like Logseq

Properties are tied to the first block of a page, or the parent block itself. I wanted a way to create meaningful connections anywhere inside a page, in a child block, or even under a reference to a block.

By allowing for this, you can decide to add

Why the arrow syntax?

Differentiating from page and block properties.


Don’t get the same querying and table view options that come with page and block properties

Suggestions for use

To start, it’s probably best to keep a limited set of function types.

This way, you don’t get lost trying to figure out if you already have a similar function and start creating endless functions