Intra-Zettels

I remember Christian emphasizing that a note was only the holder of a Zettel. Thinking about that has led me to start using Zettel IDs within notes as well. For example, I may identify a thought I wish to come back to, or feel like I could reference from somewhere else—but which is not yet ready to become its own note.

One place I've started using this is in reference URLs. Often, I read articles and write thoughts about the content. So I'll create a note for that article, with the URL and my comments included. But sometimes I capture additional URLs as I'm reading, that may contain significant additional insight into the main topic. And then I capture relevant thoughts about those secondary URLs, grouping them together, within the larger body of the note. This presents a quandary: Will that secondary URL eventually become its own note?

One way to preemptively address this is to use reference-style Markdown links, and give each URL a Zettel ID. This has the advantage of improving readability of the main body of the note, since URLs tend to be unpredictably long, and we have no current way to theme them into being less obtrusive.

So, for example, I might have a section like this:

Here is an additional reference that may be relevant to this topic: [^][201810170833]
While it seems unrelated, it's actually quite connected thematically...

This means that if I want to reference this URL multiple times in the note, it's simple and readable to do so, and if I want to reference it from another note, it's simple to do so.

It also means it's simple for me to break this URL into its own note in the future. I don't need to update a footnote numbering scheme, or worry I'm re-using an ID that's already been used. And even if I didn't update the original pointer to a wiki-style link [[201810170833]], it would still be discoverable.

Thoughts on this? My main concern is that it's a case of premature optimization.

Comments

Substantive articles are often relevant to multiple topics. So I may find myself reflecting on an article in one context one time, and a different context another time. It seems advantageous to be able to see the multiple branches of thought coming from that one article.

In a typical workflow, I may read an article, write a summary note for it, with a number of thoughts and quotes, and then later spin off some of those thoughts into their own notes. As I develop other topics, I may refer back to the article's summary note.

What I'm describing here is a case in which I'm researching something, and discover an article which is relevant to that topic. But I'm also aware it may be relevant in a larger way, or eventually develop additional trains of thought. So instead of immediately breaking this off into a separate note, I preemptively ID it, and continue to flesh out thoughts in the original context.

Later, as I break the topical note down into other thoughts and sub-topics, references to that article may appear in multiple sections, and can seamlessly be split into their own notes. This would lead to a situation in which the given article is referenced across notes. It could then be split into its own note, but would not necessarily need to be.

I remember Christian emphasizing that a note was only the holder of a Zettel. Thinking about that has led me to start using Zettel IDs within notes as well. For example, I may identify a thought I wish to come back to, or feel like I could reference from somewhere else—but which is not yet ready to become its own note.

Theoretically, you could put your whole Zettelkasten in 1 single text file and jump around between Ids using the "Search" function of your editor. (It's like a GOTO statement in code.)

One way to preemptively address this is to use reference-style Markdown links, and give each URL a Zettel ID. [...] This means that if I want to reference this URL multiple times in the note, it's simple and readable to do so, and if I want to reference it from another note, it's simple to do so.

Do you not repeat the reference definition in the other notes? That is, the line containing the actual URL.

If so, you violate the Principle of Atomicity. Not that this is a crime in itself, but it comes at a cost.

But sometimes I capture additional URLs as I'm reading, that may contain significant additional insight into the main topic. And then I capture relevant thoughts about those secondary URLs, grouping them together, within the larger body of the note. This presents a quandary: Will that secondary URL eventually become its own note?

My programmer mind is puzzled by this statement: how can the secondary URL "become its own note"? You'd have to create a new note with a new ID that talks about the URL. Is that what you mean?

I think I use a similar approach to links but with a different twist.

I use Ids with accuracy to the second, e.g. 20181018192612, to create MMD references for web links, e.g. [#20181018192612]: Some Person: "Really Amazing Topic", <http://youtube.com/videolink/>. I then re-use that same ad-hoc reference item in multiple notes on that video. This implicitly creates a cluster of notes around that link. It's like a proper a cite key, but not one kept in my reference manager. The overhead isn't worth the effort.

If I later find I want to talk about the video as a whole, I'd consider creating a new note about the video. I'd mention and use the same [#20181018192612] reference there to cite the video. And I'd include a list of relevant notes on the topic. This way, I'd have brought structure to that small cluster of notes regarding the video.

Now you could do the same, of course. But in the details on your approach, there seems to be a difference in what you actually do, what you want to achieve, and how you handle future wishes to extract a new note.

From what I gather, you'd not create a new note with a new ID that does mention and thus use the URL link ID. Instead, you'd take the URL link ID and use that as the new note directly. -- What do your Markdown links look like afterwards? To keep your example ID, would there now be a file like 201810170833 Interesting article XYZ.txt, and still a bunch of [^][201810170833] reference-style clickable links littered throughout the archive? Does the ID now point at two things, the note and the URL?

@ctietze said:
My programmer mind is puzzled by this statement: how can the secondary URL "become its own note"? You'd have to create a new note with a new ID that talks about the URL. Is that what you mean?

Yes.

I use Ids with accuracy to the second, e.g. 20181018192612, to create MMD references for web links, e.g. [#20181018192612]: Some Person: "Really Amazing Topic", http://youtube.com/videolink/. I then re-use that same ad-hoc reference item in multiple notes on that video. This implicitly creates a cluster of notes around that link. It's like a proper a cite key, but not one kept in my reference manager. The overhead isn't worth the effort.

This is very similar to what I'm doing. Except...

I'm driven to DRY (don't repeat yourself) these references up. So instead of having that URL repeated in multiple notes, I create one note containing the URL, and reference it multiple places, using the ID. That way, if the URL breaks or I find an additional mirror, I can update the URL reference note.

From what I gather, you'd not create a new note with a new ID that does mention and thus use the URL link ID. Instead, you'd take the URL link ID and use that as the new note directly.

Yes. This would function as both my citation management, and a summary note—potentially with links to other relevant notes.

To keep your example ID, would there now be a file like 201810170833 Interesting article XYZ.txt, and still a bunch of [^][201810170833] reference-style clickable links littered throughout the archive? Does the ID now point at two things, the note and the URL?

The reference-style clickable links are a bit of an anomaly here—only used in the first note the reference shows up. Everywhere else, I would reference it as [[201810170833]]. When I break the reference out into its own note, I would update the reference-style links to be normal [[201810170833]] links.