Assumptions about software implementations of note-to-note links
@sfast's and @ctietze's replies to a comment in this thread made me realize that there is another potentially important distinction that is problematic: unless I am mistaken, TheArchive implements "links" differently than almost all other ZK/wiki software. I don't know for sure because I cannot try TheArchive (Mac-only) and I haven't tried all other options.
You may recall we have been advocating to manually follow links when your app doesn’t allow clicking on them by simply searching for the ID. We ate our own dogfood, telling folks that links are just a more convenient way to perform a search...
And @sfast said:
The Archive imitates links by making everything between double-brackets a search that you can perform via mouse click. That makes this feature replicable with a normal text editor. In fact, I operated my Zettelkasten like this for a long time: Manually copy & paste the ID to follow direct links.
So this means that TheArchive doesn't actually have a function for note-to-note direct links that work the way Luhmann's ZK did or the way that web links or Wiki-links or any other links do. All the others actually link one note to another directly but do not perform other search functions. TheArchive's "links" are just searches for a note's DTID, whether in the title of the note or the note content.
It is only now, after months on the forum, that I understand why screenshots from TheArchive have only the note DTIDs in double-brackets rather than the entire note filename, whereas other software I've tried looks different. Perhaps I am slow.
But the above comments falsely suggest that, because you can copy/paste a UID in other software and search for it in the same way TheArchive automates, that it is ok to analyze workflow with TheArchive in mind as a prototype software implementation. However, this is wrong because it's not the case that the other software is simply lacking TheArchive's function - it is that other software is actually implementing direct link functionality in a different way that is incompatible with the assumptions that a pseudo-link strategy (i.e., TheArchive's search "links") encourages. This difference is important because people using any software that allows direct links will not be putting UIDs in a search bar manually whenever they want to follow a link; they will be clicking the link directly, which has a very different effect.
Sorry if this was obvious to everybody else, but if this is right, then a huge number of comments about whether certain practices are redundant, easy to implement, high or low friction, etc. are being strongly influenced by the significant difference in implementation, and the impact of that is disproportionately high because @sfast and @ctietze are obviously the most experienced and prolific posters here!
Now you may take this observation as an argument that TheArchive's implementation is better than actually using direct links. I think that's a more complicated discussion for another day. But it clearly influences claims about ZK methods.
For example, in the other thread @sfast said that WIDs (i.e. word-only note titles as IDs) are harder to use than DTIDs because:
you cannot ensure uniqueness if you change the title without reliance on software.
Any software that actually implements direct links will rely on reference to a full ID, so in most software (on this point) it doesn't matter whether you use DTIDs or WIDs or LIDs or both. And it is a huge problem to change titles in other software, unless the software has a reference update function. But @sfast talks about changing note titles as if it is common practice because it is not an issue for the minority (or majority?) of ZKers who are TheArchive users. He might be thinking that even if you change the filename, as long as the DTID is the same, it's not a problem because you can manually search the DTID. But people using direct links in other software are not going to do that - they will use that software's linking feature.
Using both is not redundant in software that relies on direct links, because each gives different information. DTIDs + WIDs do not provide any "changeability" advantage over just WIDs in most ZK software that relies on direct links.
"202004211548 I am bread" can change to "202004211548 I am not bread" without any problems.
In TheArchive only, right?
Lastly, if the above is right, it also seriously impacts this notion of software agnosticism that has been (rightly) trumpted around here.
That's why we put the DTIDs in the file names as well: because then you, the human, can perform the exact same task that the computer (via The Archive) does for you. It's nothing that a human with a computer cannot do. That's the ultimate independence of tools. That's our vision of (drumrolls) software agnosticism.
But someone using naming conventions based on TheArchive's implementation is not ending up with "agnostic" notes. They end up with notes that lose direct linking power in any other software, because TheArchive doesn't have direct links. Now, @sfast and @ctieze will say that it doesn't matter because such links can be implemented by manually searching for DTIDs. But I think this consequence (leaving TheArchive strips notes of their direct links) is not at all obvious, and some people would be quite unhappy to learn that they have to either recreate direct links or rely on a manual search strategy to reproduce them.
Tell me if I'm wrong, but I think that real software agnosticism would involve links that point to full filenames, either with a naming practice that prevents future filename changes or with software that automatically updates all links upon a filename change.
In closing, let me request that @sfast and @ctieze (and me and everyone else) keep in mind that we cannot just make broad claims about what is easy or hard to do in the ZK. Things like changing filenames, note titles (which might or might not be filenames, depending on software), and IDs are tied to software implementations in ways that are really easy to overlook. So we shouldn't be saying that it is easy or hard to change filenames - we should always be specifying the context of the claim (here, the assumed features of the software) when relevant.
It looks like you're new here. If you want to get involved, click one of these buttons!