Logseq Functional Notes Plugin

#
>

Simplified

→
#
>

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
#+BEGIN_QUERY
{
:title [“supports ->”]
:query [
:find ?result-page
:in $ ?current-page ?function
:where
[?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]
[:div.flex.flex-col
(for [page result]
[:a {:href (str “#/page/” page)} (clojure.string/capitalize page)])])}
}
#+END_QUERY

→
#
>

Next

→
#
>

settings

→
#
>

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.

→
#
>

Downsides

→
#
>

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

→