Why are UID necessary/used?
After some thinking, I consider getting rid of my UID in note titles. But before I will do so, I would like to discuss with you, who have more experience with ZK systems. I would like to ask you about their role, maybe I am missing something.
Why I would like to get rid of them
- Simplicity
1.1. without UID we can really create hypertext links "as they were designed to work" = during flow of writing a text, you just put [[name of new note]] and continue with your train of thought. And later, you can click the name and voilá - you have new note (in case that no other note with the same name exist). You just click the link and press Enter to create it. (Without using complicated macro - I know about Rene's Sublime ZK macro to create new notes from such situation with IDs) What is better, before clicking the link, you can just copy link (=title) of current note, from which you are linking, and later, you just paste it into new note. So, you have backlinks without necessity to go back and copy-paste twice.
1.2. Links are self-describing. I do not have to use macro for copying (extracting) just UID from note title or manipulate the text (e.g. by linking to 2005171833 Racing cars and ecology problem, you usually want to have not only 2005171833 in your text, but - unless other text directly describes content of linked note, you probably anyway copy the original title (in some form), e.g. I would use [[2005171833]]--Racing cars and ecology problem |, some of you use opposite form Racing cars and ecology problem....................................[[2005171833]] etc. In 95% of links when I would name my notes descriptively enough (either not too long, not too short), the note name would be satisfactory as link description also.
Space - UID typically are starting part of note title, so sidebar must be wide to show actual names. Without UID, I could narrow sidebar.
Lucidity and aesthetics - Notes look better
- Parsimony - Why use it unless absolutely necessary?
What function of UID I can see and how I can (or cannot) deal with it
plus what constraints would not using UID meant.
"Unique" identifier: My textual names of notes would be unique identifier also, just without numbers. (Software will not let you create two notes with the same names, as notes titles are file names also). No problem for me.
Loss of ability to easily search for backlinks from omnibar. E.g. when searching for "Racing cars and ecology problem", and provided ecology would be my subject with hundreds of notes, there would be many other notes listed provided they would contained these words anywhere. But is it problem for me? I cannot see any, because (1) note with this name will be always listed as first (in case I want to search for it), (2) I can include all backlinks in/bellow ZK content, aka Roam. (3) even if I am not pasting all backlink inside notes, I can easily find all of them by just searching for the title including original square brackets ("[[Racing cars and ecology problem]]"). Very basic macro could cover it in case I would use this function often (+ not maintain backlinks in note contents)
Loss of ability to rename notes (because links would be destroyed). It is not actually big issue, as I can easily replace the old names (links) with new one, using global replace feature by some utility, sublime text etc. Again, I would need to look for original title with square brackets "[[Racing cars and ecology problem]]" replacing with new version "[[Racing cars level of CO2 emissions]]"
Loss of ability to unambiguously refer to note from outside of ZK system (without necessity to use file path). That would be the only real (minor) problem I could see. I do not use my ZK system in this way. In very rare case that I would really need referring to my ZK from outside by UID, I could use it in text of the note (if fulltext search would be a possibility) or even in note name - but only as an exception e.g at the end of the note title.
Loss of ability to sort by creation date (if UID is parsed from reverse date as most users do). No problem for me, as I can always - when necessary - sort my notes by creation date (probably not in TA, but I can do it in FS Notes)
What I am missing? Are there any other important functions of UID? Thanks a lot for your comments.
Howdy, Stranger!
Comments
This is probably worthless comment, but to me, all the downsides you mention are technical issues that can be solved with rather simple programs and conventions. For example, backlinks can be accurately recovered by first reading in all the notes and recording their names and their links. From this it is trivial to construct a backlink list.
But, I'm feeling a minimalistic vibe regarding technology in the blogposts here, so I'd be interested in reading some counterpoints around this topic.
@daneb
I pondered this as well. Found the title change rename a hassle. I am the king of typos so this was a common remediation task for me that became burdensome. Bear Notes has a feature now called:
How would/did you accomplish something like this?
I only use titles or in the parlance of this thread: I don't use UID. I can't say that I have a battle tested collection thousands of notes, but I do have a little more than 600 notes, a few months of "Zettelkasten"-ing and am currently using it to write a paper, so I'd say I have some experience.
I decided to not use UIDs for exactly the reasons listed by OP. The software I use (TiddlyWiki) handles backlinks, renaming, search etc. with no problems and I rather frequently adjust titles. If TiddlyWiki someday can't be used (which is a long shot), then implementing those features is rather simple in any programming language which can open a text file.
The only downside to this method is the inability to link notes from outside. If I rename a note all the outside links are obviously not usable, at least not fully. Whenever I link something from outside the TiddlyWiki I just insert a UID in the text body and use that as the link outside.
What can I say: it works for me.
@daneb Also, you can use UID's and link to them in The Archive without having to include them in the titles. Just include them somewhere in the note text. Because double bracket links and tags are basically clickable Omnibar searches.
I sometimes wonder if we mostly assume if we use a UID or some other type of unique identifier that it has to be in the title. I did in the beginning.
I get the idea and accept that the filesystem creation date isn't always reliable. I have experienced this many times. Recording it somewhere as some sort of metadata in whatever format seems sufficient to overcome this. It doesn't have to be in the title as long as you have it somewhere with the note in case it will have value for you in the future. Recording the creation date is a simple low friction way to prevent future regret. I would recommend you consider capturing it at least within the note.
I am glad you are doing this, it is helping me to revisit my thoughts about this idea. -Thanks
@MikeBraddock: Such "live update" could be possible either manually or automatically. (Depending on how often I would need to rename my notes, or better - how densely linked they would be)
Manualy - after renaming the title, I would replace globally old links with new title by simple textual change - as suggested in my point 3) above. Global replacement in all files is not possible in The Archive (as far as I know), however it is possible in majority of text editors (for programmers), e.g. Sublime Text, Atom etc. It is matter of 10 seconds, just one command (Find->Find in Files in Sublime Text). Or - if there would be only several links, I would just change it case-by-case in The Archive by searching for [[old name]] (with brackets) in omnibar
Automatically - I could also create renaming Keyboard Macro, which would (1) provide me with current note title and ask me for new name (or for correcting typos etc), (2) rename the note, (3) change all the old links to new ones by using KM functions or terminal
grepor some similar command.UID are developed with a couple of reasons in mind:
If you trust your software (1), do not need any structural coupling (2) and are not concerned about safety/rendundancy UIDs are indeed not important. If I didn't use The Archive I wouldn't need them and DokuWiki was one of my favourites before plaintext. But in hindsight I am very thankful that my time frame expands over decades. Or:
Better have and not need than need and not have.
I am a Zettler
@Sascha and @ctietze , I am now confused about UIDs, and I need to sort this out before I start my new ZK system!
I understand that date-time IDs (DTIDs) provide context for the note creation, but ignore that for now.
If all filenames in your ZK are unique, then note (filename) titles rendered in words only (no numbers) are still Unique IDs. Call them WIDs (word IDs).
If your notes use WIDs, is it technologically harder or impossible to create direct note-to-note links? Do you need some sort of grouping of numbers or letters other than the note title?
If WIDs are fine, then why do you need DTIDs or LIDs or other non-WIDs as "backup"? What does "backup" mean here?
What use is a UID in the note body? Can text in the note body be used for direct links? If not, how do UIDs in the note text act as a backup?
Is there any benefit of DTIDs over WIDs other than providing the temporal context for the note creation?
Thanks for explaining!
Quite some aspects of the ZKM are designed for resilience and safety. Any time one might think that you want to be elegant by disregarding some fluff one should always ask oneself: Does it make my system more fragile?
Another aspect is the focus on techniques that are replicable by just a search. If the ID is the adress you can have a non-semantic string as a reference in a text ("[[ID]]") which allows better filtering than semantic strings while reading. Some aspects are not only designed to allow techniques or resilience but similar to archive are made for usability (like Markdown is made to be human readable).
I am a Zettler
Let me first say that I'm not arguing against DTIDs or LIDs or arguing for WIDs - I'm just trying to understand!
I'm not a programmer, so maybe that's why I'm having trouble grasping this.
I would love if you could answer one specific question I asked: If your notes use WIDs, is it technologically harder or impossible to create direct note-to-note links? Or are all of the drawbacks you see in WIDs about losing other types of functionality that are possible with DTIDs?
Yes, but I don't understand how DTIDs are redundant or why WIDs are not redundant.
Is that not true equally true of DTIDs? Or is there a way to change the title with DTIDs that won't break the links? Sorry, I am missing something here.
Umm...please explain? "Various techniques" does not mean anything to me. How is having the ID in the content also useful? What does it add compared to the ID in the filename alone?
OK, if you are interested in analyzing time-based aspects of note creation, then I do understand why DTIDs are useful.
I'm sure that this is meaningful to others, but when you use terms like resilience, safety, and fragility in the context of software, I just don't have the background to understand what you are specifically referring to, or to understand why WIDs are a threat to those things.
I do not understand, but perhaps this will help me: in The Archive, are all links done with only the DTID part of the filename, ignoring the rest of the name (i.e. the words)? Please remember that I don't have a Mac and thus don't know how TheArchive works.
If this is the case, then does the point you are making in the last paragraph relevant to other software ZK systems? I am just not following your point.
DTIDs and LIDs introduce an artificial address in addition to the content of the note. These can remain forever unchanged while the rest of the note is potentially volatile.
Titles, as part of the note content, are subject to revisions in the future.
For completion's sake: You could keep the file name separate from the title, and thus keep the file name fixed, while the title may still be changed. --- When you new files, your operating system or editor might already call each file
Untitled.txt, and if that is already taken, append a number, so you getUntitled.1.txtand eventuallyUntitled.9123.txt. That's effectively no different from using numerical IDs. And you explicitly said that the "WID"s are based on the note title, so we can ignore this variant.Maybe the upside of separating mutable content from immutable address isn't self-evident. Here's an example.
Imagine your Zettelkasten as an Excel spreadsheet, where each row has a number, and you're only allowed to append new notes at the end of the spreadsheet.
[REFERENCE HERE]was just me; in the past 10 years I could've ...You write in row 9999 and want to reference what is written in row 100. You could replace the
[REFERENCE HERE]placeholder either with(see row 100), which, by the rules I just stated, will be a stable reference, or you could copy and paste the title from row 100 and write(see "Amazing discovrs"). That works as well, since you can find the note via search for the title column.Years later, you notice the typo: it was supposed to be written "Amazing discoveries", not "discovrs", and you didn't pay attention when you copied the title because you were so upset. How do you resolve this? Search & Replace can be your friend for unique typos, but it requires careful one-by-one replacement for more general titles like "concept of fear", a phrase that might be part of a regular sentence, outside of a link/reference. The
(see row 100)variant is immune and unaffected by petty changes to the content.Separating the address from the content makes note more resilient for change.
With sophisticated software like Excel, you can make "real" references between table cells, e.g. using formula, and then you're even able to insert rows in-between (violating the safety rule I stated above) and Excel will update all your references for you. With proper Wiki software, you can use a "rename wiki page" function that will both rename the current page and update all links. With that, links to wiki pages by title work just as well. And if you use a wiki software, this will be so second-nature that you won't even notice how much work the software is doing for you. But it's built for that purpose, and is supposed to make the renaming rather painless.
If you use a folder of plain text files, you need equally sophisticated software if you would want to update both file names and links. That makes your workflow more fragile, because you now depend on software to do this for you. -- I can write apps or scripts to do this for me no problem, even if my Mac breaks down and I switch to Linux, or BeOS, or whatever. Takes a day or two before I can get productive again, but it will work eventually. Less tech-savvy people cannot recover from such a loss of software functionality. Their work can be harmed by taking away the software they depend on.
The Archive shows
[[whatever is in double brackets]]as a clickable link. When you click on the link, that will result in a search for the phrase in double square brackets. It does not assume that this is the file name. It does not assume that this is a special kind of meta-information. The result is the same as if you typeswhatever is in double bracketsinto the search bar.That's pretty boring
But it results in workflows that you can replicate with you operating system's global search, via the command line, and with most cloud sync service's web interfaces. AFAIK Dropbox does not search in file contents but only file names; and on the command line, it's easier to get a directory listing and then filter the file names for a phrase than it is to perform a full-text search in all files in a directory. That's why we put the DTIDs in the file names as well: because then you, the human, can perform the exact same task that the computer (via The Archive) does for you. It's nothing that a human with a computer cannot do. That's the ultimate independence of tools. That's our visionof (drumrolls) software agnosticism.
This might illustrate the point even more: Emulate Automatic Link Suggestions in Your Note-Taking App and The Archive
Author at Zettelkasten.de • https://christiantietze.de/
I am not a programmer either.
It is harder because you cannot ensure uniqueness if you change the title without reliance on software. If you use WIDs you need to incorporate very long strings in the text if you use softwaer similar to the archive.
Using both is redundant.
Yes, there is a way: Change the title but the DTIDs remain the same:
"202004211548 I am bread" can change to "202004211548 I am not bread" without any problems.
There is no explanation because it is about safety. An example is: https://forum.zettelkasten.de/discussion/1015/idea-for-a-script-to-make-structured-link-lists-easier-to-browse
It is not in the context of software but in the context of systems. See: Systems Theory and Cybernetics. But you don't need that. Just use everyday terms.
The Archive imitates links by making everything between double-brackets a search that you can perform via mouse click. That makes this feature replicable with a normal text editor. In fact, I operated my Zettelkasten like this for a long time: Manually copy & paste the ID to follow direct links.
I am a Zettler
I have two replies to @Sascha - one here, one posted in a new thread.
"It" is about safety? What is about safety?
I think this is what you are trying to say: "Having ID in both the title and the content does not add any functionality, so it is not "useful" in that sense. Rather, it is done to prevent potential problems." Is that right? If not, what does "there is no explanation" mean?
@cobblepot Although you asked @Sascha, let me try answering. I am pretty sure with "It" he means:
I must say, I find the wording a bit confusion in the discussion at the moment. If we say a Zettel contains a title and content, and its written in a file with a filename and file contents (this includes both title and content), then I can follow, but if content sometimes means the things after the title and sometimes the file contents, things get confusing fast.
My perspective on the matter is as follows:
[[<ID> <Title>]]and still work. However this is somewhat software specific, in how wiki links are implemented."It" is the ID in both title and content. And no, it is not only about avoiding problems but also reaping potential future developments.
I am a Zettler
OK, so is it right to say that your statement converts to "There is no explanation because having the ID in both title and content is about safety"? I don't follow. What do you mean "there is no explanation"?
@Sascha are you hinting, "potential future developments", that The Archive has possible plans in the roadmap to provide additional functionality involving ids?
I'd strongly advise against ditching UIDs. I didn't use them for years and instead relied on the unique title itself. I had to invest quite a bit of work to introduce UIDs later on, because there was some strange behaviour of my archive.
This are the problems I encountered:
Thus, without a well-defined, unique ID you allow for quite a bit of trouble for little payoff. Yes, the note looks cleaner without an ID in there. The mentioned advantages of a no-ID system are, however (as has been pointed out), technical (it'd be a great feature of the archive to have the option to a) specifiy your ID-format (regex), b) automically hide IDs in the search bar, c) hide them in links).
After having run into all this problems, this was my lesson: You don't know what will happen to a file name. You want a backup plan. UIDs are a great backup. Especially if you plan on using your archive for a long time, it's good to have some overhead like IDs that allow to rebuild the internal logic -- just in case. It'd have saved me a lot of time if I hadn't ditched them. Additionaly, if you do IDs right (meaning: in a datetime format), they provide useful information, too. You might want to look up, at some point, which notes where created in a specific time span or right after each other. Yes, the file saves this information in it's metadata. But to rely on that would be against my understanding of the zettelkasten idea as a self-contained system.
This could be another solution: You define a canoncial name of the zettel, document it in the file and thus use the title as a much more informative ID while keeping a backup in the file itself. This isn't as safe, but quite a bit prettier.
I mean: I can't give you any specific technique that is accomplished as a reason. This practice is based on making sure that you will be able to benefit from any development and be as safe as possible.
No. I don't hint at anything. But I am very sure that there will be many macros and features made possible by IDs.
I am a Zettler
I totally agree! We need standardized language here. One issue, I think, is that some software and some users use note titles in their note content, and others do not. Also, some people follow a 'one note per file' convention and others do not.
Doesn't this depend on the type of search? Indexed searches will be quite fast.
When you say "ID in the title" do you mean the filename or note content? Wouldn't wiki links point to the filename, usually?
It does, but I meant to say that it allows you to use more tools, tools that don't access the contents or some index of your contents. Tools that just access the metadata provided by the file system, like the filename, creation time, etc. What is returned by
statfor example.This is especially useful in the context of the command line, it makes it easier to glue together different programs calls to produce something interesting.
Although I cannot directly quote a source on this, are they not pointing to the wiki page name? And when you translate this to the context of Zettels, it makes sense to consider the title to be the wiki page name, right?
When I say title, I mean title as I defined it earlier. I said the file contents consisted of a title and content. Although where this title might be stored can differ. You could have no titles at all, some put one always as the heading
# Zettel Title, others put them in the front matter / metadata section. However it is not like they denote different things, the Zettels are just structured differently, so I don't title is that a confusing of a concept. Unless of course you start using it to actually mean filenames, but I wouldn't, as they are distinct things after all.Just starting a Zettelkasten having read Sönke Ahrens book on Smart Notes and general googling (that got me to this great site).
I can see the use of having a UUID but why not at the end of the file name?
I also like using hyphens instead of spaces - I did see a post on that on this forum but not many replies - but it does make it easer to script.
Example filename could be promises-202011241142.md, spring-async-method--202011241510.md
Any feedback before I have to do too many renames would be welcome.
At the moment I am trialling "The Archive" and "VS Code with markdown extensions" to see what works best for me (at the moment I think I might use both)
@SteveH1UK the only advantage of spaces in filenames is readability, AFAIK. There isn't anything else to consider in this regards, except for your tools supporting it. I assume a lot of scripts shared in this community would break when deriving too much from the general conventions.
UUID at the start or end has been discussed before but unfortunately i cannot provide a link. One advantage of UUID at the start is native support in your file browser (or any other browser). Chronological order is important for your notes.
my first Zettel uid: 202008120915
@SteveH1UK I answered that in the thread you created recently
https://forum.zettelkasten.de/discussion/comment/9185/#Comment_9185
I did this reply a day before I created a thread but nothing showed up. So after waiting a day I though my reply had somehow got lost in the system and I created a new thread instead