link-as-search vs link-as-direct
I've been doing all of my links as [[202005091413]] Name of file, due to The Archive prioritizing link-as-search, which I think is core to the discoverability aspect of Zettelkasten. However, I'm playing with a bunch of other markdown-based tools, and there seems to be a tendency to prefer [[202005091413 Name of file]]. This is what I think of as link-as-direct rather than link-as-search.
I'm thinking about my own implementation here, and I'm considering moving to link-as-direct for interoperability with other tools. I think the only thing I'm losing there is, in The Archive, not seeing related links by default. But, I also think that is solved by just I guess backspacing to the UID (or possibly using a KM macro to extract just the UID or something).
I'd like the thoughts of the community on this one. Am I missing something? Am I going to break anything? Anyone have a script for converting all the links in my thousands of files to their equivalent filenames?
(also mods feel free to move this if you disagree with my category choice, I wasn't sure where to put this.)
Cheers!
Howdy, Stranger!
Comments
What "other markdown-based tools that seem to be a tendency to prefer
[[202005091413 Name of file]]. "As I get better at titling notes I am tending to change revisited old note titles more and more.
Something I wouldn't be freely able to do with a "link-as-direct".
I recently found 3 notes all titled "Writing as Thinking" each with different UID's. (Don't tell the Zettelkasten god's.) I'm currently refactoring, combining them, and renaming the result. This would be a big event dealing with a bunch of "link-as-direct" links, trivial with "link-as-search".
Will Simpson
My zettelkasten is for my ideas, not the ideas of others. I don’t want to waste my time tinkering with my ZK; I’d rather dive into the work itself. My peak cognition is behind me. One day soon, I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
kestrelcreek.com
Most notably I'm playing with Obsidian, which is (speaking very broadly) trying to replicate some of the better functionality of Roam but in local markdown files. They already have very good finding related notes and backlinks functionality. The devs are building a plugin system, with one of the express purposes being to choose between link styles.
Also I'm experimenting with Devonthink applied to my ZK (as a way of connecting it to other non-zk files), and it wants direct links. It's also been pointed out that Bear and a few others do this as well, but that's a whole other set of questions about interoperability.
This is true. And, this is another reason I've been avoiding this, but 1) practically I find myself doing this pretty rarely and 2) Obsidian also has plan to automatically propagate changes throughout one's zk. And also, it seems to me that in the extreme case a relatively simple script could do this.
Obsidian sounds interesting. I've applied for early access. Must still be in a tight beta. I do worry when I read that a lot of functionality is plugin based. While that might work well for EMACS, my past experience has been not so smooth. I worry about a favorite plugin becoming orphaned.
I've 'applied' Evernote as a sort of document archive. Connecting it with non-zk files, mostly web clippings, and PDFs. I use KM to create these links. This isn't as pretty as some other implications but this works and we'll see the changes when @ctietze integrates Full MultiMarkdown Support & Inline Image Preview.
Source: https://zettelkasten.de/the-archive/roadmap/.
In The Archive
In Evernote
I use The Archive's ~/media folder a lot and fill it with dup files there as space is not an issue. This works for any file type.
In The Archive
Will Simpson
My zettelkasten is for my ideas, not the ideas of others. I don’t want to waste my time tinkering with my ZK; I’d rather dive into the work itself. My peak cognition is behind me. One day soon, I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
kestrelcreek.com
Obsidian, NVUltra, Bear, Devonthink, Roam (sorta markdown), Tiddlywiki (can be markdown). All use standard filename links.
With full filename links, your links work in any of those apps (and still work just fine in 'The Archive'). This allows you to view your notes in any of those apps and the links work! But in EVERY case but 'The Archive', if you click a UID link like this:
[[202005092100]] Hi Momit makes a new note called202005092100.Pluses and minuses to both ways of course, but 'app-interchangeability' in a profound advantage to filename links in my opinion.
Full disclosure, I started down this path because @eiff convinced me. So his opinion is biased
@will when you get in the Obsidian beta, say hi to me on the discord. It's a pretty lively community over there, with a bunch of folks from here.
Just wanted to note that nvpy Kinda does both: if the text in a link matches a note name from the sidebar, it loads that note in the editor. Otherwise, it treats the link as a search term to do a full-text search across all notes.
Personally, I modified a copy of the code to always do a search first, and then if a note matches exactly, load that note in the editor pane. If I had either back/forward navigation for those clicks, or just multiple tabs to keep other searches faster to bring up, it'd be an even greater note browsing experience. Editor-wise, it needs some love, but the code is open for that as well.
Yeah, that's pretty much the behavior I want. I feel close enough to that by just deleting the non-UID part of the result, it's a minimal amount of friction.
I like how like the first thing they say is "it's ugly." Admirable honesty.
I’m currently reconsidering my links as well, for the very same reason. Right now only using the UID, but going for “direct links” is tempting, even tough readability suffers.
@mediapathic, what did you decide to do?
I have one idea: Keep [[UID]] as a “search link” in the meta data header for each note. That means I could easily follow the direct link to a note and then click the search link and get all references to it. Perhaps that would work as a compromise.
I've struggled with this, too. I much prefer [[UID]] linking since the links won't break. It makes me more comfortable tweaking titles to be more descriptive. Only Zettlr and The Archive have in-built links as search, though. I love the mapping function of Obsidian, but using [[UID]] adds blank nodes to the map that are titled with the UID.
I wonder how hard it is to implement links-as-search functionality in these programs. Maybe we could request it? I don't know anything about programming, but it seems like it could be a settings toggle that swaps between links acting as direct links or just populating the search bar with the linked text. Worst case, maybe this could be implemented with Keyboard Maestro?
Even though [[UID Title]] is better supported by multiple programs, I'm much more comfortable using [[UID]] as links. Putting the note title inside the link just doesn't feel sustainable to me in the long run. Maybe I'll regret this in the future, though, if I ever stop using The Archive or Zettlr and am faced with the prospect of manually searching every time I want to follow a link.
ORCID: 0000-0003-2213-2533
Being free to evolve a zettel's title is paramount. The [[UID Tite]] link is stifling. I think these other programs have got it wrong.
Will Simpson
My zettelkasten is for my ideas, not the ideas of others. I don’t want to waste my time tinkering with my ZK; I’d rather dive into the work itself. My peak cognition is behind me. One day soon, I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
kestrelcreek.com
I see it as different implementations using the same syntax.
The Archive lacks an implementation as a link and the other apps lack an implementation as a search. Search works as a linking and searching which makes The Archive so compelling and the other apps limiting in terms of folks coming from or to The Archive.
Until the apps find and adopt a common distinct syntax for each different functionality that we can easily use we will have to rely on import and export scripts.
Obsidian has this:
We probably need a set for The Archive that allows seamless transition in and out of The Archive.
Until some bright developer comes up with a solution I think we will have to depend on migration scripts.
I was happy to see this discussion Future proofing my Zettelkasten – file names and linking, because this topic definitely has future-proofing considerations. I was going to post over there but then saw this discussion gain some traction.
I also struggle with this issue. I hope the discussions continue.
The format we chose adheres better to the software-agnostic concept. This is a decision you have to make as a user. Even if the majority of note taking apps use another convention and just few use link as search does not change the fact. You can opt however for more software dependence to use those features. I, personally, did opted against it way before I became part of the The Archive Super Duo of Doom.
This is part of the software-agnostic approach: Sometimes, it is not the most convenient approach available right now. But I rather now that my Zettelkasten works with any ordinary editor than making me dependent on any software ever again.
Changing titles does not need to happen often. I fiddle with the title a couple of times per note creation. But sometimes I want to change a title of very old notes. It is rarely but if it happens it would be more than just a convienience to change a couple of dozen references.
I think that is one of the big issues: There is very little experience with big archives, year-long practices and people, who actually try to perform on a high level. I see this frequently in all the communities (mostly on reddit, though). There is very much mechanical and theoretical talk which is ofte inspiring to me. But it lacks experience and long-term perspective. Even we, on the level of software, did change our opinions on what works and what not, just because we saw how big Zettelkastens behave differently. The same is true on the level of the method which is more my stick. I ran against the wall a couple of times with each level of complexity until I accepted that I need to plan for the extrem cases.
But I think with some mass replacement scripts conversion between the apps should not be too much hassle.
tl;dr: Link-as-search is the software-agnostic way. It is a personal decision on how dependent one wants to be on software.
I am a Zettler
But isn’t being software agnostic and how to treat links two separate questions?
As long as all notes has an UID not only in the file name but also in a YAML front matter or similar and all internal links use that UID, at least as a part of the link, you have the possibility to open the notes folder in any editor that has a function for Search In Folder?
If one software treats those links as search and another as actual links doesn’t matter?
My point is that there is a tremendous value in those UID’s, even if there are software alternatives that doesn’t require them.
This also means that I’m hesitant to stop using UID’s and are not concerned with the risk of lock-in. I can’t see how that would happen. As long as the UID’s are there, it should be possible to manipulate the actual link syntax with RegEx. Without UID’s, such operations would be harder to do.
Just coming in again after a long time away, and catching up.
@thoresson to answer your question; I've largely moved to Obsidian, and am taking full advantage of its ability to automatically change links in all files when a file name is changed, and enforcing unique filenames. I'm not putting a UID in any new file names, though most new files get a YAML block with a
uid: 202009251805entry. My hope is that that will be enough if I decide to go back.I agree with everything that @Sascha said about agnosticism. I am well aware that my approach is not the best for software agnosticism, but I think it's good enough for what I predict my future need will be (e.g. the UID is still there, if I'm doing a full text search), and the conveniences it provides me within Obsidian (and emacs, actually) are worth it. I could well be wrong about all of this, but given the nature of the way I work, most notably the fact that I am rarely using ZK in the usual manner of academic writing, I feel like I can afford to experiment.
So, short form, what did I decide on? Probably not what you want to be doing
.
I finally took action to start a Zkn after reading this site for a few months. I created several text files named with date/time stamps, and within 24 hours I had deleted the stamps and gone to 100% search.
The stamps were UGLY, and they required wider columns than I am used to, in order to still read the file names. I am used to changing file names often.
I have some ideas about linking to anchors in the file, like the "#" URLs in HTML, and allowing more than one in a file. They refer to a spot or block in the file, rather than the whole file. As a C/++ programmer, I am used to file boundaries being arbitrary and the blocks inside the file being the real units, and I feel a sense of lightness and "lower bar to entry" if I don't have to worry about right-sizing my files. I'll just split them up and recombine when I want. There are some notational things to work out, like distinguishing a "target" anchor from the links pointing to it, and that makes me think of allowing both directed and undirected graphs. Since both can be implemented as structured tags, there is a possible design of "everything as a tag," but I am not sure what will work out best.
I'm using Visual Studio Code, whose "Find in Files" command is already sufficient to perform any of this searching manually without too much trouble once suitable notation is in place. Once I lock on to some patterns I like, I'll speed up the process by finding extensions or learning to write my own.
@thoresson
There are behavioral issues of migrating from one app to another. The conveniences you take for granted on one app will create a habitual barrier. Technically, all can be there if you want to change the software but you will have increasing difficulties to change yourself.
It is evident in the complaints on speed. Imagine what Luhmann had to go through with his paper ZK. Now, we (me included..) complain about one click to much.
I am personally very strict because I know that I need to be high performing for decades. So, I adhere to the majority of safety measures. (digital, behavioral etc). But there is nothing wrong with rational risk taking, like @mediapathic does. If the ID is somewhere in the file someone will find a way to export the ZK to different formats.
Just want to highlight this quote. To me, it was work to build this intuition.
I am a Zettler
Welcome to the forum. I'd be interested in hearing how your work with Visual Studio Code progresses.
I too have been thinking and experimenting with placing anchor links as a way to link into a larger file. I like how you put it about not having to right-size my files. Some notes are formulated as classic zettel, atomic and some are not, why worry?
My idea is that not every block of text should have a link but that I can intentionally create links and apply them to anything I want. I've been enamored by what I call selective textual transclusion. Better explained visually.
The Katrina note is compact but the Cognitive bias cheat sheet is a bit longer. The reference relevant to the Katrina note doesn't reflect the whole Cognitive note, but just the "In order to stay focused, we favor the immediate, relatable thing in front of us over the delayed and distant" reference. The link does not have an intermediary note. Quick and easy to find the reference.
The nice thing about anchors is that they can be reused so potentially I can create one-to-many relationships with this type of linking.
I differentiate note links from anchor links [[202009210907]] ›[[202009241145]]‹ respectively as the search behavior is different.
GIF image.
Will Simpson
My zettelkasten is for my ideas, not the ideas of others. I don’t want to waste my time tinkering with my ZK; I’d rather dive into the work itself. My peak cognition is behind me. One day soon, I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
kestrelcreek.com
@Will,
This is exactly what I am thinking!
I'll label link targets when I first link to them. I got the idea from @Glade 's Atom plugin (though I think he moved it to VS Code), in which you generate a link and then paste it into the source and target--at least that's how I understood it. I don't want to be tied to Markdown though.
I have a loose set of heuristics I tend to use in plain text, and I'm usually not trying to convert to HTML or publish. I'd much rather have easy single line-breaks in my notes to myself without goofy line endings or tracking which plugins are GFM and which are not. I'll keep .md files right next to my .txt files for when I want that GitHub look. "Links as Search" means I don't care whether all of my files have officially the same link format. I'll automate what I can and hit Ctrl-Shift-F for the rest, or Ctrl-P which I think in VS Code opens the filename under the cursor. (Sure, I'd love to use just one "real" format, but I haven't found one that I like enough! And I tried... see Wikipedia on lightweight markup languages).
I like the VS Code extensions that "do one thing well" and hope to mix & match them. For instance, there's a nice-looking table formatter so I can have org-mode's nice tables without having to bring along all the rest of org-mode that I don't care about, or >shriek!< use Emacs. And they look about the same as Markdown tables, so hopefully it can be customized to support both or else I can hack on it. For links, I'm not AGAINST filenames, especially for opening non-text files. A wiki link or Markdown link seems a perfectly fine way to open an image or spreadsheet or something, where you can't put a search-anchor inside it. Org-mode's text styles are the best and most consistent, in my opinion (*bold*, /italic/, _underline_, ~strikethrough~)--another reason not to lock into Markdown but mix & match the best and allow several popular variations.
We need a "block" notation for these search anchors. I use two blank lines in my notes to denote a new section, so I will probably start with blocks between double blank lines. Some kind of "{" notation also appeals to me as a programmer, though I am not excited about parsing to match nested open & close brackets. Unix "here document" notation is tempting, as it lets you set your own begin/end pattern in line, so you can always pick something that doesn't appear in the content.
TRANSCLUSION!! As a recovering TiddlyWiki user, I care about this. But I had a revelation: the AUTHOR should not decide to transclude. The READER should. So, insert a link, and let the reader decide whether to open it in a separate window or transclude it inline. VS Code's symbol navigation is great at this, and one of its "notes"-type extensions leverages it to let you "Peek" at linked notes inline or open them separately. I think it was the "Suping up VS Code..." extension by "Kortina," but I may not be recalling that properly.
Anyway, clearly I am at the "gathering options" stage while I just keep on searching manually, but soon (I promise myself) I will narrow down the options and commit to something!
Thanks for the welcome.
@bgj99co, @will : I want to note here that in Obsidian development we have been talking a lot about linking within files, as many people come to Obsidian from Roam, which has the ability to link to arbitrary paragraphs (because it's not limited to markdown). The main stopping point for that has been not wanting to stick users with a solution that is not portable to other software. But, we do have linking to headers, e.g.
[[Name of file#Name of heading]]. It's a pretty good solution for most things, and while it doesn't translate directly to The Archive, it might give you another option to consider.Also your putting of the UID in the text as an anchor is something that I've been doing for a while, not only in my ZK but in all manner of files all over my system. I have some KM macros to do a full system search on a UID string, which means I can basically link anything to anything else that has searchable text in it (including filenames). I like the
>[[convention]]<, though, I may need to adopt that.I did paragraph specific linking for quite some time. I just asigned an ID to the paragraph as if it was a Zettel. Functionally, asigning an ID to a paragraph makes this paragraph a Zettel: Now, it is an atom you can refer to. This practice disjoints the boundaries between files and Zettel.
I personally consider this a methodological mistake with the digital Zettelkasten Method. However, there are some use cases to have longer or even very long files. Then it can become handy.
But together with my coaching experience, I think it indicates a problem with the source material or the research object. It is not the end of the world but it is more clean if you work on sorting that issue out instead of accepting it as part of the tool box: Mistakes are ok, but don't make the mistake to mistake mistakes for something other than a mistake.
I am a Zettler
One thing to keep in mind with @Will's
>[[202009302000]]<convention: things that need addresses might become their own Zettel in a future extraction process, and then the>...<part will be outdated and the chevrons need to be removed to denote a "real" Zettel again.Author at Zettelkasten.de • https://christiantietze.de/
I think I read a post of yours about this! But I could not recall whose it was.
Very interesting. I will take this to heart.
A lot of my files are like running logs. The work done on my car, the contractors who have fiddled with my house, latest episode I have heard/seen in a series...
I know this is not the textbook use case of a Zettelkasten, and I can see how the atomicity is much more critical for cross-linked intellectual content. These logs are sort of anti-Zettels I guess, as they have an inherent internal sequence. Yet, linking to them from the outside is valuable, such as linking to a specific car service item from a note about, say, personal finance and the issue of whether to buy a new car this year.
The log seems like a folgezettel, really. You read it in sequence but also link in arbitrarily from outside.
Other log-like files are lists that I always want to see together but again have individual atoms that could be linked from outside. A list of books to read, complete with URL and description and personal note of why I want to read it, for each book. I would practically never want to see one book by itself, as opposed to viewing the whole list and picking the best one to read next or reordering them, but I might link to one from another note, if writing that note reminds me of a book I remember adding to the list.
I guess it's really a shortcut vs. forcing oneself to create structure zettels to function as the log/list. If you immediately know you'll need a structure zettel, might as well let the log serve that purpose? I had not thought of any of this before--I just thought I was being lazy. "Writing is thinking"!
For intellectual content and creative re-expression, I can certainly appreciate the need to keep things atomic. Without a clear sense of some thread immediately demanding a container (log/list), my path of least resistance is to just make a little file. The ability to link resolves the fear of forgetting it as soon as I press Save! Or struggling to find the right category ("list") for it. I am very excited about that.
I will continue examining this. Hopefully I have hit on the main issue above but perhaps some more will fall out. I like your quintuple-"mistake" sentence, very clever. Thanks for the feedback!
You're right indeed, future refactoring might convert an anchor link to a zettel link. And yes, I would want to remove the chevrons mostly for esthetic reason and not for functional. During any refactoring a new zettel would be created with a wholly new UID replacing the whole string.
Will Simpson
My zettelkasten is for my ideas, not the ideas of others. I don’t want to waste my time tinkering with my ZK; I’d rather dive into the work itself. My peak cognition is behind me. One day soon, I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
kestrelcreek.com
It's fine. In German weight lifting technique, there are two terms that come to mind: "Ideal technique* and individual technique. You learn first the ideal technique until you are proficient. Then you alter the technique to adapt it to your personal needs.
This is an example on a more general principle on how to learn effectively. (Skipping the drills in the first phase is the most common mistake in any field I observed).
I am a Zettler
I find that quite odd: you have an address that is used to express/denote a certain topic already, and probably incoming links from other Zettel, so why ditch this established address? Did you run into problems, do you just want a fresh start, or something different?
Author at Zettelkasten.de • https://christiantietze.de/
I note that Obsidian is moving toward using the YAML frontmatter section exclusively for plugin usage. As of now, your frontmatter will show as a code block when you preview the document. This means losing most of the existing usage scenarios for YAML/frontmatter, at least the way most people use them inside of markdown files.
To me, this moves Obsidian in a proprietary direction, risking having your ZK trapped inside a garden vs. plain text files. This has stopped my Obsidian experimentation dead in its tracks.
My ZK is not so large that I can't strip all of the YAML and put it into the body of each note, but I have to think about this and whether or not it is a workable solution. In the meantime, seems like a good time to finally download and test The Archive...
@donblanco I have transitioned to Obsidian and like the app very much. Can you explain a little bit more as to what the shortcoming is and how it is a determinant? Thanks for your time.
It seems they just changed how tags work. I am only going by what many in the forums are complaining about. No way to sort or graph by tags, etc. Needing to move tags outside of normal YAML/frontmatter section, etc. If indeed they treat the frontmatter section different than other programs then all my existing Zettel files w/ extensive frontmatter become potentially useless...
@donblanco Thanks I will check out Obsidian forum and get in on the discussion.
I confess I may have mislead. I've not yet ever refactored a note and had to deal with the anchor UID. I only have just started using links to point into a zettel (anchor links in 12 notes). I am only guessing how I'd handle the anchor UID. I use the anchor UID when linking into longer zettel. If I refactor the longer zettel into atomic zettel each with their UID's then the need for an anchor becomes unnecessary. The original anchor is better pointed to the appropriate zettel now.
That was my thinking when I made the aforementioned post. Thinking this through a little more I think keeping the anchor UID, even if it appears on the surface to be redundant, may makes more sense. As you point out there may be more than one reference using the anchor. Once you start messing with UID's who knows what will happen and what work you'll create for yourself.
Will Simpson
My zettelkasten is for my ideas, not the ideas of others. I don’t want to waste my time tinkering with my ZK; I’d rather dive into the work itself. My peak cognition is behind me. One day soon, I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
kestrelcreek.com