Logseq Functional Notes Plugin →
#
>

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

→