To replicate the essential features of the paper-based Zettelkassen system, with potential improvements.
Requirement: The notes data must be in such a form that they may be transferred to another notes system (even a paper one) without losing any essential data.
Discussion: If the note-keeper decides to change to another notes mangement system, the data must be useful outside the Zettel-box, so that months or years of research not be lost. What is the most basic alternative system? That would probably a full-text search system. Another basic system would be a paper system like the original zettelkasten.
These needs lead to the next requirement.
It appears that it will be relatively easy to export the zettel-box data into a text format.
Requirement: The zettel-box notes must be in a text format. They may be one note per file, all notes in one file, or a combination. Alternatively, the system must be able to export such files with no loss of data.
Definition: "Text format" includes slightly structured text-based formats like Markdown or ReStructured Text. It excludes more complex formats such as XML. The intent is that the note files must be easily readable by a person.
Discussion: Using one file per note seems to be the simplest way to emulate the original paper-based system, which had one card per note. However, a larger file could be used if there is simple way to extract or recognize individual notes. This would allow a computer program to separate the individual note if needed.
Using Leo nodes for the zettels, text format files will not be hard to export.
Requirement: If a note needs identified sections, the section demarkations must be easy to type, easy to read, and easy to parse by computer.
Discussion: An identified section could be a URL, a group of references to other notes, a tag or indexing aid, a citation list, etc.
At this time, if we use one Leo node for one zettel, section markers would not seem to be needed. They could be part of the exported text format.
Requirement: Each note must be uniquely identifiable, so that it can be referenced by other notes.
Leo identifies each node with a unique ID that includes a timestamp.
The "backlink" Leo plugin lets a user add links between two nodes, and navigate to linked nodes by clicking the link in the "Link" tab. There does not seem to be a way to label a link with a name or type.
It would probably be possible to enhance the backlink plugin to have labeled links. The point of labeled links would be to search for only certain kinds of relationships, which is useful.
The plugin can also link a node a URL.
Requirement: Each note must be able to have an optional timestamp.
Discussion: A number of people have written that having a timestamp is helpful in reconstructing the context of recent work, since the most recent notes most likely represent work that was recently done.
It is currently unclear about whether only a creation date would be enough, or whether a last-modified date will also be helpful. It the interest of simplicity in a potential move to hand-created or paper notes, a single date would be better.
Leo nodes have an ID that includes a creation timestamp.
Requirement: The system must be capable of optionally attaching one or more "tags" to any note. Tags must be easy to create, delete, and attach.
Definition: A tag means a property represented by a name (a string).
Discussion: Tags serve primarily as a filtering mechanism, to help identify notes in a general area of interest.
Leo has a plugin called nodetags. This plugin lets a node be assigned one or more tags. It can do a fairly comprehensive search for combinations of tags.
The plugin does not support any structure for the tags. But if one wrote a tag name as a path statement, like zettel/navigation, it should be fairly easy to parse them into a structure, or to search on just part of the tag.
Requirement: For every link to another note that is inserted into a note, the system must create a corresponding link in the target back to the first note. Alternatively, the linking system may be inherently bi-directional, such that backlinks occur automatically.
Discussion: If the system exports data to text files, the backlinks must be included in the exported notes data.
The Leo "backlink" plugin automatically creates links between nodes in both directions, so creating a link effectively creates a matching backlink.
Requirement: Selected subsets of notes must be displayable in both a hierarchical display (where parent/child or sibling relationships exist) and a non-hierarchical display of associated notes.
Discussion: A strength of the original zettelkasten paper system was that one was not forced into thinking about the notes as having any kind of a strict hierarchy. This feature must be preserved in the new system. The apparently hierarchical identity coding was mainly for locating notes in the note boxes. However, notes near each other were more likely to relate to each other.
It would be possible to have parent/child relationship between notes that were not located near each other, but having them close together tends to make them more available when working on a subset of notes.
Requirement: It must be possible to add additional types of displays besides a basic parent/child.style.
Discussion: This should not be taken to imply that any arbitrary display idea should be easy or even feasible to implement. It is intended to indicate that other display styles than a straight parent/child hierarchical display will probably be found to be desirable, and that the system should make it possible to implement at least some kinds.
In Leo, the most obvious way to display subsets of notes would be to clone them and move the clones under a single organizing node. This collection could be ephemeral or permanent as the user desires.
For a non-hierarchical display, the simplest way would be to have all the notes (or their clones) as siblings under a single organizing node.
LeoVue is one system that makes possible coordination with browser-based displays, some of which can be be interactive so that actions in the browser can be reflected back to the Leo file. There are probably other such systems.
This is one way in which new display kinds could be created, ones that Leo's panes and display mechanisms may be less suited for. The cost, aside from the effort of implementation, would be that a web server would have to be involved, most likely on the user's computer. However, such relatively simple personal servers are not hard to install and get working.