Writing index notes (for your saved searches)
When you update to v0.4.2 today, you may notice this in the release notes:
- Changed: Invoking a search using a saved search now auto-selects a matching note by the same rules a manual search would, so you can write index notes for your saved searches.
This could become an interesting convention/trick and I'm going to experiment with it myself.
Example:
- Create a
filter, pardon, saved search, that searches for "#zettelkasten" only; - write a note titled "#zettelkasten" and make it a curated overview about the topic;
- invoke the saved search -- the curated overview note shows automatically.
As of today, this trick will be more useful for temporary projects than everlasting overviews, because the ID scheme we encourage you to adopt is not compatible with these index notes.
If you keep a note around, it should have an ID so you can link to it. This is useful for curated overviews, too. A topic overview should be a regular Zettel note. (Temporary notes don't need to have an ID; they either get discarded or become permanent by renaming to include an ID.)
When you want to assign the overview note's file called #zettelkasten.txt an ID, you cannot prepend the ID to the file name like we suggest -- or the auto-selection trick won't work. Instead, you have to put the ID inside the note only or at the end of the filename. That's odd.
So maybe the auto-selection feature should also support begin matching at the text part of a file name, i.e. skip the numerical ID part in 201710041209 #zettelkasten.txt. We will have to test how that feels in daily work, once ID-awareness is included in the app. (See @dbarends request: https://forum.zettelkasten.de/discussion/13/request-ignoring-the-id-in-the-title-when-searching)
Have fun!
-- Christian
Author at Zettelkasten.de • https://christiantietze.de/
Howdy, Stranger!
Comments
I'd like to suggest that ID-awareness would allow the user to decide (in app's preferences) where to put the ID (beginning -- or end -- of the file name, or in MMD metadata format, such as
UID : 20171010_221659) as well as the format of the ID itself.I don't have a clue how complicated that could be though.
Does this sound feasible ?
Me neither, I'll have to test if finding arbitrary ID patterns is fast enough -- and respects Markdown, like code blocks, so that you can write notes that talk about IDs without hassle.
Author at Zettelkasten.de • https://christiantietze.de/
I'm not sure exactly what you have in mind for the Archive's planned ID awareness, but I hope I'm not alone in preferring to keep the ID separate from the note title and filename. I'd request that you not make any major functionality dependent on having the ID in the title/filename.
There are a couple of possible things this can relate to, like:
We’ll discuss and test this more thoroughly when I’m done with all the other stuff and then find out experimentally what works best and how users can properly configure this to their workflows. I’ll take note of your request, too
Author at Zettelkasten.de • https://christiantietze.de/
@ctietze: I like your approach
Kind regards,
Dick Barends
This is my current approach to the question:
Do I really need an ID for a Zettel? I like to see TEXT in my file names (which makes them start talking to me), so I get a quick idea what a certain Zettel is about. IDs seem too abstract to me. That said I don't see a need for IDs.
An advantage for IDs I can see when you need to spot out when exactly you've written your note (if you use the timestamp as an ID). But apart from that?
Another argument could be that using IDs you never ever will have double note titles. But this won't happen with my ZettelKasten containing around 2k Zettel now. I roughly know what my Zettel are about - and if I am not sure when creating a new Zettel a quick search will show me the respective existing Zettel to avoid double title creation.
A new part of my Zettelkasten will be my entomological data (yes, crazy enough I decided to mix them all into my existing Zettelkasten) I now add bit by bit; since biological taxonomy is about unique names for unique species there never can be double entries. No need for IDs here too.
Maybe I just cannot see the real need for unique IDs - you can tell me to open my eyes ;-)
Or to put it this way:
TA is able to work with Zettel a bit like a relational database, that's what makes it so strong.
Let's say we have a Zettel called
Heidegger's empty total abstractionsDoes it make sense to add a timestamp?
201801231551 Heidegger's empty total abstractionsIn my POV now we just made the UID redundant. Not the best idea for a relational data structure.
Ok, let's say I want to always retrace when a Zettel was written (for what reasons ever). Then an UID as a timestamp could make sense. So, our Zettel now will be:
201801231551If you can live with this, ok. I cannot. How do I get this Zettel via search? Hm, maybe I type in 'Heidegger' or 'abstraction'. Possible that I will get something like this in the search results:
201601231522201601232351201701211511201704222451201762312351For me this is totally useless. I need to see text to decide quickly, which Zettel I need to open instead of clicking through all the results.
You may say that this could be solved by Zettel with precise tags. Maybe. But if only using text for the Zettel title (i.e. file names) I even do not need tags (and if - definitely less). Advantage.
Since you kinda ask for it, here's how I make great use of UIDs.
First and foremost, I'm like you...
...and for that very reason, I generally don't put UID in the file name but rather in MMD header (exceptions on this further down the page). This method retains information while keeping it out of my way.
But why use UIDs in the first place ?
For two reasons, mainly.
The small one : to have a record of when the file was created (because file metadata as seen in the Finder can get lost, modified or corrupted).
And the big one : to link to stuff, either from other notes in my archive or from outside of it.
If I need to reference a note, I make sure to include its UID in wikiLink format, like this
[[20180210_232732]]. Even if the file gets renamed or moved somewhere else, the ID remains untouched and the "link" is still valid.This is incredibly efficient. Go try a search on the ZK forum for that string and sure enough, it will bring up this post, and only this one (as long as I don't get quoted somewhere else).
If I want to point to a specific paragraph in a longer document, I sometimes add a "bookmark", hidden in HTML comment, like this
<!-- ^20180210_232812 -->. The^symbol, inspired by footnote syntax from Markdown, indicates me that something else points here and that this ID is not related to the current text but to that something else.If I add some information to an existing note, I often place marker, like this
<!-- +20180210_222651 -->. The+prefix denote addition and the ID itself indicates when it was made. Plus it can be referenced from elsewhere.Now why use timestamps ? Because they :
UIDs are widely used by many apps to create links between elements. Be it Bear, Ulysses, Quiver or Boostnotes. The downside of their UIDs though, is that they look something like this
39EC600C-ADC4-43FF-93EC-54FA5B55F8FB-57063-0000655AA2015F39(actual ID from Bear) which, funny enough, reminds some activation code from my old days on Windows XP. Despite being funny though, this string on its own tells me nothing. That's why I settled on creating my own IDs.That, in my view, is the beauty of a system relying on files and folders rather a database. You can bend it to your will and use (or not) IDs in the format you like.
Of course, this goes beyond The Archive. As I said earlier, I add an ID to everything I create (in MultiMarkdown metadata header) or collect (append to file name). If I need to reference a PDF file, it will go like this : "For more on this, see dishwasher manual >20180210_230645". Surrounding context will be enough to know what this ID is about and Spotlight will bring up the file in seconds. The
>symbols, again inspired by Markdown, reminds me of an arrow that says "go look at this".Phew ! 600 words down the page, I hope I haven't bored you to death. May you find at least some inspiration for your own workflow.
Cheers.
Thanks @maclm for your detailed response!
Yup, if (!) needed that's a good way to do it!
That is a good point: it's possible to change the file name without changing any links to it. That's why I requested a "rename all links when renaming a Zettel's title" for TA.
Since I only want to do ALL my writing work in ONE app (I'm more and more sure that it will be TA), I then do not need UIDs for that purpose anymore. And I do want to use ONE app only, I'm tired of switching from here to there, because this app has what that don't and vice versa...
D'accord! I just transfer a whole database into text files now just because of that...
So - as I don't use UIDs, I just can do
[[dishwasher manual]].Exactly. But not using UIDs can save work here: I have to type less plus I can see directly what's the link about. No surrounding text needed. Quod erat demonstrandum ;-)
And surrounding context in most cases only lets you GUESS what the exact content of a linked file could be... That's too dim for me.
As I said above - I do not like to switch apps when working on text, this for me is terribly distracting. I need ONE workbench. When I need to ask Spotlight - my text file system is not good enough...
BTW: That's why I put ALL files I am daily working on and with together in ONE folder (for me it's: scientific work for my job, entomological data, botanical data, general information, literary texts, journal etc. ) - my Zettelkasten!
Anyway, I don't say that using UIDs is worthless (as you showed it's not), I only say that for my workflow it's redundant and not needed. And - if someone wants to start with a Zettelkasten - that it will be good to think before, if UIDs are really needed.
I'm confused: When you click on a link in the Archive, the archive makes the text of the link the active search. In addition, if the link text corresponds to the prefix of a file name, the Archive opens that file. So if you don't use the UIDs as the first thing in your file name, how do your links work? It seems like with your system this link would just give you a list of all files that contain the string "20180210_232732", which includes the file and all files that contain links to it, and that you would then have to further select the intended file from that list before you can view and edit that file.
What am I missing?
@galen
That is the reason I put the ID everywhere:
The reason for putting the ID in the title and in the content of the file is to create redundancy to make use of other apps. Not all apps share all features. With redundancy you play safe. Sure, THE ARCHIVE IS THE BEST APP OF ALL TIME AND POSSIBLE WORLDS (
) but what if you want to change and make use of a search that only searches in the titles?
Safety first.
EDIT: Links are much shorter:
EDIT II: When you put the ID first in the file name you can use any file browsing feature to sort you notes if you want by date.
I am a Zettler
Yes, it's this feature that makes starting filenames with the UID completely essential to the proper functioning of a zettelkasten, in my view.
@ChrisJohnson, I think there might be some misunderstanding on of the issue of redundancy. Redundancy is a problem in a relational database, as you mention, but a zettelkasten is not a relational database — it is much more free-form and relies on a very simple query engine, and is thus (in my experience) usually quite explicit in its coding of connections between notes. It's very common for me to create backlinks to an index note in every note mentioned in the index note. This is redundant information, yes, but my goal is not to represent my web of knowledge in the most compact form possible — my goal is to make my web of knowledge easy to explore quickly.
As another example, I use the UID of a zettel at least twice in every zettel: once in the filename so that
[[UID]]links bring me directly to that note (a feature of The Archive and nvALT), and again in the title to allow for easy link creation. So a zettel with filename201802111047 Example Zettelwould have this as its first line:Example Zettel[[201802111047]]This allows me to quickly copy and paste the first line of a zettel to create a direct link to that zettel. Sure the information is redundant, but the redundancy serves the purpose of speeding up link creation.
The system you describe is vulnerable to link rot if you ever decide to change the titles of your notes, which requires a heavy-duty solution (namely your "rename all links when renaming a Zettel's title" feature request) that goes against the "Software Agnostic Programming" ethos of The Archive's developers. Your system is also subject to confusion if two notes have very similar titles, so you need some convention to deal with that. With UIDs those problems do not need to be solved because they do not arise.
Christian and Sascha are young guys, but it's almost certain that they have thought about this problem far more than you have, and I would recommend that you follow their system until you find a specific functional (as opposed to aesthetic) reason to deviate from it. Your writing sounds to me as if you do not understand the problem well enough to deviate wisely. And with more understanding, your aesthetics might change. (I personally find the UID system quite beautiful.)
Same without UIDs.
True.
Similar file names are not same file names. I cannot see the problem here. And if similar Zettel names may confuse UIDs cannot change this (if using the UID + text as file name; only using the UID as file name is not on option for me, as I described in a post above).
Aesthetic reasons?
Nothing (as far as I can tell).
My system is far from perfect and the approach @Sascha suggests is way better.
Except for one thing : using Editorial on iOS, there is not enough room in the list to see the actual file name if it starts with the ID.
I brought this up as an example of how redundant information in a zettelkasten can serve a good purpose, not to show that UIDs make it easier to create links with. In fact, it is more work to create links with UIDs, but the resulting zettelkasten is more robust. In my opinion this is a good tradeoff.
The issue is, if you are using The Archive or nvALT, you must use a unique prefix of the filename as your link text to guarantee that clicking on the link will bring you directly to the zettel, as opposed to just initiating a search. So you need some system in place that guarantees that every filename always has a unique prefix that is calculable at the time the zettel is created and that will remain unique, even as new zettels are added. E.g., you might have a zettel that contains
See [[Example Note 1]] for more about this.which works fine until you add a note named
Example Note 11. Then the link stops working. So adding a new zettel has non-local effects on the behavior of the zettelkasten. Because UIDs are guaranteed (by convention) to be unique prefixes of the filename, a link in the form of[[UID]]will never stop working as a result of adding a new zettel, whatever its name.If you are ok dealing with links that once worked not working anymore, or have some other means of keeping links functional, then no worries. But this is a consideration when abandoning UIDs.
Also, UIDs allows links to act as quick references. For example, say we have a zettel named
201802111709 BK Econ _Wealth of Nations_ Connections to Modern Monetary Policy. I can link to it in passing like this:As Smith makes very clear [[201802111709]], this is not a problem.To my eye this is much cleaner than always using the entire filename, even if we forgo UIDs. I.e.,
As Smith makes very clear [[BK Econ _Wealth of Nations_ Connections to Modern Monetary Policy]], this is not a problem.This is especially pertinent if you abstain from using tags by coding zettel content in filenames, as you implied you might do when you said
since this will make filenames longer and link text more ungainly.
Your objections to UIDs so far seem rooted in your current personal aesthetics — e.g., not wanting to have zettels contain "redundant" information, not wanting to use non-link text to identify the link target, etc. — and not in their functional shortcomings — i.e., shortcomings that you have found after gaining some experience with using them in a sizable zettelkasten. This is not to dismiss aesthetic considerations, which are supremely important, but to simply encourage you to learn why the system was designed as it was before assuming you understand how it should change. What you have written clearly indicates that you have not grasped the advantages of using UIDs, or even how to use UIDs correctly. Until you understand how to use UIDs in a zettelkasten and what the advantage of doing so is, you are not qualified to argue that they should not be used.
Ah yes, I've experienced this myself. I don't use iOS to interface with my zettelkasten except in emergencies, so this isn't a consideration for me. But if I used it more often I could see that it would be a big pain.
If using synoptical Zettel titles - is it really necessary to change them later? When new aspects occur, it's a good idea to create a new Zettel.
If using an exact title, e.g. when dealing with taxonomical data (as I do), an UID prevents linking problems, if the taxon may change to a synonym (which means, the Zettel name will change).
Nevertheless, in that case now I have to change ALL links (in other Zettel) to the taxon, which became a synonym unless you only used the UID as the link, which exactly is what I do not find helpful in my workflow.
Example: Let's say my file is
2018021212H590213 Lucanus bicolor SAUNDERS (nec OLIVIER) 1839Later I find out that this is not the current taxon anylonger but now a synonym. So, I will change it to
2018021212H590213 Odontolabis cuvera ssp. cuvera HOPE, 1842As long as in all Zettel which will link to this Zettel I only used the
2018021212H590213I am totally fine.
To use the UID only as the link doesn't always make sense. To know, what the link exactly is about, you have to click to see - which I find distracting. That's why I like to use the whole name. Now the UID becomes redundant, means an information without need here.
This has nothing to do with aesthetics, it's about function.
@galen
Maybe I missed something (definitely I'm not an 'expert'), maybe I didn't understand the UID concept fully - that's why I've thrown my hat into the discussion. Then one can show me, where I am wrong; that's totally fine. That's what discussions are for, aren't they? I am happy to learn. But there is definitely no need for unfriendly and snooty statements, whether I am qualified to join to argue or not. If you do not like 'unqualified' statements, just stop replying to.
I change filenames with some regularity, either to differentiate an old zettel from a new one with a similar name, or because I have adopted a new content-coding convention in the names. In a more mature system where conventions are completely settled, this would be less necessary, but I am still experimenting with how best to name notes.
Yes, this is what UIDs allow you to avoid.
I think this is because you're not yet using UIDs in an effective way. See below.
You definitely don't want to have to click the link to find out what the note is about — I am fully with you there. But this is what contextual text around the link is for. UIDs allow you to separate link text from contextual text.
To follow your example, you could use
2018021212H590213as the link text, and some form of the rest of the title as contextual text. For example,This was some years before Lucanus bicolor[[2018021212H590213]] first showed up in western entomological taxonomies.Here the link will always work even if the taxon changes, and you can supply as much or as little of the rest of the zettel title to indicate the contents of the link. After the taxon changes, you would most likely want to update the text, but here again you could tailor the contextual text as needed. E.g.,
This was some years before Odontolabis cuvera (formerly Lucanus bicolor)[[2018021212H590213]] first showed up in western entomological taxonomies.And both of these are much easier on the eyes than
This was some years before [[Lucanus bicolor SAUNDERS (nec OLIVIER) 1839]] first showed up in western entomological taxonomies.Basically the UID allows you to separate the link text (which is a structural element of the zettel, and should never change after you create the link) from the contextual text, which is a semantic element of the linking zettel and which might change for any number of reasons after you create it. This is desirable because the name of a file might contain more information than you want in the linking zettel (such as who first classified a species), or less information than you want (such as former taxons). If you don't use UIDs you are forced to combine link text with contextual text, which can lead to a muddled zettelkasten, with links that are both overly long and incomplete. And in all likelihood you will have to supplement the link text with additional contextual text in any case.
Fair enough — apologies for my unpleasant tone. It sounds to me as if you have dismissed UIDs without first understanding them, but that is no reason for me to get snooty.
I think it is important to understand that starting file names with UIDs or not is not so much a question of right or wrong, but more one of specific tradeoffs that depend on your particular usage patterns.
If you, like me, regularly access your notes on an iPhone, then having a UID at the beginning of each file name is pretty much a deal breaker. Another significant disadvantage is that you lose the ability to instantly switch to notes that you know (the beginning of) the name of (e.g., whenever I want to look at my Regular Expressions cheat sheet, I just need to type "reg").
It is absolutely correct that link handling is more foolproof with UIDs, but if you rarely rename a note, it is also not a problem at all to do a quick batch search and replace for "[[Old Title]]" -> "[[New Title]]" in those cases. Furthermore, not having one note title be a complete subset of another one is also trivially easy to avoid.
So it is clear that starting file names with UIDs has both advantages and disadvantages. Instead of trying to argue whether the advantages outweigh the disadvantages or vice versa, maybe it would be more useful to think about how the advantages of both approaches could be combined.
Ideally, we would want the UID to not clog up the file name, but still be able to use it to link to a note directly and not just get a list of notes, which also includes all the notes that link to the original note. One way to accomplish this would be to include the UID together with a prefix in the note body, for example "ID:201802130850". The format of the internal links would remain "[[201802130850]]".
The obvious downside of this approach would be that, with the current version of The Archive, you would need to manually prepend "ID:" to the search string after clicking a link (and also hit Arrow Down to actually view the single remaining note). That would not be terribly convenient... unless The Archive had an option "[x] Prepend ____ whenever an internal link is clicked". Ideally, TA would also always show a note if it was the only remaining search result -- this would actually be a universally useful feature, especially when you use tags.
Maybe there are other ways to solve this problem, but implementing such a prepend option does not strike me as terribly difficult, and it would allow you to keep foolproof linking without all the disadvantages of starting file names with UIDs.
Fortunately, moving UIDs between file names and note bodies is very easy to do programmatically, so even if you already have a Zettelkasten with 3000 notes whose names start with UIDs, you could just use a short script to migrate them to the new format. The same holds true if you, for whatever reason, wanted to go back to file names starting with UIDs: All you would need to do is to run a simple script once.
If you like The Archive's "PrettyFunctional (Basic)" theme, consider upgrading to the "PrettyFunctional (Regular)" theme.
Sorry if this has already been covered, but one thing that placing a UID at the beginning of the filename makes impossible is meaningfully sorting by name — which may not be canonical Zettelkasten practice, but can still be awfully useful.
(On the other hand, the current version of The Archive doesn't seem to offer any other option for sorting by creation date. @ctietze , would you please consider adding this? Maybe add a pop-up menu for sort order to the top of the note list column, and/or add it to a contextual menu in the note list?)
I've thought about adding prefix to distinguish the link from its target. But you're wright, that's a bit inconvenient, unless...
Maybe there could be a specific URL scheme for this.
Since
[[WikiLinks]]usethearchive://match/<TERM>, here's what comes to (my) mind :thearchive://link/<TERM>could use @Basil suggestion "[x] Prepend ____" from the app preferences.As an aside, I sometimes wish
thearchive://was shortened tota://. Not sure how close that would come to what's considered bad practice though. (But there wasnv://in nvALT...)Using
View > Sort Bywe already have title and modification date. You're right that without ID in the filename, we can't have by creation date without resorting to the Finder or other external app (Leap comes to mind).But that metadata can easily be corrupted or modified externally (Dropbox, iCloud...). I don't know for how long that would remain reliable. I see modification date as a live thing, thus more useful to me.
Great stuff you come up here in the process! Could you also open new discussions with the requests so we can reference and discuss them outside this thread's context, too?
Author at Zettelkasten.de • https://christiantietze.de/
IDs interfere with iOS
As a proud conscientious objector of smartphone usage with a strong believe and sense of mission I am happy for this additional feature of the IDs.
Seriously, I am wondering how you think the net benefit of a smartphone over a physical note book is.
-> New discussion thread incoming.
Tone of Writing
You guys came to a good solution on yourself. I just want to credit you for civil manners.
I am a Zettler
I'm not suggesting dropping sorting by modification date; I want all three sorting options (creation, modification, filename), plus UID as a separate metadata category from filename or creation date (no immediate use case, but I can imagine someday wanting to distinguish between the file as a filesystem object and the zettel as a zettelkasten object), and possibly others that I'm not thinking of right at this moment. While it's true that file creation date metadata is not absolutely reliable, that hardly means it's useless.