I hope the original intention behind this thread remains clear. One might say that a collection of notes draws upon Luhmann’s insights if:
a. there is no pre-conceived hierarchy of topics
b. notes can be linked together
c. note sequences can emerge*
i.e. that there be no rigid hierarchy, while allowing structure to emerge.
Tinderbox shines when it comes to emergent structure. The ‘magic’ (to borrow the term) is in seeing relationships and meaning emerge out of years of research and reflection.
The original question was about whether Tinderbox’s features could be used for a very specific use case. Namely, how to use Tinderbox to export notes that have been organised according to the three principles mentioned above.
I agree with @PaulWalters that sometimes it is better not to use Tinderbox and just use something else. But I like working in Tinderbox, and only wanted to explore whether a TBX-based note collection could be exported in a way that would numerically maintain the representation of sequences. I am grateful to those who volunteered solutions, be they low-tech or automated.
The question most definitely is not about a particular technique, let alone an arcane numbering scheme. If one is never going to export from TBX, the whole question of ‘addresses’ is redundant. There are other meaningful ways to learn from one’s note collection, whichever side of the egg you prefer. But, if it is acceptable use of the forum to ask questions about exporting notes with an eye to printing on paper or using them in other apps, then some of the ‘old’ techniques might still be informative and helpful to our discussion.
(* I know this one is debated, but I for one have experienced practical and cognitive benefit in utilising both note sequences and links, be it on paper or on a computer.)
There’s really nothing to “debate” – I like clutter and assign meaning to the texture of the whole – the rooms in my puzzle palace are generally not adjacent; others like structure and sequence. Horses for courses, and Tinderbox can accommodate those poles and many more.
Personally, I think there’s a bit of a prescriptiveness in the blogs and various forums (but not here) that assign a kind of sacredness to Zettelkasten – which (I think I am agreeing with @brookter here) is unfortunate because it misses the value of alternatives. But, fads fade, and the work goes on.
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.
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.
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.
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.
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.
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.
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.
