Having two different types of links
First of all thanks @Sascha for a great article describing structure notes. This idea appears in multiple places, another way to call these type of notes is Hub or Map of Content notes. Usually it represents some kind of category or a grouping. I like this approach a lot cause it allows to organize notes into hierarchy (heterarchy to be more precise) and see a bigger picture.
There are many ways of working with hierarchical structures, for example categories can be used in search by creating paths in your Zettelkasten, something like "Zettelkasten -> Step Model" and "Zettelkasten -> Stock-flow". So you can find both notes using "Zettelkasten" query.
Also, backlink from "Step Model" to "Zettelkasten" represents a broader context for the "Step Model" idea and a relationship with other ideas in these context (Stock-flow in the example).
Another way of using structure notes is a form of "Contents" of an article/book allowing to combine multiple notes into a single document (a form of transclusion).
Usually links do not represent a hierarchical relationship, in most cases a link represents a connection to an idea, concept or a definition of an object.
This opens a question, are the links in structure/hub notes the same as the links between ideas or it makes sense having two different types of relationships in the notes graph?
I would love to see if this concept makes sense to other people here and/or if missing something.
Howdy, Stranger!
Comments
I should preface this by saying that my structure notes are slightly different from those described in Sascha’s writing. At the bottom of my post I've taken a simple screenshot.
I should also preface that this is my method, not the "standard" zettelkasten method. And I don’t even use IDs for my zettels, so these ideas of mine would need to be reformulated if one wants to adapt them for oneself.
Short answer, I don't identify only two types of link (if for type we intend "meaning"), and I don't have automatic link type distintion when they are placed into a structure note or into a Zettel. My own situation is much heterogeneous. Every note can contain links of many types.
As a principle in my approach, whether inside a Structure Note or in a simple Zettel, I want every link to be a qualified relationship.
That is, when I reread structure notes or zettels, the link should effectively convey not only that there is a connection (A towards B or A into B ), but also the type and meaning of that connection, that denote why the link exists.
I don’t just need to convey that two or more notes are related, but also in what sense and why.
Many times simply placing a link is enough. But f the link itself, thanks to the note title implied in the link, does not succeed in expressing it:
1) I infer the meaning of the link from the context, from what is around the link, and I may extend this inference until the title of the whole note. (And building a "meaningful context" around a link when I place a link is a fundamental part of my linking process. Linking is both creating a link and giving it a meaning that survives over years).
2) If even the context around the link does not clarify the nature of the relationship, then I need to make the meaning of that link more explicit myself, by adding something that gives an explicit meaning.
Some examples of 1), of semantics deduced from the context:
In structure notes and zettels containing a set of links, I don’t just create a single flat list of links, but sometimes I divide them into multiple titled sections, other times I create a indented bullet list where indentation carry a semantic meaning.
In particular, I’ve assigned a default semantics to the indentation of bullets.
[[A]]
-- [[B]]
-- [[C]]
By default, this means that B and C are “children”of whatever kind of A: depending on the case B and C could be thoughts derived from examining A, parts of A in a part-of relations, details of A, implications when I considering the idea A, effects of applying A and so on. The link [[B]] gains meaning not only from the title B but also from B’s position and indentation relative to [[A]] and [[C]]. B indented respect to A has a meaning, B and C close together could be another meaning, and so on.
In addition to this, the structure note’s title itself can also help provide the semantics of the link. For instance, if the structure note is titled “how can I solve problem X,” then [[A]], [[B]], [[C]] could be interpreted as solutions to problem X, or ideas involved in some way in solution of X. If the structure note has another title, links contained inherits another meaning.
All the techniques above can be combined:
How can I solve problem X (structure note title)
Under the hypothesis 1 (structure note section title)
[[A]] (cluster of ideas to consider under hypotesis 1
-- [[B]]
---- [[C]]
--[[G]]
Under the hypothesis 2
[[D]]
[[E]]
-- [[F]]
The meaning of [[C]] is determined by the text C, its positional relationship to B then to A, from beeing contained into the section qualified with the title “when hypothesis 1 is true,” and finally into the main context of solving problem X.
That simple structuring, therefore, becomes much more expressive than having a plain note like this:
Problem X
[[A]]
[[B]]
[[C]]
[[D]]
[[E]]
[[F]]
[[G]]
When there are only a bunch of links the difference the difference may not be relevant, but in a complex structure note the structure, therefore, can become much important than the single links.
This, I emphasize again, I do both in structure notes and in Zettels. In fact, in my zettelkasten I’ve even abandoned the explicit distinction between Zettel and structure note: every Zettel that has a cluster of links inside it can function as a small Structure Note :-). But this is another story...
2) What I've described is powerful, but sometimes is not enough. Despite this setup, the nature of [[B]] may not be clear, neither from what B expresses itself nor from its position. For example, B and G could be two zettels of very different types, so [[B]] and [[G]] two very different links.
At that point, I improve expressiveness by adding something near B and G. Adding a few words, or even emojis or icons.
For example, if [[A]] is a solution technique, [[B]] could be a critical issue that may arise when applying [[A]], and [[C]] could be a countermeasure to avoid [[B]].
I could prefix B with a “attenzione” (means "warning" in Italian) or, even better, the emoji of a fire or a hazard sign. And for C, a firefighter icon :-)
That piece of outline, for instance, becomes:
🛠️[[A]]
-- 🔥[[B]]
---- 🧑🚒[[C]]
I recognize with one sight what links are the tecniques, issues and countermeasure and their mutual relationships.
I can also notice if there are fires without at least one firefighter, this is useful to check if my train of thought is complete :-)
Another technique I use is to have, at the beginning of a note, links to the "parent ideas" made explicit in this way:
up:: [[Parent1]] [[Parent2]]
This indicates that the current Zettel Z is part-of Parent1 or Parent2, is generalized by Parent1 or Parent2, belongs to the cluster Parent1 Parent2, belongs to subject Parent 1and so on. It’s another way of giving explicit meaning to the special links [[Parent1]] and [[Parent2]].
For example, my "Atomicity" zettel has a "up:: [[Core Principles (Zettelkasten)]]" at the top of the note, and Core Principles (Zettelkasten) Zettel has a "up::[[Zettelkasten]]" at the top.
This is another way of having qualified links between zettels.
Another type, used recently. When I have a couple of ideas that in pairs form a dualism of some kind (for example, developing top down vs developing bottom up), I qualify links to this two zettels with a yin yang emoji ☯️. Into the structure note that contains both, and/or into both notes there is a link to the other with this prefix.
For some techniques I’m consistent in applying them across all my thousands of notes (I have a rule that every Zettels has at least one parent note, for example), while for others much less so. Over time I’ve used many variants of the same approach (I don’t always use emojis, I don’t always use the same emojis for a specific meaning, sometimes I divide link lists into sections and other times I end up with a huge tree instead).
But the principle always remains: avoiding links and flat link lists that don’t express the meaning of the links. Simple link lists are fine for me only when they are very small; otherwise, I need to make them meaningful.
This is a fragment taken from one of my real structure note:
Use of bullets and indentations, auxiliary texts, emoji, relative position of every link, title of every link, al these elements contributes to explain the meaning of every link. Here I didn't use a fireworker but a bandaid for qualify a countermeasure for a potential issue. In this small fragment I have three roles in which notes can be involved: as advices, as issues involved following an advice and as countermeasures for issues.
just another thing. The image above is a fragment of some kind of hierarchy or heterarchy, but my structures are not always built to represent hierarchies. When useful, they develop in a chronological way, or in a train of thought with the same dynamics of a Folgezettel.
This is another example, a fragment of the body of a zettel developed evaluating the different way of making atomic notes (made from a recent topic in this site):
The emoji that I've used show me at a glance that some ideas make a dualism.
This is an example, too, of a note that is both a Zettel ("one idea") and a Structure Note (a "composition of related ideas"). The title of this zettel is "There are many different ways I can atomize ideas in a Zettelkasten" (traslated from italian) and it's "the idea", that fragment is a part of its body. Again, this is my approach, it's not a standard way of doing Zettelkasten
This makes lots of sense.
Is there any features around this parent-child relationships in the program you are using for your Zettelkasten?
What do you think about having hierarchical links support in your program allowing you to visualize the hierarchy at different levels and with different depth? Or use hierarchy for searching, grouping, etc.
I followed your examples and nodded along, then this stood out to me: on what level do you mean they are the same or not?
(Cue @Andy with a load of references in hand for argument mapping and qualifying links.)
This is not prescriptive, just experiential: I find myself thinking of links from large structures to detail notes along the lines of whole/part relationships; or containment of elements.
Depends on the structure:
A comparison does neither contain the compared parts, nor would I characterize the comparison a 'whole' comprised of the compared parts (although one could easily make an argument for that). I think of it as a 'using' relationship instead, that merely brings into a relation the parts that are compared. Because the relation is so complex, it needs to be expressed as an entity in the ZK itself, a note, and cannot just be represented via the usual way a relation is created: a link.
On that level, which is also a very superficially pragmatic standpoint, all links are relations, so all are similar. And each link is unique -- inasmuch as it creates a relation between two concrete other things.
Naturally, that's a question of categorization. Types and tokens, entities and classes, categories and elements. -- We could talk about both of us having pets, or more specifically: dogs, while each of our dogs would be completely different from the other. Same with notes (unless you create perfect duplicates/clones on the level of analysis of 'files on your computer drive' (that are represented as different bits being switched on/off in the actual drive, that in turn can be represented in the actual hardware in different ways), which would be pointless
-- So in practice I find the context of the link, where it is, in which file it is, and where it points to, to be sufficient to make it unique in practice as I follow relations in the network, and also same-y enough to actually make recognition and usage possible.
"Are they the same" becomes an ontological question, and depends on your interest for this inquiry.
Is any potential analytical difference important to make the Zettelkasten work? I don't think there's an argument supporting this.
Author at Zettelkasten.de • https://christiantietze.de/
The use of that particular syntax you saw, "up::", is not accidental :-)
In Obsidian, it’s a property that is supported by Dataview.
Obsidian lacks a built-in ability to create typed links; the trick of using links together with an inline property can compensate for this limitation.
There’s another plugin that uses and extends a similar mechanism, it’s called Bread Crumb. It’s a very interesting idea, but personally I don’t use it.
At least in my initial intentions, I found the idea of using Dataview to automatically gather notes that have a given note as their parent very intriguing.
It’s exactly the method for having "children backlinks".
In the actual practice of my Zettelkasten, however, I use the automatic clustering of children only as an aid to building a manual collection of links inside the parent note.
Thanks to automatic clustering, I can see if I’ve forgotten to add some link to a structure note, for example.
This is especially useful when I have a parent note still in a very embryonic state. At a certain point I may decide that it can become a structure note, so I go check mainly which notes I have declared as children of this one.
Once that work is done, though, I set aside children backlinking, because I believe that links should be selected, properly formatted, and placed intentionally.
Once this task is completed, the presence of up:: [[parent]] remains fundamental for navigation from the child note to the parent note, above all. This is today the main purpose.
Its placing, presence and use is something that becomes deeply internalized.
When I open a note, I already know by habit that there’s at least the possibility of "moving upward", and I know exactly where to find these gates: at the top, right after the note’s front matter.
Such a simple construct, strengthened by habit, allows you to develop and rewalk the chain of ideas that I think is among the most used and useful: from the bottom upward, from more specific ideas to broader or more general ones.
Even if you don’t use particular tools to exploit them automatically thanks to features of the tool, if you adopt a simple convention like this you bring out a meaningful chain of idea flow.
Going back to the earlier example, I basically have a backbone built purely by habit that lets me start from a single idea about atomicity to the bottom of my Zettelkasten and climb all the way up to Zettelkasten main note, without having to use search engine or other constructs.
This is for "north", but if you want, you can do the same process by creating other chains that semantically link notes, point to point, moving towards "south", for example, or other directions.
So, in the end, yes. You can use qualified linking such my "up" for exploit the automatic clustering capabilities of the tool, but in my specific case they become useful above all for making emerge "predefined" note-to-note navigation paths.
@ctietze said:
Above, other people already explained various practical ways to create different link types. There is a lot of published theory about link types, but I will restrain myself and only mention one that @gimalay might find interesting: "Hierarchy in knowledge systems" by Michael K. Bergman in the Encyclopedia of Knowledge Organization. Check out section 5, "A typology of knowledge system hierarchies" for an extensive list of types of hierarchical relations (links).
@Andy thank you for the great references! I'm definitely going to educate myself.
I was thinking about this in a bit different way. When we structure text we are using sections (headers) and subsections to represent relative structure. For example:
This effectively indicates that Subsection is a part of Section and that Subsection makes sense in the context of the Section. When I write notes in Zettelkasten style I'm striving for concise and atomic notes. In the case if Subsection contains lots of information it may be reasonable to extract it into a separated note but preserve the relationship at the same time. Which is usually done via MOC/Structure notes.
I personally found that this kind of extract operation very useful. The result of the extraction can be represent in Markdown as a MOC link, like:
I want to build a PKM management tool which can differentiate between regular links and structural links cause this can give a few potential benefits:
Or in other words, since Markdown is a tree with headers, sub-headers, etc. I find very useful having a way to extend this tree with additional notes by using a special type of link. (which also a form of transclusion.
It's definitely note required to make Zettelkasten work. But it may be a quality of life improvement.
To clarify: Do you mean the difference between two ideas linked within a structure note vs two atomic notes being linked. Or do you mean an link from a structure note to an atomic note vs two atomic notes being linked?
I am a Zettler
I mean a link from a structure note to an atomic note can represent a sort of category/parent-child relationship. While a link from an atomic note to another atomic note usually doesn’t imply that.
@gimalay said:
You're not alone! These are familiar problems in the organization of personal knowledge bases. People have written about these problems for decades, and people have built software programs that have features like those that you listed above. Almost everything that you listed above can be done in Obsidian with plugins, for example.
An example of a software system that is highly transclusion-based is Jon Sterling's Forester, previously mentioned in this forum.
Yes, I’ve seen people try to address this problem in various ways, and I recently made another attempt myself.
Unfortunately, Obsidian doesn’t natively support this type of relationship, nor does it offer a straightforward syntax to express it. To solve this, I’ve built a tool that includes this functionality using a simple, backwards-compatible Markdown syntax.
Structure links are expressed as paragraphs that contain only a single link, like this:
In the tool I built, this syntax represents a parent-child relationship between "Section" and "Subsection," while still allowing you to add any context you like alongside it.
At the same time, any other tool will interpret this as a regular link, making the approach backwards-compatible.
I see this as adding an extra dimension (depth), allowing users to "zoom in" and "zoom out" as they navigate their notes.
When we are working with text we express structure of a document using outlines, headers, etc. It's a very natural way of writing and thinking. I want to have a way to express this structure across multiple documents.
We are doing this anyway using MOC's, but the system doesn't know the difference.
@gimalay said:
Oh, you mentioned that tool in the discussion "PMK solution for your favorite text editor". I'd like to try it in BBEdit sometime.
But I am skeptical of your solution, and I don't see it as backwards-compatible, because transclusion of one file in another and linking between two files are not the same. I would prefer explicit syntax for transclusion.
MultiMarkdown and DEVONthink already use double curly braces for transclusion, not to mention the transclusion syntax in other flavors of Markdown. And remember that any good text editor has a command to treat any text as a link to a file (in BBEdit it's the "Open Selection" command), and such behavior can be easily scripted if it's not natively supported, so if you want to open a transcluded file reference in a text editor that doesn't support a given transclusion syntax, that is easy enough to do, and more intuitive in my view than repurposing link syntax for transclusion.
EDIT: I interpreted your "structure link" concept as "transclusion" because the first two bullet points in your previous comment said "Construct higher order notes from concise and atomic ones" and "Ability to re-use a Section (note) as part of another MOC/Structure/Hierarchy" which seem to me to be transclusion-related.
IWE supports a set of transformations including transclusion, for example it can extract a file by transforming
into, two files
and Subsection.md
Or flatten files back into original form using LSP code actions or CLI commands.
For example, if you have a MOC file, like
It can output flatten version where subsections content is in one place
This file is a flatten version of the IWE markdown docs converted into PDF https://github.com/iwe-org/iwe/blob/master/docs/book.pdf
from this MOC file https://github.com/iwe-org/iwe/blob/master/docs/index.md
@gimalay said:
I wonder why the original file after extracting the subsection isn't like this?:
At least that retains the hierarchical structure in the original file, so anyone viewing the file can see that "Subsection" is a heading and not just an ordinary link.
Great question. It's the simplest form I was able to find. In the example you provided it's unclear how to interpret the content under header
Looking at this MOC example the structure seems clear.
https://github.com/iwe-org/iwe/blob/master/docs/index.md
You can find more examples here: https://github.com/iwe-org/iwe/blob/master/docs/maps-of-content.md
@gimalay said:
Why is it unclear? It's not unclear to me.
What you are doing, as you said, is transformations, which you called extracting and flattening. In outliner software terms, this is equivalent to collapsing and expanding. But your tool is not an outliner; there is more flexibility because the original file and the extracted parts are just Markdown files. So when you flatten (expand) a file, the extra text under an extracted (collapsed) heading can be appended to the end of that section. That seems simple and clear to me.
In contrast, what is unclear to me is this:
In your structure note syntax, [[Subsection]] and [[Subsection2]] are supposed to mean extracted (collapsed) sections. But those do not intuitively look like collapsed sections to me! They just look like ordinary links in text! Instead, this looks intuitively like a collapsed section to me:
The way that hierarchy is typically indicated in hierarchical structure notes is with nested list elements. That is how it is done in the hierarchy notes in the Breadcrumbs plugin for Obsidian, for example.
Instead of using list elements to indicate hierarchy, you are using a strange mix of heading elements and link elements. I think it would be better to use all heading elements to indicate hierarchy, with text under heading elements appended to the end of that section when the file is flattened (expanded).
I don't think that the exact syntax matters that much. I think there is many way to do this and it can be changed. My question is more about the concept of having the structure links (parent-child) in addition to regular links. I want to understand if the concept makes sense for other people here.
@gimalay, I disagree, I think the syntax is important. The concept of link types is of little use if I can't tell the difference between link types by looking at the syntax.
It seems to me that you view structure note primarily as a set. I think you benefit from incorporating seeing structure notes as spaces. The internal structure on the structure note is key to their effectiveness.
I am a Zettler