How do you determine what the "parent" of a Zettel is?

Avatasato

In my Zettel, I've established Index Notes (as an index), which link to each Zettel. As my Zettel expands, however, I am having trouble making such links. How are your Zettelkasten organized in terms of "parent Zettel"?

ctietze

What kind of "parent" are you thinking of?

Are you using Folgezettel to create some kind of manual order?

Otherwise, the notion of parent/child needs explanation

zk_1000

This depends a lot on the size of your Zettelkasten. With tens or hundreds of notes you rely mostly on indexes. With thousands of notes or more, they are less relevant.

When you struggle to find a certain note, add it to a parent so you can find it next time. No need to come up with a rigid topology.

GeoEng51

I agree with @zk_1000 - if, by "parent note", you are thinking of something like a Structure note. I create most of my structure notes organically, as described. On occasion, I go the other way around, starting with a structure note and then adding various zettels as appropriate.

tjex

In my zk, a note only ever has a parent if it is spawned directly from another note.
Otherwise, I don't consider a note to have a 'parent' as it could be potentially related to many different 'parents'.

If I'm writing noteA, and am inspired to make a new note (noteB), then noteB will have noteA as its reference.

---
yaml
---

# noteB

Body text

---

Refs:

- noteA

ctietze

@tjex I'm a bit confused why the parent--child relationship is applied in that case. Can you explain that a bit more?

These are usually quite rigid: you can't turn them upside down eventually and make the former parent now be the child of what used to be its child. So it's a rigid relationship. To establish rigid relationships at all, I believe one needs good reasons, because the cost of tearing them down in case of error is not negligible.

For context, of course I also think in terms of one note being the "parent" of another in a hierarchy. But these hierarchies are formed to solve a problem. Cue @Andy and the mention of #transhierarchy, and also #heterarchy as the concept of having multiple hierarchies overlap and live inside the same "soup" of notes.

tjex

@ctietze
Maybe I'm underappreciating the parent--child meaning? I'm taking it to mean that the 'parent' note is the source of another note's creation. This isn't related to Folgezettel (but I also don't think the OP was referring to this either?)

Practically speaking, it's the same idea that I got from the 'References' section in the zettelkasten introduction write up here on zettelkasten.de.

Sometimes, however, you will refer to other Zettel as your source of inspiration. In that case, you base your thoughts on something you have already processed in the past. You reference the Zettel by linking to it via the ID, connecting the new to the old.

The parent--child relationship in this case is useful information for the child note, as returning the parent (the source of the note) offers extra context as to why the note was created, or what it was in relation to.

For example, I have a note "what defines creative ideation?", and its reference is another note, which is my structure note for me masters thesis. Following the reference back to the 'parent' sparks my memory about the creation and its context within my ZK and 'idea space' at large.

I like it as it seems to be in line with how memory works (associated information), so by referencing the source of the note, I get that context and memory stimulation. Much like a literature note does for the atomic notes that link back to the reference note.

Andy

@tjex said:

Maybe I'm underappreciating the parent--child meaning? I'm taking it to mean that the 'parent' note is the source of another note's creation. This isn't related to Folgezettel (but I also don't think the OP was referring to this either?)

Parent and child are standard tree structure terms. Folgezettel creates a tree structure, so it's appropriate to use the terms in the context of Folgezettel.

If all we have is is noteA and noteB and a link from noteB to noteA, that is trivially a tree structure as well. But if noteB links to noteC too, and there is no differentiation between types of links, it's not a (directed) tree anymore.

@tjex's interpretation of a parent as "the source of another note's creation" is specifying a particular meaning for the term "parent" in the context of tjex's system. We could say it's tjex's semantics. That's fine, but tjex's semantics are not obvious from the note example he shared above. We wouldn't know just by looking at the example that noteB -> noteA indicates that noteA "is the source of" noteB; we would need tjex to tell us that, or we would need to read the document that specifies the semantics of his system.

People sometimes say that Folgezettel has no particular meaning or intention, and that's analogous to how we don't know what noteB -> noteA means in tjex's example until he tells us what it means.

@ctietze and I had a private discussion about #transhierarchy (I'm still deciding about whether to start a public discussion about it) in which I said:

A big limitation of the account of transhierarchy in the paper is that the authors say that they deliberately avoid discussing any additional semantics beyond nodes and directed edges, but I suspect that anyone who wants to take full advantage of the power of transhierarchy will need to get deeper into formal semantics.

You could replace the word "transhierarchy" in that quote with the word "hierarchy" and I would still completely endorse it. If you want to take full advantage of the power of tree structures or hierarchies, you will want to make more explicit specifications of your semantics in a semantic schema. The notion of parent/child is not sufficient.

By the way, in the discussion about tjex's system we talked a little about the purpose of a discourse schema, which is a kind of semantic schema.