A brutalist approach to knowledge management in Obsidian

[a_bahez]

Hi all, a really old Obsidian user here (I’ve used this app since v0.5 or so). I’m a Product Manager in a small startup and also an Anthropology PhD student. My main use case is Knowledge Management, and I’d like to share my personal approach to it, which I call “Brutalist” since it’s the closest word I’ve found to describe the gist of this mindset, particularly in the web elaboration.

The Brutalist approach is an epistemic, ethic and aesthetic way of work with digital notes. I call it Brutalist because it feels and looks pretty rough, but at least to me has been sturdy enough to keep me using the same system 3 years without changes. The first two dimensions are expressed in a set of guiding principles inspired by multiple sources. The aesthetic dimension is more free, and I share my personal approach after the principles.

Separation of concerns

Notes are not tasks, nor agendas, projects, essays, books or papers. Each functional component of knowledge and management should be separated in a consistent way (different apps, vaults, directories, files or blocks). If I cannot extract each component programmatically then it needs refactoring.

Same principle applies to content versus presentation. I love (and do) editorial and web design, but at a note, draft and final writing levels I don’t care about them. Once content is ready, I can pass it through multiple pipelines that may include advanced CSS or In Design to focus on craft a better visual experience.

You are always wrong

Some people use a popular metaphor to classify its notes: from seed to evergreen tree. My notes have always the same status #ToBeImproved, ergo, that tag are useless. I can’t tell how many times I have delete a perfectly written, densely linked note because it is essentially naive or wrong. Think about an idea as evergreen falls in an epistemic trap: to think about truth as an inherent value of some fact, data or belief. Confusing truth with reality is a western bias with ancient roots, as an anthropologist I cannot accept it, because there are multiple, intriguing ways of knowing. Truth is a product made of a dense network of ideas, people, objects and history, framed inside an epistemic paradigm; changing the paradigm changes the values. It doesn’t matter if your vault is only about western medicine, thinking in a constructivist fashion will release new ways of intelectual creativity.

Elaboration first

Brutalism is know to show the raw materials of the building. In Obsidian, the raw material is mainly text (although it can be a drawing, a picture or any little piece of communicating media) and relations, elaboration is about the content. Elaboration is the process of thinking by writing. One problem with outliners is that they seem to follow the train of thought pattern, forming a serial thinking in which each bullet is an independent idea that may be related with the former without expliciting its relation. Outlining is good as starting point but you shouldn’t leave the note without writing one or more paragraphs that structures your idea using logical or narrative connections.

Elaborate before anything, before creating directories, tags, even links. If you elaborate first, links will emerge and force your prose to change towards a neverending quality refining loop.

Thinking before linking

There are plenty of frameworks to link better your notes. From MOCS to Compass to Mental Models. To make explicit in the prose what is the reason of the link is always better. A link may be relevant for many reasons:

• x note is an instance of y
• x is a subset of y
• x is a semantic dependency of P (x is a part of proposition P; without x, P makes no sense)
• x is isomorphic to y (shares the same formal structure)
• x is an analogy of y
• etcetera

To create a complex and rich network of personal knowledge you only need two things: text and links. In fact, as Gordon Brander has shown in its fantastic essay, links act as tags, folders, comments, outliners.

That’s all. Only four principles can make the cognitive architecture: separate functions, have a constructivist mindset, use prose to think and make your links explicit. After this point, I think that the Brutalist approach can have many flavors, I mean methods, tactics, workarounds, etc. I’ll show some practical hints that have been useful to me.

Truth to materials

As text is the beton brut, the raw material, I follow some rules in my vault.

1. I write in source mode always. Seen some example notes in the Discord made me care about the content-markup ratio; markdown is one of the lightest markup languages, and we have managed to make it look like code (as a pure functional-syntax writing) and in many cases is only to get visual output (yaml visualization fields, declarative output in dataview). I see the markup as an aesthetic value, so I care about how and when I put italics, code blocks and so on.
2. I limit the subset of markdown features to write notes. Again, inspired by the specification of subtext by Gordon Brander, I try to use as minimal markup elements as posible. For long content formats, I use pretty standard markdown (plus some pandoc syntax to automate references using citeproc)
3. I see performance as a feature. Minimize plugins force me to take the most critical or versatile offered and try to make de most of them. For example, the Shell Commands plugin can replace the Git related ones, also the advanced search or text refactor features. Using Vim can search and replace by regex and enable some advanced editing. I have created a theme merging some css snippets that were related to better visualize markup syntax and app and relevant (to me) UI structure. You can finding in themes as “Brutalism”. I will work in it to get a better reusable version if anyone is interested.

How to construct notes

I follow the classic division of notes: fleeting, references, permanent and add the daily note as a different category from fleeting for reasons I’m about to explain. All notes are constructions, building representations of observable an conceivable realities.

• The reference note is constructed as a dialogue, contrary to the popular idea of put it in your own words I think we should treat others as valid voices in our own notes, not as hidden abstracted references. A reference is a book, an article, a personal interview, a memorized quote I heard in the market. Our brains are not silos and our voices are not only ours, we are part of a dense semiosphere. Deliberately impose our voice as a monologue is a trick to hide others and stress ourselves (another western bias: individualism), but that doesn’t change the fact that their voices are still there. Use your own words as having a conversation.
• The fleeting note is constructed as an open experimental device that includes jottings, doodles, post-its, secret personal languages, mindmaps, recordings os sound landscapes, handmade cartographies, drawings, bodily experiences and practices that will turn into embodied knowledge. All of that constitutes a living personal archive that usually won’t live in Obsidian, but informs the elaboration via descriptions, embedded media and references.
• The permanent note is constructed as I described above: through elaboration and explicit linking
• The daily notes is used as an advanced field journal. As you can see, I’m not particularly convinced of that individualist emphasis, so I prefer to replace personal reflection journaling by reflexivity journaling, that is, putting me inside the network of culture, people, social structures, material objects and ecological relations to better understanding my ideas, privileges, biases and beliefs. To do this I have a special syntax for daily notes. A daily note has 4 blocks: descriptions, dialogs/quotes, personal annotations and analytical annotations. Descriptions are single paragraphs, dialogs are surrounded by dashes, personal annotations are surrounded by parenthesis, analytical annotations are links. This allow me to run multiple analysis (some automated) to my daily notes to abstract/discover ideas and patterns that are not only mine, but product of my particular historical situation

I hope this helps some of you. If you read it all, thank you. I’ll be glad to discuss anything, but I have to say sorry if I delay responses, school + work + family absorb most of my time and energy.

[davidlandry]

Thanks a lot for sharing!

Could you elaborate a bit more about your daily notes? What is the difference between a personal and analytical annotation?

[a_bahez]

Sure! The fundamental difference between a personal annotation and an analytical one is that the former is a subjective reflection, while the latter is a theoretical intuition about the situation I narrate in my journal. Here is a very simple outline of the syntax of my daily note:

This is a description of something that happened, with certain details on interesting things. - John: said something that I quote verbatim - (this is how his comment made me feel about the situation), and finally, this relates to a [[theoretical idea]] that I will develop separately.

Here’s a more concrete example:

Today, the technical team discussed large language models in a session with the Chief Technology Officer. The question was about their personal opinions regarding them. The conversation gradually shifted towards how they felt about the topic.

-Alex: I do believe they will take our jobs. Besides being a data analyst, I love acting, and I would like to become a voice actor someday. What worries me the most is that artificial intelligence will even replace such creative professions.-

-Jhon: Artificial intelligence scares me. I'm concerned about how many people in my family will fall victim to some kind of automated fraud. But fear motivates me to not lag behind and keep learning. I've already taken one course, and I'm about to finish the second one- (As I hear him talk about fear, I feel uneasy; I can't help but get angry at the idea that fear is a motivation, as if we were already living in a dystopia of behavioral manipulation triggered by negative emotions) [[rhetoric of fear and technology]]

The analytical annotation [[rhetoric of fear and technology]] begins as follows:

Large language models have been introduced to some people through fear. The first thing they learned about ChatGPT is how it would take their jobs or how it could help criminals pretend to be a kidnapped family member. Associating fear with a rejection of technology seems to be the most obvious response. However, some have used fear as a way to compel themselves to learn and use those technologies before being used by them through others.

This analytical note that emerged from my diary has nothing to do with my personal attitude towards LLMs, which is more skeptical. However, it allowed me to explore an interesting idea: that fear and technology don’t always result in rejection. As a result, I can consider how to create new conversational devices to further explore that idea and propose hypotheses that can be generalized. For instance, in the following conversation, I had a question that delved deeper: What would an artificial intelligence that doesn’t evoke fear be like? This inquiry unravels a network of emotions and experiences, including trust, attributing strong agency to algorithms, and even concepts like anthropomorphism and ethics of care mediated by automatons.

On the other hand, personal notes help me understand myself, but in a broader context. Using that syntax, for example, I can extract all the texts where I’m the only one talking about how I felt, what I said, or what I did, to restructure them in a scheme (for example, a json file) that allows me to analyze myself reflectively without losing the context of the conversation and the help of an LLM.

In summary, a personal annotation is a subjective reflection of my experience, while an analytical one is an idea, a permanent note that emerges from an interaction with other people, things, or the environment. Analytical annotations have a tradition in qualitative analysis methods. For example, in grounded theory, they are called “memos” or “codes,” and there is an excellent implementation of that method created by Ryan Murphy in Obsidian.

I hope this is helpful.

[jeetsukumaran]

Thank you for sharing. I really like your take on the “source” note. I’ve always felt that while I I appreciate the “express it in your own words” as a way to make you think rather then just collect info, and get all the benefits of recoding (which is good), sometimes, as you say, you want to engage the text more directly. Also, many PKM models emphasizes the “spiritual superiority”, if you like, of your own independent thought (which is also good), but I feel many workflows (e.g., academic) would benefit from some emphasis on the provenance of those thoughts that link, base, anchor, or are otherwise built based on the source.

Thank you also for linking to the Brander piece. I am curious if you have any examples of how he uses links to express ontologies:

I have been struggling with this. I am wondering if you might have advice on how to solve it or how you would approach it using the brutalist appraach.

For example, consider two notes, one on a place cell and the other on a bvc cell. There are many many things we can write about these but for now, let’s focus on just the following:

A bvc cell is a neuron involved in spatial cognition that uses egocentric coding.

A place cell is a neuron involved in spatial cognition that uses allocentric coding.

Here after a “knowledge session”, I might end up with the following notes:

• bvc-cell
• place-cell
• egocentric-coding
• allocentric-coding

What I would like to capture is that “egocentric coding” is a troponym of “bvc cell” and while “allocentric coding” is a troponym of “place cell”, and that these two types of cells differ in this troponym. (I’m using “troponym” =“way of doing something”). This is of course straightforward to express in ontology languages, but can these semantics be captured in Obsidian using just links?

Maybe in the bvc-cell note using metadata, I could add:

[troponym:: [[allocentric-coding]] ]

Following Gordon’s “reimagining”, it would be:

[[allocentric-coding|troponym]]

Not much to choose from in terms of readibility and the refactoring magic still applies, but I think the metadata approach has lots of benefits in the resurfacing (i.e., active searches).
Either way, though, how would I capture that contrast with the place cell?

(edit: replaced ‘grid cell’ with ‘bvc cell’; cut and paste typo)

[davidlandry]

@jeetsukumaran

Following Gordon’s “reimagining”, it would be:

[[allocentric-coding|troponym]]

This statement of using link text as the predicate also stood out for me. I mostly use link text for disambiguation or to “collapse” multiple words to a particular page. For instance I preserve text fluidity by remapping the plural (“Transformers”) to my main page for the topic (“Transformer”).

Using the link text as the predicate seems like a stretch to me in most circumstances, but maybe more literature in Semantic Modeling makes a good case for it.

[jeetsukumaran]

I’m no expert in semantic modeling, so cannot comment on that part. But it does seem a little hacky, and does not seem to me to add any clarity to the metadata approach and the visual noise is comparable. Arguably it might even be accused of reducing clarity, in fact, as in reading view it would show up as just “troponym”, and you would have to hover on the link to have even a guess what the troponym was?

[holroy]

I do believe that the triple which is spoken of is more of a graph concept, where it would not be meaningful to just have an arrow from John to 1945 without notifying why there is a link.

So the question, I think, would rather be how can we signify or add information to the link textually. Like, in the page of John, how can we distinguish between the links [[1945]] as the birth year, or maybe [[1958]] when he was married.

Here it could be argued that doing John was [[1945|born]], and [[1958|married]] to his [[Jane|wife]], would enhance the link, but also reduce the sentence quality. Another alternative could be to use inline fields: John [born:: [[1945]] ], and was [married:: [[1958]] ] to (wife:: [[Susan]]). Proper/better styling of inline fields other than the current default, would be vital for something like that to work.

In both cases, it would however be nice to get some of the context in the files that were linked to. That is that the backlink could show which alias was used, or which inline field was set when the link was used. Otherwise the “extra” link information would only serve a purpose in the originating note, where it was defined, if that make sense.

(Hmmm… Is it possible to write a query to get all the fields linking to a page, and group the results on the field used?)

Anyways, my main point is that “link text” would have a greater purpose in a graph where the arrows/links don’t have the context of surrounding text, and secondary that it could possibly be interesting to have more information connected to our textual links (but I’m not quite sure how to utilise/markup such information).

[jeetsukumaran]

You touch on the issue exactly: " how can we distinguish between the links [[1945]] as the birth year, or maybe [[1958]] when he was married."

And this is the biggest issue I’ve faced with the “backlinks” approach to replace metadata. This becomes worse if your vault has other types of connections (e.g., daily notes linking to captures), and even if not, any sufficiently cross-disciplinary or complex note graph makes backlinks (alone) a very noisy channel for semantic links as a note may be backlinked from notes of different domains and relationships.

(Hmmm… Is it possible to write a query to get all the fields linking to a page, and group the results on the field used?)

Interesting. So you are imagining given data such as:

• note1: parent:: [[note-a]]
• note2: parent:: [[note-a]]
• note3: child:: [[note-a]]

the query will return (for note-a):

# Note-A

- **parent** of:
  - [[note1]]
  - [[note2]]
- **child** of:
  - [[note3]]

?

[holroy]

Yeah, wouldn’t that be a rather neat query?

Potentially a query returning the sentence around the link, to provide some of the context, follows some of the same lines.

The closest existing variant I know of would bee to have the links in list/task item, and then query for items linking to current note (or similar).

[jeetsukumaran]

Yep, it absolutely would!

We have all the mechanisms in place, we just a need a good policy.

Well, ideally in terms of mechanism, we would probably want line- or block-scoped dataview results. We run up against the Obsidian “file-scope” or “list/task-item scope” and nothing in between mechanism limitations for sure here. At least, that’s with Dataview. I guess Obsidian’s native queries can give us lines/blocks, but not sure how to work with that programmatically.

But working with the list/task construct seems to be the only way to make sure we can pull the relevant associated fields together. Extended example to allow multiple ontological domains:

- [ ]  [domain:: domain1] 
    - [ ] Contextual information [parent:: [[note1| we can add something useful here to]]]
    - [ ] Or maybe a readable relationship desc here with metadata: [child:: [[note2]]]
    - [ ] Or something else  [child:: [[note3]]]
- [ ]  [domain:: domain2] 
    - Contextual information [parent:: [[note4]]]
    - Contextual information [child:: [[note5]]]
    - Contextual information [child:: [[note6]]]

While I have not actually thought through all the logic, I think a DV query could recover this structure and relationships if supplied with the various field names? It could be a TASK query, or just a standard table with the tasks pulled from pages etc.

(Should we and if so, is there a way to, split this discussion to a separate thread, e.g. “Ontological Triples” … )

[a_bahez]

I apologize if I sound like a party pooper, but I suppose my opinion in this case is obvious. I will discuss some points that I summarize below:

1. More context on Brander’s proposal
2. The problem with ontologies and markup languages
3. The why before the how
4. Obsidian is not the best tool for semantic ontology
5. But if I had to force it in that direction, what would I do?

Context on Gordon Brander’s ideas

The text I reference from Brander about links is written in the context of an exploration the author is doing to build Subconscious, an alternative to Obsidian. In that text, it is important to remember that for each proposal in which a link replaces things like tags or folders, a technical implementation that processes the links is needed. A link cannot replace a tag without a backlink that shows all the references pointing to it. Similarly, a semantic triplet would require a technical implementation that processes the text and link address in a fundamentally different way from the original markdown specification. In another text, Brander takes a position against a syntax that mixes the link address with the displayed text and promotes a more radical separation between an editing mode (source view) and a preview mode. According to him, [[wikilinks]] should be replaced by /slashlinks (that is, references that only contain the address and not the prose text).

Ontologies and Markup Languages

With that context in mind, what are we exactly trying to accomplish? Let’s remember that markdown is a lightweight way to write HTML (and that HTML is a subset of XML). In HTML, links, like other elements, are capable of having attributes, and in fact, the link address is an attribute of the <a> tag, the href, like <a href="link-address">Prose Text</a>. In specifications like the semantic web’s OWL, ontologies are worked with through attributes, properties, and values based on RDF. Markdown does not have such a purpose or specification. Putting all that aside, investigating the history of the Semantic Web itself gives us an idea of the complexity of its general implementation and the problems it generates, to the extent that it has not managed to establish itself as a major technology when compared to other paradigms such as blockchain or natural language processing. However, it does have its very specific specialized uses.

Why Before How

Formal ontology is a fascinating topic. But before we continue, I have to ask, why would someone want to implement it in Obsidian? What ultimate purpose are they trying to achieve with it? The answer to that question determines the very response of how to implement it. Is it just curiosity to push Obsidian to its limits in this aspect? Great, let’s keep experimenting! There are many people who dedicate hours to make Obsidian look and behave like Notion or Logseq, instead of using Notion or Logseq directly. Part of the charm is the flexibility. However, if you’re looking to define your own personal ontology, I wouldn’t bet on doing it with Obsidian.

Obsidian is not the best tool for building a formal ontology

Simply because that is not its purpose. An application designed for note-taking where each node is treated as an object (with a storage format that is a database rather than local files) could achieve that goal more efficiently and straightforwardly. In fact, there are a couple of applications that do just that: https://anytype.io/ does an incredible job with a graph centered around object nodes and formally specified relationships, and https://capacities.io/ also has a specifically object-oriented approach.

What I would do if I had to do it in Obsidian

First, I would ask myself, what do I want to achieve exactly? If I wanted to formally model a knowledge domain, I would definitely use a Python notebook first (again, separation of concerns) to properly prototype the model. Then, I would define a markdown-compatible specification to implement it. For example, I might explore using the markdown attributes logic. However, the brutalist way to do it would be to use plain natural language in the style of an informal ontology. Let me explain.

An important part of an ontology is vocabulary control, which defines the relationships. Based on this simple idea, I would define a specification that allows me to understand when I am describing an ontological predicate between two nodes (notes). In my case, this would be whenever there are two or more notes in the same sentence, because specifying the relationship in prose is a principle of my personal approach. Speculating on this specification, I would define something like:

• A sentence is a string of characters that is surrounded by a period and a space or a line break (except at the beginning of the note).
• A semantic statement is when two or more [[links]] appear within the same sentence (example: [[a]] is a subset of [[b]]).
• A predicate is all the text that appears between the links in a semantic statement and its first words are verbs

In this way, if I documented and controlled the expression “is a subset of” to always write it in the same way, I could extract all the times I have used that predicate with a general search and some regex (I wouldn’t even need Dataview). But again, it all depends on my ultimate purpose. If I want to see in a single document all the predicates I have declared in my vault (and I’m not sure what utility that would have, especially if they are factual predicates like A was born in year N), I would use a combination of the specification with inline fields. However, I am convinced that I would achieve better and more elegant results if I modeled it as a database and used a programming language.

[cobalt]

I got nerd-sniped hard by that link on informal ontoloyg, thanks for that