The Zettelkasten notes plugin creates what is called a time ID, which is a current time stamp in the format YearMonthDayHourMin (e.g. 202005191856).
For someone new to Zettelkasten who wonders why in world would someone want to do that to their precious note title, what do you tell them?
It creates a meaningful / sortable / searchable and unique identifier for any given file or note. Much better than say starting with 00000001 say and working upwards in increments of 1.
I have no idea why I should use ZK notes feature (202003202020 - this kind of stuff). If I want to change a note name, obsidian will automatically rename it. So the usage of this feature in Obsidian is not clear to me.
I suppose one reason to retain the UID is that it will retain its usefulness whichever note taking or management software you keep your notes in.
Yes the origin of the UID approach was in the card-based manual system where the zettlekasten creator used a complex code to connect individual cards. That alphanumeric code tracked how he believed the notes related and developed. When the technique moved to digital collation systems the complex branching code was dropped but it was often necessary to have one unique id per note in order to link to notes. Now with bidirectional linking there is no need for that - UNLESS you want to be sure that you can export and index in a different tool. Seems like an enormous amount of effort to me personally when you have the functionality now being built into tools like Obsidian or Roam.
In my humble opinion what many users are missing about Zettlekasten is that the value is in the process of stopping and thinking how your notes connect. There is much excitement about new digital tools that allow you to link on the fly but that risk falling right back into the Collectors Fallacy that the Zettlekasten system values was in avoiding. The belief seems to be that the digital tool will do all the connecting for you - and there is value in serendipitous discovery. But the value of Zettlekasten is rooted a great deal in the fact it forces you to think about your notes and how they connect and how they ought to be organized.
Hrm, where is the documentation for how Obsidian “Zettles?” One of the values to me for having the unique identifier is not having to decide where something goes when its a seed for something that can grow into the future-- it could be a throw-away note or a future reference, but without more thinking, there is no way to know yet.
Not sure I see how the id helps with this. With Obsidian (or Roam) you can always link to the note title whatever it is…how does a meaningless id help with that? It just obscures what the note was about whereas a title is something you can recognize as related to whatever you are investigating. Not being critical - point I’m stumbling around is that a note is a seed regardless of it’s title. Why does a numeric id help preserve that seed where a meaningful title does not? The beauty of Obsidian is you don’t have to decide where it goes but you can always link to it later when you find things that tie.
Yes, link management is a wonderful feature of Obsidian. However, the beauty of Zettelkasten convention is that, should you ever leve Obsidian, export/import will be trivial and you’ll never be dependent on finding software with that auto-linking feature. I think it’s about choosing conventions that future proof your work. I don’t think anyone is claiming that a meaningful title doesn’t help preservation. It’s just a convention that works for some people that’s designed for resilience.
I guess I’m not understanding. If you ever leave Obsidian you have a folder of md files with names. Those files will have internal wikilink style links [[]]. If you are using the auto generated time stamp file names then internal links will be UIDs, if not then internal links will be meaningful file names. Unless you are planning to take them to a specific tool I don’t see how they’ll be any different? If you are taking them to a specific tool designed to somehow find meaning in UIDs then your neither future-proofing nor adding resilience.
If you are creating UIDs with meaning as the original Zettlekasten approach did then I see it. But I don’t think anyone is doing that these days. Certainly most threads here or in Discord seem more obsessed with getting the program to find links for them (which IMHO misses the key value of the Zettlekasten approach).
Chris, I am one of these new users that lizardmenfromspace is talking about. I am not sure why I like the ZK date UID for my notes but it does tie them to a very specific time. But six months from now, I may have a vague idea about a note I would like to review and would like to search for it. There is no way I will remember the date UID to search for it. Really, no way. But, if I remember some vague thoughts about the content or part of a title that is (hopefully) related to the content, I can begin a search and probably find what I am looking for.
I am also struggling with the unlinked mentions which I think is an amazing tool. If I have a ZK UID or a combination of the ZK UID and a title, there is little to no chance it will be mentioned in another note unless I am making a formal link.
I am trying to sort these things out and feel like I am not making much progress. In reading through this thread I see that greasemonkey made some comments along this line. So, this is my stumbling around two cents!
For me, having the extra “axis” of chronology which the ZK UID provides, in addition to any linking, etc. I have provided is important. Mentally, having a date/time of a document is important. I just really want to know when it was created.
I use the ZID along with a “text” title (I.e. “2020-08-15T20.57.50 This is a note”) - that gives me the text/human readable aspects along with the chronology AND it lets me have multiple notes with the same “title” text (I.e. I might have an Alaskan vacation in 2007 and 2010 - they are two different things, and it breaks the flow if I have to come up with a new title just to make the notes “different”).
That’s just me.
I appreciate the pros and cons outlined above as to whether a UID has value or not. One thing I have trouble understanding is why the UID needs to be in the title. I have a series of Autohotkey scripts to create the templates for a note discussed elsewhere. (Note Type: and others as suggested elsewhere in this forum). One of the metadata fields I create is the same UID the plugin creates (YMDHM), which can easily be automated into the script. But the title of the note does not include the UID. Is there any reason why the UID, if one sees value in it, is better in the title than in the body of the note? I cannot think of one, but I may be missing something
@ljs1454 This is where I am. I’m still wanting to experiment with UIDs but don’t understand why I can’t just include them in the body of the note with other meta-data.
I agree with others about the usefulness of having the date in the title. When I search in Obsidian, the results are alphabetical. If the note titles are plain English (or some other natural language) I don’t know how that sort order is useful. With the date prefix, my search results are in chronological order, which can be very helpful when I actually need to see notes as a sequence of events, like log entries. For example, if you have a long-term illness, your notes will be in chronological order which charts the progression of the illness. While Obsidian is obviously designed to not require such a rigid construct as a log, there are simply times when your notes are best served as a sequence of events.
I get very annoyed when I’m reading an online article, and it has no date. It might be about the behavior of some software. My first thought is, “Are these statements even valid anymore?” While I could put the date in the note, I prefer it at the front of the title because there are times when this tells me what I need to know. For example, I could have a note titled,
Partitioning a drive with Disk Utility
Sounds useful. Now compare it to this title:
201412081650-Partitioning a drive with Disk Utility
Without even looking at the note body, I know this info is 6 years old and may be stale. (In fact it would be.)
There are other times when you may make notes that beg for a date:
Compare this to:
You may not need the date down to the minute in these examples, but the benefit in the latter case is that all dates are in a common format.
Thus by using the Zettelkasten-type date:
Notes in Obsidian are just .md files. As any file in the system, they do have an inherent creation date attribute, so you can sort things chronologically regardless of the naming scheme you chose. You do lose the ability to sort things alphabetically if you append an arbitrary number in front of the title though.
The time-based relevancy issue can be solved easily by adding a date to a note template. It will follow one set standard and will be inserted automatically. It will look much more readable at a glance too.
There are cases where having a date in the title is obviously beneficial (dailies, logs, health records, client projects etc) and nothing stops one from prefixing those particular files and folders with the amount of digits they require. I wouldn’t use those few types of files to justify prefixing all notes in the system with a rather long string of digits though.
I remember spending quite a bit of time trying to wrap my mind around the issue. The main point of confusion for me was how natural and reasonable using immutable IDs felt for an app like The Archive, where linking is based on searches in the way Obsidian handles tags. That approach allows for using partial titles (ie just IDs) for linking and keeps things pretty clean. It is also somewhat of a must to use an immutable ID there as the app itself does not perform auto-renaming, so links can easily break with one careless change of mind.
With Obsidian I found that time-based IDs add nothing but clutter. They make it impossible to keep the file list compact, they look monstrous on the graph and in the body of a note unless you use | for each link. Using just the ID part for linking doesn’t work in Obsidian, and even if it did, it would not allow one to take full advantage of automatic link suggestions and renaming.
Personally, I realized I was trying to fit something from a different paradigm to the system that did not require it.
File metadata is not immutable and somewhat fragile, so I don’t rely on creation dates. I could think of a few ways they could be destroyed. I typically have no reason to sort notes alphabetically (although I could appreciate certain constructs that would), but I have several reasons to sort chronologically. For example, just as computers do, my use of notes tends to exhibit locality of reference (the principle of locality) so I’ll revisit recently made notes for a while. I’ll put /./ in the search bar and have a list of my most recent notes since they’re sorting chronologically. I don’t rely on internal timestamps because I find it much more useful to have that timestamp on the file name, as in the example above.
When I’m doing research I’ll copy/paste entire web pages of articles/papers/whatever into Obsidian, where I have the timestamp and the document title in the file name. That timestamp also serves as version control. If a paper is revised, I can copy/paste it again and it will have the same file name title, but a different timestamp. By searching for keywords in a title, Obsidian will find all versions. If at a point in the future I want to keep only the last version, I can see which to delete simply by the list of file names, and they’re already in order.
Another reason all of my Obsidian files have a timestamp is that the timestamp acts as a unique serial number since the stamp goes down to the second (I cannot create more than one new note per second). Let’s say I have two vaults of research and I want to merge them, but there’s a bit of data overlap. The timestamps guarantee that there won’t be any name conflicts / accidentally overwritten files. It also means any internal links within the two sets of data won’t inadvertently create false links due to name collision, because it is guaranteed that there cannot be any name collisions. The merge still represents two sets of data until such time as I create those relationships. Let’s say I have merged two (or more!) vaults and I want to eliminate any duplicate titles even though they have different timestamps. The following Unix/Linux/Mac line command will identify the duplicate titles and how many copies of each are in the vault:
find . -type f | sed ‘s[^.\/[[;s/[1].//’ | sort | uniq -c | grep -v '^1 ’
I can also easily rely on those stamps to find data added between two dates, before a date, after a date, etc. I can do all of this without having to inspect file contents or rely on filesystem metadata.
If by system you mean Obsidian, whether or not it’s necessary depends upon one’s ontology. I take a much broader view of my data, not only across vaults, but across entire systems. One day Obsidian, too, will go away. Not being Blanche Dubois, I tend not to rely on the kindness of strangers (to write things to migrate my data). I’ve been through enough migrations and data integrations to see value in a bit of considered structure up front so as not to lose data down the road.
Ultimately everyone does what works for them. I just tend to “future-proof” my stuff a lot. Maybe this post will help others make the decision on timestamps.
^. ↩︎