Functional Notes

Linked notes have opened up a lot of great possibilities. How can we level up the links? Notes can be thought of as a page or a block or whatever core entity you like, though perhaps it would be simpler if there was only unify blocks and pages in logseq|one type. Here follows a theory of notes (perhaps based on a theory of knowledge, who knows).

→

In a linked note taking, there are two basic types of objects: note and link.

→

A note is an atomic idea. A link exists in a note, and refers to another note. A note can be a file, a “block”, or some other basic entity. In linked note software, a link is usually denoted by brackets: [[A Note]].

→

In a thorough note system, everything can be represented by a note. We can have notes that aggregate other notes, notes for people, notes for places, notes for days, an image can be a note, a tag can be a note, a note can describe the note structure, etc.

→

What if links could be notes too?

→
# Claim 1
This claim is supported by [[Observation A]]
# Claim 1
[[supported by]]->[[Observation A]]

Then everything can become a Note, and I am thinking of a Note essentially as a function.

func [[A Cool New Idea]] -> (contents of [[A Cool New Idea]])

Whenever the arrow -> is used directly between two links, this indicates that the link before the arrow is describing the link after the arrow.

Right to left processing, so

[[Unsure]] -> [[Supports]] -> [[Observation 1]] -> [[Claim A]]

becomes

([[Certainty/High]] -> 
	([[Supports]] -> 
		([[Observation 1]] -> 
			([[Claim A]])
		)
	)
)

both of which essentially mean:
I am highly certain that observation 1 supports claim A
(sidenote: not sure you would want to have a certainty link specifically)

→

More Examples

[[Idea B]] -> [[Isomorphic]] -> [[Idea A]]

does this order make sense?

[[Philosophy]] -> [[is-a]] -> [[Type]]

means Philosophy is a Type

[[Type]] -> [[Philosophy]]

means this note is of type Philosophy, kind of like running

[[Type]]() {
return [[Philosophy]]
}
[[Claim A]] <- [[Supports]]
([[Observation 1]] -> [[Supports]] -> [[Claim A]]) -> [[Unsure]]

so let’s try the function write out:

[[Unsure]]([[supports]]([[Observation 1]]) { return [[Claim A]] }) {
return true
}

[[supports]]([[Observation 1]]) {
return [[Claim A]]
}

so here I’m saying “I’m unsure that Observation 1 supports Claim A.”

vs

[[Observation 1]] -> [[Supports]] -> [[Claim A]] -> [[Unsure]]

which means


[[Unsure]]([[Claim A]]) {
return true
}

[[Supports]]([[Observation 1]]) {

}

and here I’m saying “Observation 1 supports that I’m unsure about Claim A.”

Indents help make this clearer

- Observation 1
- -> [[Supports]] -> [[Claim A]]
- -> [[Unsure]]

= “I’m unsure that Observation 1 supports Claim A.”

vs

- Claim A
- -> [[Unsure]]
- <- [[Supports]] <- [[Observation 1]]

= “Observation 1 supports that I’m unsure about Claim A.” (assuming arrows can be done in both directions)

x -> y -> z means, given x, return y, and given y and x, return z. If there is no note link in front of the ->, then the current note is implied. The last note in the chain is always implied to end with a -> true

how to equate inverses?

[[Supports]] [[Inverse]] [[Supported By]]

Woah.. this could change the game.. Now we are creating a n-order mathematical group / ring / field?. Where instead of two operations (+ and *) with inverses, where each element is also a possible operation, and we can have n operations. Thus we can have n operations…

[[Observation A]] -> [[Supports]] -> 
- (all blocks x where [[Observation A]] -> [[Supports]] -> x)
- (also, due to inverse definition, all blocks x where x -> [[Supported By]] -> [[Observation A]])
→

Special Functions

→

Identity

[[identity]] 

For every note a, a -> [[identity]] -> a

Every query has -> [[Identity]] appended to it. This way if A supports B, and B is identical to C, then [[A]] -> [[Supports]] -> will return B and C. Even if A has no explicitly defined relationship with C.

→

Inverse

[[inverse]] 

if x and y are inverses, (a -> x -> b) -> [[identity]] -> (b -> y -> a)

So how would we query including an inverse?

So if

[[A]] -> [[Supports]] -> [[B]]
[[C]] -> [[Supported By]] -> [[A]]
[[Supports]] -> [[inverse]] -> [[Supported By]]

then

[[A]] -> [[Supports]] ->

==

[[A]] -> [[Supports]] -> [[identity]] ->

not sure yet how to make inverses “just work” using the existing [[identity]] and the simple inverse definition above…

→

Syntax

→

exploring Universal Constructions

→

void = initial object = in set category, empty set = in logic, proving “false”

→

initial object = for every point in a category there is one and only one arrow from the initial object to the point

→

identity exists, void -> void

→

nothing can return void

→

anything that takes in a void can return any type, void -> a

→

unit = terminal object = () = in set category, set with one element = in logic, proving “true”

→

terminal object = from every point in a category, there is one and only one arrow to the terminal object

→

two terminal objects are always have a uniquely ismorphic = only one way to isomorph between the two

→

you can return a unit from anything, a -> ()

→

can use unit to define the element of a set, one :: () -> int, two :: () -> int

→

as many unit -> t functions exist as elements in the type t

→

instead of talking about elements in category theory, we can talk about the function from unit

→

bool = in set category, set with two elements

→

TODO how are groups, rings, fields defined as a category?

→

Logseq specifics

→

If in a block, applies to block one level up. If at top level block in a page, then applies to page.

→

How to query?

→

TBD

→

More Thoughts

→

We already see some of this from the unification of tags and pages in roam research and logseq

→

The only limit to our structure is the file under the hood. It is a text file.

→

My proposal for a generic, extensible note “grammar”:

→