reConsidering TB, does this primitive functionality exist?

Q & A - getting started with Tinderbox
1

Hello everyone,

I was an early user of Tinderbox back in Uni, just when Apple started with Mac OS X. It’s been a long time. (I wonder how generous the Eastgate’s “upgrade” policy is :slightly_smiling_face:. That computer and the email associated with that uni account is long gone!)

At the time I didn’t use Tinderbox “deeply” but I did enjoy what it afforded me at the time. I am refactoring my work process lately. And while I have always been helped by visual aids, I suffered an injury since those early Tinderbox days that has made visualizing things all the more important. Over the last year of refactoring things I had been looking for a more visual approach to my notes with greater and lesser success. I didn’t know Tinderbox was still around.

So while I know TB is a robust and odd piece of software, there is basically one thing I would “require” from it.

Ideally I could have a multiple containers and each would represent some sort of relationship among the notes within it. A note could live in any of those containers. I am aware TB supports aliases and some of the limitations of aliases. But what I ideally would like to be able to do is to query across any number of given containers to say, what notes do all the selected containers have in common and place those notes into a new container.

Then more ideally(!) once I see there is a meaningful relation among notes shared by various containers, any notes which would be so shared would land “automagically” into the container which describes that new relation.

Consider the containers sets and I am looking to find intersections among them. Then to programmatically to pull members of that intersection into the note which represents that intersection.

I hope this is clear. I have a tried a few other tools which get close but don’t really think of leveraging the container - note relationship well (Heptabase is so so close.)

I know a common suggestion is to check out the trial. I was always a slow learner and user of any new software; my injury made that all the more so. So even tho Eastgate provides a generous trial, it likely wouldn’t be sufficient for me to suss out all that I would like to test with my other tasks which sap my diminished cognitive capacity.

I appreciate the candor here on this board. And I said primitive above, I mean without the use of applescript or whatever to support such functionality.

If my legendary license allowed the $100 upgrade it would be easier to blindly test drive the software. But $300, not so much.

My post may be more error ridden than I wish. Before my TBI I had dyslexia. The TBI unfortunately didn’t cure it like in a cartoon, but further complicated it.

Thank you all for your help!

2

Yes, Tinderbox upgrades are $98 from any previous version.

Ideally I could have a multiple containers and each would represent some sort of relationship among the notes within it. A note could live in any of those containers… But what I ideally would like to be able to do is to query across any number of given containers to say, what notes do all the selected containers have in common and place those notes into a new container.

This is so abstract that, I suspect, few readers will follow what you would like to do. If we knew what sort of notes you were working with, it might be easier!

But yes, you can easily find notes that are inside(Rome) & inside(Baths). Or inside(Rome) | inside(Constantinople).

1 Like
3

Consider the containers sets and I am looking to find intersections among them. Then to programmatically to pull members of that intersection into the note which represents that intersection.

If you enjoy academic papers, you might take a look at Parunak, H.van Dyk (1993). Hypercubes Grow on Trees (and other Observations from the Land of Hypersets). Hypertext’93, 73-81. In the ACM digital library if you happen to be an ACM member.

4

Thank you for the quick response! I doubt that Eastgate extends upgrades to previous versions that only exist in memory! :slightly_smiling_face:

It sounds like TB can do part of what I want. That is great news.

Yeah so let me give an example. This is “simple” version of what I am talking about since I didn’t need any fancy tools to find it.

A lot of the stuff I work with revolves around Biblical literature and related texts.

Let’s say I have a container which contains brothers. Now I know there are different sorts of brother themes in ancient literature. So notes from that container will also be in containers like reconciled brothers and unreconciled brothers. (This could be ordered differently, but going to keep it “simple”).

Now I also have a container which contains meaningful chiasms (a syntactic structure in oral and ancient written literature which can span large amounts of text) called chiasms. Of course there are different types of chiasms. I have two containers: parallel chiasms and nested chiasms.

As I am looking through parallel chiasms I notice that Jacob and Esau are notes within it. I also know they are in reconciled brothers (a contended argument) and I see some other reconciled brother pairs are in parallel chiasms. That’s interesting I wonder if members of unreconciled brothers tend to be in a given type of chiasm (in this simple case, nest chiasms), so I query inside(unreconciled brothers) & inside(nested chiasms) and see that there is a relationship there. So I have a little evidence to start considering the semantic use of the chiastic syntax. Surely the brother relations alone may not cohere so.

Now I would like a container that is populated by inside(unreconciled brothers) & inside(nested chiasms); let’s call it chiasms of unreconciliation. Ideally this container will dynamically updates its notes. If a new note fits: inside(unreconciled brothers) & inside(nested chiasms) an alias in now placed into chiasms of unreconciliation.

Basically I would like to use a container to represent a group notes which are semantically linked. The semantic link is the container. I would like see the relationships among different semantic links. Most note taking software doesn’t do a lot with links other than to say this note is linked to that one. It’s not terribly useful for most of the stuff I care about. Being able to place these semantic links within one another (the brothers container would contain reconciled brothers and unreconciled brothers) while also showing relationships with other semantic links which are not related hierarchically is what I am looking for.

This can be done with some other methods, but the visual aspect is helpful at least for this human user. Within a given container the relative position of notes to one another can take some meaning. Sections can be used for some provisional refinement into possible other relationships. Etc.

I hope this makes things a little more clear.

Also I wonder within a give note that has aliases in many containers can you “see” to which containers all the aliases belong.

Thanks again for the help. I really appreciate it.

5

As part of ACM’s move to make more data open, access to an DL.ACM records pre-2001 (i.e. less that 50 years after ACM’s formation) is now free. This is not the same as formal Open Access but it does mean older papers can be read without a library subscription. At least, that is my understanding†.

†. Please correct me if wrong. I have DL.ACM subscriber access but trying to test without it , it keeps finding my eligibility and logging me it. so, I’ve not been able to fully test the above, though I do believe it to be correct.

6

Tinderbox has come a long way in its 24 years. Old query codes have been subsumed into action code and action code itself is significantly more powerful† than it was at outset.

Try the find(scope) operator (also see find(condition)). find() returns a List of all original notes and all aliases matching the query. So an action like this (not tested) ought to work:

// get a List of all containers of notes/aliases with the current note's name
var:list vListing = find($Name==$Name(that));
$MyList =;
vListing.each(anItem){
   $MyList += $Container(anItem);
}
// as notes/aliases can have the same name and be in the same container
// uncomment the next line to de-dupe the list
// $MyList = $MyList.unique();
// get a count of the size of the above list
$MyNumber = $MyList.count();
// add these attributes to the current note's Displayed Attributes
$DisplayedAttributes +=["MyList";'MyNumber"];

†. Compare early aTbRef (v2.3.4 baseline) with the current one (v10.0.0 baseline)

7

There is a lot to unpack here. It feels like you are relying heavily on the container concept, which is useful, but can also be limiting. I believe you can achieve what you’re looking to accomplish with effective use of attributes, queries, and action code. You could also use templates to build your own views (or even publish your material) if the internal views don’t suit your needs.

Our next two weeks of meetups have themes, so we’ll be focusing on these themes(AI), but perhaps we can drill down on your project after that (make it one of the weekly themes.

8

Wow, I appreciate the offer. It is very generous. And you are likely correct. And I also figured there would be a more complex method to accomplish my ends “more effectively”. But this means a fairly high learning curve for a tool that isn’t terribly extensible from what I can tell. In other words, taking that time and effort isn’t going to scale anywhere else. Then I am left wondering if the better solution would be, if I were to want to dedicate that time and energy, another method that is portable and use another method of visualization that is again more extensible. The latter methods being open sourced, more widely used, etc.

I do enjoy niche and odd solutions or software, but perhaps as you suggest I was hoping that Tinderbox would more natively manage such a thing. And maybe it can. I will think about it. Someone sent me a few of the applicable chapters of the Tinderbox Way. It is a very finely written text! But devil is in the details.

9

Honestly, Tinderbox is the most extensible tool I found.

On this note of extensibility, I’ve found Tinderbox to be the most portable in learning. When you’re learning Tinderbox, you are NOT learning proprietary means and methods. You are learning your own mind, incremental formalization, and open standards—types of knowledge, mental constructs, digital languages and formats, data types and formats, PKM methods, channels, interfaces, coding conventions As they note, with great power comes great responsibility, and accountability. :).

Producing a view in Tinderbox starts with understanding what data (i.e., notes and attribute values) are needed to for that view, i.e., whether it is one of the 10 internal Tinderbox views, a template you build yourself or leveraged from someone else, or a visualization (e.g., an opensoruce or commercial JS librarary).

Here is a template you can look at that has all 10 internal Tinderbox views active:

5Cs TBX Comprehensive Tinderbox Views Overview
5Cs TBX Comprehensive Tinderbox Views Overview4178×2728 942 KB
.

10

:rofl:. Then again, I suppose it depends on one’s personal definition of “extensible”.

To give so some better perspective on what Tinderbox offers, in addition to The Tinderbox Way, I’d strongly recommend a skim through aTbRef (disclaimer: I’m its author). The later is a reference—and deliberately not a ‘how to’—but it ought to calibrate your current perception of ‘lack of extensibility’, not least as Tinderbox (and the Mac’s OS) has come a long way since early OS X†.

Tinderbox is highly flexible, not least in coping with the import/export inabilities of other apps. In the app itself there are all sorts of views. For instance, Attribute Browser view is new since your old use of the apps. AB view repays massively on use of info extracted into attributes—essentially the metadata you’ve generated ‘manually’ (by hand or via queries/action) or on import.

I think the perception of difficulty of use is driven by one/both of two things, heavy use of a particular app (thus creating the sense its foibles are generic norms) or using commodity software like MS Office that does a lot of things but mostly not very well in depth and often through un-reconfigurable ‘wizard’ type mechanisms. Most often people are looking to deeper tools such as Tinderbox because commodity tools either/both don’t support their needs or fail at scale. However …

… with much power comes much responsibility. We tend to assume the change in the app we use will ‘just’ makes things easy. Yet, in deep tools, the increased control we are seeking takes nuanced configuration, thus—at least at outset—‘extra’ thought and work.

Why? Because, the limit of commodity tools is they do an OK job at most things for most people. step outside that envelope and you may be a party of one. So, you (the app use) have to define/shape what you need. Tinderbox is a ‘toolbox for notes’. Few if any of us need or want to use every tool in the box but individually we hammer on some features really hard and in a manner no other person does.

Thus, use involves shifting one’s approach from “which button do I press” to “how best to record/structure my information to enable the perspective I want”. I find the same consideration apples with my Reference Manager (Bookends), collecting notes in DEVONthink, etc.

†. FWIW, I started tinkering with the Tinderbox demo in 2003 and finally dived in to using the app in early 2004 (v2.1.0), since which it has been my primary writing/thinking/noting space. My notes on trying to understand Tinderbox’s feature is what led to the initial aTbRef (at v2.3.4).

1 Like