[Feature request] change [[Interlinked notes]] behavior

xal

Hi,

I implemented the Zettelkasten method using The Archive app after read the book 'How to Take Smart Notes' (Sönke Ahrens).

For note unique identification, I do not use time-based UID. File names are UID since I archive all my notes in plain text in a same folder (and we can't name 2 different notes with the same name).

But I met a problem with The Archive [[wiki link]] behavior. For example:

• 'A.txt'
• 'A B.txt'

are 2 different files.

In a note C.txt, I have a link to the note [[A]]. But by clicking this link, I can't directly reach the note A, instead, The Archive show me all the results obtained with the term 'A'.

Feature request: I want that when I use a file exact name as wiki link, I can reach directly this note, even if other notes contain a part of that note name. In the app 1Writer (iOS), I have exactly this wanted behavior regarding wiki-link. In the app nvUltra (I'm beta tester), I have also the wanted behavior.

What do you think? It that make sense for you?

xal

I would add that I read this insightful topic on note UID: https://forum.zettelkasten.de/discussion/61/writing-index-notes-for-your-saved-searches

To summarize my personal position:

• Time-based UID is not essential since I put all my plain text files in a same folder. De facto note’s file name is UID.

• I change file name very occasionally, so I’m OK about renaming [[old link]] to [[new link]] if needed.

• But the only thing that bother me is that I could have a first file for example ‘plain text.txt’ and have links [[plain text]] to this note. And later I could create a note ‘plain text journal.txt’ and met the problem that [[plain text]] link can’t anymore directly reach ‘plain text.txt’ file. It is natural I think to give top priority to a link that match exactly a file name.

mediapathic

I feel like the broadness of the search is, really, the essential feature that allows for things like discovery of connections, so I stridently disagree with this.

As a possible alternate solution, Keyboard Maestro (or several other scripting solutions, I'm willing to bet this could be done in Alfred or Launchbar with proper use of applescript) could be used to translate the standard [[TERM]] text into the thearchive://match/TERM format used by the external URL scheme, which it seems could get you the result you desire.

xal

@mediapathic said:
I feel like the broadness of the search is, really, the essential feature that allows for things like discovery of connections, so I stridently disagree with this.

I agree with the importance of the broadness of the search and this is not my point.

My understanding of the Zettelkasten method is that it is better to not categorize notes but to create links between them. This is how our brain works (by connecting things). And to create none ambiguous links we need unique note ID. So in this use case, when a link [[term]] match exactly a note file name (which is unique) I have to reach directly that note. A direct link should not be the same as a search.

Is that makes sense?

mediapathic

In my opinion, creating ambiguous links is part of the essence of the Zettelkasten method. But, I will leave that discussion to those on here who are more invested in the theory. I will say, however, that it seems to me that the problem you are dealing with here is precisely why a UID in the name is recommended, and I don't see why you don't use that as well.

Will

@xal said:

• I change file name very occasionally, so I’m OK about renaming [[old link]] to [[new link]] if needed.

Using a timestamp as a UID instead of the file name as a UID allows freely changing the note title. Now and in the future without breaking links without consequences. Who knows how many [[old link]] to [[new link]] conversions that could occur in the future. I just envision this getting out of hand in a large developed Zettelkasten.

Apps that allow what you are asking likely are adding metadata in some proprietary database. Unexportable and non-future proof. This defeats the plain text ethos.

Sascha

This is a two-part-statement.

A

The Archive is not designed with specialised features in mind. The navigation is based on search and nothing else. One of the reasons is our software agnostic approach. When you rely on search only, you can switch to any software without significant problems.

Also, The Archive is not solely designed for managing a Zettelkasten. It is designed to handle

1. Big archives of textfiles with thousands or tens of thousands of files.
2. File complexity (Version 2)
3. Compilation of files (Version 3)

Notice that there is no mentioning of any method or school. Software should stay in its place: Managing the digital substance: Files, characters, strings, words etc. If software does more you import bias.

We can't avoid every bias in our software. But we will try hard to.

Therefore, any request that is at odds with that pledge won't be in line with what we have in mind because it would swap a general search shortcut for a specialized feature.

B

@Will already wrote what is the methodological issue. I will put it in context with what I wrote above.

For note unique identification, I do not use time-based UID. File names are UID since I archive all my notes in plain text in a same folder (and we can't name 2 different notes with the same name).

I change file name very occasionally, so I’m OK about renaming [[old link]] to [[new link]] if needed.

B.1: This is a losing game because your archive will grow. Everything that is rare now will become annoyingly frequent in a couple of years.

B.2: You want the software to do something that you should do yourself. You example is perfect support for this point. "A" is not a unique string if you have another file that is named "A B". Therefore, you didn't provide uniqueness and the app correctly returns both if you search for A. Dan Sheffler uses (used?) this to his advantages to create namespaces, for example. Your request would break his personal approach using The Archive.

The technical reason is the above stated: You want the software to do something that should be embedded in your method: Each Zettel ("node") should be truly unique. @Will and @mediapathic are spot on.

Conclusion

(A) You request is at odds with what we believe is proper software design and (B) it is based on a technical error in your method.

My advice is the same as @Will and @mediapathic: Use UIDs

MartinBB

If I may add to this, I started out thinking that I would not bother with UIDs in the filename because I felt they got in the way. I went off and experimented with other software for a while and have recently come back to The Archive. When I did so, I started using UIDs in the filename, contrary to my former practice. At this point I realised that while UIDs in the filename might not be necessary in my case, they were actually very useful. So you could call me a convert to the idea, somewhat against my expectations. If you had asked me a few months ago, I would have been against the practice. But now that I have begun to use the system on a regular basis, I am finding reasons to continue.

xal

Thank you @Sascha and all for your insightful posts. I’m convinced now that it is better and more future proof to use YYYYMMDDHHMM format UID at the beginning of file name. And I put also the UID at the beginning of the title in the file content.

Regarding my initial request and example of those two files

• A.txt
• A B.txt

In an app like 1Writer and nvUltra (which manage text with no special metadata I think), if I use [[A]] in a note C.txt I can reach directly A.txt without ambiguity. So I didn’t understand why not in The Archive.

ctietze

While it would be technically possible (well, nearly anything is ) we decided to do it in a different way. 1Writer and wikis create literal file name connections. To keep this system intact, you always need an app that does this thing.

We opted in to make these links search shortcuts instead, much like nvAlt introduced it (probably by accident, because there's no "open file" except literal search matches). This way, the link is just a convenience for the user to save some typing, not really an extra feature: You could just as well use macOS Finder, the Terminal, Dropbox Web Search, or Spotlight to get to a note by its ID through copy & paste. (This is how Sascha and I navigated in nvAlt for years: manually.)

xal

@ctietze said:
While it would be technically possible (well, nearly anything is ) we decided to do it in a different way. 1Writer and wikis create literal file name connections.

After playing a lot with 1Writer, I think the [[wiki link]] system in 1Writer is pretty similar to TA, except it seems there is an initial test. Based on my example of two files 'A.txt' and 'A B.txt', and when using [[A]] wiki-link in a note, 1Writer does an initial test:

if (A.txt exists) {display A.txt} else {display results of 'A' term search}. And that makes sense for me.

Anyway, I find using time-based UID better now, and everything works well for me in TA.

Sascha

Be aware that the double brackets do not signify a link in The Archive. Clicking on a highlighted string triggers a search. The search is what actually happens in the App. The link is what you intend.