Zettelkasten Forum

Zettel ID and General Unique Identifiers

The notion of Zettel ID as a Unique Identifier can also be expanded to a more broad system that encompasses more than your Zettel notes. In my personal system, any object can have a GUID (General Unique Identifier) - Zettels, books, paper documents, even To-Dos or (digital/analog) calendar events - your imagination is the limit.

This GUID works across all application and media boundaries to reference one object to another, just like Zettel IDs. In principle, you could use time-unique stamps, but those are clunky to use in any context where you can't copy-paste (such as in paper notebooks or when there's a physical separation of devices). As such, I personally construct the GUID much differently from a typical note ID (see further down)

Let me show you an example: My notes on Stephen Covey's book "the 7 habits of highly effective people" ( I use evernote for all my needs; sorry for it being in German):

It contains a link to my to-do manager (denoted by the "T" at the GUID start. Let's look for that:
Which again includes GUIDs that have been copy-pasted.
Because they're so short, the GUID also works with hand-written notes. You can also include things like page numbers:

A few notes on the GUIDs:

First of all, the system in place is something that works for me - they originally came into being in high school as a way to link various sources and homework, etc. I would write for example write HA-M-150106-1|12-16,18b (Hausaufgabenblatt (exercise sheet), mathematics, 15. January 2006, sheet number one, problems 12 to 16 and 18b) so that I knew what I needed to do for homework and don't confuse sheet problems 12 to 16 with sheet 3 problems 12 to 16 that we got that week. From the beginning, this system included a key of what topic the referenced object was about and what the object actually was (homework sheet, book page, a digital file, etc.). This way of doing things stuck with me.

Secondly: The main difference of ZIDs and my GUID system is that the GUID system includes information about the type of object referenced (or, where to find it - [EN] for Evernote [T] for Task manager, [K] for calendar (Kalender), etc.) and a way of including the contents of the object (topic, page number, etc).

I soon expanded the system to find my way in longer documents. You can see it in the 3th example image, on the bottom and top: Use [GUID|#'$] to mark page numbers (#) and smaller units ($, for example sections, or numbered annotations). To jump inside a document, I use just [Page number] or [Page number|annotation number]. Works with e-books, as well. Something similar for references in Zettelkasten, with [A], [B], etc. linking sources with individual sentences:

You can of course use increasing numbers or a date-number of item format for your Zettelkasten: [ZK-190525-3] would be the 3th Zettel Note today; or somthing like [ZK-M-0007a3a] - Zettel about Mathematics, overarching #0007 (set theory), a3a (Cantor's theorem) - you see you can easily construct either hierarchy, Folgezettel or both with it.

I won't claim that this system is the best one for standalone Zettelkastening (?) - it was, after all, there before the Zettelkasten and as such, the ZK had to fit the existing system. However, it has a few advantages against using time stamps as IDs, such as universality, supporting hierarchy/Folgezettel (if you use that) and the fact that you can see what the object you're touching is about. I just wanted to put it out here to hear your thoughts and maybe serve as an inspiration.


  • @gescho Thanks for this immersive look at your system!

    I'm very into the idea of unique identifiers outside of the Zettelkasten.

    I've lately begun using timestamps as identifiers across my entire file system. I have prepended timestamps on filenames for a long time, but have now standardized this in a more "zettel-friendly" way, so as to encourage search and cross-referencing.

    I will sometimes timestamp a note in a paper journal, typically then copying it into my digital notes, so that the paper note will point "forward" into my note system.

    I've also started doing something like this with my physical belongings. If a suit, for example, has a unique ID, I can have a note about its purchase, size, fit, etc.

    For me, 12-digit timestamps are still the best option. They're just short enough to be workable, just precise enough to be unique, and obvious enough to avoid fiddling too much trying to figure it out.

    I actually used to use timestamps with seconds precision (14-digit), but the example of the folks here convinced me to shorten it—which has proved far more manageable. If I'm dating an old file, or trying to figure out the "current timestamp", specifying to the minute is just a lot easier.

    I also like the fact that timestamps work with varying degrees of precision. If I'm not sure about the minute or hour, I can shorten the search string to "zoom out". If I can't come up with a specific enough timestamp for an object, I can just zero-fill the ID (ie, 201905000000).

    I would consider using some tags or abbreviations to help locate things across boundaries (ie, Email vs File system vs Paper Notebooks). I've done this to some extent before, and may consider rebuilding a system like that again. But I would probably treat this as contextual / search information, rather than a "hard-coded" part of the ID itself.

    Anyway, thanks for broaching the topic!

  • This is fascinating!

    I actually already implement something like this, wherein I rename almost everything that gets referenced elsewhere with a UID. But, I just use the standard 12-digit timestamp. What's interesting to me here is the embedding of contextual information within the UID.

    A few immediate responses:

    • I feel like for me this would fall prey to what I call The Filing Problem, which is the issue of needing to know what a thing is going to be before making the thing, thus stifling the original idea with the need to understand it before developing it. An example would be if I start writing notes for a story; I don't know, in that moment, if it's going to be a short story, a novel, flash fiction, or maybe even an article. If I need to tag it to reflect that, it's going to be bad if the tag changes when the context changes.
    • I'd like to see some more examples of how you construct your tags. I fear there would be a chance of accidental repetition.
    • There's also the issue of incomprehensibility at a later date, but lord knows I write notes to myself like (real example from earlier today) "Prelapsarian genre analysis in TREES Occupation" so I can't really complain about that.

    Great stuff! Thanks!

  • Additional thought: The timestamp method of generating a UID also guarantees being able to sort by creation time in a filesystem. Obviously for paper notes this is not relevant, but that is another potential disadvantage I see to this method.

  • @mediapathic
    Filing problem: I wasn't aware that that existed. I write most GUIDs after the underlying ressource has been concluded, or at the latest when I need to connect the object with another object, which can happen before I'm finished with that particular resource. That's the moment where you need to decide what the object needs to be and where it fits, anyway. The GUID doesn't make any prediction about the content of the object, and I've tried to make very sweeping Object Categories.

    My object categories so far (the beginning letter of the GUID):

    • ZK Zettelkasten
    • B Book. No distinction between physical and electronic
    • T To-Do, actionable item (most likely, see Todo program of choice)
    • YT "Youtube" - actually means any kind of notes on video, or links to video, etc. This is a case of a category that meant something specific broadening to something general.
    • BL "Blinkist" - any kind of pre-made book excerpt. Same generalization as YT.
    • M "Mitschrift" - any kind of notes from lectures, or notes on books that are not in Zettelkasten format. Very often either digital longform notes or scans of ones.
    • K "Kalender" - calendar items.
    • EN - A general category that marks anything that's in Evernote and not marked something named above. In effect the most often used category - articles, excel files, drafts/notes for projects, anything.
    • BuJo - my Bullet Journal
    • AT (Arbeitstagebuch) - you've seen this in one of the pictures above. A journal with quick outlines of models / workflows. Depreciated in favor of the Zettelkasten method.

    After the object category comes the identifier part. That's either constructed as:

    • timestamp (day) - example [-190226-]
    • using initials of author/website and title - [EN-BS-AiI] for an article "Agility and Illegibility" on Breakingsmart.com
    • an index number paired with a category number - example [ZK-M0008] for a Zettel about mathematics - most often used in Zettels

    And of course, combining the methods above. The articles about Coveys book actually have the GUIDs [EN-7HEP-AoM1] for the first article, [EN-7HEP-AoM2] for the second article, and so on. The Zettels again begin with [ZK-7HEP-1] and so on. The book itself has the ID [B-SC-T7HEP] ("Book: Stepehn Covey - The 7 Habits of highly Effective _People")

    After the UID, there's room for sub-counters like those that can be used for Folgezettels. In Zettels, I generally start with [ZK-M0008a], than [ZK-M0008b], etc. denoting hierarchies or Folgezettel, and [ZK-M0008a1], [ZK-M0008a2], [ZK-M0008a2a] denoting Folgezettels exclusively, although the logic is a bit fuzzy here.

    The [] square brackets are an optional part of this system. They're used to distinguish references in general from normal text. Similary, I use <> brackets to write comments directly in source text (for example in a clipped web article>.
    Using just [A], [B], etc. denotes sources (particular in Zettels). Using just [2], [256], etc. denotes page numbers. Where there may be overlap with citation style in the source, I use <[256]> instead.

    I noticed incomprehensibility issues later on - you can't identify notes just with the GUID. However, once you're working with the objects, they're a lot more distinguishable than using timestamps alone, maybe because "[ZK-M0008a2a]" vs. "[ZK-M0008b5d]" is more easily chunckable and more distinct than "20190526202056" vs "20190524103052".

    Regarding creation date: you're absolutely correct, which is why I use normal dates in the margins for paper notes. Creation and change date are nice ways to sort, but I'm happy with file system/Evernote generated ones.

Sign In or Register to comment.