To spark up some discussions on this new forum, I want to ask a question.
I study Economics - a social science that heavily utilizes mathematical concepts. I have been using org-roam for a while, and there are two kinds of notes that often rise to the surface:
The kind of notes that talks about a concept: For example: “regression”, “neural networks”, etc… These notes are technical in nature, so they are easy to name. When I link these kind of notes, I often link them with their concept dependencies. For example, a note named “Solow model” would be tagged as “economics theory”, “growth models”, “ordinary differential equations”
The second kinds of notes is about ideas/arguments. For example, the “Solow model” implies that “In the long run, only technological innovation is important to growth”, and I create a new notes with that exact long title. This note will be linked to “Solow model”, and linked from ideas/arguments in the future that is based on this idea.
Currently, my two kinds of notes stay in the same roam folder, but I started to feel like they should be categorized into two parallel structures:
Concept notes should stay in one graph, and the way I develop the contents in concepts notes are similar to building a personal wiki. This helps me understand what the concepts are, but not to create new organic ideas from these concepts.
Ideas/arguments notes should be more about chains of relations, these are the kinds of notes that I think fitting to the slip-box method. By looking at the Idea/argument notes, I can start formulating my manuscript.
What do you think is the good method to organize these two kinds of notes? With the current state of org-roam, I think I should just put them into two separated folders, but by that I lose the abilities to see the links between them. I think there should be more ways to define different kinds of notes. With that, in the graph, my idea notes will be colored differently from my concepts notes, so I can easily follow my chain of arguments, while still being able to grasp the relations in their underlying concepts/basis.
I have no definitive view on this (my ideas on organization are evolving), but the impulse to want to hard-separate these types of notes feels like potentially counter-productive.
I mentioned this post a couple times on slack. Have you read it? I think it might be related, along with this FR for tags.
Interesting read. I haven’t read it before. The idea of having a structure notes is nice. But in org-roam, a structure note like this would point to everything it mentions in the graph, which makes the graph more convoluted.
Having tags that works as meta-categorizations and not links is really close to what I have been thinking. The structure notes idea is only feasible if we can have links that is not roam-links (don’t show up in graph). Sadly, I am an elisp-noob, so I cannot follow with the speed in which you guys have been working.
If Emacs eventually support transclusion (as there has been discussion gathered here), there would be more ways in which this problem can be approached. For example, each org heading can be equivalent to a note, and can be referred/linked to, so every note is a structure note on their own.
Let’s say we have a structure note that mention about 10 other notes, which is pretty easy after a while:
Looking from the structure note view: It’s great! I can recall the structure by a glimpse and move to the children notes if I wish to.
Looking from the children note view: It’s okay/neutral. The structure note is mentioned in the back-link buffer. The back-link to structure note don’t actually bring me much important information. Sometimes it does, but normally it’s quite obvious where a children note belong to.
Looking from the graph view: It’s messy. The structure notes now create another 10 arrows, which tends to make the graph quite convoluted. For the first-layer structure notes, I can try to filter the graph to near-related nodes only, but when multiple-layers/overlapping structure exists, filter is not so helpful.
I think it was too extreme when I said “not feasible”. Sorry about that. It is feasible and and probably still work for many people. But I think we should prepare (at least theoretically) solution to this problem. Little inconvenience can get quite troublesome when notes get abundant and complex.
Yeah, clearly there’s room for innovating on the graphing and UI-in-general front, and things like tags may help that. Did you see the related discussions here on graphing?
I had discussed some of this in Slack awhile ago. I think this organization is important, and I had been planning to create templates to use for different kinds of notes that would include customized meta-data sections that I could write my own functions to search over and narrow / filter. I think all of these issues are inter-related: OR is, at its core, a graph database, and some of us are looking for features that a graph database would be expected to provide.
The links between notes is the most basic relationship, but a note can have many relationships that we might want to document along the way. A graph db like neo4j considers edges between nodes as ‘relationships’, and you can have as many types as you want (though they are typically very focused so they are meaningful and can be re-used often). They encourage treating edges as verbs (not simply tags), so a note is “linked to” or “referenced by” another note. In the same way you could have a relationship that is “indexed by”, and if you don’t want to see that in your graph you would filter for only notes that are not the targets of “indexed by” edges (or, more generally, you could filter out the edges).
The benefit of the graph with various relationships is that it has no hierarchy. I may want to link to an index note with a general “referenced by” edge at some point. By filtering on edges, I won’t lose this link in my graph while filtering out the “indexed by” edges (because it is still just a regular note – there is no hierarchy). Using meta-strategies like multiple sub-dirs or file-naming conventions (# or ## for different levels of structure) creates pseudo-hierarchy, and although you might still link across them like a regular note, they are abstractly viewed as being special or different.
Tags don’t have the same problem with hierarchy, but then they lose information about relationships.
Something tickles me: the way you put it, tags can also represent a “indexed by” relationship from an existing note to a note that does not necessary exists. So should we treat tags that way: being a placeholder for a note that is not there yet and is excluded from graph by default?
There’s a tension between this aspect of what it is “at its core”, and the other aspect, which is note-taking/writing.
Tiago Forte had an interesting interview recently with Ahrens, and at one point asked him his thoughts on the ideal note-taking software. He replied that above all it needed to present “a very low threshold of writing, where you don’t get distracted by the software” (here’s the part of the interview where he talks specifically about software and this idea). This is the idea I often have in mind when commenting on these issues.
Years back, I was thinking a lot about and working on RDF metadata. RDF is a graph-based data model: subject-verb-object (note-link-note).
Not saying it’s a good idea (I’d have to think about it a lot more; particularly how that would impact the UX, and how it’d relate to org), but off the top of my head, it seems we could associate tags with links too, to qualify those relationships you note. We already have two types of links, effectively (standard, and citation), and that list could be expanded.
We could, but I think that encourages liberal creation of new tags and discourages actually making index notes, both of which I think are undesirable or are considered anti-patterns. I think tags are better suited to categorize/filter certain types of notes – private, bib, concept, journal, etc. Things that are broad and limited to a small list of possibilities. While the number of relationships should also be constrained, their benefit is they create specific associations, note-to-note, while tags jumble everything into a bag.
Maybe at its core its just org-mode / writing, but without backlinks there is no org-roam, and the backlinks are a graph
I completely agree that the most important aspect is a low threshold to putting your ideas down in writing. To that end I haven’t opened a feature-request on github because I have no easy, optionally-used solution. I was going to see if I could come up with something that worked for me and share the ideas if I thought others might like it.
@hieuphay -
You are making some interesting points, but there are a couple of issues being conflated. One is whether it makes sense to somehow mark a difference between notes that are concepts and notes that are ideas or arguments. The point of a ZK is ultimately written output, and probably anything you write for other people will be a combination of concepts and arguments, so I can’t see the benefit in separating them structurally.
You also say that structure notes are good from the point of view of the structure note, but not from a graph view. I find the idea of a graph view that can be navigated by clicking appealing, but it is not clear to me that it actually would have any tangible benefit. But even if it does, it would be a benefit that showed itself in a different stage of working with the ZK than the structure note would. I think navigating in a graph would be good for discovering “accidental” connections between ideas. Creating and working with a structure note, on the other hand, is a prelude to writing and putting thoughts in a more structured organization.
To me, one of the benefits of software like org-roam is that it has the potential for looking at a set of notes with different views that might each yield different benefits. You can have many structure notes that organize the same group of atomic notes in different ways to achieve different goals.
Lastly, I can’t imagine that there will be any type of software that could organize a collection of 1000+ notes in a way that wasn’t completely messy. I don’t think any practice should be discarded because it would result in a messy graph view!
