Zettelkasten Forum


A question about ID permanence

Hello Zettelkasten forum, this is my first post here, and I'm still trying to learn about working with a Zettelkasten, so I hope you'll help enlighten me on this, and possibly more, topics around using/creating one.

My main question here is: What do people think about the idea of an individual note (once it's been "sorted" into your Zettelkasten structure) having a permanent, unchangeable ID associated with it?

My reading of how this system was developed was due to the physical restrictions imposed on having to manage large amount of knowledge from paper cards that are organized carefully. Due to that, changing any individual note's ID was effectively a herculean task that was unrealistic and undesirable. But with modern software, it's completely possible to mutate the ID of a note and have that change across an entire Zettelkasten. I'm currently on the fence about this: Is it a good idea to have a workflow which allows for ID changing, or should a workflow only support ID permanence coupled with a place where quick notes can be taken that can be "sorted" into the Zettelkasten later?

Since I have no real experience with the system to my name, I was hoping to hear more detailed ideas from those who have been working with the system for a while with large knowledge bases. Thanks in advance for your time :)

Comments

  • edited April 2020

    There have been some discussions recently that relate to this:
    https://forum.zettelkasten.de/discussion/1039/why-are-uid-necessary-used
    https://forum.zettelkasten.de/discussion/1045/rethinking-my-use-of-uids

    Permanent IDs allow for permalinks, making it safe to have links to your Zettelkasten from the outside, e.g. your calendar application.

    If the IDs are only for internal use (so no permalinks) and you don't mind being dependent on particular software for handling changing IDs (not everybody is a programmer, so it could cause lock-in), then you are indeed safe to change them however you wish, as long as you do so with care (e.g. consistently).

    Is it a good idea to have a workflow which allows for ID changing

    That would depend on what I mentioned above and what kind of ID you wish for. If you don't like non-descriptive IDs like DTIDs (Date/Time based IDs) but prefer those based on e.g. the title, then you probably want to have your IDs changed. Otherwise they might not rightfully represent the content anymore over time as changes happen to your Zettel.

    or should a workflow only support ID permanence coupled with a place where quick notes can be taken that can be "sorted" into the Zettelkasten later?

    I don't really see the problem with permanent IDs here, even in the context of quick notes. If ID generation is made easy (preferably automatic), then what does it matter? You can just create a quick note about something, with an ID like any other note, but just mark it as a draft note, be that by tag or some other convention.

    Disclaimer: I am definitely not "those who have been working with the system for a while with large knowledge bases", just started out myself.

Sign In or Register to comment.
http://forum.zettelkasten.de/discussion/1073/a-question-about-id-permanence
forum.zettelkasten.de
crawl=CC-MAIN-2021-04
30078
application/http; msgtype=response
sha1:OFUU3MOQSLOA6UU43ZEB7KIU667WUIDG
<urn:uuid:95b86c47-4045-46ea-8f2a-c088cc0783af>
2021-01-28T07:37:15Z
83.223.95.12
text/html
sha1:763APRF4WTIIO4AVMPKTBWVNLCTY4AWD
<urn:uuid:9cef314d-c614-44b1-87f3-523292204d53>
http://forum.zettelkasten.de/discussion/1073/a-question-about-id-permanence
response
<urn:uuid:7a40d383-b050-4817-a70f-c767b3a4355f>
isPartOf: CC-MAIN-2021-04
publisher: Common Crawl
description: Wide crawl of the web for January 2021
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-33.ec2.internal
software: Apache Nutch 1.17 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.2-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/