Zettelkasten Forum


Transitioning links from Obsidian to the Archive

Hi everyone!

I'm in the process of switching over from Obsidian to the Archive, in an attempt to make my note taking less distracted and more future-proof. As I understand it now, the best way to future-proof linking files is to enclose only the note ID in square brackets and put the title outside of it, instead of enclosing the whole title in brackets. I realize that by doing that I'm giving up easily linking whenever I go back to Obsidian, Zettlr, Bear or other note-taking apps, right? While this is of some concern to me, my main concern has to do with the seemingly immense work that would go into changing all the links in my Zettelkasten to this new format. I currently have around 700 notes and I don't even know how many links. To do this manually would take so much time and energy that I'm doubting if it's worth it. Does anyone maybe know of a way to do this efficiently, without having to manually change all the links?

«1

Comments

  • @3210163 welcome to the forums.

    You are escaping Obsidian for the same reasons I can't see myself switching to Obsidian. After spending time with The Archive, the distracting environment of Obsidian is a non-starter for me.

    What you ask might be doable. But I question why? Don't the links from Obsidian work in The Archive? I suggest settling into a link format you are comfortable with and, from now on, use it. You'll quickly be able to tell pre The Archive from post The Archive links. In your example, you want to change a title of a link from the Obsidian days. I'd deal with it then. The likelihood of this coming up is low.

    How do your links look? What is the filename of the link? Please show us a sample.
    I remember at one point, I switched the formatting of all my links early on, but I can't remember how. Old age is my excuse.

    Will Simpson
    “Read Poetry, Listen to Good Music, and Get Exercise”
    kestrelcreek.com

  • As far as I remember Obsidian, there is a feature that asigns IDs to every note. So, the process would be:

    1. Asign an ID that is part of the filename to each note by that plugin. But because the time-based ID can be created by using the meta-data of each file a script could be used also.
    2. Obsidian should take care to update each link within the file like to something like "[[202204070757 A super note]]"
    3. If you use multiple vaults put all notes (anything with an ID) into your ZK folder.
    4. Open the folder with The Archive and you're done.

    I am a Zettler

  • @3120163 said:
    I'm in the process of switching over from Obsidian to the Archive, in an attempt to make my note taking less distracted and more future-proof.

    @Will said:
    You are escaping Obsidian for the same reasons I can't see myself switching to Obsidian. After spending time with The Archive, the distracting environment of Obsidian is a non-starter for me.

    This is, by the way, one of the core design principles of The Archive. My prediction is that we starting from a few-feature-phase (nvALT) to a bloat phase (currently in) back to the world of distraction free editing (where The Archive already is).

    Especially, in note making (being creative) a distraction free environment is paramount.

    I am a Zettler

  • edited April 7

    I use both Obsidian and The Archive, although I mainly use Obsidian for the Kanban boards and the Dataview plugin.

    The biggest problem I found was also as you described. When using The Archive, I have been enclosing only the Zettel ID in square brackets with the Title outside. Unfortunately, Obsidian (and likely many other apps) does not support this which limits the ability to share notes between apps.

    So while I have previously used this linking strategy with The Archive, I am no longer doing so as I now consider it a potential "lock-in".

    What's nice about Obsidian is that it allows you to automatically update internal links when renaming files (@ctietze I think this could be a very useful future feature of The Archive).

  • @3210163

    Start fresh with The Archive and pick up where you left off in Obsidian. Then bring notes over to The Archive as you need them. As your notes grow in volume in The Archive, you can leave the weeds, propagate the flowers, correct mistakes you have made, and improve your skills.

    Making notes is more valuable than the time messing with notes.

    Free yourself from the burden of those 700 notes needing to be mass migrated. That, too, is a distraction.

  • @Will said:
    You are escaping Obsidian for the same reasons I can't see myself switching to Obsidian. After spending time with The Archive, the distracting environment of Obsidian is a non-starter for me.

    Spicy!, @Sascha even bolded distracting environment. In my personal experience, of having used Obsidian since beginning of 2020, I don't find it particularly distracting. Reminded me of a Cal Newport podcast episode I heard recently where a student was concerned about getting distracted by YouTube recommendations and Cal told him just ignore them... That is the same approach I'd have in this scenario.

    No is forcing you to use the extra features, such as backlinks or graph view. I hardly touch the graph view and basically use the software in much the same way that someone would use The Archive I imagine. I even made an archive copy cat theme for fun, that has the headers all the same size and displayed.

    P.S. sorry OP for being combative on your thread and not being helpful. I've been wishing for awhile that Obsidian gives alternative options for how it handles linking, so that It would be in line with Zettlr and The Archive. Perhaps this will change in the future when they come out with their Plugins API.

  • edited April 8

    In my personal experience, of having used Obsidian since beginning of 2020, I don't find it particularly distracting.

    Self-reporting is, sadly, notoriously bad. This is an issue for both science and self-development. I battle this issue in during my coaching all the time. It is hard to get a accurate picture of anything related to introspection. Copied from my ZK:

    Ward et al.1 found a deterioration in working memory and fluid intelligence in their experiments, even when the smartphone was turned off or placed on the display. Such measures are futile, the authors write. When the smartphone was in another room, the scores improved significantly. But the question is whether these are actually values that the participants would have achieved if they did not own a smartphone at all.

    There is a good reason for distraction free editors with minimal features. The brain is dividing ressources in the presence of potential sources of information to be receptive. You can track this phenomonen back to how the different states of being prey or predator are instantiated in the brain. (Hat Tip as always to The Master and his Emissary).

    EDIT: This is, by the way, one of th reasons taking notes on the smartphone is furthering the damage smartphones do to your brain anyway. (And part of the reason why I don't even own a smartphone)

    Reminded me of a Cal Newport podcast episode I heard recently where a student was concerned about getting distracted by YouTube recommendations and Cal told him just ignore them... That is the same approach I'd have in this scenario.

    That is bad advice. Ignoring is in itself a cognitive task for the brain. Focus is about both reducing distractive elements in the environment, increasing the number of enriching ones (like plants) and train yourself to focus. Distraction can be used to train yourself like Goku used weighted clothing but it is always additional resistance.


    1. Adrian F. Ward, Kristen Duke, Ayelet Gneezy, and Maarten W. Bos (2017): Brain Drain: The Mere Presence of One’s Own Smartphone Reduces Available Cognitive Capacity, Journal of the Association for Consumer Research 2, 2017, Vol. 2, S. 140-154. ↩︎

    I am a Zettler

  • edited April 8

    @Sascha I have been using Firefox as my browser of choice for a while. Whenever I open a new tab, to say do a search or just go to a web site that I visit frequently, Firefox first opens a page with a slew of links to interesting Pocket articles. The temptation to start reading about the links and even following them is overpowering - so much so that, at worst, I frequently forget why I opened the "blank" page in the first place, or at best, waste reading time pursuing inconsequential articles. This is highly embarrassing and an egregious example of being distracted, but I mention it to make a point supporting the idea of removing distractions from our work environment. I discovered that it is possible to turn off the "recommended by pocket" function in Firefox, which now produces a much simpler and distraction free "new tab". But you are correct - I can't ignore the suggestions; I have to remove them from my sight entirely.

  • @GeoEng51 ⌘, in Firefox, go to "Home" -- I find the clickable quick links row to be useful more often than not, but the rest is gone.

    That's as good as it gets :)

    Make sure to remove sponsored content to reduce tracking. Also from the "General" settings at the bottom:

    Author at Zettelkasten.de • https://christiantietze.de/

  • edited April 8

    Self-reporting is, sadly, notoriously bad. This is an issue for both science and self-development. I battle this issue in during my coaching all the time

    @Sascha sure, I'm just giving another perspective, which is what is mostly happening in these forums?

    That is bad advice. Ignoring is in itself a cognitive task for the brain.

    Ya, I was being hyperbolic/sassy, I know that environment does matter. But Obsidian is highly customizable in terms of the visual design and whether you want certain buttons/features to be available. I just don't buy the argument that it is some distraction machine, sucking your cognitive attention, such that you can't do a meaningful amount of knowledge work. If that was the case very few people would be using it I imagine.

    In my sassy opinion/unjustified again, I think the biggest bottleneck for people is that of broad energy management (isn't lost on me that energy gets sapped by a million small distractions) or having a good workflow.

    The more persuasive argument from the OP is that it isn't future proof. Which also reminded me that people say the paper zettelkasten is future proof because it doesn't rely on changing format, but it isn't backed up and susceptible to house fires.

    P.S. also not lost on me that this is a dumb response of mine, as it isn't helping OP, making me question what I'm doing with my time :o

  • While I agree with @Sascha about distraction (as I am concerned about concentration) and resistance, I also agree with @Nick :

    @Nick said:
    I know that environment does matter. But Obsidian is highly customizable in terms of the visual design and whether you want certain buttons/features to be available.

    My workspace looks like that in full screen while writting :

    I know it is not the same as The Archive, but it is not so bloated after taking time to calibrate. And yes… you need to take time to calibrate.

    I have succeed to obtain that too :

    If I understand well the question, @3120163, you need to come from : [[MyUberZettelFile]] to that : [[MyUberZettelFile]]Title ?

    I can't see an automatic and easy way to obtain this without handling each file manually, or using a little py code that would do the trick (I know they exist to manipulate md and txt files but don't look at me like that, I become dumb when the code comes in town…).

    First of all, I would create alias for every non expressive files names with frontmatter. When I type alias on my brackets, Obsidian suggests it and you end up with a link like that : [[MyUberZettelFile|alias]]. After that, I would open Sublim text, find all, selecting the pipe character "|" and replace it with "]]" and put a small thing in front of the useless brackets. I would do the same for the useless ones : "µ]]" suppression, et voilà !

    Like @MikeBraddock I would limit myself to useful zettels at first, and making things sweet and smooth, in progression.

  • edited April 9

    Dang. I wrote more confrontatively than intended. I apologise!

    @Nick said:

    Self-reporting is, sadly, notoriously bad. This is an issue for both science and self-development. I battle this issue in during my coaching all the time

    @Sascha sure, I'm just giving another perspective, which is what is mostly happening in these forums?

    I understood. I just wanted to highlight that ones subjective impression in suprsingly bad. I think we need to place ourselves under suspicion in quite a lot of environments and rebalance the ratio of trust in our intuitions and suspicion.

    That is bad advice. Ignoring is in itself a cognitive task for the brain.

    Ya, I was being hyperbolic/sassy, I know that environment does matter.

    Ah, I was refering to Cal Newports advice. Not you following his advice.

    But Obsidian is highly customizable in terms of the visual design and whether you want certain buttons/features to be available. I just don't buy the argument that it is some distraction machine, sucking your cognitive attention, such that you can't do a meaningful amount of knowledge work.

    I little bit strawmany. :)

    I personally think that Obsidian is a very fine app compared to a lot of apps. It is very many upsides. But it does not deliver a good environment for creative work compared to other apps.

    There is a good reason why quite a number of app designers decide to limit the features (like iA Writer). Even the possibility in the background is distracting.

    Of course, the distraction is limited if you adapt an app like Obsidian in a way like @Loni does. Perhaps, even so small that it could be ignored. However, I see a lot of bloat on the screens of people.

    If that was the case very few people would be using it I imagine.

    People even put poisonous food into their bodies and watch themselves get sick while thinking everything is fine.

    In my sassy opinion/unjustified again, I think the biggest bottleneck for people is that of broad energy management (isn't lost on me that energy gets sapped by a million small distractions) or having a good workflow.

    I agree in part. For many people it is.

    P.S. also not lost on me that this is a dumb response of mine, as it isn't helping OP, making me question what I'm doing with my time :o

    A little bit of offtopic rarely hurts. :)

    I am a Zettler

  • @Sascha said:
    There is a good reason why quite a number of app designers decide to limit the features (like iA Writer). Even the possibility in the background is distracting.

    And I hate IAWriter with my whole heart. When you spend all of your day in your writting app, at least choose a color that does not hurt your eyes and choose a font are essential to feel "at home". I dislike their typos and their "not so white" and grey-dark background hurts my eyes badly. I hate the feeling of being treating like a stupid child, unable to pick by my self only one color and one font. I am not the only human on earth who suffers from migraines, headaches, eyes problem either.

    Let me told you about FocusWriter :

    You can choose background, font, colors… And then you feel at home. It is like choosing pen and paper before writing, it is really personal from my point of view. I come from design and illustration, maybe it explains but…

    • Ergonomy is inclusivity. Yes, I would rather risk a little bit of distraction if it means allowing someone with specific problems to be able to use my (non existant, I am afraid) app.
    • Personnalisation is implication : making some little changes links the user with the product they use. They make it "their", they don't want to quit it. The most extreme example is : how many Emacs users fight against Vim users ? Because they invest SO MUCH time to developp their workflows, habits and customisation into the soft that they can't even tolerate that anybody says they don't want to use it.

    And there, something specifically related to my dark side : I really feel that only three fonts and three colors is like developpers telling me "Hey we know better than you what is good for you". No one do that.

  • @Loni iA Writer might be a bad example since I ditched the software for the same reason like you. :D

    I am a Zettler

  • Thanks everyone for your replies!

    I have now transformed the links from [[Note title]] to [[ID Note title]]. I think I'm just gradually transform them to [[ID]] Note title as I encounter them, so that when I change the title of the note, the link won't be affected.

    As for the discussion about Obsidian, let me clarify a bit what I meant. I just noticed that I became quite distracted by the endless possibilities of the seemingly endless supplies of plugins. At the same time, what bothered me was that I even need plugins for seemingly basic things, such as a clean interface and distraction free environment. I installed plugins like Stille and Fullscreen focus mode, but they seem to be unstable, causing my laptop to crash. These issues could probably be fixed, but I don't really want to spend my time fixing issues when I could be doing the work.

  • Try "Focus mode", much better. I don't know for Stille, but Focus much works better than the "Fullscreen focus mode" plugin.

  • edited June 14

    Speaking of ia writer, it got support of wikilinks today :) https://ia.net/topics/ia-writer-6-now-with-lasers

    It's a bit peculiar that title [[ID]] or [[ID]] title format seemingly has more popularity lately, but The Archive 'copy link' logic creates links the same way obsidian/ia writer do, for example: [[202012061631 the archive]]

  • Both IA Writer's and The Archive's wiki links in the format of [[202012061631 the archive]] are sensitive to file name changes. Using the format title [[ID]] or [[ID]] title allows changes in the filename, or you can completely remove the filename and refer to the target with only the UID making an interstitial ad-hoc link.

    I wonder how this might affect the long-term usability/lock-in of the different wiki link formats. Apps that manage filename changes with database calls are not without their other problems.

    Will Simpson
    “Read Poetry, Listen to Good Music, and Get Exercise”
    kestrelcreek.com

  • That iA Writer finally incorporated wikilinks is great news, but in all honestly, I'm a bit disappointed in how it's implemented as I was hoping to use iA Writer on iOS as a companion to TA. I've grown so accustomed to wikilink-as-search in TA, that for me at least, any other software is a deal breaker (as far as being used as a ZK).

    But as I thought about this some more, it's understandable why they (and others) treat it this way: what else are they going to use for linking for those that do not use UID's? They really do not have any other choice for linking other than the file name.

    This also makes me appreciate UID's and TA that much more because the wikilink-as-search method more readily allows for linking knowledge rather than just notes. (Which is not to imply that users of other software do not do the same.) A UID is adaptable to any context that the writer contextualizes for it. A static title (as link [which does not updated if changed in iA, btw]), however, may actually interrupt the the context by its semantic intrusion.

    Here's to hoping that TA will eventually have an iOS companion... (but in all honestly, all my knowledge work is done on my Mac anyway, it's just nice to have options...)

  • edited June 15

    I use iA Writer with a mixed approach. I write my links as [[UID Full-filename|UID]]. They visually show up as just the UID, but have the benefit of not being locked into one piece of software, as most apps support wikilinks of this format. And, if I ever change the filename, it's trivial for me to search the UID to find the original file again. For me, this gives a good compromise between future-proof and practical day-to-day.

    If I ever change apps (totally possible) then it's not a huge headache.

    To the OP, if you do want to do this sort of large scale text change (I would personally recommend sticking to broadly-supported wikilinks, but I understand TA has a different approach) then your best bet is to hire a programmer to write a script to change them for you. Make sure you do a backup first. I've used code to do batch changes to my notes in the past.

  • I checked out the new version of iA Writer, but as others have noted, it doesn't handle links the same way as The Archive (TA). TA will take a link like [[202206122253]] and go find the file which has the full name of "202206122253 My Paternal Grandparents.md" in my ZK folder. I don't think iA Writer will do this (and neither will my other favourite program, NotePlan). But I'm not going to change from TA as my primary ZK app, because I like it so much.

    I'm not 100% sure about iA Writer and file names. I've tried opening one markdown file from my ZK and then clicked on an embedded link like the one I show above. iA Writer has a problem because it won't go look in the folder from which it just opened one file - instead I get an error message (on the Mac, "No Content to Preview"; on my iPhone, "Cannot access items outside library - please make sure that the Library Path is correct"). Unfortunately, I can't see any way to set the Library path, either in the iOS app or in the Mac app. The error may have something to do with me storing my ZK files on a DropBox folder, but I don't believe that is the case.

    By the way, 1Writer (on iOS) will access UID-only links like the one shown above in exactly the same way as TA - it goes to the folder from which it just opened a file and then looks for another file with the linked UID in its file name -- so that is what I use on my iPhone. Unfortunately, it doesn't have a "go back to the previous file" button :neutral:

  • @Will said:
    Both IA Writer's and The Archive's wiki links in the format of [[202012061631 the archive]] are sensitive to file name changes. Using the format title [[ID]] or [[ID]] title allows changes in the filename, or you can completely remove the filename and refer to the target with only the UID making an interstitial ad-hoc link.

    Wouldn't renaming the file leave a lot of outdated [[ID]] links all over one's ZK though? Granted, they would still work but there's probably a good reason the file was renamed and it wouldn't be reflected in previously created links. After several renamings things could get pretty messy.

    Personally, I would feel inclined to perform a "find and replace" in such scenario and that makes ID links no different from having full title links to start with. And those come with quite a few perks in apps like Obsidian: automatic updates on rename, link completion, indirect mentions, quick file switching and creation, etc. Filenames read better in file lists and on the graph, and links actually work in any app that supports [[wiki-links]] regardless of the linking paradigm they use.

    As much as I like the compact look of ID-only links and their reliability, I just couldn't bring myself to give up all the conveniences for the promise of flexibility I know I would not take a full advantage of. I do use an ID inside my note meta though, as external linking is something title-only filenames fail at spectacularly.

    The risk no linking approach prevents, unfortunately, is a potential change of meaning that comes with that change of the filename. That's the main reason I approach renaming with a lot of caution.

  • You make some excellent points. I, too, am worried about the long-term sustainability of the practice of just using the UID as the link. Will this be supported outside The Archive? We'll see.

    @val said:
    Wouldn't renaming the file leave a lot of outdated [[ID]] links all over one's ZK though?

    Yes, it might seem the practice of renaming files without renaming the 'titles' associated with links would leave a mess. About 2.3% of my links don't have the filename/title. But in practice, this seems a nonissue, and it matters what you consider "a lot." But I'm still worried that I may have limited my options for the future.

    While I occasionally do a title search, I have other methods of ZK exploration that are more fruitful. It often doesn't matter what the filename/title is. Think about those crazy zettelnauts who use the Folgezettel file naming convention. They probably never change a title/filename?

    Title changes (estimated):
    1. Happen usually in the proofing/inbox/incubation stage. Early in the writing phase before many if any links are created.
    2. 73.8% are spelling or grammar corrections and don't change the meaning.
    3. 26.2% are in the category we'll call messy.
    4. Title changes occur maybe 8.4% of the time. I'd love to get to this level. Titles should be malleable, and it is optimistic that I revise them for the better at this rate.
    5. This means that with 2771 zettel, 60 have some messiness, accounting for 2.1% of my current ZK. I'm not worried. If I see a problem with a 'title' during a review session, I'll fix it and its links.

    Will Simpson
    “Read Poetry, Listen to Good Music, and Get Exercise”
    kestrelcreek.com

  • I'm honestly impressed with the precision of your numbers. How do you even go about estimating something like that?

    @Will said:
    About 2.3% of my links don't have the filename/title. But in practice, this seems a nonissue, and it matters what you consider "a lot."

    In this case for me "a lot" = ">1 and constantly accumulating". It's not the number per se, it's the feeling of ever growing entropy and things slipping though my fingers that makes me feel uncomfortable. I accept certain things being out of my control but avoid making conscious decisions to let them go into that territory.

    While I occasionally do a title search, I have other methods of ZK exploration that are more fruitful. It often doesn't matter what the filename/title is.

    I agree that the note's title doesn't have to be a primary mean of finding that note. I can see how a full text search could return much richer results or how tags and structure notes could lead one somewhere meaningful quickly and precisely.

    But I also find that titles can be a very quick and convenient way of getting around if composed with that intent and if software takes a good advantage of them.

    It's a view that I rarely have to go out of, as most of my linking, searching and file switching happens within the bondaries of that simple window. I start typing and things appear. It's a very satisfying, straightforward and human experience, made possible by treating filenames as something that matters (and Obsidian being smart about those things).

    Not saying it's an obviously superior approach but it does have benefits and is worth a consideration.

  • @val, "a lot = >1" is a pretty high standard and is mathematically confusing.

    Indeed, creating filenames is something that matters. It is a form of connection ideas. Connections happen first in mind space, then manifest by titling a note. Titling notes is a superpower.

    I am just thinking while writing. Maybe there is an argument that could be made that there is no need for a note to have a relevant or stable title at all and that all links could be solely UIDs. The opportunity for some slick app like The Archive to come along and make the links all the same simple symbol that, on hovering with the mouse, would reveal a transcluded synopsis of the target note. Using a small unobtrusive symbol for links would make a note visually distracting and look like a paper with footnotes, with the app managing the footnotes and the user not even involved.

    You have me beat! Below is a screenshot of my zero-distraction work environment; you can see I have more "visual" distractions than you.

    Will Simpson
    “Read Poetry, Listen to Good Music, and Get Exercise”
    kestrelcreek.com

  • @val said:
    Wouldn't renaming the file leave a lot of outdated [[ID]] links all over one's ZK though? Granted, they would still work but there's probably a good reason the file was renamed and it wouldn't be reflected in previously created links. After several renamings things could get pretty messy. Personally, I would feel inclined to perform a "find and replace" in such scenario...

    It's actually an advantage not to have instant renames, and not to update the titles everywhere. By freeing you from the false security of a consistent title, such messiness drives you towards a better understanding of the idea—which is most often not fully grasped in the beginning, and not fully captured in any single rename.

    @Will said:
    You make some excellent points. I, too, am worried about the long-term sustainability of the practice of just using the UID as the link. Will this be supported outside The Archive? We'll see.

    A great reason to adopt this practice is so you can use it outside of any given app, including The Archive. I use UIDs for almost all my files. And I'll reference UIDs from within any file.

    I sometimes even use them in paper notebooks, on labels, in my closet, etc.

  • @Will said:
    "a lot = >1" is a pretty high standard and is mathematically confusing

    You left out the most important part "…and constantly accumulating". I just really don't enjoy knowing I've designed my system to leak chaos that way.

    @Will said:
    You have me beat! Below is a screenshot of my zero-distraction work environment; you can see I have more "visual" distractions than you.

    I'd take your window over mine any day, to be honest. Metadata folding is a nice little feature but it doesn't compare to the benefits a native application has over Electron. I geniunly like a lot of things about The Archive.

    My point was more about workflows than appearences though. There are conveniences, that title based filenames enable, that let me stay in this distraction-free mode most if not all of the time (I do split that window in half occasionaly for side to side work, to be fair).

    Link completion is arguably the biggest one. Being able to just type [[ and few characters to insert a fully formatted, self-descriptive and auto-updating link saves a lot of toggling views, hopping between the notes and copy&pasting. It also helps to have clean human readable titles in the search output. I often run queries in the body of a note itself and output does not always come in the form of a simple list. Not having to use regexp to clean up filenames in a sortable table for example is a huge relief.

    The most important benefit of full title based links for me though – their utility is universal. For humans such filenames are natural and software works well with filenames that are specified in full. I recently had my vault opened in Obsidian, ia Writer, VSCode (with Markdown Memo extention) and The Archive. Neither application had issues following full links. Three of them provided link auto-completion and required minimal change of habit to work in. I'd have to resort to a cumbersome search workflow in three out of four if partial links were used.


    What you described as you were thinking in writing is actually somewhat possible in Obsidian.

    It doesn't solve any fundamental issues with ID only filenames though, I'm afraid.

    • You still need descriptions for such links, so they are no different from [[ID]] Links and would get outdated in the same way.
    • ID-only filenames are hard for humans to navigate. The smarter an application gets to go around this issue, the more of a lock-in using it would become.
  • @micahredding said:
    It's actually an advantage not to have instant renames, and not to update the titles everywhere. By freeing you from the false security of a consistent title, such messiness drives you towards a better understanding of the idea—which is most often not fully grasped in the beginning, and not fully captured in any single rename.

    The problem is, neither approach provides true security. What differs between them is a placement of potential disconnect ("a link title that doesn't seem related but represents true content of the linked note" vs "a link title that looks related but doesn't deliver on its promise once followed").

    Personally, I like neither option, so I always approach renaming with caution. If I suspect that my edit may significantly affect meaning, backlinks get a very attentive look to make sure no connection is lost. I may also store the old title as an alias within note's metadata or a more elaborate comment in the note's body if the change was significant enough. Helps with searching but it's also a better more centralized way to store note's history than outdated titles all over the place, in my opinion.

    With smaller changes like typos, adjusted naming schemas or slight rewording, I'm thankful for the automatically enforced consistency.

    @micahredding said:
    A great reason to adopt this practice is so you can use it outside of any given app, including The Archive. I use UIDs for almost all my files. And I'll reference UIDs from within any file.

    I sometimes even use them in paper notebooks, on labels, in my closet, etc.

    That's what I do as well. I just store the UID inside my metadata block. It keeps filenames clean of clutter but still allows for solid external "links".

  • @val said:
    The problem is, neither approach provides true security.

    I'm not looking for security. I'm looking to ensure the "insecurity" of being open to semantic drift, so that true conflicts of even a subtle nature gradually emerge and become defined. This can then provoke reformulations of the key concepts. Which is the benefit I acquire from the process.

    What differs between them is a placement of potential disconnect ("a link title that doesn't seem related but represents true content of the linked note" vs "a link title that looks related but doesn't deliver on its promise once followed").

    The original context in which the link was made is what you want to preserve. So that a link comes to promise something that it does not deliver...So that this situation can be rectified by the creation of new notes, breaking up old notes, etc.

    The alternative is an illusory uniformity across the linking contexts, which doesn't tell us where to begin with our reformulations.

  • @val, I hope you are well. What I love about discussing these ideas as it helps me clarify my thinking and exposes gaps in my understanding. Thank you.

    I play looser with my ZK. I do see your points about wanting to keep as much of your ZK in sync as you can. Some software apps strive to ensure a structure of synchronicity at the cost of the user spending time interacting with the material and lock-in strategies.

    I'm not sure I understand what you mean by "there are conveniences that title-based filenames enable, that let me stay in this distraction-free mode." In what ways are title-based filenames distraction-free? Help me understand.

    Link completion is arguably the biggest one. Being able to just type [[ and few characters to insert a fully formatted, self-descriptive and auto-updating link saves a lot of toggling views, hopping between the notes and copy&pasting. It also helps to have clean human-readable titles in the search output. I often run queries in the body of a note itself and output does not always come in the form of a simple list. Not having to use regexp to clean up filenames in a sortable table for example is a huge relief.

    I created a Keyboard Maestro plugin last night for The Archive that replicates the "[[ and few characters to insert a fully formatted, self-descriptive and auto-updating link" without the auto-updating (I have a separate "file naming change watcher" plugin for that but it is not yet implemented). Here is a gif showing it in operation.

    I'm not sure I'd ever use this though as this is not how I form relationships between ideas or 'links'. I have to search established notes and read them to determine if they are candidates for connection. I can't remember more than the last 3-5 notes by their filenames to be able to choose them from a list. This requires thinking, reading, sophisticated search strategies, and "a lot of toggling views, hopping between the notes and copy & pasting." I wouldn't have it any other way. I find this the most enjoyable part of zettelkasting.

    It doesn't solve any fundamental issues with ID only filenames though, I'm afraid.

    • You still need descriptions for such links, so they are no different from [[ID]] Links and would get outdated in the same way.

    In practice, yes you'd still want descriptions with UID links. The advantage of using the [[ID]] Links is that the link description can be related to the reason for the individual link and not the note's filename. In one case a link may be because of a question, in a second the link may be because of an argument, and in a third, it might be a collaboration of an idea creating the start of an idea thread. Making clear the reason for the link helps the future self.

    • ID-only filenames are hard for humans to navigate. The smarter an application gets to go around this issue, the more of a lock-in using it would become.

    I agree that ID-only filenames are hard for humans to navigate. I'd not recommend listing notes with just ID-only filenames. In practice, these bad boys are placed in a note surrounded by context. It is up to the human to position these in a recognizable context.

    Below is an example of the mix of [[ID]] Filename and [[ID]] Descriptive link wrapped in a contextually human-readable format. I think it would be not as valuable if it was purely a constantly updated [[ID Filename]].

    Will Simpson
    “Read Poetry, Listen to Good Music, and Get Exercise”
    kestrelcreek.com

Sign In or Register to comment.