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”: