Functional Note Taking
Functional Note Taking
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]])
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…
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”:
Functional Note Taking
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]])
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…
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”: