Agreed!
1 Like
I’ve now had a chance to download the demo and test it, while reading the instructions in @mwra’s post above.
This code is numbering things exactly as I would expect it to. And the two variables that the user can set make it very configurable indeed.
For my purposes, this does what I had originally been looking to do. I’m trying to study the code with the TBX Reference open alongside. Also, I’ve only tried it in the dummy file. I’ll try to implement it in (a copy of) my working document to kick the tires a bit more, and get back to you.
Thank you very much, @mwra.
1 Like
Ooh - hit top dead centre for once. Good news! I hope the demo helps others. A method to implement a ‘numbering’ system something like this in Tinderbox has been suggested and is being investigated (though I don’t read that as necessarily getting carried forward.
That said if others here have comments/requests on the narrow issue of zettelkasten-like ‘numbering’ do please say so.
Meanwhile, I’ll follow up with @talazem on the export side of his original request (we’re on a PM at present) and I’ll share back a further demo if we make sensible progress.
2 Likes
If you make “sensible progress” I’d love to see the demo! I was getting hung up in all of the details of making the perfect export and numbering, etc. I’ve taken a break from it and I’m focusing on reading and taking notes! I will want to circle back at some point to tweak it for export, etc.
Sure, that’s the plan. I’m pushing ahead on a PM queue as we’re gently pulling out edge case stuff and it might sound like crickets here but progress is happening. For instance, @talazem noted that using full stops (periods) for the segment delimiters in the code fails if you use the code as the zettel note $Name. Why? Consider, if I export ‘001.002.003’ to HTML, I end up with a filename ‘001.002.003.html’. Not helpful!
So I’ve also parameterised the the ‘code’ segment delimiter in the ‘Zettels’ note. A full stop (or period) might work well internally, but if exporting you might want to use a different delimiter. If you don’t, a full stop might be more useful in giving horizontal compression of a long code.
So here is an updated demo. I’ve changed $ZettelCode to $ZettelNumber to track @talazem’s usage but none of these user attribute names are writ in stone. Change them to your needs - though make sure the code-setting rule is updated.
zettelcode-demo.tbx (115.8 KB)
Thanks, Mark! I wasn’t trying to push. . . I’m just really curious to see demo files of Zettelkastens.
FWIW, I’m using a fixed reference named $Zettel_String. I use this as an Action:
"$Zettel_String=$Created.format("yM0Dhmm");
Interesting. I’m a bit of a by-stander here, as in I’m not a zettelkasten-er (I know, not on trend at all).
I get what code you get but I assume it doesn’t allow for subsequent zettel-note moves in the TBX?
Correct. I want my Zettels to have a fixed ID. If I ever dump notes into a markdown system such as The Archive I would want the numbers to be consistent. I want to be able to move notes around in a hierarchy and still retain my IDs.
Err, but they do: $ID (Tinderbox’s UUID for notes). See here. Or am I misunderstanding?
Sorry, I don’t mean to get the conversation off track. I like having the ID built from the date., i.e. 202003251154. I’m drinking the kool-aid over here: You Only Find What You Have Identified • Zettelkasten Method
Nothing wrong with that! I’d simply mis-understood your earlier comment to imply Tinderbox notes had no unique ID. Date/time of creation is an alternative. Although date/time attributes reflect time to the millisecond, depending on how you format the data not all note will have a different value.
Even if you use some other $Name, you can still sort on $Created—or any other date.
I can’t help but reflect that Luhmann’s system was constrained by the limitations of the (paper) card medium. Recreating that in a tool as rich as Tinderbox can be fool’s errand if recreating limits dependent on the paper medium. That’s not critique. If a solution works for you, that’s good. 
1 Like
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