Use something like this in a stamp, or agent, etc.
$MyString=runCommand("date +'%Y%m%d%H%M%S'");
1 Like
Dear Dr. Mark Anderson,
Thanks a lot for your zettelcode-demo.tbx.
It is very easy to use because the Zettelnumber of the document is automatically changed when the file location is changed. I am now free from the inconvenience of having a unique numbering system.
Now, my question is: I added a new file in your zettelcode-demo.tbx
as zettelcode-demo-1.tbx.
I have two problems.
I am using MacDown (ver. 0.8.0d71 (1079)) to display the exported file.
Problem 01: The Japanese in the title displayed in
is sometimes "garbled?
Problem 02: The link destination in the file is not written correctly.
When exporting as .md, the link is created.
The path specification is not exported as expected.
Zettels.md handles the relationship between the entire folder and file, but From the “Link test” written in the Test cell at the beginning, the link Testcell > bee > cow > dog.md shows up, but
But the link back from dog.md to Testcell.md
The link in dog.md is written as <a href="Zettels/">Return</a>.
To return the link specified in the original Zettels.md
The fact <a href="Zettels/Testcell.md">Return</a> is different from the fact that I wrote.
Especially for problem 02. I would appreciate it if you could tell me what kind of treatment I should implement.
Is the Japanese “garbled” in problem 01? is it a problem with MacDown?
Respectfully, WAKAMATSU (from Japan)
P.S
The zettelcode-demo-1.tbx and exportFiles are attached as a zip file.
zettelcode-demo-1.zip (195.4 KB)
Thank you for the file. It seems to be something to do with Markdown and whilst I know what Markdown is, I don’t use it so have no expertise to apply to this. Perhaps a Markdown expert could help?
Or, remove all the Markdown mark-up and get it working as HTML and then add Markdown. That way it is easier to see what is happening with the export.
Dear Dr.Mark Anderson.
Thank you very much for your time and advice.
I will try the method you suggested.
I rarely use Markdown markup, so I will try converting to html first.
After that, when I find out the problem with Markdown,I will pose the question again.
Respectfully, WAKAMATSU
This is an old thread, and I am not sure if it is politic to revise it.
I have been playing around with Luhmann’s numbering system, and I am stuck on how to automate it.
Before, getting into those weeds, a quick note why it might be bothering with it in the first place. As discussed above, Luhmann was forced to use paper and digital systems allowing for different indexing methods. My hunch, though, is that the paper folge method forces one to make an initial decision about where the note best fits. Does it follow below a note, or go to the side of it. The process of working that out forces particular kind of engagement with the material in a way that tagging systems don’t. And so the benefit accrues at the point of creation more than at the point of retrieval. (Digital systems have that covered.)
This is moot, I am not sure how beneficial is. But I guess I will find out through trying it.
Now my coding problem. I have written some code that uses a link action to add a sequential number to a Zettel created in a map view by dragging out a link, for example 10A1 becomes 10A2.
function fSetStemFolgeCode(){
//$Color(destination)="black";
if($ZettelCode(source).contains("(.+)(\d)$"))
{$ZettelCode(destination)=$1+($2+1).format(0)};
So far so good.
But I have no idea how to increment a letter, Is there a way of making 10A2A into 10A2B and so on?
I am guessing there may be a way of doing that with some kind of look up table but that seems painful, or maybe there is a way of doing this with unicode character codes. I dunno. I am fairly clueless on that level of refinement.
If anybody has any ideas ?
Thanks in advance,
Gavin
You should look at this thread and the others associated with it: Tinderbox Meetup April 23, 2023 Video: On ZettelKasten with Sascha Fast from Zettelkasten.de
Also, before investing too much effort in this branching, it appears that branching is not necessarily considered good zettelkastern practice.
There is a danger of process observance trumping useful insight. At its heart the method is about making meaningful notes once and linking them as needed. I’m unconvinced Luhmann, had he had current tools would have obsessed about at capturing the limitations contemporary paper limitation. Writing a useful note is about what’s in the note; where it lives in the system, as long as findable is less of an issue as it can be found. With paper, that was a real problem.
1 Like
But I have no idea how to increment a letter, Is there a way of making 10A2A into 10A2B and so on?
Let us suppose we have a note /config/zettel for which
$MyDictionary: { 'A':0, 'B':1, 'C':2 ....'Z':25}
$MyString: ABCDE...Z
Then you have the letter K, var current=$MyDictionary["K"] ; will get you its index (11), and $MyString[current+1 ] will give you the next letter. You’ll want to special-case the letter after Z, for example MyString[(current+1).mod(26)].
Thanks Mark for the input.
I am not sure that Sascha has fully grasped the point that Daniel was making in the article you have shared.
Daniel appears to be suggesting that the the ritual of considering where to put a note starts to open up a sense of how it might be connected in a way that is different to just doing a search and making links. It is a moment of friction that compels a different level of engagement with the material which one might not otherwise have. Certainly tagging just by itself is inferior, because as Sönke Ahrens points out in his book, tags by themselves don’t contain information on the thought process that prompted the idea that things should be linked.
And the fact that Luhmann did not have much choice because he had to work with paper does not negate the hypothesis. In other words, there might be an accidental but nevertheless positive byproduct in a workflow which has other things to be said against it . Constraint in different ways is essential to making decision making. One can look at the Folge principal as a separate and complimentary approach to both manual linking of notes and using keywords or tags.
The above of course may be nonsense. The only way to find out who is right is to test both approaches in an experimental spirit. Ultimately, I may well stick on something altogether different. The chances of me implementing anybody’s system exactly as they did is close to zero, just because of the near impossibility of internalising someone else’s formula.
Hopefully, I will find something out !
Gavin
2 Likes
Thanks so much for this. I will give it a go !
1 Like
Here here!!! It is you obligation to make it your own. Three are three elements to "personal’ knowledge management:
- Method(s)
- Toos(s)
- You
The later being the most critical and irreplaceable and obviously, singularly unique, bu definition as there is only one You!
Sascha Fast has been writing about the Zettelkasten method for over ten years and has his own book on the subject:
The chances of him not having grasped something regarding the method are about nil, I would say! And the post that was linked above was only one in a series going back to 2013:
And there is plenty of debate on the forums of their site:
There are thousands of threads and posts regarding the Zettelkasten method there.
I think Michael Becker is right up to a point with his three elements: but I prefer to see the whole thing as a “system” consisting of person-tools-method-work to be done. There is, I believe, an interaction between the components of the system, and if you change any one of the components, the whole system needs to adapt to adjust to that. (And maybe it is worth observing that, in the view of John Gall, failure is an intrinsic feature of systems: https://en.wikipedia.org/wiki/Systemantics.)
Anyway, if you are going to use a tool like Tinderbox, it would seem counter-intuitive not to exploit the features it offers, and to try instead to use solutions that were developed for another set of tools. For some reason I find myself remembering that in the UK a hammer is sometimes called a “Birmingham screwdriver” 
The claim that Folgezettel (FZ) leads to this friction is just correct on surface level.
- If you depend your ability to assign an ID to a note on going through the branches of FZ you impose that said friction.
- However, the placing is not important. If there are two possibilities to integrate a note you just chose one and then link to the other place.
- Luhmann: “With this technique it is not important where you place a new note. When there are multiple options, you can solve the problem by placing the note wherever you want and create references to capture other possible contexts.”
- Not being important means that it is not creating value to decide how to place a note. If you act on the premise that the placing is not important, the friction is forcing you to engage with an aspect of the method that is not value creating and therefore imposing opportunity costs to you.
- FZ doesn’t force you and can’t force you to make a meaningful connection. There are just two possible ways to branch: Sibling or child. There are more than two possible types of relationships between old notes and new notes. Therefore, FZ is not powerful enough to actually capture the type of connection.
- FZ relationships need to be re-understood when you review them later. It is almost certain that you forget the vast majority of them if you are not working very frequently with your ZK or at least with certain areas of it.
- The FZ structure will grow to a high degree of complexity. If you want to work in a more orderly way with it the amount of necessary work and strain on your working memory will be high.
So, FZ does impose friction. But the assumed benefit of this friction is realized by working with your ZK anyhow:
- If you integrate a note into your ZK diligently, you spent quite some time browsing the already existing link structure of your ZK since it is part of how you navigate your Zettelkasten.
- If you use Structure Notes and integrate a note there, you have the opportunity to integrate the note very specific and meaningful. Meaningful means here: You describe the relationship between the note and the overarching structure explicitly.
- Theoretically, each Structure Notes is one way to access your entire ZK. Imagine a structure note that links to any other note. If you organize the links hierarchically, you created a complete FZ structure on one file. If you create another “total” structure note but make different decisions to place a note, you created a parallel FZ access structure. (Same notes, different FZ relations) The benefit of structure note is that it is malleable. If you are not satisfied by more choices, you can change them. FZ is permanent. You can’t work with FZ. When it’s done, it’s done.
It is not that FZ doesn’t produce any benefits. But there are other techniques and practices that produce more of the same type of benefits and more different benefits.
Practically speaking: Using FZ creates a hierarchical view, mostly on the left side of your screen. The view is hard-coded into the filename or an attribute. Structure notes (as the main alternative) create a view in the center of your screen (in the editor window).
Lüdecke writes for example:
Links or references do not emphasize the relationship between notes (ideas, content). The context of connections usually remains unclear due to arbitrary relationships. source
The very point I am making is that FZ are not providing meaningful context.
Wherever you read about FZ providing context you’ll encounter the claim that FZ does it. But the actual mechanism how it provides the context is either left out or proposed in foggy terms like “relationships of relationships”. (“Relationships of relationships” is, by the way, a technical term of Luhmann’s systems theory.)
Lüdecke is doing exactly that. Just stating that FZ does that.
The general fallacy all proponents are making I am aware of is the following:
- (1) FZ is an effect.
- (2) The effect is beneficial.
- (Therefore) FZ is beneficial.
It is a fallacy because the benefit of the effect needs to be established through the lens of opportunity costs and in isolation. Yes, FZ produces friction, which can be interpreted as “good friction” (eufriction). But to make the claim that this if beneficial, you need to base your claim on a comparison to other habits and techniques.
To give you an illustrating example:
There is not a single healthy nor unhealthy type of food. Is pizza healthy? Not, if you compare it with other options like self-prepared whole food meals. But if you are broke or stranded on an island, having a pizza (or even just a bucket of almost spoiled whipped cream) can be life-saving. This might be a controversial position, but being alive is more healthy than being ended by starvation.
Yet, people make all kinds of claims on the health properties without any contextual reasoning.
The same is true for FZ. The reasoning needs to be dialectic. But it isn’t.
You are making the very point about tags that I make about Folgezettel. 
FZ by themselves do not contain meaningful information since they just can establish that there is a connection but not the nature of the connection itself.
I am sure. In Lüdecke’s article, there is just the claim that FZ does this or that. There is no justification or exploration of the actual how FZ do that.
Other articles you’ll find in the internet lack the above-mentioned dialectic reasoning necessary to make claims on the benefits. (At least as I am aware of.)
The weakness of my position is: Since I am holding my position for a long time (more than a decade) and base it on my iterations of discussions and reasoning, chances are that I am reading selectively. So, if there is any dialectic reasoning about FZ, I am happy to engage with this topic once more.
So, my position is that FZ might be useful but pale in comparison to other techniques.
But if you like it, you like it.
1 Like
Yup, you’re spot on! Work do be done definitely belongs in the list!!!
1 Like
Sascha,
Thanks for returning to the Great Folgezettel Debate and offering such a detailed exposition of your thinking. And apologies too for taking a while to acknowledge this. I am juggling multiple projects right now.
As I said earlier, I regard this as an experiment, rather than a crusade designed to embody a strongly held prior belief.
But let me take up a couple of issues. Firstly, linking in the Folgezettel method is not as dumb (in the sense of inert) as tagging.
If you look at Luhmann’s practice, he may have said that it doesn’t matter where you put a note, and he may have also meant that in a sense, but that also doesn’t mean that he was inattentive to position. He is just saying that one should not worry about it or be particularly invested in it. If he had not cared at all, he wouldn’t have bothered at all.
In terms of his actual practice, the notes that stem on from each other, sometimes advance an argument, in ways equivalent to paragraphs in a sequential draft. (Often they don’t, of course.) The physicality of his system, small bits of paper that therefore only have a certain amount of space on them, will effectively force this at times. (On a digital system, one can make the notes as long as one likes, but benefits accrue from the atomic nature of small notes. One can isolate individual ideas and arguments more clearly.)
It is also quite possible to use a Folgezettal numbering system while at the same time adding in brief descriptions of what the proposed connection is. (One could of course also do this with any other form of linking from anchors within the text.)
Finally, and this may be the most relevant point for TB users, TB doesn’t excel at search. In Obsidian, Roam, etc. (and Devonthink) it is easy to find related notes and to link them in wiki style. That process is more of a faff in TB, and the search interface is (sorry Mark) really clunky and hard to deploy.
TB also works on the basis of notes having specific containers. One can work with all one’s notes in a single container but that makes maps extremely unwieldy and so some degree of categorisation is inherent in the use of TB, even if it is just in the sense of a higher level container.
I find maps extremely useful with their capacity for spatial organisation, and different note types, which can be coloured and flagged in certain ways, but there is an incompatibility with getting the most out of maps at the same time as following the linking practices you are suggesting. Put simply, if one wants to use maps effectively and gain their benefits, one needs an initial position. (In my view, the hyperbolic view doesn’t really solve this.)
I also suspect that Luhmann must have often worked with his Zettels by pulling a bunch of them out and then sorting through them on a tabletop so that he could see what relationships needed refining. That physicality is similar to TB’s.
You mention in your pizza example, the need to understand context (usage scenarios), and the importance of arbitrating between the different cost-benefit propositions contained with any proposed solution.
There is not a single healthy nor unhealthy type of food. Is pizza healthy? Not, if you compare it with other options like self-prepared whole food meals. But if you are broke or stranded on an island, having a pizza (or even just a bucket of almost spoiled whipped cream) can be life-saving. This might be a controversial position, but being alive is more healthy than being ended by starvation.
Yet, people make all kinds of claims on the health properties without any contextual reasoning.
The same is true for FZ. The reasoning needs to be dialectic. But it isn’t.
The simplest follow on to that is to say: sure!
If I was not relying on maps for complex functions and just working with freeflow notes in a Roam-style application, then I suspect that the case for using Folgezettels would be less promising. But I am using TB, and there are benefits in using maps, costs in not having the note-linking ease of Roam etc., costs for using Folgezettels in any system, and benefits for using Folgezettels in any system.
So, the cost-benefit maths is complex, as is the context. My hunch is that the Folgezettel principles are more useful (maybe uniquely so) when working with TB rather than with other systems.
And also this is not about copying Luhmann or hoping to achieve his prodigious productivity through the means of some version of digital sorcery.
This also runs 180 degrees counter to what I think Martin is suggestion above, that I am intent upon bodging a job by applying a shiny but inappropriate tool. (BTW I am not saying that defensively. 
)
Anyway, if you are going to use a tool like Tinderbox, it would seem counter-intuitive not to exploit the features it offers, and to try instead to use solutions that were developed for another set of tools. For some reason I find myself remembering that in the UK a hammer is sometimes called a “Birmingham screwdriver”
Instead, I am trying to find a specific adaptation that suits my broader needs working within the constraints of the tools I have.
It could be a dead end but I will find out with time. Unless, of course, I find myself stubbornly sticking to the same track as a result of the sunk cost fallacy. Certainly more than possible. 
That is patently not the case. I suspect the ‘problem’ is you are presuming a particular UI/concept of use (perhaps a different you’re more used to). It really is worth spending some time looking at how Tinderbox’s search tools (find, queries, etc.) work and how they are implemented before casually stating search ‘doesn’t excel’. If you’re struggling with search, perhaps share some example problems.
Another misunderstanding and misleading statement. Tinderbox doesn’t require use of containers, with a few exceptions such as things like storing template or agent result. We, as users, may choose to use containers or not but it’s simply untrue to state it is a requirement imposed by the app.
Tinderbox really does repay spending a little time understanding how it works before dismissing it here in the forum because it doesn’t work like [some other app] as it is misleading for other users trying to understnad the app.
Mark. This is unfortunate. I appear to have set a pigeon racing that I did not mean to. And so let me clarify for some clumsiness on my part.
Rather than saying that Tinderbox doesn’t excel in search generally. Let me rephrase that: Tinderbox’s search UI doesn’t work with in the same way as other Zettelkasten orientated note-making apps. i.e. it does not excel in search specifically when doing the kinds of Zettelkasten linking that is being discussed here in this thread. And that doesn’t mean it is bad but just not as good as the other alternatives. I can see I should have used another verb, perhaps.
In those tools, it is easy to locate related notes and to pull them into a note you are working with while still centred on that note. Tinderbox doesn’t handle search in the same way. I often have to do two or three extra steps to review possible connections. It could be there are better ways of using the UI that I have not fully tried or understood. But I have been using it for over ten years.
It is also possible that I am attached to particular patterns and workflows that might make me resistant to things that others are more comfortable with.
In general, and this may be a personal observation irrelevant to others, I experience some unhelpful friction when using the command F search function, which is not the case with Devonthink, as a point of comparison. The UX is different in terms of how search is built.
That all said, TB has an excellent architecture for doing other kinds of search. You can build agents, and do all kinds of other things that are impossible in other programmes.
That is why I am using it so heavily and I am such a fan!
The suggestion that I am “dismissing Tinderbox" couldn’t be further from the truth. And I am surprised that my attempt to explain personal experience was taken that way. Perhaps a function of my clumsiness.
The capacities that Tinderbox has for intricate visual display is something that I find particularly useful and it is something I am trying to stretch the potential of where I can.
On the point about containers, I see what you mean. It doesn’t technically require containers in any absolute sense. But still, it is hard if you are using maps not to organise things within separate maps (containers) because there is a point at which a bigger map becomes unwieldy to use. Again may be a matter out of personal preference.
Hope that helps …
1 Like
This was a monumentally unproductive way to phrase what turns out to be a very minor objection to a tiny detail of the user interface. (I will ignore the silly comment about the search interface being “really clunky” because, if pressing ⌘-F is “hard to deploy”, we might be living on different planets.)
Tinderbox offers (a) fast full-text search, (b) persistent searches with regular expressions, a powerful and flexible query language, and optional actions — and has offered that for 20 years! (c) a link apprentice, (d) fuzzy search based on text embeddings, and (e) search based on neural-network-based extraction of names, entities, and places.
One can work with all one’s notes in a single container but that makes maps extremely unwieldy and so some degree of categorisation is inherent in the use of TB, even if it is just in the sense of a higher level container.
Why is it that the existence of containers is held as a defect of Tinderbox? If you don’t like containers, don’t use them! You don’t see me running around and laughing at, say, Roam, The Brain, and Tana because they don’t have containers. If you have lots of notes and don’t use some sort of elision mechanism, your maps will eventually become unwieldy: this is true of any system, or any conceivable system. Containers are one elision system — one that happens to be rather good. Link horizons (The Brain) are another. (Link horizons were, I believe, first used by Janet Walker in Symbolics Document Examiner.).
I’ve got to run: breakfast to be made, and feathers to unruffle.
2 Likes
Thanks. You elegantly explain this issue: Tinderbox is not optimised for zettelkasten process nor specifically designed for it.
Tinderbox’s Cmd+F find stays nicely out of the way, but once invoked the search bar stays in the view unless you click done. This reflects the fact that not all users need to be using the find feature all the time.
Find searches $Text, $Name and a choice of one user attribute: default selection is $Text and $Name but all 3 options can toggle separately; it also has (toggle-able regex and case-sensitive options in easy reach). It isn’t like DEVONthink search, but nor should we expect it to be. DEVONthink is essentially a repository (an ‘everything bucket’ though that terms is not disparaging in this context). So the sorts of searches we do in DEVONthink are in a very different context.
The way to unpick your problem is to not start out from negative comparisons (it’s not like X). What are you trying to search for (in X or in Tinderbox), i.e. what are you expecting to match? Much of Tinderbox’s depth is in the ability to abstract—by thoughtful use—information either implicit or explicit in a note’s title or $Text. Tool’s like The Archive, which mimic the paper card notions (IOW just one piece of $Text) are forced to embrace the limitations of such a format. This is where understanding can break down as constraint-based choices are assumed to be deliberate design choices rather than best choice in limited context. But it’s not a zero-sum consideration which is why comparing very different designs lead to confusion.
Many of us—probably most humans—place a higher value in what we see literally (so the UI). Thus, if the (think we) understand app A and app B looks different it is—at first sight—worse. But that is a superficial, and likely unintended, analysis. Un helpfully, as an app’s UI can thus stand proxy for the process we effect within it, we falsely assume app A is the correct canonical way to work. That is, I suspect, why the new breed of PKM apps tend to use the same plain text+wiki concept+Markdown as any departure from that—it’s too big risk for developers to use any other metaphor. What’s also forgotten is that useful PKM apps pre-ate this supposed canon.ttbx dates from 2002 (informed by/building on ideas/apps from the 1980s) and TheBrain is from the late 1990s. Sometimes we get sucked into the new. Are one window apps better than the old Mac OS, or is this a case of over venerating the constraints of small/single screen working.
Tinderbox is a far deeper, more featured app than a pure zettelkasten tool. But that should not surprise as the latter is doing a narrow (yet powerful) bounded process—and only that. Making Tinderbox look like a zettelkasten app is a fool’s errand, but only because they start form a different place. Using the zettelkasten method in Tinderbox is tractable but only if not doing so by trying to make a file-less plain text app.
Indeed, zetelkasten—stripped of the magic of the name—essentially means taking thoughtful, limited-scope notes, storing ideas/concepts in a single place, and interlinking freely (but with deliberation). There are lots of ways to do that, but our tendency to confuse UI with process can blind us to alternative—even possibly, better—ways to the same end.
2 Likes