Hello all,
I am new to Tinderbox and grateful that I encountered such a tool. Right now I am trying to navigate between all aliases of a note to see all connections I made. How can I achieve this?
I’ve not delved into agents and actions yet. So the answer is straightforward, pardon my clumsiness.
Thank you.
Do be aware that whilst the text links (links anchored in $Text, similar to a web page) are common to an original and all its aliases, that note and each alias can have it’s own aliases. That might not be what you assume (although the status quo is for a reason).
A note is not linked in any way to its aliases so there is no navigational method as such (and the lack of a connecting link means you can’t use hyperbolic view to see original and aliases together. Without knowing how all the aliases came to be its is hard to understand this scenario more deeply.
Meanwhile, youmight find it useful to read up on Aliases (and pages linking to that article (which are listed at the end of the article).
I checked the reference file for hyperbolic view and aliases and experimented a little bit in Tinderbox. I want to ask about the best practice using a note across multiple contexts. I can link without placing an alias at two places. And one solution came to my mind is to use aliases and duplicate same relationships from the original note. How do you proceed?
It’s hard to give advice as we don’t know which view(s) you are using—Tinderbox has 11 views—or what you are trying to do. The is no one single way, so for each individual the process is slightly different. Best practice is thus a blend of:
If using aliases (most likely in maps) note that when dragging links to an alias, the popup (circled) allows the link to terminate at the original and not the alias.
Indeed, if dragging between two aliases, both can be altered so that two originals are linked despite the linking context being two aliases..
Bottom line, it makes more sense at this stage to explore what you are trying to do (subject matter/context, methodology, etc.) so that the community can suggest what on the Tinderbox toolbox suits that best. Trying to start by asking for best practice tends to lead to a do-over as best practice will vary from person to person as goals differ.
HTH
The attribute $Aliases provides a list of all aliases of an original note. That might be useful.
It helps a lot to be more concrete? Can you tell us more about your data, and the question you’d like to answer?
It’s possible the idiomatic approach is to create a note that is linked to your original note, and not to use an alias at all. Or aliases may be exactly right.
Here’s the workflow in my mind:
I think links rather than aliases are likely what you want.
The core skill of an alias is that it retains its identity across renaming. That’s not really core to a proposition such as “this must be the best possible world” or “Alcibiades is wrong.”
More broadly, this might be more formalism than your task requires. Or it might not! Here is an interesting auto ethnography in which quite a lot of work was supported by <1000 notes.
3800935.3830837.pdf (1.1 MB)
Tinderbox composites were intended for this sort of thing, but your current data scheme is probably too complex for composites. (It might be interesting to try, though…)
Grady Booch has been on Twitter recently discussing doing something similar with UML.
Let me restate my question. Let’s say I started with creating a skeleton for a book, the notes resides in the book’s container. But there will be times I want to re-categorize those ideas according to my own schema or want to use them in output. Let’s say I created aliases for this purpose. And some time passed. I want to see where I used that particular note. I can’t go between aliases. How can I get a quick view of where that note appeared? I am not a fan of linking across containers. I want to see the linked piece on a new container. I respect opinions of tools. If that’s not the way you operate, I can happily rethink my procedure. But from Zettelkasten tradition, this is what I am used to.
I will check the paper, as it’s always interesting to read about the knowledge work.
My data scheme is quite simple actually, don’t be overwhelmed by the names. It just means create a container every time you want to go deeper and picture the corresponding idea with dots (concepts), linking words and formed propositions.
It looks like you are after a re-useable set of notes/links to pre-populate new maps (of new investigation. For such blocks I see two constituent elements:
So you could have a prototype that instantiates a sub-map with stub notes for your new process but the links on the sub-tab would need to then be added by hand.
Tinderbox containers are not typically used as disparate card files, and so it’s really quite common to link across containers. You don’t have to do this, of course!
For example, one common arrangement is to keep the references for an article or a book in one container, and the notes taken from those references in another. The references are kept sorted by author and date, and the notes are arranged topically.
While we’re on this subject: I often recommend that people avoid complex organization at the start of a new project. It’s easy to build apparatus that you won’t need; we call this premature formalization.. This probably isn’t an issue for you, but I want to mention this as a signpost for the future.
Thank you both for your responses. I decided to create artificial aliases. “Note (2)” for example and I will link the original to the second instance.
I am somehow resistant to linking across containers. Maybe this can change in the future
You may find this discussion useful, as it may be similar to your use case:
It is eight years ago already. At the time, I had a system for “cloning” a set of notes in one container into another container, using aliases. The idea was to have a kind of template of concepts whose inter-relationships I wanted to explore, and then clone several, distinct instances of all of them, then alter the relationships. It worked more or less, but more less than more and eventually I gave up using it. It was difficult to revise. And the goal was to be able to alter a concept’s content (in $TEXT) anywhere.
Part of the reason I did it this way was that at the time there was no way of using Actionscript to create a note. That has changed. Moreover, there is more programmatic access to links than ever before. So you may find that you could achieve more of what you want if you were to switch to using more Actionscript, rather than the affordances of aliases or the GUI.
You are not alone in this…this has me reflecting on work the community was doing a year or two ago on create diagram/flat file vies of tinderbox notes. See the work @echuck did on this, I’ve also has several attempts at this as well.
My only causing, IME (in my expeirence), is that creating duplicate notes makes it hard to avail yourself of one of Tinderbox’s most important concepts: keep your key concepts in once place, what I call resoruce notes, and your writing and thinking notes in another—and use transclusion and inclusion methods (i.e., templates and action code) to cross-reference your thinking.
Which tutorial demonstrates the use of templates and action codes for these purposes?
Let me get back to you this weekend, I’m buried until Saturday. Need to find them or create something new for you.
The problem is in Tinderbox community you guys jump directly into synthesis but I adopt an intermediary step of creating Zettels and Zettels can be used in different places.
I create aliases right now and discovered that a link can be established either between the original note and the alias, I do the both. This solved everything.
@entropydave Thank you for pointing out.
I wanted to follow up on Michael’s comment to clarify a point that might be of interest to the goals stated by @c4lvorias in the original post. The “Diagram View” I shared in June of 2025 works on the concept that original notes in your document can be reflected into a set of “reflection notes” residing in a designated container that in turn presents a diagram in Map view of the reflected notes, but using the reflection notes.
It is important to note that a reflected note (i.e., original) is not duplicated. Instead, a reflection note is created and linked back to the original (reflected) note. There is action code that synchronizes attributes and links between the reflection note and its original note. The user can control precisely which attributes and links are synchronized. I should also emphasize that reflection notes are not aliases. Reflection notes only exist within a Diagram container, but they do link back to their original reflected note, and the original reflected note can link to each of its reflections, assuming that there are multiple Diagram views where the same original note is reflected. The Diagram View package provides all the action code necessary to establish reflections and maintain synchronization between a reflection note and its original.
While the purpose of the Diagram View package is to enhance the Map View to allow a Diagram container to be mapped with what appear to be notes scattered throughout your document and residing in various containers. However, this approach could be used for other purposes besides creating diagrams in Map view. In particular, each Diagram container contains its own set of real notes, not aliases. There is no reason that this couldn’t support other views or ways of working with your notes that could overcome some of the constraints of a fixed hierarchy.
As noted, the user has control via either the Diagram container or for each individual reflection note on what attributes and links of the original are synchronized. For example, if $Color is synchronized, then changing the $Color of an original note will result in a reflection note having the same $Color. Conversely, synchronization can be turned off for any attribute. For example, synchronization of $Text could disabled, allowing a reflection note to have its own $Text independent of the original. It is also possible to extend the facilities provided in the Diagram View package to further customize how synchronization works. As an example, you might want the $Text of a reflection note to include a portion of the $Text from the original, but with additional text added automatically or as a follow on manual edit. This can also work both ways. The original (reflected) note could include elements from a reflection note (or from any or all of its reflections). In other words, the Diagram View provides new scaffolding that can be extended with custom behaviors.
Perhaps this might give you some further ideas on how to use Tinderbox for your purposes.
