A Tinderbox solution to organising a Zettelkasten?

Tinderbox Tasks
1

I have a Tinderbox file which serves as my collection of reading notes. I have modelled it on Luhmann’s infamous Zettelkasten, by which I primarily mean:

a. that there be no pre-conceived hierarchy of topics,
b. that note sequences (folgezettel) could emerge,
c. that I can link notes together.

Of course, Tinderbox allows for all three of these activities perfectly (and the recent addition of ZipLinks makes it easy and quick). TBX also gives me analytic tools that other note-taking software or plain text solutions do not.

However, I must be able to export my collection into the Finder. This allows me to sync them via iCloud and access them in apps like 1Writer, and to make sure that years of notes are not locked into any one application in the long term.

It is imperative that I be able to keep the order of notes that I have carefully cultivated in TBX intact upon export. As a result, the exported notes cannot merely have descriptive file names: they have to be based upon some kind of sequential numbering system that would preserve the order of notes in TBX. This desire to file new notes within existing note-sequences (Luhmann’s folgezettel) also precludes using the creation date of the note as its title.

My initial solution was simply to follow Luhmann, using his alphanumeric system that allows for interpolating notes as the name of my notes.

There were two problems with this:

  1. if I want to change the order of my notes in the TBX Outline, I would have to go back and manually renumber all subsequent notes. This is clearly not feasible, and also takes away one of the main benefits of a collecting one’s notes in Tinderbox: the ability to think through arranging one’s notes into a meaningful order, without breaking all the links to the note.

  2. because each note’s name was a mix of numerals and letters, I could not use TBX’s ‘Sort’ feature (for the reasons outlined in another post) to re-order the notes should they get scrambled in TBX. Alphanumeric numbers like 1/10a5 would end up coming before 1/2b, as they are treated as lexical and not numeric units.

The solution which I am now trying is to simply use the TBX System Attribute ‘OutlineOrder’ as the note’s ‘number’. This attribute changes its number automatically depending on the place of the note in the outline. The export of the notes can, of course, be set up to use this OutlineOrder number as the name of the files produced, thus allowing the notes to be sorted correctly in the Finder.

I’m posting this in case it is of use for any others using TBX for similar purposes. However, if anyone sees any potential downsides to this, or has a better solution, please do chime in.

5 Likes
2

Instead of building your own, and facing the potentially onerous task of regularly maintaining the Tinderbox document(s) you are using for this purpose, why not just use something like The Archive, which is purpose built for this sort of work, and saves its notes as plain-text files that can be synced to iOS / 1Writer etc.

In essence you are reproducing in action code and export code what already-existing software already does well.

2 Likes
3

I’ve had the same quandry. Since Ziplinks have been added to Tinderbox, it now does what I need (with a few little issues). The Archive is a great program, but doesn’t have the visual/spatial aspect that Tinderbox has, and that Luhmann’s original zettelkasten has.

1 Like
4

True that. But very portable.

5

Thanks for the suggestion, @PaulWalters. I started this TBX-based solution a year ago, for a few reasons:

  1. I don’t think that the way that The Archive (and similar software) has been built is actually suitable for Luhmann-style zettelkasten (by which I mean the three points at the top of my original post). By using the date the note was created as the organising principle, you cannot file new notes behind pre-existing notes and create local note sequences (folgezettel).

  2. None of the other software holds a candle to what Tinderbox provides by way of analysis of your notes, using agents, the Attribute Browser, etc.

  3. None of the other software actually harnesses the ability of a computer for realising a digital zettelkasten.

Let me unpack this third point because it is important. In my view, the primary benefit of the Archive (for example) over a paper-based zettelkasten is its ability to search using keywords, Google-style. In fact, this is the primary way in which one finds one’s notes in their version of a zettelkasten. The only other benefits are speed (which is not always a virtue) and the portability of a digital collection via sync, using laptops, etc.

However, my own experience supports what University of Chicago’s Andrew Abbott has found: that keyword indexing and search is not only over-rated, but counter-productive for scholarship. Compare this to what Tinderbox can do: like The Archive and others, you can view your notes in an outline, a list. If named correctly, this allows you to see clusters of notes, the note sequences to which I refer above, grow over time. So far, nothing that a paper-based zettelkasten can’t do.

Where Tinderbox shines singularly amongst all software for a zettelkasten (with the possible exception of ConnnectedText) are all the other views. This is not eye-candy. The recently-introduced Hyperbolic View in Tinderbox is the most brilliant way to see links made between notes across the entire collection. Unlike Map View, the benefit of which is largely restricted to one container, Hyperbolic View shows you the a notes links to all other notes in the file, and more importantly how those notes link to any other notes.

Between Outline View and Hyperbolic View, you have the most perfect visualisation of your zettelkasten and all its internal links and connections. The Outline View for local note sequences, and Hyperbolic View for notes sequences created via links. If you are going to use a computer for notes, this is why you do it. Tinderbox is really ideal for the purpose.

4 Likes
6
  1. How about using $OutlineOrder as the exported name?
  • Pro: always sorts right in Finder,
  • Con: the same note many have a new name tomorrow
  • Rebuttal: the purpose of unchanging numbers was to make links work for Luhmann, and we already do that.
  1. Use a Table Of Contents, not Finder ordering
  • Pro: you can use whatever order you like; you don’t have to expose messy numerical codes
  • Con: might be harder for ultra-low-tech clients, like opening files
  • Rebuttal: the old software development maxim: you ain’t gonna need it.
  1. Use a homogenous index system and sort on that. In other words: 005.001.030.000 instead of 5a30
  • Pro: easy to extract subfields with regex, keep things sorted; Finder and Tinderbox sorting should coincide
  • Con: messy. involves regex. reproducing last-century expedients.
  • Rebuttal: not that messy.
4 Likes
7

I understand the analysis. The wild card is the requirement

“I must be able to export my collection into the Finder. This allows me to sync them via iCloud and access them in apps like 1Writer, and to make sure that years of notes are not locked into any one application in the long term.”

My own approach is, if I must have a requirement like that, then I don’t use Tinderbox. So, I agree with you that Tinderbox is a fine Zettelkasten tool – IFF I don’t try to transport those files to another OS environment.

1 Like
8

If the Export is a problem, bear in mind that the TBX file is XML. OK, not something the average person knows, but not an impossible to read private binary format. So, your data isn’t trapped. I only mention this so you can decide if the effort in ongoing export is worth it given you can get at the XML if some crisis occurs.

2 Likes
9

@PaulWalters: My day-to-day usage of the notes is in Tinderbox. The condition to export is primarily for long-term security (without having to worry about fiddling with XML, @mwra, though you are right that it is also comforting), and occasional portable access. The export is a keyboard shortcut away and takes a moment. But, yes, it has made me think of this issue of how best to number the cards. But the virtues of a zettelkasten in TBX far outshine these small challenges.

10

Thanks for the analysis, @eastgate. Your third solution may work for some, but doesn’t really replicate Luhmann: the branching could go many more places deep (21/3d26g53 was apparently a real card, discussing Habermas). And while it solves sorting (the original problem of the other thread), it precludes the other benefit of using a computer and software that allows for reordering the notes without breaking links since there is a permanent ID—one would need to manually change all subsequent cards if the order was changed.

Not sure if I understood #2, but if I did, then again it goes against the Luhmann approach: you don’t want to be making a Table of Contents for the whole collection because related and linkable notes are often dispersed. The point of the address is to provide a door in to the collection using the Keywords Index, and then exploring via note sequences and links thereafter. But maybe I misunderstood.

So far, it seems that #1 remains on top for purposes of export.

11

The table of contents can be assembled by the computer. But you know what you prefer!

12

It seems to me that Mark B’s solution 3 is getting you closest to what you want to do.

The following is tentative, so please ignore if you don’t find it helpful or if I’ve missed something obvious, but…

As far as can see from your other post, if you take away the commas, your numbering scheme is actually just a regular sequence of numbers and letters. If you made the following changes:

a) all numbers are given leading zeroes (the further down the hierarchy, the fewer zeroes are needed), and;
b) you translate the numbers with commas into decimal numbers, while giving the numbers without commas a .0 number, then

you’d be able to sort on the UUID.

e.g. the following numbers from your current scheme are not currently sorted properly, but if you made the translation (to the number after ->)

  • 0_11,2a5 -> 0_011.2a05
  • 0_1,3a5 -> 0_001.3a05
  • 0_1a5b7a -> 0_001.0a05b07a
  • 0_2a5f3g1 -> 0_002.0a05f03g01

and will sort in the Finder as follows

  1. 0_001.0a05b07a
  2. 0_001.3a05b3
  3. 0_002.0a05f03g01
  4. 0_011.0a05

which is what you’re after (I think)…
(If you have commas at levels below the first one, then you’d repeat the ‘make it a decimal’ trick.)

Obviously, it doesn’t matter whether you think you’ll need the ‘decimal’ numbers as 001.1 or 001.001, as long as you do the same thing every time.

The example you give from Luhmann would simply be 021/003.0d026g053, which is sortable and extensible.

If you were starting from scratch, wouldn’t this work for you? I may have missed something obvious, of course.

But you need to get there from where you are… This would be a really complicated regular expression to do in one go, but it could be done as a series of fairly simple conversions, I think, and once you’ve done the conversion, then you can simply continue with the new format. You can add new levels arbitrarily as you go on, as long as you stick to leading zeroes for numbers.

How may cards do you have now?

Sorry if I’ve missed something…

5 Likes
13

No, you’ve not missed anything at all, David. It is I who misunderstood what @eastgate was suggesting earlier. This is now clear, and works very well. Using periods or commas for later interpolation works exactly as it should, and the whole thing doesn’t look too bad. Here’s a dummy file demonstrating it:

Screenshot 2020-03-25 at 14.02.34
Screenshot 2020-03-25 at 14.02.341432×766 71.1 KB

My digital zettelkasten in the TBX file is not yet too extensive, so some hours of renumbering will suffice. Many thanks for the extensive and clear explanation, @brookter.

The decision now is whether using Luhmann’s numbering manually adds or takes away value in a Tinderbox-based zettelkasten. Adopting MarkB’s technique above:

  1. Manually number by Luhmann’s system & sort by it
  • Pro: Note-sequences & branches are visually represented by the alphanumeric system, which allows you to quickly recognise that notes are in a sequence and related. If you ever have to abandon cultivating the zettelkasten in TBX, you could carry on the same naming protocol in other software or even in a paper-based ZKN.
  • Con: You lose the ability to reorganise the notes at will (reorganising is one way of reflecting and understanding your note collection).
  • Rebuttal: A benefit of fixed addresses is that you don’t waste too much time worrying about where a note goes; just link to it.
  1. Sort manually in Outline view & automate numbering for purposes of export
  • Pro: You are able to reorganise the notes after having filed them, with all the cognitive benefits this brings.
  • Con: There is no numerical representation of note-sequences and branching. Automated numbering does not actually protect against the disaster of your note-sequences being destroyed if you accidentally (mis-)sort your notes, as the OutlineNumber will automatically change to reflect its new position in the outline. If you ever have to move your zettelkasten out of Tinderbox, you’d have to find some way to number every individual note in a fashion that would preserve your order.
  • Rebuttal: In TBX, you could still visually reflect branching by making branch notes ‘children’ of the parent note, and by making more links. If you ever have to move out, you’ll find a way to use a computer to renumber the notes.

(I’d normally not post my train-of-thought on something like this. But since others use TBX for their zettlkasten, I hope it might be useful. And the feedback and suggestions from all the participants is gratefully received, and any more welcome.)

1 Like
14

I’m very pleased it helped!

15

Well you could make a hybrid system that combines the sibling order of ancestors:

$MyString=;
$MyList=collect(ancestors,$Path).sort($OutlineOrder);
$MyList.each(X){
   if($MyString){
      $MyString=$MyString+"."+$SiblingOrder(X).format(0,3,"0");
   }else{
      $MyString=$SiblingOrder(X).format(0,3,"0");
   };
};
$MyString=$MyString+"."+$SiblingOrder.format(0,3,"0");
$MyStringA=$MyString;

I’ve deliberately left-padded the sibling numbers with a zero, so the each ‘segment’ of the zettel number has 3 digital - allowing 999 siblings per segment. If you think any segment might need over 1,000 siblings amend the ‘3’ to a ‘4’ in the format() code and you will get 4 digits allowing up to 9,999 per segment. Although the segments between fixed lengths are constant, the number of segments is only limited by how deeply you nest.

It seems a lot to run as a rule but sadly moving a note via drag-drop doesn’t seem to fire the Edict (which isn’t what i expected).

As people seem quite first up about the zettelkasten approach, putting this logic in an action might be useful (with a parameter allowing the user to set the number of padding digits).

1 Like
16

Forgot to add, for those who like things visualised, here is the above in action:

Untitled 2020-03-25 17-08-01
Untitled 2020-03-25 17-08-012164×950 302 KB

I’d also add, that I’ve used Sandbox group system attributes like ‘$MyString’ to help illustrate (assumed) data types during the process. However, for real use—especially if you tend to use Sandbox attributes—to replace those attributes with user attributes (of the same data type) but with names that make more sense to you and which won’t be used in other rules, etc.

17

OK, there are some immediate issues - perhaps not insurmountable:

  • The sibling numbering in a map includes adornments and although by default all adornments number after all notes, so this _ought not to be an issue. In testing the above, using ‘Got to front’/ ‘Go to back’ commands (which move the note to the end of the sibling orders (albeit shown in the map via Z-order) it seem to the sibling separation of adornments to break down. Downside, this might make you think you’d lost a zettel note due to a sequence gap.
  • The edict approach is probably flawed as if a note is moved you will need to update, at minimum, all sibling notes and more if the note has moved level in the outline.

Still, I do think it shows a way forward.

1 Like
18

This indeed has great potential, @mwra, thank you! Is there a way to modify this, so as to start the counting from a particular note? I’m trying to figure out how to tailor it to start counting from a specific container.

I’m grateful to everyone who has made this an educational experience beyond the issue of zettelkasten-ing.

19

Make the root container for the zettel the first sibling. Just sticking an offset into the code is a nasty kludge, even if you fully understand the code. Or you could test the outline level inside the loop and just ignore the root level folder. That assumes the root container of the zettel notes isn’t part of the zettelkasten, but there’s not enough information here to know if that’s possible. Please be aware that I know nothing about zettelkasten except what I’ve read here (as it’s not really something that particularly interests me). I’ll assume if something’s not described, I don’t need to take it into account as I just helping to resolve a problem expressed within Tinderbox.

In looking to tweak the numbering systems, do be aware of a law of diminishing returns. The more baroque the code gets the more scope for hard to figure errors grows. Good enough sometimes is better than perfect. :slight_smile:

20

I am getting lost re-reading this thread, wondering just what problems are on the board for resolution. It seems like these are the issues:

  1. How to number notes in so-called zettlekasten fashion (a la Luhmann, in other words).
  2. How to encode the path between notes into the note-numbering scheme.
  3. How to use the note-numbering scheme to reassemble notes if they need to be exported.

Is this correct? If not, please adjust – I’ve made this note into a Discourse wiki-note so others can edit it.

2 Likes